The le NIC driver causes a kernel panic and reboot when ifconfig is used. This was observed on two separate machines with different hardware configurations and a DE201 NIC, and was also reported on -questions by others with different DE20x cards and setups. The cards I used to test were known to work under 3.x. Everything from 4.0-R to the current -STABLE displays this behaviour. The machine boots up fine, recognizes the card and crashes as soon as ifconfig(8) is run. Fatal trap 12: page fault while in kernel mode fault virtual address = 0x0 fault code = supervisor read, page not present instruction pointer = 0x8:0x0 stack pointer = 0x10:0xce323d70 frame pointer = 0x10:0xce323d84 code segment = base rx0, limit 0xffff, tytpe 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 168 (ifconfig) interrupt mask = net trap number = 12 panic: page fault Fix: Sorry, no fix. How-To-Repeat: Install DE20x NIC on 4.0 machine and rebuild kernel with le driver. Manually run ifconfig on le0 and watch it crash and burn.
State Changed From-To: open->feedback Hi Alex To be able to help you debug this problem we need some more information. Please see the FAQ (http://www.FreeBSD.org/FAQ/FAQ.html) section 'For serious FreeBSD hackers only' question 'Making the most of a kernel panic' for info how you can help us getting the info we need. Please send the info as a follow-up to this PR by sending a mail to 'freebsd-gnats-submit@FreeBSD.org' with the subject of this mail as subject. Or if the problem has been solved in later version of FreeBSD please let us know that as well. Thanks Johan K
State Changed From-To: feedback->closed Feedback timeout
I am seeing this problem in a 4.3-STABLE system. It runs fine until I try to start the network; then it crashes. The kernel backtrace looks like this: #0 dumpsys #1 boot #2 poweroff_wait #3 trap_fatal #4 trap_pfault #5 trap #6 ?? #7 intr_mux #8 vec9 #9 softclock #10 splz_swi #11 in_control #12 if_ioctl #13 soo_ioctl #14 ioctl #15 syscall2 #16 Xint0x80_syscall #17 ?? #18 ?? I'm available to dig more information from the dump whenever you ask. (The machine is almost useless when it's off the net, and I want to get it back up and running.)