Re: Bug: get EXT3-fs error Allocating block in system zone
Robert Hancock schrieb: Linus Torvalds wrote: On Mon, 10 Dec 2007, Marco Gatti wrote: I didn't compile completly. drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else Heh. That #else should be an #endif, of course. It is a bit strange that it still tries to do IO to high memory. Either the whole 64 bit capability thing in AHCI is broken, or the bounce buffering doesn't work right. Or maybe you tried the iommu=off without the original patch that tried to turn off 64-bit DMA? Linus From what I can see, it appears that iommu=off disables the IOMMU but doesn't actually do anything to prevent attempts to DMA above 4GB. If you try to map something over 4GB it just chokes with that mask overflow (in arch/x86/kernel/pci-nommu_64.c). The iommu=off option actually seems rather useless, as it's the default in the only case where it will actually work (no memory above 4GB).. Hi, finally got a BIOS update from Fujitsu-Siemens-Computers that solved that problem. Now it works with 2.6.24. if interesting I added dmesg here: Linux version 2.6.24 ([EMAIL PROTECTED]) (gcc version 4.1.1 (Gentoo 4.1.1-r3)) #2 SMP Thu Jan 31 19:38:52 CET 2008 Command line: root=/dev/sda3 udev BIOS-provided physical RAM map: BIOS-e820: - 0009c800 (usable) BIOS-e820: 0009c800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - df5b (usable) BIOS-e820: df5b - df5c4000 (ACPI data) BIOS-e820: df5c4000 - df5c7000 (ACPI NVS) BIOS-e820: df5c7000 - e000 (reserved) BIOS-e820: f800 - fc00 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) BIOS-e820: 0001 - 00020e00 (usable) BIOS-e820: 00020e00 - 00021000 (reserved) Entering add_active_range(0, 0, 156) 0 entries of 3200 used Entering add_active_range(0, 256, 914864) 1 entries of 3200 used Entering add_active_range(0, 1048576, 2154496) 2 entries of 3200 used end_pfn_map = 2162688 DMI present. ACPI: RSDP 000F7350, 0014 (r0 PTLTD ) ACPI: RSDT DF5BEDF9, 0058 (r1 PTLTDRSDT 6 LTP0) ACPI: FACP DF5C3AF3, 0074 (r1 FSC6 F4240) ACPI: DSDT DF5BEE51, 4CA2 (r1 FSCD2587/A16 MSFT 301) ACPI: FACS DF5C6FC0, 0040 ACPI: TCPA DF5C3B67, 0032 (r1 Phoeni x 6 TL 0) ACPI: _MAR DF5C3B99, 0030 (r1 Intel OEMDMAR 6 LOHR1) ACPI: SSDT DF5C3BC9, 007A (r1 FSCCST_CPU06 CSF1) ACPI: SSDT DF5C3C43, 007A (r1 FSCCST_CPU16 CSF1) ACPI: SSDT DF5C3CBD, 00B6 (r1 FSCPST_CPU06 CSF1) ACPI: SSDT DF5C3D73, 00B6 (r1 FSCPST_CPU16 CSF1) ACPI: SPCR DF5C3E29, 0050 (r1 PTLTD $UCRTBL$6 PTL 1) ACPI: MCFG DF5C3E79, 003C (r1 PTLTDMCFG 6 LTP0) ACPI: HPET DF5C3EB5, 0038 (r1 PTLTD HPETTBL 6 LTP1) ACPI: APIC DF5C3EED, 0068 (r1 PTLTD APIC 6 LTP0) ACPI: BOOT DF5C3F55, 0028 (r1 PTLTD $SBFTBL$6 LTP1) ACPI: ASF! DF5C3F7D, 0083 (r16 CETP CETP6 PTL 1) ACPI: DMI detected: Fujitsu Siemens No NUMA configuration found Faking a node at -00020e00 Entering add_active_range(0, 0, 156) 0 entries of 3200 used Entering add_active_range(0, 256, 914864) 1 entries of 3200 used Entering add_active_range(0, 1048576, 2154496) 2 entries of 3200 used Bootmem setup node 0 -00020e00 [e200-e21f] PMD -81000120 on node 0 [e220-e23f] PMD -81000160 on node 0 [e240-e25f] PMD -810001a0 on node 0 [e260-e27f] PMD -810001e0 on node 0 [e280-e29f] PMD -81000220 on node 0 [e2a0-e2bf] PMD -81000260 on node 0 [e2c0-e2df] PMD -810002a0 on node 0 [e2e0-e2ff] PMD -810002e0 on node 0 [e2000100-e200011f] PMD -81000320 on node 0 [e2000120-e200013f] PMD -81000360 on node 0 [e2000140-e200015f] PMD -810003a0 on node 0 [e2000160-e200017f] PMD -810003e0 on node 0 [e2000180-e200019f] PMD -81000420 on node 0 [e20001a0-e20001bf] PMD -81000460 on node 0 [e20001c0-e20001df] PMD -810004a0 on node 0 [e20001e0-e20001ff] PMD -810004e0 on node 0 [e2000200-e200021f] PMD -81000520 on node 0 [e2000220-e200023f]
Re: Bug: get EXT3-fs error Allocating block in system zone
Linus Torvalds schrieb: On Sun, 9 Dec 2007, Robert Hancock wrote: The obvious suspect with a filesystem problem would be the disk controller driver, AHCI here. However, the controller appears to set the flag to indicate that it supports 64-bit DMA, so it should be fine, unless it lies of course (which we know that ATI SB600 chipset does, but I don't believe Intel is known to). Could still be a DMA mapping bug that only shows up when IOMMU is used. However, AHCI is a pretty well tested driver.. AHCI is a pretty well tested driver, but 99%+ of all testers still tend to have less than 4GB of memory. So I do *not* believe that the highmem bits are all that well tested at all. Can somebody who knows the driver send Marco a test-patch to just limit DMA to the low 32 bits, and then Marco can at least verify that yes, that that it. While it looks like DMA problems, there could obviously be some other subtle issue with big-memory machines (ie the PCI allocations etc tend to change too!) Linus Hello, I tried clearing all BIOS settings to standard. So s-ata controller does p-ata emulation legacy. It seems to use ata_piix. Some errors occurs in dmesg, see bellow. But everything seems to work fine with it. No ext3 issues. On the other hand, the I/O is very low (4.2 MB/s) in comparison to ahci. Maybe this can give us a hint for problems in ahci and 64-bit dma. Cheers, Marco -SNIP- Linux version 2.6.23.11 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)) #2 SMP Mon Dec 17 19:54:18 CET 2007 Command line: root=/dev/hdd3 udev BIOS-provided physical RAM map: BIOS-e820: - 0009d800 (usable) BIOS-e820: 0009d800 - 000a (reserved) BIOS-e820: 000ce000 - 000d (reserved) BIOS-e820: 000e - 0010 (reserved) BIOS-e820: 0010 - df5c (usable) BIOS-e820: df5c - df5c8000 (ACPI data) BIOS-e820: df5c8000 - df5cb000 (ACPI NVS) BIOS-e820: df5cb000 - df70 (reserved) BIOS-e820: df80 - e010 (reserved) BIOS-e820: f800 - fc00 (reserved) BIOS-e820: fec0 - fec1 (reserved) BIOS-e820: fee0 - fee01000 (reserved) BIOS-e820: ffb0 - 0001 (reserved) BIOS-e820: 0001 - 00021a00 (usable) BIOS-e820: 00021a00 - 00021c00 (reserved) Entering add_active_range(0, 0, 157) 0 entries of 3200 used Entering add_active_range(0, 256, 914880) 1 entries of 3200 used Entering add_active_range(0, 1048576, 2203648) 2 entries of 3200 used end_pfn_map = 2211840 DMI present. ACPI: RSDP 000F7240, 0014 (r0 PTLTD ) ACPI: RSDT DF5C2D9F, 0058 (r1 PTLTDRSDT 6 LTP0) ACPI: FACP DF5C7AF3, 0074 (r1 FSC6 F4240) ACPI: DSDT DF5C2DF7, 4CFC (r1 FSCD2587/A16 MSFT 301) ACPI: FACS DF5CAFC0, 0040 ACPI: TCPA DF5C7B67, 0032 (r1 Phoeni x 6 TL 0) ACPI: _MAR DF5C7B99, 0030 (r1 Intel OEMDMAR 6 LOHR1) ACPI: SSDT DF5C7BC9, 007A (r1 FSCCST_CPU06 CSF1) ACPI: SSDT DF5C7C43, 007A (r1 FSCCST_CPU16 CSF1) ACPI: SSDT DF5C7CBD, 00B6 (r1 FSCPST_CPU06 CSF1) ACPI: SSDT DF5C7D73, 00B6 (r1 FSCPST_CPU16 CSF1) ACPI: SPCR DF5C7E29, 0050 (r1 PTLTD $UCRTBL$6 PTL 1) ACPI: MCFG DF5C7E79, 003C (r1 PTLTDMCFG 6 LTP0) ACPI: HPET DF5C7EB5, 0038 (r1 PTLTD HPETTBL 6 LTP1) ACPI: APIC DF5C7EED, 0068 (r1 PTLTD APIC 6 LTP0) ACPI: BOOT DF5C7F55, 0028 (r1 PTLTD $SBFTBL$6 LTP1) ACPI: ASF! DF5C7F7D, 0083 (r16 CETP CETP6 PTL 1) No NUMA configuration found Faking a node at -00021a00 Entering add_active_range(0, 0, 157) 0 entries of 3200 used Entering add_active_range(0, 256, 914880) 1 entries of 3200 used Entering add_active_range(0, 1048576, 2203648) 2 entries of 3200 used Bootmem setup node 0 -00021a00 Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 2203648 Movable zone start PFN for each node early_node_map[3] active PFN ranges 0:0 - 157 0: 256 - 914880 0: 1048576 - 2203648 On node 0 totalpages: 2069853 DMA zone: 56 pages used for memmap DMA zone: 1459 pages reserved DMA zone: 2482 pages, LIFO batch:0 DMA32 zone: 14280 pages used for memmap DMA32 zone: 896504 pages, LIFO batch:31 Normal zone: 15792 pages used for memmap Normal zone: 1139280 pages, LIFO batch:31 Movable zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x1008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Re: Bug: get EXT3-fs error Allocating block in system zone
AHCI is a pretty well tested driver, but 99%+ of all testers still tend to have less than 4GB of memory. So I do *not* believe that the highmem bits are all that well tested at all. Lab tested well and we pretty rapidly found the problems with non Intel AHCI that had 4GB cases. dmesg, see bellow. But everything seems to work fine with it. No ext3 issues. On the other hand, the I/O is very low (4.2 MB/s) in comparison to ahci. Maybe this can give us a hint for problems in ahci and 64-bit dma. 4.2MB/sec is abnormally low. scsi0 : ata_piix scsi1 : ata_piix ata1: SATA max UDMA/133 cmd 0x00011cc0 ctl 0x00011cb6 bmdma 0x00011c60 irq 22 ata2: SATA max UDMA/133 cmd 0x00011cb8 ctl 0x00011cb2 bmdma 0x00011c68 irq 22 No devices. The messages here don't make any sense at all. Adding 284k swap on /dev/hdd2. Priority:-1 extents:1 across:284k ADDRCONF(NETDEV_UP): eth0: link is not ready And in fact you are using /dev/hda so you are not using the ata_piix driver at all but something like the IDE legacy mode PIO driver - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
Linus Torvalds schrieb: On Mon, 10 Dec 2007, Marco Gatti wrote: I didn't compile completly. drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else Heh. That #else should be an #endif, of course. It is a bit strange that it still tries to do IO to high memory. Either the whole 64 bit capability thing in AHCI is broken, or the bounce buffering doesn't work right. Or maybe you tried the iommu=off without the original patch that tried to turn off 64-bit DMA? Hello, I tried latest kernels 2.6.23.11 and 2.6.24-rc5-git3. No change, same issues. The NCQ fixes doesn't affect any 64-bit dma issues with big mem. Marco - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Responding to 2 thread 2.6.23.8 - Hang with sata_mv (7042)... AND Bug: get EXT3-fs error Allocating block in system zone
I am a little confused as to exactly what thread I am to respond to and/or what requests...but lets try this and see if I get close? I have the far below mentioned hardware/configuration (flat 4Gig of DDR mem (0x0_000_ to 0x1_000_)...PPC/8548E - 36bit addressing As can be seen below - Mark has asked me try patching my sata_mv (and scsi_lib) with some patches from the second thread in subject: 1) Disable 64bit DMA in sata_mv (equivalent of the CAP_64 for AHCI) and disabling the bounce: 2) Disable queue bounce limit in drivers/scsi/scsi_lib.c +#if 0 blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost)); +#endif Mark had already asked me to try #1 a while back - and that didn't work. So, I tried #2 - and now it doesn't hang for me went writing a large File (which was my error condition)... So, as Linux suggested in his email, it looks like something is wrong in the bounce buffering? What - somebody will have to look into this further... Is that enough info Mark - let me know what you else you want me to try with my setup... Tom -Original Message- From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 11:44 AM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; [EMAIL PROTECTED] Subject: Re: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat 4Gig (no holes) Memory Morrison, Tom wrote: .. To re-state the problem Hardware/Configuration: MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 2.6.23.8 (using PHYS_64BIT PTE_64BIT - for 36 bit addressing MSI is NOT compiled in) Flat 4Gig Memory Map (no holes - 0 - 0x0__ defined - special low reserve memory is also used) Local Bus PCI Express IOMem mapped to unique space in 0xC__ with extensions to the ioremap routines to create the appropriate requested physical address... This is (and should be) transparent to the requesting function that calls ioremap. 2 SATA hard drives connected. To recreate: Write a large file (now greater than 310Mbytes) - hangs and soft lockup is detected by kernel - no useful info in stack trace... Of interest: a) Replace sata_mv.c - with the 'old' Marvell's reference driver and it works perfectly!! b) Also, sata_mv works perfectly in all conditions - if we boot with less than the ~3750M from the command line (which I note is ~below where its PEX IOmemory space is located). .. Tom: could you please try and follow the recent thread here (linux-ide) entitled Bug: get EXT3-fs error Allocating block in system zone . Somebody there has a similar problem on x86-32 with RAM above 4GB using a standard AHCI SATA controller. Jens has posted a couple of debugging patches there to try and isolate things. (patches attached here for convenience, though you'll have to modify/hack the first one for sata_mv instead of ahci). -ml - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Responding to 2 thread 2.6.23.8 - Hang with sata_mv (7042)... AND Bug: get EXT3-fs error Allocating block in system zone
Morrison, Tom wrote: I am a little confused as to exactly what thread I am to respond to and/or what requests...but lets try this and see if I get close? I have the far below mentioned hardware/configuration (flat 4Gig of DDR mem (0x0_000_ to 0x1_000_)...PPC/8548E - 36bit addressing As can be seen below - Mark has asked me try patching my sata_mv (and scsi_lib) with some patches from the second thread in subject: 1) Disable 64bit DMA in sata_mv (equivalent of the CAP_64 for AHCI) and disabling the bounce: 2) Disable queue bounce limit in drivers/scsi/scsi_lib.c +#if 0 blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost)); +#endif Mark had already asked me to try #1 a while back - and that didn't work. So, I tried #2 - and now it doesn't hang for me went writing a large File (which was my error condition)... So, as Linus suggested in his email, it looks like something is wrong in the bounce buffering? What - somebody will have to look into this further... .. That's a bit strange, actually.. because you said that this system does not have any RAM at any addresses above 0x. The physical RAM in this system is supposedly from 0 - 0x (4Gbytes). -Original Message- From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Monday, December 10, 2007 11:44 AM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; [EMAIL PROTECTED] Subject: Re: Revisiting - 2.6.23.8 - Hang with sata_mv (7042) + Flat 4Gig (no holes) Memory Morrison, Tom wrote: .. To re-state the problem Hardware/Configuration: MPC8548E with a 7042 (rev 2 - connected internal via a PEX switch) 2.6.23.8 (using PHYS_64BIT PTE_64BIT - for 36 bit addressing MSI is NOT compiled in) Flat 4Gig Memory Map (no holes - 0 - 0x0__ defined - special low reserve memory is also used) Local Bus PCI Express IOMem mapped to unique space in 0xC__ with extensions to the ioremap routines to create the appropriate requested physical address... This is (and should be) transparent to the requesting function that calls ioremap. 2 SATA hard drives connected. To recreate: Write a large file (now greater than 310Mbytes) - hangs and soft lockup is detected by kernel - no useful info in stack trace... Of interest: a) Replace sata_mv.c - with the 'old' Marvell's reference driver and it works perfectly!! b) Also, sata_mv works perfectly in all conditions - if we boot with less than the ~3750M from the command line (which I note is ~below where its PEX IOmemory space is located). .. Tom: could you please try and follow the recent thread here (linux-ide) entitled Bug: get EXT3-fs error Allocating block in system zone . Somebody there has a similar problem on x86-32 with RAM above 4GB using a standard AHCI SATA controller. Jens has posted a couple of debugging patches there to try and isolate things. (patches attached here for convenience, though you'll have to modify/hack the first one for sata_mv instead of ahci). -ml - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Responding to 2 thread 2.6.23.8 - Hang with sata_mv (7042)... AND Bug: get EXT3-fs error Allocating block in system zone
Correct, it has a flat memory map 0-0x I don't make this stuff up and I checked it 3 times (with without this set (#if 0 #if 1) - just to make sure I don't have something else weird going on... I'll send you privately my sata_mv.c - so you can inspect that yourself (only custom thing is the EDMA buffers hi/low buffers are set to point to the physical PCI space which is way up in 0xC__ space... tom -Original Message- From: Mark Lord [mailto:[EMAIL PROTECTED] Sent: Tuesday, December 11, 2007 12:42 PM To: Morrison, Tom Cc: Jeff Garzik; linux-ide@vger.kernel.org; Tejun Heo; [EMAIL PROTECTED] Subject: Re: Responding to 2 thread 2.6.23.8 - Hang with sata_mv (7042)... AND Bug: get EXT3-fs error Allocating block in system zone Morrison, Tom wrote: snip results that worked That's a bit strange, actually.. because you said that this system does not have any RAM at any addresses above 0x. The physical RAM in this system is supposedly from 0 - 0x (4Gbytes). snip original question - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
Linus Torvalds wrote: On Sun, 9 Dec 2007, Robert Hancock wrote: The obvious suspect with a filesystem problem would be the disk controller driver, AHCI here. However, the controller appears to set the flag to indicate that it supports 64-bit DMA, so it should be fine, unless it lies of course (which we know that ATI SB600 chipset does, but I don't believe Intel is known to). Could still be a DMA mapping bug that only shows up when IOMMU is used. However, AHCI is a pretty well tested driver.. AHCI is a pretty well tested driver, but 99%+ of all testers still tend to have less than 4GB of memory. So I do *not* believe that the highmem bits are all that well tested at all. Can somebody who knows the driver send Marco a test-patch to just limit DMA to the low 32 bits, and then Marco can at least verify that yes, that that it. While it looks like DMA problems, there could obviously be some other subtle issue with big-memory machines (ie the PCI allocations etc tend to change too!) .. We have another outstanding bug report of a Marvell chipset being used in a funky 32-bit PPC situation with memory above the 4GB mark. Possibly related, possibly not. The Marvell SATA driver is still VERY EXPERIMENTAL right now, missing some errata and stuff. This should improve over the next few months. Cheers - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
Mark Lord schrieb: AHCI is a pretty well tested driver, but 99%+ of all testers still tend to have less than 4GB of memory. So I do *not* believe that the highmem bits are all that well tested at all. Can somebody who knows the driver send Marco a test-patch to just limit DMA to the low 32 bits, and then Marco can at least verify that yes, that that it. While it looks like DMA problems, there could obviously be some other subtle issue with big-memory machines (ie the PCI allocations etc tend to change too!) .. We have another outstanding bug report of a Marvell chipset being used in a funky 32-bit PPC situation with memory above the 4GB mark. Possibly related, possibly not. The Marvell SATA driver is still VERY EXPERIMENTAL right now, missing some errata and stuff. This should improve over the next few months. Hello, I don't have a Marvell chipset. I didn't compiled in this. I have a Intel Corporation PT IDER Controller and an intel matrix storage controller. So I think it doesn't concern my case... Greets - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
Jens Axboe schrieb: Hello Jens, Thanks for help. I just applied the patch. Unfortunately it doesn't work. Can you try and additionally boot with iommu=off as a boot parameter? Yes. This is the end of getting any sata devices. See screenshots for errors. It continued untill ata4. At the end no root device was found. Hmm, even though the address is set to 0x we still seem to receive requests outside that range. Lets assume it's the scsi logic, can you test this? IOW, patch + iommu=off + this patch. I probably wont see any more mails tonight, we can continue this tomorrow (or someone else can step in, whatever comes first :-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 2faced6..769ce3a 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1572,7 +1572,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost, #endif blk_queue_max_sectors(q, shost-max_sectors); +#if 0 blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost)); +#else blk_queue_segment_boundary(q, shost-dma_boundary); if (!shost-use_clustering) I applied the path. Got Hunk #1 succeeded at 1562 with fuzz 2 (offset -10 lines). I didn't compile completly. drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else make[2]: *** [drivers/scsi/scsi_lib.o] Error 1 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
On Mon, Dec 10 2007, Marco Gatti wrote: Jens Axboe schrieb: Hello Jens, Thanks for help. I just applied the patch. Unfortunately it doesn't work. Can you try and additionally boot with iommu=off as a boot parameter? Yes. This is the end of getting any sata devices. See screenshots for errors. It continued untill ata4. At the end no root device was found. Hmm, even though the address is set to 0x we still seem to receive requests outside that range. Lets assume it's the scsi logic, can you test this? IOW, patch + iommu=off + this patch. I probably wont see any more mails tonight, we can continue this tomorrow (or someone else can step in, whatever comes first :-) diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c index 2faced6..769ce3a 100644 --- a/drivers/scsi/scsi_lib.c +++ b/drivers/scsi/scsi_lib.c @@ -1572,7 +1572,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host *shost, #endif blk_queue_max_sectors(q, shost-max_sectors); +#if 0 blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost)); +#else blk_queue_segment_boundary(q, shost-dma_boundary); if (!shost-use_clustering) I applied the path. Got Hunk #1 succeeded at 1562 with fuzz 2 (offset -10 lines). I didn't compile completly. drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else make[2]: *** [drivers/scsi/scsi_lib.o] Error 1 make[1]: *** [drivers/scsi] Error 2 make: *** [drivers] Error 2 Doh sorry, that #else wants to be an #endif -- Jens Axboe - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
On Mon, 10 Dec 2007, Marco Gatti wrote: I didn't compile completly. drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else Heh. That #else should be an #endif, of course. It is a bit strange that it still tries to do IO to high memory. Either the whole 64 bit capability thing in AHCI is broken, or the bounce buffering doesn't work right. Or maybe you tried the iommu=off without the original patch that tried to turn off 64-bit DMA? Linus - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
Linus Torvalds wrote: On Mon, 10 Dec 2007, Marco Gatti wrote: I didn't compile completly. drivers/scsi/scsi_lib.c:1565:1: error: unterminated #else Heh. That #else should be an #endif, of course. It is a bit strange that it still tries to do IO to high memory. Either the whole 64 bit capability thing in AHCI is broken, or the bounce buffering doesn't work right. Or maybe you tried the iommu=off without the original patch that tried to turn off 64-bit DMA? Linus From what I can see, it appears that iommu=off disables the IOMMU but doesn't actually do anything to prevent attempts to DMA above 4GB. If you try to map something over 4GB it just chokes with that mask overflow (in arch/x86/kernel/pci-nommu_64.c). The iommu=off option actually seems rather useless, as it's the default in the only case where it will actually work (no memory above 4GB).. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-ide in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
On Sun, Dec 09 2007, Linus Torvalds wrote:
On Sun, 9 Dec 2007, Robert Hancock wrote:
The obvious suspect with a filesystem problem would be the disk
controller driver, AHCI here. However, the controller appears to set the
flag to indicate that it supports 64-bit DMA, so it should be fine,
unless it lies of course (which we know that ATI SB600 chipset does, but
I don't believe Intel is known to).
Could still be a DMA mapping bug that only shows up when IOMMU is used.
However, AHCI is a pretty well tested driver..
AHCI is a pretty well tested driver, but 99%+ of all testers still tend to
have less than 4GB of memory. So I do *not* believe that the highmem bits
are all that well tested at all.
Can somebody who knows the driver send Marco a test-patch to just limit
DMA to the low 32 bits, and then Marco can at least verify that yes, that
that it. While it looks like DMA problems, there could obviously be some
other subtle issue with big-memory machines (ie the PCI allocations etc
tend to change too!)
Was just thinking that, this should do the trick. If this works, then we
can look at whether this is a hardware or iommu or block bouncing
(unlikely, would affect more people) bug.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 4688dbf..cad3cbc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -623,6 +623,9 @@ static void ahci_save_initial_config(struct pci_dev *pdev,
hpriv-saved_cap = cap = readl(mmio + HOST_CAP);
hpriv-saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL);
+ hpriv-saved_cap = ~HOST_CAP_64;
+ cap = ~HOST_CAP_64;
+
/* some chips have errata preventing 64bit use */
if ((cap HOST_CAP_64) (hpriv-flags AHCI_HFLAG_32BIT_ONLY)) {
dev_printk(KERN_INFO, pdev-dev,
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
On Sun, Dec 09 2007, Marco Gatti wrote:
Jens Axboe schrieb:
Was just thinking that, this should do the trick. If this works, then we
can look at whether this is a hardware or iommu or block bouncing
(unlikely, would affect more people) bug.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 4688dbf..cad3cbc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -623,6 +623,9 @@ static void ahci_save_initial_config(struct pci_dev
*pdev,
hpriv-saved_cap = cap = readl(mmio + HOST_CAP);
hpriv-saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL);
+hpriv-saved_cap = ~HOST_CAP_64;
+cap = ~HOST_CAP_64;
+
/* some chips have errata preventing 64bit use */
if ((cap HOST_CAP_64) (hpriv-flags AHCI_HFLAG_32BIT_ONLY)) {
dev_printk(KERN_INFO, pdev-dev,
Hello Jens,
Thanks for help. I just applied the patch. Unfortunately it doesn't work.
Can you try and additionally boot with iommu=off as a boot parameter?
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Bug: get EXT3-fs error Allocating block in system zone
Jens Axboe schrieb:
Was just thinking that, this should do the trick. If this works, then we
can look at whether this is a hardware or iommu or block bouncing
(unlikely, would affect more people) bug.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 4688dbf..cad3cbc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -623,6 +623,9 @@ static void ahci_save_initial_config(struct pci_dev *pdev,
hpriv-saved_cap = cap = readl(mmio + HOST_CAP);
hpriv-saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL);
+ hpriv-saved_cap = ~HOST_CAP_64;
+ cap = ~HOST_CAP_64;
+
/* some chips have errata preventing 64bit use */
if ((cap HOST_CAP_64) (hpriv-flags AHCI_HFLAG_32BIT_ONLY)) {
dev_printk(KERN_INFO, pdev-dev,
Hello Jens,
Thanks for help. I just applied the patch. Unfortunately it doesn't work.
dmesg:
Linux version 2.6.23.9 ([EMAIL PROTECTED]) (gcc version 4.1.2 (Gentoo 4.1.2
p1.0.2)) #4 SMP Mon Dec 10 20:39:59 CET 2007
Command line: root=/dev/sdb3 udev
BIOS-provided physical RAM map:
BIOS-e820: - 0009c800 (usable)
BIOS-e820: 0009c800 - 000a (reserved)
BIOS-e820: 000ce000 - 000d (reserved)
BIOS-e820: 000e - 0010 (reserved)
BIOS-e820: 0010 - df5c (usable)
BIOS-e820: df5c - df5c8000 (ACPI data)
BIOS-e820: df5c8000 - df5cb000 (ACPI NVS)
BIOS-e820: df5cb000 - df70 (reserved)
BIOS-e820: df80 - e010 (reserved)
BIOS-e820: f800 - fc00 (reserved)
BIOS-e820: fec0 - fec1 (reserved)
BIOS-e820: fee0 - fee01000 (reserved)
BIOS-e820: ffb0 - 0001 (reserved)
BIOS-e820: 0001 - 00021a00 (usable)
BIOS-e820: 00021a00 - 00021c00 (reserved)
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 914880) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 2203648) 2 entries of 3200 used
end_pfn_map = 2211840
DMI present.
ACPI: RSDP 000F7240, 0014 (r0 PTLTD )
ACPI: RSDT DF5C2D9F, 0058 (r1 PTLTDRSDT 6 LTP0)
ACPI: FACP DF5C7AF3, 0074 (r1 FSC6 F4240)
ACPI: DSDT DF5C2DF7, 4CFC (r1 FSCD2587/A16 MSFT 301)
ACPI: FACS DF5CAFC0, 0040
ACPI: TCPA DF5C7B67, 0032 (r1 Phoeni x 6 TL 0)
ACPI: _MAR DF5C7B99, 0030 (r1 Intel OEMDMAR 6 LOHR1)
ACPI: SSDT DF5C7BC9, 007A (r1 FSCCST_CPU06 CSF1)
ACPI: SSDT DF5C7C43, 007A (r1 FSCCST_CPU16 CSF1)
ACPI: SSDT DF5C7CBD, 00B6 (r1 FSCPST_CPU06 CSF1)
ACPI: SSDT DF5C7D73, 00B6 (r1 FSCPST_CPU16 CSF1)
ACPI: SPCR DF5C7E29, 0050 (r1 PTLTD $UCRTBL$6 PTL 1)
ACPI: MCFG DF5C7E79, 003C (r1 PTLTDMCFG 6 LTP0)
ACPI: HPET DF5C7EB5, 0038 (r1 PTLTD HPETTBL 6 LTP1)
ACPI: APIC DF5C7EED, 0068 (r1 PTLTD APIC 6 LTP0)
ACPI: BOOT DF5C7F55, 0028 (r1 PTLTD $SBFTBL$6 LTP1)
ACPI: ASF! DF5C7F7D, 0083 (r16 CETP CETP6 PTL 1)
No NUMA configuration found
Faking a node at -00021a00
Entering add_active_range(0, 0, 156) 0 entries of 3200 used
Entering add_active_range(0, 256, 914880) 1 entries of 3200 used
Entering add_active_range(0, 1048576, 2203648) 2 entries of 3200 used
Bootmem setup node 0 -00021a00
Zone PFN ranges:
DMA 0 - 4096
DMA324096 - 1048576
Normal1048576 - 2203648
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
0:0 - 156
0: 256 - 914880
0: 1048576 - 2203648
On node 0 totalpages: 2069852
DMA zone: 56 pages used for memmap
DMA zone: 1460 pages reserved
DMA zone: 2480 pages, LIFO batch:0
DMA32 zone: 14280 pages used for memmap
DMA32 zone: 896504 pages, LIFO batch:31
Normal zone: 15792 pages used for memmap
Normal zone: 1139280 pages, LIFO batch:31
Movable zone: 0 pages used for memmap
ACPI: PM-Timer IO Port: 0x1008
ACPI: Local APIC address 0xfee0
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled)
Processor #0 (Bootup-CPU)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled)
Processor #1
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0])
IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23
ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Setting APIC routing to flat
ACPI: HPET id: 0x base: 0xfed0
Using ACPI (MADT) for SMP configuration information
Re: Bug: get EXT3-fs error Allocating block in system zone
On Sun, Dec 09 2007, Marco Gatti wrote:
Jens Axboe schrieb:
On Sun, Dec 09 2007, Marco Gatti wrote:
Jens Axboe schrieb:
Was just thinking that, this should do the trick. If this works, then we
can look at whether this is a hardware or iommu or block bouncing
(unlikely, would affect more people) bug.
diff --git a/drivers/ata/ahci.c b/drivers/ata/ahci.c
index 4688dbf..cad3cbc 100644
--- a/drivers/ata/ahci.c
+++ b/drivers/ata/ahci.c
@@ -623,6 +623,9 @@ static void ahci_save_initial_config(struct pci_dev
*pdev,
hpriv-saved_cap = cap = readl(mmio + HOST_CAP);
hpriv-saved_port_map = port_map = readl(mmio + HOST_PORTS_IMPL);
+ hpriv-saved_cap = ~HOST_CAP_64;
+ cap = ~HOST_CAP_64;
+
/* some chips have errata preventing 64bit use */
if ((cap HOST_CAP_64) (hpriv-flags AHCI_HFLAG_32BIT_ONLY)) {
dev_printk(KERN_INFO, pdev-dev,
Hello Jens,
Thanks for help. I just applied the patch. Unfortunately it doesn't work.
Can you try and additionally boot with iommu=off as a boot parameter?
Yes. This is the end of getting any sata devices. See screenshots for
errors. It continued untill ata4. At the end no root device was found.
Hmm, even though the address is set to 0x we still seem to
receive requests outside that range. Lets assume it's the scsi logic,
can you test this? IOW, patch + iommu=off + this patch.
I probably wont see any more mails tonight, we can continue this
tomorrow (or someone else can step in, whatever comes first :-)
diff --git a/drivers/scsi/scsi_lib.c b/drivers/scsi/scsi_lib.c
index 2faced6..769ce3a 100644
--- a/drivers/scsi/scsi_lib.c
+++ b/drivers/scsi/scsi_lib.c
@@ -1572,7 +1572,9 @@ struct request_queue *__scsi_alloc_queue(struct Scsi_Host
*shost,
#endif
blk_queue_max_sectors(q, shost-max_sectors);
+#if 0
blk_queue_bounce_limit(q, scsi_calculate_bounce_limit(shost));
+#else
blk_queue_segment_boundary(q, shost-dma_boundary);
if (!shost-use_clustering)
--
Jens Axboe
-
To unsubscribe from this list: send the line unsubscribe linux-ide in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
