Re: via rhine network failure on 2.6.0-test4

[Steve French <smfrench@austin.rr.com>]

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
>
>
>
>