Re: FreeBSD panics...

On Thursday 22 March 2007 20:58, Sławomir Babiński SYSINFO wrote:
Can anyone look at this and sell any tips why my server panics?

Wrong list. This should have been sent to -current or -net ...

root@mercury:/root# uname -a

FreeBSD mercury.msi.pl 6.2-STABLE FreeBSD 6.2-STABLE #7: Wed Mar 21
19:20:18 CET 2007 root@xxxxxxxxxxxxxx:/usr/obj/usr/src/sys/cobaltus
i386
...
#7 0xc0743318 in m_copydata (m=0x0, off=0, len=1, cp=0xc502bf08
"essful\r\n257 \"/\" is the current directory\r\n250 CWó\f")
at /usr/src/sys/kern/uipc_mbuf.c:543

#8 0xc048d71d in ippr_ftp_process (fin=0xe2d4db30, nat=0xca66e400,
ftp=0xc502be00, rv=1) at ip_ftp_pxy.c:1192
#9 0xc048db2c in ippr_ftp_in (fin=0xe2d4db30, aps=0x0, nat=0xca66e400)
at ip_ftp_pxy.c:1358
#10 0xc0492dfb in appr_check (fin=0xe2d4db30, nat=0xca66e400) at
/usr/src/sys/contrib/ipfilter/netinet/ip_proxy.c:540
#11 0xc048a8af in fr_natin (fin=0xe2d4db30, nat=0xca66e400, natadd=1,
nflags=1)
at /usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4105
#12 0xc048a744 in fr_checknatin (fin=0xe2d4db30, passp=0xe2d4db2c) at
/usr/src/sys/contrib/ipfilter/netinet/ip_nat.c:4040
#13 0xc047c666 in fr_check (ip=0xc4a18820, hlen=20, ifp=0x0, out=0,
mp=0xe2d4dc18)
at /usr/src/sys/contrib/ipfilter/netinet/fil.c:2466

Looks like a good example why it is a bad idea to have an application
proxy running in the kernel. More to the point, could you provide "fin"
in frames 8 through 12 and the local variables in frame 8, too?

--
/"\ Best regards, | mlaier@xxxxxxxxxxx
\ / Max Laier | ICQ #67774661
X http://pf4freebsd.love2party.net/ | mlaier@EFnet
/ \ ASCII Ribbon Campaign | Against HTML Mail and News

Attachment: pgp22dDyhDelT.pgp
Description: PGP signature

Relevant Pages

  • Re: pin/bind a pthread to a processor? (take 2)
    ... Dan Eischen and Julian Elischer, ... The same is true for the kernel, only I create a thread in the kernel with kthread_create and then bind and pin it. ... While this is not the end of the world, it is causing me difficulties with my experiments as I'm trying to process 1,488,095 Ethernet frames per second, meaning a new 64B frame is ready every 672ns. ...
    (freebsd-hackers)
  • Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
    ... at the end of _fpstate. ... apps can check for uc_flag aswell, ... I would suggest using the uc_flag for the rt frames, and simply rely on the OSXSAVE flag for non-rt signal frames. ... It a rather sucky approach, but since any sane user of these fields (as opposed to just relying on the kernel to save/restore) should use the SIGINFO frames, I don't see a problem *as long as it's possible to get the information* -- any solution which demands performance should just turn on SIGINFO and be happy. ...
    (Linux-Kernel)
  • Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
    ... This issue of not-zeroing, is present in only 64bit kernels and for 64bit apps, ... kernel was always zero'ing the reserved bits ... at the end of _fpstate. ... In short, for non-rt frames, they can check the reserved bits at the end ...
    (Linux-Kernel)
  • Re: [RFC] x86: xsave/xrstor support, ucontext_t extensions
    ... > Suresh Siddha wrote: ... >> In short, for non-rt frames, they can check the reserved bits at the end ... > the OSXSAVE flag for non-rt signal frames. ... kernel also need to find out what layout ...
    (Linux-Kernel)
  • Re: Question about fair schedulers
    ... understanding that it would give 50% CPU to each task, resulting in the video dropping frames. ... For example, if my job is as a programmer and I'm waiting for a build during lunchbreak then I may not care that the process in the background makes my DVD-player drop a few frames, as long as it gets done 10% quicker. ... If you want the kernel to treat one job or the other as more important then you must *TELL* it that, ... It's just that an ideal scheduler shouldn't drop frames in this case (it should give 70% to the video even without nicing the encoder). ...
    (Linux-Kernel)