Panic: Fatal trap 12: page fault while in kernel mode
Hi, I was playing around with CAM and got this reproducible panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x46 fault code = supervisor read, page not present instruction pointer = 0x:0xc03962fe stack pointer = 0x10:0xd835b9b4 frame pointer = 0x10:0xd835ba24 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 585 (dvdtest) kernel: type 12 trap, code=0 Stoppes at generic_bcopy+0x1a: repe mocsl (%esi),%es:(%edi) db> tr generic_bcopy(c4034780,c4205000,d835ba58,c0136c42,c4034780) at generic_bcopy+0x1a sbp_action(c4034780,c4205000,c0136953,c41f1400,c4205000) at sbp_action+0x18 xpt_run_dev_sendq(c4034740,c41f1418,0,d835ba8c,c027895f)at xpt_run_dev_dendq+0x192 xtp_action(c4205000,0,c41f1430,c4202000,c4205000) at xpt_action+0x238 cam_periph_runccb(c4205000,0,2,1,c40fb960) at cam_periph_runccb+0x48 passsendcbb(c41e6500,c4205000,c4203400,c462920) at passsendccb+0xc7 passioctl(c4213100,c2601502,c4203400,3,c401fbe0) at passioctl+0xf0 spec_ioctl(d835bb7c,d835bc28,c02c34a1,d835bb7c,c025454d) at spec_ioctl+0x19e spec_vnoperate(d835bb7c,c025454d,c0460ea0,1,c0447b00) at spec_vnoperate+0x18 vn_ioctl(c422c330,c2601502,c4203400,c42c9480,c401fbe0) at vn_ioctl+0x1a1 ioctl(c401fbe0,d835bd10,c03f9491,3ec,3) at ioctl+0x475 syscall(2f,2f,2f,bfbffb90,bfbff910) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (54, FreeBSD ELF32, ioctl), eip = 0x281a354f, esp = 0xbfbff8dc, ebp = 0xbfbff8f8 --- db > Kernel is from this morning with up to date sources and ATAPICAM built in: FreeBSD cheops.phoenix 5.1-CURRENT FreeBSD 5.1-CURRENT #7: Sun Sep 21 14:05:38 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CHEOPS i386 If you need further information or the source that caused the panic, please let me know. Regards, Markus -- GPG Pub-Key: http://www.phoenix-systems.de/mbrueffer.asc GPG Fingerprint: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 GPG Key ID : 0x78F8A8D4 pgp0.pgp Description: signature
Re: mpd, ng, Cisco VPN, resource leak
Hi Christoph On Monday 16 June 2003 16:03, Christoph Kukulies wrote: > For months I'm trying to get back to a working VPN using mpd > on a FreeBSD 4.4 client site and a Cisco VPN server on the peer end. > > With 5.0 and 5.1-current the network connection stopped working. > > I could work for a minute or so then the connection got hung. > Trying to reconnect with a new ssh session got some message > about 'resource deadlock avoided' and a subsequent ping to the peer side > gets the onminous 'no buffers space available' or an additional : > > > [EMAIL PROTECTED] ssh acc01 > ssh: connect to host acc01 port 22: Connection refused > [EMAIL PROTECTED] ping acs01 > PING acc01 (138.134.123.12): 56 data bytes > ping: sendto: Resource deadlock avoided > ping: sendto: No buffer space available > ping: sendto: No buffer space available > ^C > --- acc01 ping statistics --- > 3 packets transmitted, 0 packets received, 100% packet loss > > > The connection refused occurs on the peer side where the previous > ssh connection had succeeded. It's not that the sshd died. Rebooting > my system allows be to connect again for a minute or 2 and then again > the hang. > > How could I pinpoint the problem so that some knowing kernel/netgraph > person will be available to find the cause? > > Is there a way to do a continous netstat -m or vmstat -m during a session > setup? I mean other than writing it to a file in a shell while loop? I know exactly what you are talking about. I had the same problems here. Please have a look at http://www.cs.rpi.edu/~flemej/fbsd-cisco-vpn/ . That (partly) solved the problems for me, however I have to set the routes to the subnets behind the VPN-server manually after establishing a connection to the VPN-server via mpd. If I set the routes in the mentioned script, the routingtable seems to be ok, but setting the routing entrys this way leads to the same problems you already mentioned. I have no idea whats wrong and why I have to set them manually. Perhaps we can figure out this minor last problem together. Best Regards, Markus -- GPG Pub-Key: http://www.phoenix-systems.de/mbrueffer.asc GPG Fingerprint: 3F9B EBE8 F290 E5CC 1447 8760 D48D 1072 78F8 A8D4 GPG Key ID : 0x78F8A8D4 pgp0.pgp Description: signature
