Summary: | kernel panic in CONFIG_USB_NET_AX8817X driver | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Randy Barlow <randy> |
Component: | [OLD] Core system | Assignee: | Gentoo Kernel Bug Wranglers and Kernel Maintainers <kernel> |
Status: | RESOLVED CANTFIX | ||
Severity: | normal | ||
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | AMD64 | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
Screenshot of kernel panic
kernel config Traceback with Intel Pro/1000 chip |
Description
Randy Barlow
2011-06-09 13:49:17 UTC
Created attachment 276379 [details]
Screenshot of kernel panic
I had a hard time getting the full kernel panic. The router doesn't seem to log the kernel panic anywhere that I can find, it just seems to appear on the console. Because of this, I took a photo of the panic and I've attached that photo to this ticket. I may be able to set the router's console to a higher resolution if necessary, to get the full traceback.
Is there somewhere in particular that the traceback might be getting written to a file?
Created attachment 276381 [details]
kernel config
Here is my kernel config.
I do note that the interface in question does seem to have RX errors, and I've noted this in the past. $ /sbin/ifconfig eth1 eth1 Link encap:Ethernet HWaddr 00:50:b6:00:78:ff inet addr:XX.XX.XX.XX Bcast:255.255.255.255 Mask:255.255.254.0 inet6 addr: fe80::250:b6ff:fe00:78ff/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:18453 errors:2 dropped:0 overruns:0 frame:2 TX packets:2688 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:1804937 (1.7 MiB) TX bytes:592019 (578.1 KiB) Let me know if there is any further information that I could provide. Thanks! Created attachment 277261 [details]
Traceback with Intel Pro/1000 chip
I decided to buy a more respectable network card to use for my WAN connection, so I got an Intel Pro 1000 Gigabit card. I expected this to resolve the problem, but it turns out that I am able to cause my router to kernel panic when it is using this card as well. I've attached a screen shot of the traceback (I still unfortunately wasn't able to see the whole thing on the console).
Is it possible for me to get the full traceback in text format from the disk somewhere, or does the kernel not log these to disk?
$ cat /etc/conf.d/net | sed "s/real_ip_addresses/Xs" # This blank configuration will automatically use DHCP for any net.* # scripts in /etc/init.d. To create a more complete configuration, # please review /etc/conf.d/net.example and save your configuration # in /etc/conf.d/net (this file :]!). config_eth0="null" # Build a bridge on eth0, so our virtual hosts can get on the local network. bridge_br0="eth0" config_br0="192.168.25.1/24 2001:XXXX:XXXX:XXXX::1/64" depend_br0() { need net.eth0 } # We get a WAN IP address from Time Warner config_eth1="dhcp" dns_search_eth1="mydomain.com" # Our he.net IPv6 tunnel! # using IProute2 method, makes it easier :) modules="iproute2" iptunnel_he6="mode sit remote 216.66.22.2 local XXX.XXX.XXX.XXX ttl 255" depend_he6="net.eth1" config_he6="2001:XXXX:XXXX:XXXX::2/64" routes_he6="default via 2001:XXXX:XXXX:XXXX::1 dev he6" Just to make it clear, this machine has two physical NICs. eth0 is my internal LAN interface, and eth1 is connected to my cable modem. I do a bridge on eth0 with some virtual machines, and that bridge is the virtual LAN interface as well. I use iptables to do NAT and a little packet forwarding, and ip6tables to do some packet filtering. If any more information about my particular setup would be helpful, let me know! This is really hard to debug with a full trace. Have you tried 3.1? This may have to go upstream I meant "without", of course. I gave up on using this NIC in favor of a proper internal NIC (Intel based too!) a few months ago. I do still have it, though I am not using it for anything. If you would prefer to close this ticket, I wouldn't be sad (or you can keep it open in case anyone else has this problem…) ok, thanks, closing for now, then. Hopefully this problem does not reappear for anyone else. |