Bug 9831
| Summary: | sis190 regression, "ifconfig eth0 up" produces eth0: ioctl SIOCSIFFLAGS: Invalid argument | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Gabriel A. Devenyi (ace) |
| Component: | Network | Assignee: | Francois Romieu (romieu) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | akpm, bunk, kernel, romieu |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.24-gentoo | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
lspci -vvxxx
dmesg of kernel with working sis190 Kernel dmesg with pci=nommconf Disable retrieval of MAC address from APC Read the mac address from the eeprom first |
||
|
Description
Gabriel A. Devenyi
2008-01-27 08:38:11 UTC
(for my reference) downstream bug is https://bugs.gentoo.org/show_bug.cgi?id=207706 There was probably a kenrel oops. Please check /var/log/messages, see if it was there? Whatever, the null mac address is not encouraging. Can you send the dmesg of the working 2.6.23 kernel and a lspci -vvxxx ? Thanks in advance. -- Ueimor Created attachment 14615 [details]
lspci -vvxxx
Created attachment 14616 [details]
dmesg of kernel with working sis190
Now, this is interesting, seems there's a 00:00:00:00:00 MAC address for this as well, however, the Ethernet actually works.
Re comment #2, Andrew, there is no OOPS I can find in /var/log/messages Any patches for me to test, do you need some git bisecting or other testing? I should also point out that this works on 2.6.23-gentoo-r6, which includes the patches here http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.23/ And that it fails on 2.6.24-gentoo, which include the patches here http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.24/ ace@staticwave.ca 2008-01-29 17:25 : > I should also point out that this works on 2.6.23-gentoo-r6, which includes > the > patches here http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.23/ > > And that it fails on 2.6.24-gentoo, which include the patches here > http://dev.gentoo.org/~dsd/genpatches/trunk/2.6.24/ I'll dig that. Thanks for the pointer. In the meantime can you try to boot with pci=nommconf and see if dmesg changes at all ? Created attachment 14655 [details]
Kernel dmesg with pci=nommconf
Here's the dmesg with the pci=nommconf, no change in the operation of the ethernet card.
And after some git-bisect digging, this appears to be the patch that breaks sis190 on my machine. *please note* that I still have the issue of a NULL mac address, although I guess that may be considered a different bug. Comments? bada339ba24dee9e143bfb42e1dc61f146619846 is first bad commit commit bada339ba24dee9e143bfb42e1dc61f146619846 Author: Jeff Garzik <jgarzik@redhat.com> Date: Tue Oct 23 20:19:37 2007 -0700 [NET]: Validate device addr prior to interface-up Signed-off-by: Jeff Garzik <jgarzik@redhat.com> Signed-off-by: David S. Miller <davem@davemloft.net> :040000 040000 9c90fdf19e779e031fe99750315774e5b10c78b1 ba116466ea212ba57000acad9230b3f0fc71161a M include :040000 040000 b68d43485820b283151ad05f6fbc33e6e1337bc3 64480498bfb494bf36f69bbe0802514764513336 M net Created attachment 14666 [details]
Disable retrieval of MAC address from APC
Gabriel, can you give this hack a try ?
--
Ueimor
It works! (using 2.6.24-gentoo) I guess the "APC" is broken for my ethernet card, however the eeprom works correctly. Does this mean my card needs a blacklist or is there some implementation error in the current code? Not sure if this is relevent, but the ifconfig reports something odd for the "Base address":
eth0 Link encap:Ethernet HWaddr 00:30:1B:80:CB:8B
inet addr:192.168.1.3 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:2221 errors:0 dropped:0 overruns:0 frame:0
TX packets:2127 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:520982 (508.7 Kb) TX bytes:364277 (355.7 Kb)
Interrupt:21 Base address:0xdead
bugme-daemon@bugzilla.kernel.org <bugme-daemon@bugzilla.kernel.org> : [...] > It works! (using 2.6.24-gentoo) I guess the "APC" is broken for my ethernet > card, however the eeprom works correctly. Does this mean my card needs a > blacklist or is there some implementation error in the current code ? I'll hack something to read eeprom first then try APC if it fails. ace@staticwave.ca 2008-01-31 20:57 : > Not sure if this is relevent, but the ifconfig reports something odd for the > "Base address": Base address is useless. It should have been removed from the kernel long ago but it is a low priority item. Please ignore it. Created attachment 14774 [details]
Read the mac address from the eeprom first
Gabriel, can you check that this patch works ?
--
Ueimor
Thanks, seems to work fine. Francois, thanks for working on this. Is it suitable to be sent to Jeff? (I'd like to get it upstream then pushed through the -stable tree) this is now in Jeff's tree (upstream-fixes, so should be in 2.6.25). Francois, thanks for working on this so quickly. |