Re: skge error; hangs w/ hardware memory hole
On Sunday 23 July 2006 08:32, Anthony DeRobertis wrote:
> Andreas Kleen wrote:
>
> >
> > You need to use iommu=soft swiotlb=force
> >
> > The standard IOMMU is also broken on VIA, but forced swiotlb should
> > work.
>
> Didn't work :-(
swiotlb=force is unfortunately broken right now.
But which this patch it should work. Does it?
-Andi
Test patch only: disable DMA over 4GB
Index: linux-2.6.17-work/arch/x86_64/kernel/pci-dma.c
===
--- linux-2.6.17-work.orig/arch/x86_64/kernel/pci-dma.c
+++ linux-2.6.17-work/arch/x86_64/kernel/pci-dma.c
@@ -202,7 +202,7 @@ int dma_set_mask(struct device *dev, u64
{
if (!dev->dma_mask || !dma_supported(dev, mask))
return -EIO;
- *dev->dma_mask = mask;
+ *dev->dma_mask = mask & 0x;
return 0;
}
EXPORT_SYMBOL(dma_set_mask);
-
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
Anthony DeRobertis wrote: Andreas Kleen wrote: You need to use iommu=soft swiotlb=force The standard IOMMU is also broken on VIA, but forced swiotlb should work. Didn't work :-( Excepts from the log: Bootdata ok (command line is BOOT_IMAGE=2.6.17-1-smp ro root=902 iommu=soft swiotlb=force single) ... skge eth0: enabling interface skge :00:0a.0: PCI error cmd=0x117 status=0x22b0 skge unable to clear error (so ignoring them) skge eth0: Link is up at 1000 Mbps, full duplex, flow control tx and rx And then the NIC didn't work. Attaching full dmesg. Bootdata ok (command line is BOOT_IMAGE=2.6.17-1-smp ro root=902 iommu=soft swiotlb=force single) Linux version 2.6.17-1-amd64-k8-smp (Debian 2.6.17-2) ([EMAIL PROTECTED]) (gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)) #1 SMP Thu Jun 29 23:03:09 CEST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - d7fb (usable) BIOS-e820: d7fb - d7fc (ACPI data) BIOS-e820: d7fc - d7ff (ACPI NVS) BIOS-e820: d7ff - d800 (reserved) BIOS-e820: ff78 - 0001 (reserved) BIOS-e820: 0001 - 00012400 (usable) DMI 2.3 present. ACPI: RSDP (v002 ACPIAM) @ 0x000fa7c0 ACPI: XSDT (v001 A M I OEMXSDT 0x1506 MSFT 0x0097) @ 0xd7fb0100 ACPI: FADT (v003 A M I OEMFACP 0x1506 MSFT 0x0097) @ 0xd7fb0290 ACPI: MADT (v001 A M I OEMAPIC 0x1506 MSFT 0x0097) @ 0xd7fb0390 ACPI: OEMB (v001 A M I OEMBIOS 0x1506 MSFT 0x0097) @ 0xd7fc0040 ACPI: DSDT (v001 A0036 A0036001 0x0001 MSFT 0x010d) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 00012400 NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -00012400 On node 0 totalpages: 1014222 DMA zone: 2502 pages, LIFO batch:0 DMA32 zone: 866280 pages, LIFO batch:31 Normal zone: 145440 pages, LIFO batch:31 Looks like a VIA chipset. Disabling IOMMU. Override with "iommu=allowed" ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:3 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:3 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at dc00 (gap: d800:2778) SMP: Allowing 2 CPUs, 0 hotplug CPUs Built 1 zonelists Kernel command line: BOOT_IMAGE=2.6.17-1-smp ro root=902 iommu=soft swiotlb=force single Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Disabling vsyscall due to use of PM timer time.c: Using 3.579545 MHz WALL PM GTOD PM timer. time.c: Detected 2202.921 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x163a000 - 0x563a000 Memory: 3984540k/4784128k available (1870k kernel code, 143520k reserved, 820k data, 172k init) Calibrating delay using timer specific routine.. 4411.18 BogoMIPS (lpj=8822378) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0(2) -> Node 0 -> Core 0 Using local APIC timer interrupts. result 12516619 Detected 12.516 MHz APIC timer. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4405.96 BogoMIPS (lpj=8811936) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1/1(2) -> Node 0 -> Core 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff -82 cycles, maxerr 637 cycles) Brought up 2 CPUs testing NMI watchdog ... OK. migration_cost=632 checking if image is initramfs... it is Freeing initrd memory: 1348k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Subsystem revision 20060127 ACPI: Interpreter enabled ACPI: Using IOAPIC f
Re: skge error; hangs w/ hardware memory hole
Andreas Kleen wrote: > > You need to use iommu=soft swiotlb=force > > The standard IOMMU is also broken on VIA, but forced swiotlb should > work. Didn't work :-( Excepts from the log: Bootdata ok (command line is BOOT_IMAGE=2.6.17-1-smp ro root=902 iommu=soft swiotlb=force single) ... skge eth0: enabling interface skge :00:0a.0: PCI error cmd=0x117 status=0x22b0 skge unable to clear error (so ignoring them) skge eth0: Link is up at 1000 Mbps, full duplex, flow control tx and rx And then the NIC didn't work. Attaching full dmesg. Bootdata ok (command line is BOOT_IMAGE=2.6.17-1-smp ro root=902 iommu=soft swiotlb=force single) Linux version 2.6.17-1-amd64-k8-smp (Debian 2.6.17-2) ([EMAIL PROTECTED]) (gcc version 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)) #1 SMP Thu Jun 29 23:03:09 CEST 2006 BIOS-provided physical RAM map: BIOS-e820: - 0009fc00 (usable) BIOS-e820: 0009fc00 - 000a (reserved) BIOS-e820: 000e4000 - 0010 (reserved) BIOS-e820: 0010 - d7fb (usable) BIOS-e820: d7fb - d7fc (ACPI data) BIOS-e820: d7fc - d7ff (ACPI NVS) BIOS-e820: d7ff - d800 (reserved) BIOS-e820: ff78 - 0001 (reserved) BIOS-e820: 0001 - 00012400 (usable) DMI 2.3 present. ACPI: RSDP (v002 ACPIAM) @ 0x000fa7c0 ACPI: XSDT (v001 A M I OEMXSDT 0x1506 MSFT 0x0097) @ 0xd7fb0100 ACPI: FADT (v003 A M I OEMFACP 0x1506 MSFT 0x0097) @ 0xd7fb0290 ACPI: MADT (v001 A M I OEMAPIC 0x1506 MSFT 0x0097) @ 0xd7fb0390 ACPI: OEMB (v001 A M I OEMBIOS 0x1506 MSFT 0x0097) @ 0xd7fc0040 ACPI: DSDT (v001 A0036 A0036001 0x0001 MSFT 0x010d) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 00012400 NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -00012400 On node 0 totalpages: 1014222 DMA zone: 2502 pages, LIFO batch:0 DMA32 zone: 866280 pages, LIFO batch:31 Normal zone: 145440 pages, LIFO batch:31 Looks like a VIA chipset. Disabling IOMMU. Override with "iommu=allowed" ACPI: PM-Timer IO Port: 0x808 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled) Processor #0 15:3 APIC version 16 ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled) Processor #1 15:3 APIC version 16 ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at dc00 (gap: d800:2778) SMP: Allowing 2 CPUs, 0 hotplug CPUs Built 1 zonelists Kernel command line: BOOT_IMAGE=2.6.17-1-smp ro root=902 iommu=soft swiotlb=force single Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Disabling vsyscall due to use of PM timer time.c: Using 3.579545 MHz WALL PM GTOD PM timer. time.c: Detected 2202.921 MHz processor. Console: colour VGA+ 80x25 Dentry cache hash table entries: 524288 (order: 10, 4194304 bytes) Inode-cache hash table entries: 262144 (order: 9, 2097152 bytes) PCI-DMA: Using software bounce buffering for IO (SWIOTLB) Placing software IO TLB between 0x163a000 - 0x563a000 Memory: 3984540k/4784128k available (1870k kernel code, 143520k reserved, 820k data, 172k init) Calibrating delay using timer specific routine.. 4411.18 BogoMIPS (lpj=8822378) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 0/0(2) -> Node 0 -> Core 0 Using local APIC timer interrupts. result 12516619 Detected 12.516 MHz APIC timer. Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 4405.96 BogoMIPS (lpj=8811936) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU 1/1(2) -> Node 0 -> Core 1 AMD Athlon(tm) 64 X2 Dual Core Processor 4400+ stepping 02 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff -82 cycles, maxerr 637 cycles) Brought up 2 CPUs testing NMI watchdog ... OK. migration_cost=632 checking if image is initramfs... it is Freeing initrd memory: 1348k freed NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Subsystem revision 20060127 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) PCI: Quirk
Re: skge error; hangs w/ hardware memory hole
On Wednesday 12 July 2006 06:09, Kevin Brown wrote: > Andreas Kleen wrote: > > If it helps I can do a proper patch that only bounces IO > 4GB through > > the copy. > > For the A8V series of boards, that will almost certainly be just fine, > because as far as I know you can't populate them with more than 4G of > memory anyway. Even if you only put 4GB in then memory remapping for the PCI hole will usually put some memory beyond 4GB. Of course again the mainboard vendor seems to have never tested this so there might be other more subtle problems the kernel can't help with. > > If someone has more than 4G of memory, it's likely they'll be willing to > take the performance hit from the mod in exchange for being able to use > more than 4G of memory. Somewhat of a platitude. They would have no choice. > > Bottom line: do the patch. It'll be worth using. I'm still waiting for a positive test result. Ideally from multiple people because it's a pretty radical step to blacklist all VIA chipsets like this (and it's s still possible that only some BIOS are broken, not all VIA boards) In fact I've been trying to get confirmation from VIA on this, but they never answered my queries. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
Andreas Kleen wrote: If it helps I can do a proper patch that only bounces IO > 4GB through the copy. For the A8V series of boards, that will almost certainly be just fine, because as far as I know you can't populate them with more than 4G of memory anyway. If someone has more than 4G of memory, it's likely they'll be willing to take the performance hit from the mod in exchange for being able to use more than 4G of memory. Bottom line: do the patch. It'll be worth using. - Kevin - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
Spamming bug robot dropped from cc list. Am Mi 12.07.2006 04:46 schrieb Anthony DeRobertis <[EMAIL PROTECTED]>: > OK, here are the results with iommu=force. All of these are copied > down > by hand, so please forgive any transcription errors: You need to use iommu=soft swiotlb=force The standard IOMMU is also broken on VIA, but forced swiotlb should work. However it is a bit slow because it will force all IO through an additional copy. If it helps I can do a proper patch that only bounces IO > 4GB through the copy. > Honestly, should I chuck this board through the window of my nearest > ASUS and/or VIA office, and buy an NForce board? We can probably get it to work, but you're clearly outside validated territory (= you're running the hardware in a untested by the vendor configuration). Normally that's not a good idea. BTW there are NForce systems with similar problems, but they are rare. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
OK, here are the results with iommu=force. All of these are copied down by hand, so please forgive any transcription errors: 2.6.12[1]: Last line displayed on screen is "ata1: dev 0 ATA max UDMA/133 390721968 sectors, lba48". Then it sits there. Scrolling with shift-pgup/pgdown works. Control-Alt-Del reboots the machine. According to /var/log/dmesg, the next line --- which never appears --- should be "ata1: dev 0 configured for UDMA/133" 2.6.17-1: The kernel panics with a null pointer dereference on loading uhci_hcd. The addresses given are usb_kick_khud+7, usb_hc_died+106, pcibios_set_master+30, etc. After the panic, it sits there (just like 2.6.12) 2.6.17-mm6: The last line displayed is "SATA link up 1.5 Gbps SStatus 113 Scontrol 300". It completely hangs: neither scrolling nor control-alt-del work. Honestly, should I chuck this board through the window of my nearest ASUS and/or VIA office, and buy an NForce board? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
Andi Kleen wrote: > Is that a board with VIA chipset? Yep. > > VIA doesn't seem to support PCI accesses with addresses >4GB and they also > don't have a working GART IOMMU. > > It will likely work with iommu=force I'll give this a try I do get a line in dmesg which reads: PCI-DMA: Disabling IOMMU. - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
* Andi Kleen <[EMAIL PROTECTED]> [2006-07-07 23:28]: > Is that a board with VIA chipset? Yes, according to lspci, there's a VIA K8T800Pro and VT8237. :00:00.0 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.1 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.2 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.3 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.4 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:00.7 Host bridge: VIA Technologies, Inc. K8T800Pro Host Bridge :00:01.0 PCI bridge: VIA Technologies, Inc. VT8237 PCI bridge [K8T800/K8T890 South] (prog-if 00 [Normal decode]) :00:07.0 FireWire (IEEE 1394): VIA Technologies, Inc. IEEE 1394 Host Controller (rev 80) (prog-if 10 [OHCI]) :00:0f.0 RAID bus controller: VIA Technologies, Inc. VIA VT6420 SATA RAID Controller (rev 80) :00:0f.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06) (prog-if 8a [Master SecP PriP]) :00:10.0 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.1 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.2 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.3 USB Controller: VIA Technologies, Inc. VT82x UHCI USB 1.1 Controller (rev 81) (prog-if 00 [UHCI]) :00:10.4 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 86) (prog-if 20 [EHCI]) :00:11.0 ISA bridge: VIA Technologies, Inc. VT8237 ISA bridge [KT600/K8T800/K8T890 South] :00:11.5 Multimedia audio controller: VIA Technologies, Inc. VT8233/A/8235/8237 AC97 Audio Controller (rev 60) -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
On Friday 07 July 2006 23:18, Stephen Hemminger wrote: > On Mon, 3 Jul 2006 22:52:38 +0200 > Martin Michlmayr <[EMAIL PROTECTED]> wrote: > > > We received the following bug report at http://bugs.debian.org/341801 > > > > | I have a Asus A8V with 4GB of RAM. When I turn on the hardware memory > > | hole in the BIOS, the skge driver prints out this message: > > | skge hardware error detected (status 0xc00) > > | and then does not work. Setting debug=16 doesn't really show anything. Is that a board with VIA chipset? VIA doesn't seem to support PCI accesses with addresses >4GB and they also don't have a working GART IOMMU. It will likely work with iommu=force I've been pondering to force this, but was still waiting for more reports. -Andi - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: skge error; hangs w/ hardware memory hole
On Mon, 3 Jul 2006 22:52:38 +0200 Martin Michlmayr <[EMAIL PROTECTED]> wrote: > We received the following bug report at http://bugs.debian.org/341801 > > | I have a Asus A8V with 4GB of RAM. When I turn on the hardware memory > | hole in the BIOS, the skge driver prints out this message: > | skge hardware error detected (status 0xc00) > | and then does not work. Setting debug=16 doesn't really show anything. > > Another users confirms this bug, saying: > > | I'm running kernel 2.6.15-1-amd64-generic version 2.6.15-6, and see > | the very same thing. > | So I have to turn off the memory remapping feature that allows the > | system to see all 4 gig of memory, and thus lose the use of about 200 > | megabytes of memory. > | Hardware: ASUS A8V Deluxe, 4G RAM, Athlon 64 3200+ CPU. > > This problem has probably been there forever and also happens with the > sk98lin driver: > > | With sk98lin under both 2.6.12 and 2.6.17 I get the following message, > | repeated countless times, and finally a hang: [this is copied from > | screen on to a sheet a paper and re-typed, beware typos]: > > | eth0: Adapter failed > | eth0: -- ERROR -- > | class: Hardware failure > | Nr: 0x264 > | Msg: unexpected IRQ Status error > > The bug is still present in 2.6.17 -mm6: > > | -mm6 does not work with skge and the hardware memory hole. It gave > | these messages: > > | skge eth0: enabling interface > | skge :00:0a.0: PCI error cmd=0x117 status=0x22b0 > | skge unable to clear error (so ignoring them) > | skge eth0: Link is up at 1000 Mbps, full duplex, flow control tx and rx > > | DHCP never managed to get an IP address. > > Any idea what to do about this? I don't really have access to the hardware, or know the x86-64 details perhaps Andi Kleen would be of more help. But my suspicion is that the remapping doesn't work for i/o devices because of hardware or BIOS. One simple workaround is to force use of the I/O mmu on the amd64 processor. This has a small performance impact (requires more setup). See Documentation/x86_64/boot-options.txt iommu=force -- Stephen Hemminger <[EMAIL PROTECTED]> Quis custodiet ipsos custodes? - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
skge error; hangs w/ hardware memory hole
We received the following bug report at http://bugs.debian.org/341801 | I have a Asus A8V with 4GB of RAM. When I turn on the hardware memory | hole in the BIOS, the skge driver prints out this message: | skge hardware error detected (status 0xc00) | and then does not work. Setting debug=16 doesn't really show anything. Another users confirms this bug, saying: | I'm running kernel 2.6.15-1-amd64-generic version 2.6.15-6, and see | the very same thing. | So I have to turn off the memory remapping feature that allows the | system to see all 4 gig of memory, and thus lose the use of about 200 | megabytes of memory. | Hardware: ASUS A8V Deluxe, 4G RAM, Athlon 64 3200+ CPU. This problem has probably been there forever and also happens with the sk98lin driver: | With sk98lin under both 2.6.12 and 2.6.17 I get the following message, | repeated countless times, and finally a hang: [this is copied from | screen on to a sheet a paper and re-typed, beware typos]: | eth0: Adapter failed | eth0: -- ERROR -- | class: Hardware failure | Nr: 0x264 | Msg: unexpected IRQ Status error The bug is still present in 2.6.17 -mm6: | -mm6 does not work with skge and the hardware memory hole. It gave | these messages: | skge eth0: enabling interface | skge :00:0a.0: PCI error cmd=0x117 status=0x22b0 | skge unable to clear error (so ignoring them) | skge eth0: Link is up at 1000 Mbps, full duplex, flow control tx and rx | DHCP never managed to get an IP address. Any idea what to do about this? -- Martin Michlmayr http://www.cyrius.com/ - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
