[lkml]   [2003]   [Aug]   [24]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: via rhine network failure on 2.6.0-test4
Jeff is probably right - /proc/interrupts is similar on both the failing 
(test4) and working (test3) except for the eth0 entry (the via rhine
chipset on the motherboard) assigned to IRQ11 in test3 and IRQ5 in test4.

Differences in the boot.msg between test3 and test4 start with an entry
"PM Adding info for No Bus: legacy" in the working one which is not
found in the failing (test4) boot.msg. There are differences in the
"ACPI Subsystem revision" number that is logged. Various ACPI related
messages are found in the failing boot.msg before "ACPI interpreter
enabled" In the good one (test3) following the PCI: Probing PCI
hardware line are a series of "PM: Adding info for ..". messages which
look like they are finding various PCI devices (these are not found in
the failing test4 case).

I am experimenting with disabling ACPI on test4 to see if that bypasses
the problem.

Jeff Garzik wrote:

> Steve French wrote:
>> The via rhine driver fails to get a dhcp address on my test system on
>> 2.6.0-test4. ethereal shows no dhcp request leaving the box but
>> ifconfig does show the device and it is detected in /proc/pci.
>> Switching from the test3 vs. test4 snapshots built with equivalent
>> configure options on the same system (SuSE 8.2) - test3 works but
>> test4 does not. This is using essentially the default config for
>> both the test3 and test4 cases - the only changes are SMP disabled,
>> scsi devices disabled, Athlon, via-rhine enabled in network devices
>> and a handful of additional filesystems enabled, debug memory
>> allocations enabled. This is the first time in many months that I
>> have seen problems with the via-rhine driver on 2.6
>> Analyzing the code differences between 2.6.0-test3 and test4 (in
>> via-rhine.c) is not very promising since the only line that has
>> changed (kfree to free_netdev) is in the routine via_rhine_remove_one
>> that seems unlikely to cause problems sending data on the network.
>> Ideas as to what could have caused the regression?
> Does /proc/interrupts show any interrupts being received on your eth
> device? Does dmesg report any irq assignment problems, or similar?
> This sounds like ACPI or irq routing related.
> Jeff

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:48    [W:0.053 / U:0.744 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site