Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Len Brown wrote: ..same problem with 2.6.20-rc3. Last worked with 2.6.19-rc6-git12, so it was 2.6.19 where it failed. Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet doesn't get configured, route -n says it's an Unsupported operation, ifconfig only shows for localhost, ifconfig eth0 192.168.10.5 also complains of a config error. It seems that the "acpi=noirq" (and probably also the acpi=off) case is simply an additional broken case, not a success case to compare to. The thing we really want to compare is dmesg and /proc/interrupts from 2.6.19-rc6-git12, and the broken current release. Perhaps you can put that info in the bug report when you file it. thanks, -Len 2.6.19-rc6-git12 fails in exactly the same way, from /var/log/messages it seems 2.6.19-rc6 19/11/06 first saw the problem, details later when I boot 2.6.19-rc5. If I boot an affected kernel with the SuSEfirewall2 enabled and then stop the firewall, the problems goes away. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Len Brown wrote: ..same problem with 2.6.20-rc3. Last worked with 2.6.19-rc6-git12, so it was 2.6.19 where it failed. Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet doesn't get configured, route -n says it's an Unsupported operation, ifconfig only shows for localhost, ifconfig eth0 192.168.10.5 also complains of a config error. It seems that the acpi=noirq (and probably also the acpi=off) case is simply an additional broken case, not a success case to compare to. The thing we really want to compare is dmesg and /proc/interrupts from 2.6.19-rc6-git12, and the broken current release. Perhaps you can put that info in the bug report when you file it. thanks, -Len 2.6.19-rc6-git12 fails in exactly the same way, from /var/log/messages it seems 2.6.19-rc6 19/11/06 first saw the problem, details later when I boot 2.6.19-rc5. If I boot an affected kernel with the SuSEfirewall2 enabled and then stop the firewall, the problems goes away. Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Wed, Jan 03, 2007 at 04:53:58PM +, Sid Boyce wrote: ... > It seems >=2.6.19 and the SuSEfirewall are incompatible. Actually, many programs could be incomapatible with newer kernel versions, so sometimes upgrades or at least recompilations are needed. ... > There is still the problem where the ethernet doesn't get configured > with acpi=off which I shall post to the acpi devel list, but this is not > a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS: I don't know acpi enough but as far as I know some mainboards can't work properly with acpi off, so it's probably not a bug. Cheers, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Wed, Jan 03, 2007 at 04:53:58PM +, Sid Boyce wrote: ... It seems =2.6.19 and the SuSEfirewall are incompatible. Actually, many programs could be incomapatible with newer kernel versions, so sometimes upgrades or at least recompilations are needed. ... There is still the problem where the ethernet doesn't get configured with acpi=off which I shall post to the acpi devel list, but this is not a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS: I don't know acpi enough but as far as I know some mainboards can't work properly with acpi off, so it's probably not a bug. Cheers, Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote: Jarek Poplawski wrote: ... If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) >from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. ... Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With >=2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. This could be a problem with DNS. Could you do all tests (including pinging) with -n option? I've read your other message on netdev and see you have firewall working and addresses from various networks in logs. I think it would be much easier to exclude possible network config errors and try to isolate pinging problems by connecting (with switch or even crossed cable if possible) only 2 boxes with firewalls and other net devices disabled and try to repeat this pinging with tcpdumps. Jarek P. It seems >=2.6.19 and the SuSEfirewall are incompatible. Turning off the firewall on the laptop cured the problem using 2.6.20-rc2 and 2.6.20-rc3. I thought it was off. On the 64x2 box, the firewall is turned off, so I shall have to reconfigure the network to use the Gigabit ethernet instead of the eepro100 in case I turned it off after seeing the bug on that box, but didn't stop the firewall. There is still the problem where the ethernet doesn't get configured with acpi=off which I shall post to the acpi devel list, but this is not a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS: Function not implemented. Thanks and Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote: > Jarek Poplawski wrote: ... > >If you could send full ifconfig, route -n (or ip route > >if you use additional tables) and tcpdump (all packets) > >from both boxes while pinging each other and a few words > >how it is connected (other cards, other active boxes in > >the network?) maybe something more could be found. ... > Everything is fine with a eepro100 on the 64x2 box that gave the same > problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) > using the forcedeth module. On the x86_64 laptop the problem is with a > Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a > 2.6.18.2 kernel, there is no problem. > With all configurations of cards on both, route -n is the same on all > kernels and instantly reports back. With >=2.6.19 on the laptop, netstat > -r takes a very long time before returning the information ~30 seconds, > instantly on 2.6.18.2. This could be a problem with DNS. Could you do all tests (including pinging) with -n option? I've read your other message on netdev and see you have firewall working and addresses from various networks in logs. I think it would be much easier to exclude possible network config errors and try to isolate pinging problems by connecting (with switch or even crossed cable if possible) only 2 boxes with firewalls and other net devices disabled and try to repeat this pinging with tcpdumps. Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote: Jarek Poplawski wrote: ... If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. ... Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With =2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. This could be a problem with DNS. Could you do all tests (including pinging) with -n option? I've read your other message on netdev and see you have firewall working and addresses from various networks in logs. I think it would be much easier to exclude possible network config errors and try to isolate pinging problems by connecting (with switch or even crossed cable if possible) only 2 boxes with firewalls and other net devices disabled and try to repeat this pinging with tcpdumps. Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Tue, Jan 02, 2007 at 03:32:01PM +, Sid Boyce wrote: Jarek Poplawski wrote: ... If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. ... Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With =2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. This could be a problem with DNS. Could you do all tests (including pinging) with -n option? I've read your other message on netdev and see you have firewall working and addresses from various networks in logs. I think it would be much easier to exclude possible network config errors and try to isolate pinging problems by connecting (with switch or even crossed cable if possible) only 2 boxes with firewalls and other net devices disabled and try to repeat this pinging with tcpdumps. Jarek P. It seems =2.6.19 and the SuSEfirewall are incompatible. Turning off the firewall on the laptop cured the problem using 2.6.20-rc2 and 2.6.20-rc3. I thought it was off. On the 64x2 box, the firewall is turned off, so I shall have to reconfigure the network to use the Gigabit ethernet instead of the eepro100 in case I turned it off after seeing the bug on that box, but didn't stop the firewall. There is still the problem where the ethernet doesn't get configured with acpi=off which I shall post to the acpi devel list, but this is not a showstopper for me. ifconfig eth0 192.168.10.5 returns SIOCSIFFLAGS: Function not implemented. Thanks and Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
> ..same problem with 2.6.20-rc3. Last worked with > 2.6.19-rc6-git12, so it was 2.6.19 where it failed. > Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet > doesn't get configured, route -n says it's an Unsupported operation, > ifconfig only shows for localhost, ifconfig eth0 192.168.10.5 also > complains of a config error. It seems that the "acpi=noirq" (and probably also the acpi=off) case is simply an additional broken case, not a success case to compare to. The thing we really want to compare is dmesg and /proc/interrupts from 2.6.19-rc6-git12, and the broken current release. Perhaps you can put that info in the bug report when you file it. thanks, -Len - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Apologies for the long spiel, if memory serves me correct, gzip'd attachments are verboten. openSUSE 10.2 Network does not get configured with "acpi=noirq" or "acpi=off". There may be something in dmesg that allows further analysis of the problem. 00:0a:e4:4e:a1:42 is the laptop MAC address. 00:48:54:d0:22:f0 is the firewall box 00:50:22:40:0F:D2 is a local box Some things in dmesg which look decidedly strange when compared to what is seen with 2.6.18.2-34, two mac addresses strung together with an additional :08:00. I'm guessing here, this may be normal but I haven't seen such before. Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1fefb000 (ACPI data) BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (reserved) BIOS-e820: fffe - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68c0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1fef5d48 ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x1fefae56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x1fefafb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 1fef Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -1fef Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 130800 On node 0 totalpages: 130703 DMA zone: 56 pages used for memmap DMA zone: 1183 pages reserved DMA zone: 2760 pages, LIFO batch:0 DMA32 zone: 1732 pages used for memmap DMA32 zone: 124972 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) 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 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000d8000 Nosave address range: 000d8000 - 0010 Allocating PCI resources starting at 3000 (gap: 2000:dffe) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 49664 bytes of per cpu data Built 1 zonelists. Total pages: 127732 Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking aperture... CPU 0: aperture @ e000 size 256 MB Memory: 507156k/523200k available (1948k kernel code, 15656k reserved, 950k data, 324k init) Calibrating delay using timer specific routine.. 3591.92 BogoMIPS (lpj=1795961) Security Framework v1.0.0 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 -> Node 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 28k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12464666 Detected 12.464 MHz APIC timer. Brought up 1 CPUs testing NMI watchdog ... OK. time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. time.c: Detected 1794.911 MHz processor. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Tuesday 02 January 2007 10:41, Sid Boyce wrote: > Same problem with 2.6.19-rc3. Do you mean 2.6.20-rc3 still does not work? What was the last kernel that worked properly with no cmdline parameters? > Apologies for the long spiel, if memory serves me correct, gzip'd > attachments are verboten. Bugzilla may be a good place to put more information. If the system fails in ACPI mode, but works in non-ACPI mode, then please file a bug here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and attach the complete dmesg -s64000 for the last working, plus failing kernel -- along with /proc/interrupts for both, and a single copy of lspci -vv output. > openSUSE 10.2 > Network does not get configured with "acpi=noirq" or "acpi=off". Do you mean it does not work when running in ACPI mode, but it does work correctly if you boot with "acpi=noirq" or "acpi=off"? If so, please include the dmesg -s64000 and /proc/interrupts for the acpi=off case also. Nothing jumps out as incorrect with the ACPI IRQ routing below. Maybe somebody who knows about the tg3 can suggest what the error messages mean and if they are related to interrupt problems, or perhaps something else like IO resource issues? -Len > There may be something in dmesg that allows further analysis of the > problem. > 00:0a:e4:4e:a1:42 is the laptop MAC address. > 00:48:54:d0:22:f0 is the firewall box > 00:50:22:40:0F:D2 is a local box > Some things in dmesg which look decidedly strange when compared to what > is seen with 2.6.18.2-34, two mac addresses strung together with an > additional :08:00. I'm guessing here, this may be normal but I haven't > seen such before. > Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 > 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 > Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 > BIOS-provided physical RAM map: > BIOS-e820: - 0009f800 (usable) > BIOS-e820: 0009f800 - 000a (reserved) > BIOS-e820: 000d8000 - 0010 (reserved) > BIOS-e820: 0010 - 1fef (usable) > BIOS-e820: 1fef - 1fefb000 (ACPI data) > BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) > BIOS-e820: 1ff0 - 2000 (reserved) > BIOS-e820: fffe - 0001 (reserved) > Entering add_active_range(0, 0, 159) 0 entries of 3200 used > Entering add_active_range(0, 256, 130800) 1 entries of 3200 used > end_pfn_map = 1048576 > DMI 2.3 present. > ACPI: RSDP (v000 PTLTD ) @ > 0x000f68c0 > ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ > 0x1fef5d48 > ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ > 0x1fefae56 > ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ > 0x1fefaeda > ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ > 0x1fefafb0 > ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ > 0x > Scanning NUMA topology in Northbridge 24 > Number of nodes 1 > Node 0 MemBase Limit 1fef > Entering add_active_range(0, 0, 159) 0 entries of 3200 used > Entering add_active_range(0, 256, 130800) 1 entries of 3200 used > NUMA: Using 63 for the hash shift. > Using node hash shift of 63 > Bootmem setup node 0 -1fef > Zone PFN ranges: > DMA 0 -> 4096 > DMA324096 -> 1048576 > Normal1048576 -> 1048576 > early_node_map[2] active PFN ranges > 0:0 -> 159 > 0: 256 -> 130800 > On node 0 totalpages: 130703 > DMA zone: 56 pages used for memmap > DMA zone: 1183 pages reserved > DMA zone: 2760 pages, LIFO batch:0 > DMA32 zone: 1732 pages used for memmap > DMA32 zone: 124972 pages, LIFO batch:31 > Normal zone: 0 pages used for memmap > ACPI: PM-Timer IO Port: 0x4008 > ACPI: Local APIC address 0xfee0 > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > Processor #0 (Bootup-CPU) > ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) > ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) > IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) > 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 > Nosave address range: 0009f000 - 000a > Nosave address range: 000a - 000d8000 > Nosave address range: 000d8000 - 0010 > Allocating PCI resources starting at 3000 (gap: 2000:dffe) > SMP: Allowing 1 CPUs, 0 hotplug CPUs > PERCPU: Allocating 49664 bytes of per cpu data > Built 1 zonelists. Total pages: 127732 > Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 >
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Same problem with 2.6.19-rc3. Apologies for the long spiel, if memory serves me correct, gzip'd attachments are verboten. openSUSE 10.2 Network does not get configured with "acpi=noirq" or "acpi=off". There may be something in dmesg that allows further analysis of the problem. 00:0a:e4:4e:a1:42 is the laptop MAC address. 00:48:54:d0:22:f0 is the firewall box 00:50:22:40:0F:D2 is a local box Some things in dmesg which look decidedly strange when compared to what is seen with 2.6.18.2-34, two mac addresses strung together with an additional :08:00. I'm guessing here, this may be normal but I haven't seen such before. Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1fefb000 (ACPI data) BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (reserved) BIOS-e820: fffe - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68c0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1fef5d48 ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x1fefae56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x1fefafb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 1fef Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -1fef Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1048576 early_node_map[2] active PFN ranges 0:0 -> 159 0: 256 -> 130800 On node 0 totalpages: 130703 DMA zone: 56 pages used for memmap DMA zone: 1183 pages reserved DMA zone: 2760 pages, LIFO batch:0 DMA32 zone: 1732 pages used for memmap DMA32 zone: 124972 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) 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 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000d8000 Nosave address range: 000d8000 - 0010 Allocating PCI resources starting at 3000 (gap: 2000:dffe) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 49664 bytes of per cpu data Built 1 zonelists. Total pages: 127732 Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking aperture... CPU 0: aperture @ e000 size 256 MB Memory: 507156k/523200k available (1948k kernel code, 15656k reserved, 950k data, 324k init) Calibrating delay using timer specific routine.. 3591.92 BogoMIPS (lpj=1795961) Security Framework v1.0.0 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 -> Node 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 28k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12464666 Detected 12.464 MHz APIC timer. Brought up 1 CPUs testing NMI watchdog ... OK. time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. time.c: Detected 1794.911 MHz processor. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. I have a problem with posting to linux-kernel and netdev, my mail got returned as SPAM, now it just gets dropped. postmaster says the filter is seeing a sub-string of something that is filtered. I shall try posting under another email address. Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With >=2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. Boycie:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0* 255.255.255.0 U 0 0 0 eth0 loopback* 255.0.0.0 U 0 0 0 lo default Smoothie.site 0.0.0.0 UG0 0 0 eth0 Boycie:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 192.168.10.102 0.0.0.0 UG0 00 eth0 -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. I have a problem with posting to linux-kernel and netdev, my mail got returned as SPAM, now it just gets dropped. postmaster says the filter is seeing a sub-string of something that is filtered. Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With >=2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. Boycie:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0* 255.255.255.0 U 0 0 0 eth0 loopback* 255.0.0.0 U 0 0 0 lo default Smoothie.site 0.0.0.0 UG0 0 0 eth0 Boycie:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 192.168.10.102 0.0.0.0 UG0 00 eth0 Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. I have a problem with posting to linux-kernel and netdev, my mail got returned as SPAM, now it just gets dropped. postmaster says the filter is seeing a sub-string of something that is filtered. I shall try under my other email address. Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With >=2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. Boycie:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0* 255.255.255.0 U 0 0 0 eth0 loopback* 255.0.0.0 U 0 0 0 lo default Smoothie.site 0.0.0.0 UG0 0 0 eth0 Boycie:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 192.168.10.102 0.0.0.0 UG0 00 eth0 -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: > Jarek Poplawski wrote: > >On 28-12-2006 04:23, Sid Boyce wrote: > >> > >>I first saw the problem on the 64x2 box after upgrading to 2.6.19. The > >>network appeared OK with ifconfig and route -n, but I had no network > >>access. Pinging any other box, the box was responding, but no response > >... > >>barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig > >>Password: > >>eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 > >> inet addr:192.168.10.5 Bcast:255.255.255.255 > >> Mask:255.255.255.0 > > > >This Bcast isn't probably what you need. > > > >Regards, > >Jarek P. > > > > > > Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. I have a problem with posting to linux-kernel and netdev, my mail got returned as SPAM, now it just gets dropped. postmaster says the filter is seeing a sub-string of something that is filtered. I shall try under my other email address. Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With =2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. Boycie:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0* 255.255.255.0 U 0 0 0 eth0 loopback* 255.0.0.0 U 0 0 0 lo default Smoothie.site 0.0.0.0 UG0 0 0 eth0 Boycie:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 192.168.10.102 0.0.0.0 UG0 00 eth0 -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. I have a problem with posting to linux-kernel and netdev, my mail got returned as SPAM, now it just gets dropped. postmaster says the filter is seeing a sub-string of something that is filtered. Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With =2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. Boycie:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0* 255.255.255.0 U 0 0 0 eth0 loopback* 255.0.0.0 U 0 0 0 lo default Smoothie.site 0.0.0.0 UG0 0 0 eth0 Boycie:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 192.168.10.102 0.0.0.0 UG0 00 eth0 Regards Sid. -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Jarek Poplawski wrote: On Sat, Dec 30, 2006 at 02:21:15AM +, Sid Boyce wrote: Jarek Poplawski wrote: On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. Corrected on the one box where it was not correct, problem is still there. There are many things to suspect yet: - firewall, - switch, - routing, - ifconfig, - other misonfigured box, - connecting and so on. I think you should try with some linux networking group at first and if you really think it's driver then netdev@vger.kernel.org (instead of linux-kernel@). If you could send full ifconfig, route -n (or ip route if you use additional tables) and tcpdump (all packets) from both boxes while pinging each other and a few words how it is connected (other cards, other active boxes in the network?) maybe something more could be found. Cheers, Jarek P. PS: Sorry for late responding. I have a problem with posting to linux-kernel and netdev, my mail got returned as SPAM, now it just gets dropped. postmaster says the filter is seeing a sub-string of something that is filtered. I shall try posting under another email address. Everything is fine with a eepro100 on the 64x2 box that gave the same problem with a nVidia Corporation MCP51 Ethernet Controller (rev a1) using the forcedeth module. On the x86_64 laptop the problem is with a Broadcom NetXtreme BCM5788 using the tg3 module. Switching back to a 2.6.18.2 kernel, there is no problem. With all configurations of cards on both, route -n is the same on all kernels and instantly reports back. With =2.6.19 on the laptop, netstat -r takes a very long time before returning the information ~30 seconds, instantly on 2.6.18.2. Boycie:~ # netstat -r Kernel IP routing table Destination Gateway Genmask Flags MSS Window irtt Iface 192.168.10.0* 255.255.255.0 U 0 0 0 eth0 loopback* 255.0.0.0 U 0 0 0 lo default Smoothie.site 0.0.0.0 UG0 0 0 eth0 Boycie:~ # route -n Kernel IP routing table Destination Gateway Genmask Flags Metric RefUse Iface 192.168.10.00.0.0.0 255.255.255.0 U 0 00 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 00 lo 0.0.0.0 192.168.10.102 0.0.0.0 UG0 00 eth0 -- Sid Boyce ... Hamradio License G3VBV, Licensed Private Pilot Emeritus IBM/Amdahl Mainframes and Sun/Fujitsu Servers Tech Support Specialist, Cricket Coach Microsoft Windows Free Zone - Linux used for all Computing Tasks - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Same problem with 2.6.19-rc3. Apologies for the long spiel, if memory serves me correct, gzip'd attachments are verboten. openSUSE 10.2 Network does not get configured with acpi=noirq or acpi=off. There may be something in dmesg that allows further analysis of the problem. 00:0a:e4:4e:a1:42 is the laptop MAC address. 00:48:54:d0:22:f0 is the firewall box 00:50:22:40:0F:D2 is a local box Some things in dmesg which look decidedly strange when compared to what is seen with 2.6.18.2-34, two mac addresses strung together with an additional :08:00. I'm guessing here, this may be normal but I haven't seen such before. Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1fefb000 (ACPI data) BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (reserved) BIOS-e820: fffe - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68c0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1fef5d48 ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x1fefae56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x1fefafb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 1fef Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -1fef Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 130800 On node 0 totalpages: 130703 DMA zone: 56 pages used for memmap DMA zone: 1183 pages reserved DMA zone: 2760 pages, LIFO batch:0 DMA32 zone: 1732 pages used for memmap DMA32 zone: 124972 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) 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 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000d8000 Nosave address range: 000d8000 - 0010 Allocating PCI resources starting at 3000 (gap: 2000:dffe) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 49664 bytes of per cpu data Built 1 zonelists. Total pages: 127732 Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking aperture... CPU 0: aperture @ e000 size 256 MB Memory: 507156k/523200k available (1948k kernel code, 15656k reserved, 950k data, 324k init) Calibrating delay using timer specific routine.. 3591.92 BogoMIPS (lpj=1795961) Security Framework v1.0.0 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 - Node 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 28k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12464666 Detected 12.464 MHz APIC timer. Brought up 1 CPUs testing NMI watchdog ... OK. time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. time.c: Detected 1794.911 MHz processor. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0]
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
Apologies for the long spiel, if memory serves me correct, gzip'd attachments are verboten. openSUSE 10.2 Network does not get configured with acpi=noirq or acpi=off. There may be something in dmesg that allows further analysis of the problem. 00:0a:e4:4e:a1:42 is the laptop MAC address. 00:48:54:d0:22:f0 is the firewall box 00:50:22:40:0F:D2 is a local box Some things in dmesg which look decidedly strange when compared to what is seen with 2.6.18.2-34, two mac addresses strung together with an additional :08:00. I'm guessing here, this may be normal but I haven't seen such before. Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1fefb000 (ACPI data) BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (reserved) BIOS-e820: fffe - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68c0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1fef5d48 ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x1fefae56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x1fefafb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 1fef Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -1fef Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 130800 On node 0 totalpages: 130703 DMA zone: 56 pages used for memmap DMA zone: 1183 pages reserved DMA zone: 2760 pages, LIFO batch:0 DMA32 zone: 1732 pages used for memmap DMA32 zone: 124972 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) 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 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000d8000 Nosave address range: 000d8000 - 0010 Allocating PCI resources starting at 3000 (gap: 2000:dffe) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 49664 bytes of per cpu data Built 1 zonelists. Total pages: 127732 Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Console: colour dummy device 80x25 Dentry cache hash table entries: 65536 (order: 7, 524288 bytes) Inode-cache hash table entries: 32768 (order: 6, 262144 bytes) Checking aperture... CPU 0: aperture @ e000 size 256 MB Memory: 507156k/523200k available (1948k kernel code, 15656k reserved, 950k data, 324k init) Calibrating delay using timer specific routine.. 3591.92 BogoMIPS (lpj=1795961) Security Framework v1.0.0 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 - Node 0 SMP alternatives: switching to UP code Freeing SMP alternatives: 28k freed ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12464666 Detected 12.464 MHz APIC timer. Brought up 1 CPUs testing NMI watchdog ... OK. time.c: Using 3.579545 MHz WALL PM GTOD PIT/TSC timer. time.c: Detected 1794.911 MHz processor. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On Tuesday 02 January 2007 10:41, Sid Boyce wrote: Same problem with 2.6.19-rc3. Do you mean 2.6.20-rc3 still does not work? What was the last kernel that worked properly with no cmdline parameters? Apologies for the long spiel, if memory serves me correct, gzip'd attachments are verboten. Bugzilla may be a good place to put more information. If the system fails in ACPI mode, but works in non-ACPI mode, then please file a bug here: http://bugzilla.kernel.org/enter_bug.cgi?product=ACPI and attach the complete dmesg -s64000 for the last working, plus failing kernel -- along with /proc/interrupts for both, and a single copy of lspci -vv output. openSUSE 10.2 Network does not get configured with acpi=noirq or acpi=off. Do you mean it does not work when running in ACPI mode, but it does work correctly if you boot with acpi=noirq or acpi=off? If so, please include the dmesg -s64000 and /proc/interrupts for the acpi=off case also. Nothing jumps out as incorrect with the ACPI IRQ routing below. Maybe somebody who knows about the tg3 can suggest what the error messages mean and if they are related to interrupt problems, or perhaps something else like IO resource issues? -Len There may be something in dmesg that allows further analysis of the problem. 00:0a:e4:4e:a1:42 is the laptop MAC address. 00:48:54:d0:22:f0 is the firewall box 00:50:22:40:0F:D2 is a local box Some things in dmesg which look decidedly strange when compared to what is seen with 2.6.18.2-34, two mac addresses strung together with an additional :08:00. I'm guessing here, this may be normal but I haven't seen such before. Linux version 2.6.20-rc1-git7-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (SUSE Linux)) #4 SMP Wed Dec 20 01:17:23 GMT 2006 Command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 1fef (usable) BIOS-e820: 1fef - 1fefb000 (ACPI data) BIOS-e820: 1fefb000 - 1ff0 (ACPI NVS) BIOS-e820: 1ff0 - 2000 (reserved) BIOS-e820: fffe - 0001 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f68c0 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x1fef5d48 ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x1fefae56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x1fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x1fefafb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase Limit 1fef Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 130800) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 -1fef Zone PFN ranges: DMA 0 - 4096 DMA324096 - 1048576 Normal1048576 - 1048576 early_node_map[2] active PFN ranges 0:0 - 159 0: 256 - 130800 On node 0 totalpages: 130703 DMA zone: 56 pages used for memmap DMA zone: 1183 pages reserved DMA zone: 2760 pages, LIFO batch:0 DMA32 zone: 1732 pages used for memmap DMA32 zone: 124972 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) 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 Nosave address range: 0009f000 - 000a Nosave address range: 000a - 000d8000 Nosave address range: 000d8000 - 0010 Allocating PCI resources starting at 3000 (gap: 2000:dffe) SMP: Allowing 1 CPUs, 0 hotplug CPUs PERCPU: Allocating 49664 bytes of per cpu data Built 1 zonelists. Total pages: 127732 Kernel command line: root=/dev/hda1 vga=0x317resume=/dev/hda2 splash=silent 3 Initializing CPU#0 PID hash table entries: 2048 (order: 11, 16384 bytes) Console: colour
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
..same problem with 2.6.20-rc3. Last worked with 2.6.19-rc6-git12, so it was 2.6.19 where it failed. Attaching both case1 normal, case2 acpi=noirq. With acpi=noirq ethernet doesn't get configured, route -n says it's an Unsupported operation, ifconfig only shows for localhost, ifconfig eth0 192.168.10.5 also complains of a config error. It seems that the acpi=noirq (and probably also the acpi=off) case is simply an additional broken case, not a success case to compare to. The thing we really want to compare is dmesg and /proc/interrupts from 2.6.19-rc6-git12, and the broken current release. Perhaps you can put that info in the bug report when you file it. thanks, -Len - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On 28-12-2006 04:23, Sid Boyce wrote: > > > I first saw the problem on the 64x2 box after upgrading to 2.6.19. The > network appeared OK with ifconfig and route -n, but I had no network > access. Pinging any other box, the box was responding, but no response ... > barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig > Password: > eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 > inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response was received by the 64x2. I checked cables and the switch which were OK, so I figured I had a faulty receiver on the on-board ethernet. I plugged in a PCI eepro100, reconfigured the network and it's been fine ever since. I upgraded to 2.6.20-rc2 (also 2.6.19 and later) on the x86_64 laptop and that also experienced the same problem - different cards in both boxes. Downgraded to 2.6.19-rc5 and network is up. == 64x2 box == 64: None 00.0: 10701 Ethernet [Created at net.115] UDI: /org/freedesktop/Hal/devices/net_00_01_6c_e6_ab_7a Unique ID: usDW.ndpeucax6V1 Parent ID: rBUF.siZp+507g89 SysFS ID: /class/net/eth0 SysFS Device Link: /devices/pci:00/:00:14.0 Hardware Class: network interface Model: "Ethernet network interface" Driver: "forcedeth" Device File: eth0 HW Address: 00:01:6c:e6:ab:7a Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #39 (Ethernet controller) *** PROBLEM ** eepro100 working (64x2) === 65: None 01.0: 10701 Ethernet [Created at net.115] UDI: /org/freedesktop/Hal/devices/net_00_d0_b7_13_e5_ea Unique ID: L2Ua.ndpeucax6V1 Parent ID: JNkJ.HVgIlgOrmpC SysFS ID: /class/net/eth1 SysFS Device Link: /devices/pci:00/:00:10.0/:04:08.0 Hardware Class: network interface Model: "Ethernet network interface" Driver: "eepro100" Device File: eth1 HW Address: 00:d0:b7:13:e5:ea Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #46 (Ethernet controller) === Acer 1501LCe x86_64 laptop. 49: udi = '/org/freedesktop/Hal/devices/pci_14e4_169c' info.bus = 'pci' info.linux.driver = 'tg3' info.parent = '/org/freedesktop/Hal/devices/computer' info.product = 'NetXtreme BCM5788 Gigabit Ethernet' info.udi = '/org/freedesktop/Hal/devices/pci_14e4_169c' info.vendor = 'Broadcom Corporation' linux.hotplug_type = 1 (0x1) linux.subsystem = 'pci' linux.sysfs_path = '/sys/devices/pci:00/:00:0c.0' linux.sysfs_path_device = '/sys/devices/pci:00/:00:0c.0' pci.device_class = 2 (0x2) pci.device_protocol = 0 (0x0) pci.device_subclass = 0 (0x0) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:0c.0' pci.product = 'NetXtreme BCM5788 Gigabit Ethernet' pci.product_id = 5788 (0x169c) pci.subsys_product = 'Unknown (0x0046)' pci.subsys_product_id = 70 (0x46) pci.subsys_vendor = 'Acer Incorporated [ALI]' pci.subsys_vendor_id = 4133 (0x1025) pci.vendor = 'Broadcom Corporation' pci.vendor_id = 5348 (0x14e4) == tcpdump on barrabas when pinged from Boycie = 01:45:32.089245 arp who-has Boycie.site tell barrabas.site 01:45:32.089323 arp reply Boycie.site is-at 00:0a:e4:4e:a1:42 (oui Unknown) 01:45:32.172445 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 41, length 64 01:45:32.172480 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 41, length 64 01:45:33.189534 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 42, length 64 01:45:33.189569 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 42, length 64 01:45:34.205635 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 43, length 64 01:45:34.205667 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 43, length 64 01:45:35.221734 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 44, length 64 01:45:35.221767 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 44, length 64 01:45:36.237835 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 45, length 64 01:45:36.237868 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 45, length 64 01:45:37.254956 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 46, length 64 01:45:37.254991 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 46, length 64 01:45:38.272044 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 47, length 64 01:45:38.272077 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 47, length 64 01:45:39.288136 IP Boycie.site > barrabas.site: ICMP echo request, id 8463, seq 48, length 64 01:45:39.288170 IP barrabas.site > Boycie.site: ICMP echo reply, id 8463, seq 48, length 64 170 packets captured 340 packets received by filter 0 packets dropped by kernel Boycie sees just a few packets occasionally when pinged from barrabas, but says its dropped no packets. Also strange, I can scp a file from Boycie. barrabas:/usr/src/linux-2.6.20-rc1-git5 # scp Boycie:/IFCONFIG / Password: IFCONFIG
Re: 2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
On 28-12-2006 04:23, Sid Boyce wrote: I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response ... barrabas:/usr/src/linux-2.6.20-rc1-git5 # ssh Boycie ifconfig Password: eth0 Link encap:Ethernet HWaddr 00:0A:E4:4E:A1:42 inet addr:192.168.10.5 Bcast:255.255.255.255 Mask:255.255.255.0 This Bcast isn't probably what you need. Regards, Jarek P. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.19 and up to 2.6.20-rc2 Ethernet problems x86_64
I first saw the problem on the 64x2 box after upgrading to 2.6.19. The network appeared OK with ifconfig and route -n, but I had no network access. Pinging any other box, the box was responding, but no response was received by the 64x2. I checked cables and the switch which were OK, so I figured I had a faulty receiver on the on-board ethernet. I plugged in a PCI eepro100, reconfigured the network and it's been fine ever since. I upgraded to 2.6.20-rc2 (also 2.6.19 and later) on the x86_64 laptop and that also experienced the same problem - different cards in both boxes. Downgraded to 2.6.19-rc5 and network is up. == 64x2 box == 64: None 00.0: 10701 Ethernet [Created at net.115] UDI: /org/freedesktop/Hal/devices/net_00_01_6c_e6_ab_7a Unique ID: usDW.ndpeucax6V1 Parent ID: rBUF.siZp+507g89 SysFS ID: /class/net/eth0 SysFS Device Link: /devices/pci:00/:00:14.0 Hardware Class: network interface Model: Ethernet network interface Driver: forcedeth Device File: eth0 HW Address: 00:01:6c:e6:ab:7a Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #39 (Ethernet controller) *** PROBLEM ** eepro100 working (64x2) === 65: None 01.0: 10701 Ethernet [Created at net.115] UDI: /org/freedesktop/Hal/devices/net_00_d0_b7_13_e5_ea Unique ID: L2Ua.ndpeucax6V1 Parent ID: JNkJ.HVgIlgOrmpC SysFS ID: /class/net/eth1 SysFS Device Link: /devices/pci:00/:00:10.0/:04:08.0 Hardware Class: network interface Model: Ethernet network interface Driver: eepro100 Device File: eth1 HW Address: 00:d0:b7:13:e5:ea Link detected: yes Config Status: cfg=new, avail=yes, need=no, active=unknown Attached to: #46 (Ethernet controller) === Acer 1501LCe x86_64 laptop. 49: udi = '/org/freedesktop/Hal/devices/pci_14e4_169c' info.bus = 'pci' info.linux.driver = 'tg3' info.parent = '/org/freedesktop/Hal/devices/computer' info.product = 'NetXtreme BCM5788 Gigabit Ethernet' info.udi = '/org/freedesktop/Hal/devices/pci_14e4_169c' info.vendor = 'Broadcom Corporation' linux.hotplug_type = 1 (0x1) linux.subsystem = 'pci' linux.sysfs_path = '/sys/devices/pci:00/:00:0c.0' linux.sysfs_path_device = '/sys/devices/pci:00/:00:0c.0' pci.device_class = 2 (0x2) pci.device_protocol = 0 (0x0) pci.device_subclass = 0 (0x0) pci.linux.sysfs_path = '/sys/devices/pci:00/:00:0c.0' pci.product = 'NetXtreme BCM5788 Gigabit Ethernet' pci.product_id = 5788 (0x169c) pci.subsys_product = 'Unknown (0x0046)' pci.subsys_product_id = 70 (0x46) pci.subsys_vendor = 'Acer Incorporated [ALI]' pci.subsys_vendor_id = 4133 (0x1025) pci.vendor = 'Broadcom Corporation' pci.vendor_id = 5348 (0x14e4) == tcpdump on barrabas when pinged from Boycie = 01:45:32.089245 arp who-has Boycie.site tell barrabas.site 01:45:32.089323 arp reply Boycie.site is-at 00:0a:e4:4e:a1:42 (oui Unknown) 01:45:32.172445 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 41, length 64 01:45:32.172480 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 41, length 64 01:45:33.189534 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 42, length 64 01:45:33.189569 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 42, length 64 01:45:34.205635 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 43, length 64 01:45:34.205667 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 43, length 64 01:45:35.221734 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 44, length 64 01:45:35.221767 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 44, length 64 01:45:36.237835 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 45, length 64 01:45:36.237868 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 45, length 64 01:45:37.254956 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 46, length 64 01:45:37.254991 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 46, length 64 01:45:38.272044 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 47, length 64 01:45:38.272077 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 47, length 64 01:45:39.288136 IP Boycie.site barrabas.site: ICMP echo request, id 8463, seq 48, length 64 01:45:39.288170 IP barrabas.site Boycie.site: ICMP echo reply, id 8463, seq 48, length 64 170 packets captured 340 packets received by filter 0 packets dropped by kernel Boycie sees just a few packets occasionally when pinged from barrabas, but says its dropped no packets. Also strange, I can scp a file from Boycie. barrabas:/usr/src/linux-2.6.20-rc1-git5 # scp Boycie:/IFCONFIG / Password: IFCONFIG
