block highmem zero bounce v14
PATCH 1/1 block highmem zero bounce v14
Hi,
I've uploaded a new version of the patch that allows direct I/O to highmem memory without resorting to bouncing to lower memory. Changes since last time include:
- Sync pci64-2.4.10p4 with davem (me)
- Fix megaraid virt_to_bus on pci_alloc_consistent (!) (Arjan)
- Fix ide-dma not doing the right thing with private bh submissions that aren't necessarily b_page based (me)
- Fix ide-scsi scatter-gather highmem (me)
- Fix IDE+SCSI highmem enable bug (me)
- Limit I/O highmem enable messages a bit (me)
It's against 2.4.10-pre9 and can be found right here:
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.10-pre9/block-highmem-all-14
Signature · 1 line
Jens Axboe
Quoted 4 lines · Jens Axboe
It's against 2.4.10-pre9 and can be found right here:
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.10-pre9/block-highmem-all-14
Jens, what's your feeling about the stability of these things, especially wrt weird drivers?
Ie do you think this is really a 2.4.x thing, or early 2.5.x?
Linus
From: Linus Torvalds <[email protected]>
Date: Sun, 16 Sep 2001 14:48:32 -0700 (PDT)
Jens, what's your feeling about the stability of these things, especially wrt weird drivers?
Ie do you think this is really a 2.4.x thing, or early 2.5.x?
On my side of this work I feel that the 64-bit PCI dma infrastructure by itself is a safe merge in 2.4.11 or something like that.
Later,
David S. Miller
[email protected]
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Jens Axboe
It's against 2.4.10-pre9 and can be found right here:
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.10-pre9/block-highmem-all-14
Jens, what's your feeling about the stability of these things, especially wrt weird drivers?
One of the very first decisions I made wrt this patch was to make sure that weird/old drivers could keep on working exactly the way they do now and never have to worry about highmem stuff. That basically means enabling the stuff on a per-driver basis after it's considered safe. The can_dma_32 for SCSI and highmem for IDE flag serves that purpose. Stand alone block drivers just use blk_queue_bounce_limit to enable highmem I/O after blk_init_queue, if they don't they get highmem pages bounced as they are used too.
That leaves drivers that are 'different', stuff like ide-scsi for instance. I think I have most of these under control...
Quoted 1 line
Ie do you think this is really a 2.4.x thing, or early 2.5.x?
Most of it is really a cautious back port of the 2.5 stuff I've been working on, and with the above considerations it is/was meant as a 2.4 thing :-)
Signature · 1 line
Jens Axboe
Quoted 3 lines
Most of it is really a cautious back port of the 2.5 stuff I've been working on, and with the above considerations it is/was meant as a 2.4 thing :-)
So better deferred until 2.5, tried in 2.5 and backported to 2.4 IMHO
Alan
Quoted 5 lines · Alan Cox
Quoted 3 lines
Most of it is really a cautious back port of the 2.5 stuff I've been working on, and with the above considerations it is/was meant as a 2.4 thing :-)
So better deferred until 2.5, tried in 2.5 and backported to 2.4 IMHO
Maybe. At least the first thing I would like is for the pci64 patch to be merged in 2.4. That should be very doable without risking breakage. When that is done it's easier to see what the block-highmem patch does. And I believe that we _can_ merge it in 2.4 without a 2.5 trial, it's really not that intrusive.
Signature · 1 line
Jens Axboe
Quoted 10 lines · David S. Miller
From: Linus Torvalds <[email protected]>
Date: Sun, 16 Sep 2001 14:48:32 -0700 (PDT)Jens, what's your feeling about the stability of these things, especially wrt weird drivers?
Ie do you think this is really a 2.4.x thing, or early 2.5.x?
On my side of this work I feel that the 64-bit PCI dma infrastructure by itself is a safe merge in 2.4.11 or something like that.
I agree, and seriously hope that Linus will merge the pci64 patch in the first 2.4.11-pre's. Then we can start looking at the block highmem patch.
Signature · 1 line
Jens Axboe
Quoted 6 lines · Jens Axboe
Quoted 5 lines · Linus Torvalds
Quoted 3 lines · Jens Axboe
It's against 2.4.10-pre9 and can be found right here:
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.10-pre9/block-highmem-all-14
Jens, what's your feeling about the stability of these things, especially wrt weird drivers?
One of the very first decisions I made wrt this patch was to make sure that weird/old drivers could keep on working exactly the way they do now and never have to worry about highmem stuff.
unfortionatly, so far both megaraid and the 3ware driver broke. Megaraid is easily fixable, but still. It shows that this patch is not without risk...
Quoted 6 lines
Quoted 3 lines
One of the very first decisions I made wrt this patch was to make sure that weird/old drivers could keep on working exactly the way they do now and never have to worry about highmem stuff.
unfortionatly, so far both megaraid and the 3ware driver broke. Megaraid is easily fixable, but still. It shows that this patch is not without risk...
I am not sure the megaraid breakage is from that patch at the moment. There is another 2.4.10pre change which seems to alter the request size limits for the megaraid. I don't know where this came from but it was not discussed on the megaraid list or posted here by any megaraid folks. Given the megaraid firmware is umm "fragile" anything that changes what we feed it really does want to go through the AMI/Dell people.
A secondary issue is that 64bit DMA is only correctly handled by certain MegaRAID firmware. The checks for this are not correct until 1.1.17a-ac in some cases (eg HP rebadged board with H.01.07 and H.01.08 firmware)
Alan
spurious interrupt with ac kernel but not with vanilla 2.4.9
HI,
I noticed that on the abit kt7A MBs that i have, with via KT133A chipset, after i installed the kernel 2.4.9-ac10 (ac11 and 12 as well), at boot i get this message,
Sep 21 11:52:11 DarkStar kernel: ice 00:0b.0 Sep 21 11:52:11 DarkStar kernel: spurious 8259A interrupt: IRQ7. immediatelly before scsi adaptec detection and inizzializzation.
doing a cat /proc/interrupt I can read
ERR: 1
As many people I have parport on irq 7, and the parport simply works anyway (tested with a printer).
I was thinking to an HW problem, but with vanilla 2.4.9 kernel I do not get this message, and the code in arch/i386/kernel/i8259.c that should detect this spurious interrup is just the same on those two kernels. Changes are related to X86_IO_APIC, and I think this is the reason why this spurious interrupt is detected, but I would like to know if i should think I have some HW problem going on that stardard kernels do not detect.
bests
Luigi
Re: spurious interrupt with ac kernel but not with vanilla 2.4.9
Quoted 7 lines
I noticed that on the abit kt7A MBs that i have, with via KT133A chipset, after i installed the kernel 2.4.9-ac10 (ac11 and 12 as well), at boot i get this message,
Sep 21 11:52:11 DarkStar kernel: ice 00:0b.0 Sep 21 11:52:11 DarkStar kernel: spurious 8259A interrupt: IRQ7. immediatelly before scsi adaptec detection and inizzializzation.
Thats indicating an IRQ appeared and vanished. IRQ 7 is the IRQ that happens to occur for this.
Quoted 6 lines
I was thinking to an HW problem, but with vanilla 2.4.9 kernel I do not get this message, and the code in
arch/i386/kernel/i8259.cthat should detect this spurious interrup is just the same on those two kernels. Changes are related toX86_IO_APIC, and I think this is the reason why this spurious interrupt is detected, but I would like to know if i should think I have some HW problem going on that stardard kernels do not detect.
The APIC only applies to multiprocessor boxes unless you are building with uniprocessor apic support. Build a non SMP kernel without apic support and let me know what that does
Re: spurious interrupt with ac kernel but not with vanilla 2.4.9
Quoted 18 lines · Alan Cox
Quoted 7 lines
I noticed that on the abit kt7A MBs that i have, with via KT133A chipset, after i installed the kernel 2.4.9-ac10 (ac11 and 12 as well), at boot i get this message,
Sep 21 11:52:11 DarkStar kernel: ice 00:0b.0 Sep 21 11:52:11 DarkStar kernel: spurious 8259A interrupt: IRQ7. immediatelly before scsi adaptec detection and inizzializzation.Thats indicating an IRQ appeared and vanished. IRQ 7 is the IRQ that happens to occur for this.
Quoted 6 lines
I was thinking to an HW problem, but with vanilla 2.4.9 kernel I do not get this message, and the code in
arch/i386/kernel/i8259.cthat should detect this spurious interrup is just the same on those two kernels. Changes are related toX86_IO_APIC, and I think this is the reason why this spurious interrupt is detected, but I would like to know if i should think I have some HW problem going on that stardard kernels do not detect.
Quoted 3 lines
The APIC only applies to multiprocessor boxes unless you are building with uniprocessor apic support. Build a non SMP kernel without apic support and let me know what that does
yes, i was using a non SMP kernel with both apic and io_apic support enabled.
actally:
with APIC support
and
without IO_APIC support
I do not get this message again, but I am so sorry, because my processor has integrated APIC support.
I just made another test on a dual Athlon 1200 Mhz per CPU on an MB with AMD chipset, and here this problem does not appear.
Thanx
Luigi
Re: spurious interrupt with ac kernel but not with vanilla 2.4.9
Quoted 6 lines
Quoted 3 lines
The APIC only applies to multiprocessor boxes unless you are building with uniprocessor apic support. Build a non SMP kernel without apic support and let me know what that does
yes, i was using a non SMP kernel with both apic and
io_apicsupport enabled.
Ok.
Quoted 8 lines
actally:
with APIC support
and
withoutIO_APICsupportI do not get this message again, but I am so sorry, because my processor has integrated APIC support.
Oh your configuration options should have worked. Its more a case of working out now why the didnt. Knowing that it is uniprocessor apic triggered is a help there
Re: spurious interrupt with ac kernel but not with vanilla 2.4.9
Quoted 4 lines · Alan Cox
Oh your configuration options should have worked. Its more a case of working out now why the didnt. Knowing that it is uniprocessor apic triggered is a help there
OK, I am available for any kind of test. (this is my personal station, not a production server).
Luigi
Re: spurious interrupt with ac kernel but not with vanilla 2.4.9
In reply to Luigi GenoniQuoted 7 lines · Alan Cox
Quoted 2 lines
yes, i was using a non SMP kernel with both apic and
io_apicsupport enabled.Ok.
Oh your configuration options should have worked. Its more a case of working out now why the didnt. Knowing that it is uniprocessor apic triggered is a help there
I have been getting these spurious interrupt messages for a long time now with the UP_APIC option enabled. Using interrupt-heavy things like catting logs on a vesafb console are a pretty reliable way to trigger it.
This is on a bog-standard UP box with no IO-APIC.
It doesn't seem to affect stability at all.
regards
john
p.s. what's going on with the config options ? linus pre12 seems to get rid of the APIC fake zero page thing and enable the local APIC on UP properly, but the config options don't seem to have changed like in the ac tree
Signature · 1 line
"If you're not part of the problem, you're part of the problem space."
Quoted 12 lines · Arjan van de Ven
Quoted 11 lines · Jens Axboe
Quoted 9 lines · Linus Torvalds
Quoted 4 lines · Jens Axboe
It's against 2.4.10-pre9 and can be found right here:
*.kernel.org/pub/linux/kernel/people/axboe/patches/2.4.10-pre9/block-highmem-all-14
Jens, what's your feeling about the stability of these things, especially wrt weird drivers?
Quoted 6 lines
Quoted 3 lines
One of the very first decisions I made wrt this patch was to make sure that weird/old drivers could keep on working exactly the way they do now and never have to worry about highmem stuff.
unfortionatly, so far both megaraid and the 3ware driver broke. Megaraid is easily fixable, but still. It shows that this patch is not without risk...
megaraid broke because can_dma_32 was enabled by mistake.
jens
Quoted 1 line · Jens Axboe
megaraid broke because
can_dma_32was enabled by mistake.
Nope; without that it was still bust.
Megaraid broke (and 3ware most likely as well) because it had broken code for the "only 1 scatter gather element" case....
Quoted 3 lines
Nope; without that it was still bust.
Megaraid broke (and 3ware most likely as well) because it had broken code for the "only 1 scatter gather element" case....
Yet more evidence that it belongs in 2.5 first. Auditing every scsi driver for that error (and I bet someone had it first and it was copied..) is a big job
Quoted 7 lines · Alan Cox
Quoted 3 lines
Nope; without that it was still bust.
Megaraid broke (and 3ware most likely as well) because it had broken code for the "only 1 scatter gather element" case....Yet more evidence that it belongs in 2.5 first. Auditing every scsi driver for that error (and I bet someone had it first and it was copied..) is a big job
Somehow I knew you would say that, Alan.
jens
Quoted 5 lines
Quoted 3 lines
Yet more evidence that it belongs in 2.5 first. Auditing every scsi driver for that error (and I bet someone had it first and it was copied..) is a big job
Somehow I knew you would say that, Alan.
I spent a lot of my time debugging driver code, and if its in one driver, its normally in ten. Look at the last serial driver fixup for example
Alan
Quoted 8 lines · Alan Cox
Quoted 5 lines
Quoted 3 lines
Yet more evidence that it belongs in 2.5 first. Auditing every scsi driver for that error (and I bet someone had it first and it was copied..) is a big job
Somehow I knew you would say that, Alan.
I spent a lot of my time debugging driver code, and if its in one driver, its normally in ten. Look at the last serial driver fixup for example
That's true. However, as Arjan pointed out I can fix this up not to rely on drivers working as-is for the new single entry sg behaviour. This is already the case for regular block drivers.
Jens
Em Sat, Sep 22, 2001 at 05:41:46PM +0100, Alan Cox escreveu:
Quoted 4 lines
Quoted 1 line
Somehow I knew you would say that, Alan.
I spent a lot of my time debugging driver code, and if its in one driver, its normally in ten. Look at the last serial driver fixup for example
I got some guys learning to hack the kernel, first task? write a multiserial driver (new one for an old .br produced card by cyclades) that doesn't uses BHs neither cli/sti, next task? You bet... 8) 2.5, were are ya? come on... ;)
- Arnaldo
Quoted 6 lines · Arjan van de Ven
Quoted 1 line · Jens Axboe
megaraid broke because
can_dma_32was enabled by mistake.Nope; without that it was still bust.
Megaraid broke (and 3ware most likely as well) because it had broken code for the "only 1 scatter gather element" case....
Ah ok, that's actually a case I hadn't counted on being buggy in drivers. Typical, drive code sucks :-)
jens