Bug 31710
| Summary: | kernel reboots; looks like an unintended trap in xl? | ||
|---|---|---|---|
| Product: | Base System | Reporter: | David Jones <djones> |
| Component: | kern | Assignee: | silby |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | Unspecified | ||
| Hardware: | Any | ||
| OS: | Any | ||
State Changed From-To: open->feedback Does this still happen on more recent releases? Adding to the audit trail: In message <99888.1038830050@zoonami.com>, David Jones writes: >In message <200212012016.gB1KGMII063459@freefall.freebsd.org>, Ian Dowse write >> Does this still happen on more recent releases? > >I have no idea. We replaced the xl0 with an fxp0 (a good while ago now) and >everything has been working just great. I'm not going to put the xl0 >back in just to experiment. Sorry. > >I can ship the xl0 to anyone that wants to investigate the problem if >they want. It's a 3Com 3C905C-TX-M (according to the sticker on the >PCB). > >Cheers, > drj Responsible Changed From-To: freebsd-bugs->silby I'm going to be looking into this. State Changed From-To: feedback->closed The busdma'd driver recently MFC'd to 4.8-stable appears to solve this problem. |
I am using smbclient to copy a number of files from a PC (beaker) to my FreeBSD box (topcat). The following command: smbclient //beaker/backup-home -U mhollis%mhollis -Tc backup-home.tar crashes the FreeBSD box. Usually having copied about 300 MB of the 9GB or so. It doesn't seem to matter where the tar file is (that is, which disk I choose to write it on). I've just worked out how to enable kernel crash dumps. Here's the output of gdb where: (kgdb) where #0 dumpsys () at ../../kern/kern_shutdown.c:469 #1 0xc01abe83 in boot (howto=256) at ../../kern/kern_shutdown.c:309 #2 0xc01ac200 in poweroff_wait (junk=0xc037a3ef, howto=0) at ../../kern/kern_shutdown.c:556 #3 0xc0316199 in trap_fatal (frame=0xc0383324, eva=3234354685) at ../../i386/i386/trap.c:951 #4 0xc0315e71 in trap_pfault (frame=0xc0383324, usermode=0, eva=3234354685) at ../../i386/i386/trap.c:844 #5 0xc0315a2b in trap (frame={tf_fs = 6750224, tf_es = -1058799600, tf_ds = -1061748720, tf_edi = -1061699328, tf_esi = 6751386, tf_ebp = -1070058640, tf_isp = -1070058672, tf_ebx = -1061699328, tf_edx = -1062043648, tf_ecx = 1868770924, tf_eax = 1431037, tf_trapno = 12, tf_err = 2, tf_eip = -1071055393, tf_cs = 8, tf_eflags = 68099, tf_esp = -1058777568, tf_ss = -1061846784}) at ../../i386/i386/trap.c:443 #6 0xc028fddf in xl_newbuf (sc=0xc0e45000, c=0xc0e45620) at ../../pci/if_xl.c:1716 #7 0xc028ffb0 in xl_rxeof (sc=0xc0e45000) at ../../pci/if_xl.c:1817 #8 0xc0290688 in xl_intr (arg=0xc0e45000) at ../../pci/if_xl.c:2036 (kgdb) frame 6 #6 0xc028fddf in xl_newbuf (sc=0xc0e45000, c=0xc0e45620) at ../../pci/if_xl.c:1716 1716 MCLGET(m_new, M_DONTWAIT); (kgdb) info local _mp = 0x0 _ms = 6751386 _mm = (struct mbuf *) 0x67049a m_new = (struct mbuf *) 0xc0b7c100 As you can see it's a generic kernel. I have these crash dumps lying around, let me know if you want any more information. Hardware details, etc. This is very annoying at the moment, because I was intending to use exactly that command to do my PC backups.