Re: Bug: get EXT3-fs error Allocating block in system zone
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 - 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
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
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
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
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) P
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
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-
