Re: HEADSUP!!! USB MFC committed..

2004-03-08 Thread Yoshihiko Sarumaru
Hello,

julian wrote:

> > With GENERIC kernel, it is fine and there are no changes from
> > before, but with no usb kernel + usb.ko + umass.ko, it would be
> > panic everytime on boot.
> > 
> > It is not depend on umass. The panic would be happen when I
> > didn't load umass.ko but ucom.ko + umodem.ko and plug USB modem
> > (PHS phone).
> 
> do you need a usb device plugged in for the panic?
> I can not duplicate this..

Because of my laptop has MemoryStick reader inside, I can't
boot without a USB device. But when I boot without umass.ko, it
wouldn't panic at all.
Off cource in that case, load umodem and plug USB modem causes
panic (load umodem but not plug USB modem doesn't cause panic).

So maybe the answer for you question is yes.

--
Yoshihiko Sarumaru
mail: [EMAIL PROTECTED]   web: http://www.imasy.or.jp/~mistral/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Kernel Dump

2004-03-08 Thread Doug White
On Sat, 6 Mar 2004, Forrest W. Christian wrote:

> I recently swapped out a motherboard in a FreeBSD server for a new Intel
> Pentium 4 motherboard/processor to gain speed.
>
> Since that time, this machine has been randomly panicing such as:
>
> Fatal trap 12: page fault while in kernel mode
> mp_lock = 0003; cpuid = 0; lapic.id = 
> fault virtual address   = 0x36

null pointer offset deref.

> fault code  = supervisor write, page not present
> instruction pointer = 0x8:0xc01f60fe
> stack pointer   = 0x10:0xf25cdab8
> frame pointer   = 0x10:0xf25cdb58
> 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 = 454 (perl)
> interrupt mask  = net bio cam  <- SMP: XXX
> trap number = 12
> panic: page fault
> mp_lock = 0003; cpuid = 0; lapic.id = 
> boot() called on cpu#0
>
> >From my symbol table, this particular panic appears to have occured in
> vm_fault:
>
> c01f5fcc T vm_fault
> c01f6b1c T vm_fault_wire

thats not too unsuprising. Can you follow the instructions in the handbook
to get a crashdump and use gdb to get a backtrace?

>
> This appears to be pretty consistent (the instruction pointer).  It used
> to panic both where I mentioned above and also in pmap.c.  Since I did the
> last cvsup and kernel rebuild, I haven't seen one from the pmap area.
>
> Any ideas?
>
> - Forrest W. Christian ([EMAIL PROTECTED]) AC7DE
> --
> The Innovation Machine Ltd.  P.O. Box 5749
> http://www.imach.com/Helena, MT  59604
> Home of PacketFlux Technologies and BackupDNS.com   (406)-449-3345
> --
>   Protect your personal freedoms - visit http://www.lp.org/
> ___
> [EMAIL PROTECTED] mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
>

-- 
Doug White|  FreeBSD: The Power to Serve
[EMAIL PROTECTED]  |  www.FreeBSD.org
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Using read-only NULLFS leads to panic. gdb output included, e asy to reproduce.

2004-03-08 Thread Tim Robbins
On Mon, Mar 08, 2004 at 09:58:47AM +0100, Helge Oldach wrote:

> Did I miss this MFC, or haven't you back-ported it yet?

Here's the patch against RELENG_4:
http://people.freebsd.org/~tjr/nullfs-4.diff

It works, but I'm not going to commit it until I've had time to
check a few things first.


Tim
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


Re: Kernel Dump

2004-03-08 Thread Forrest W. Christian
On Mon, 8 Mar 2004, Doug White wrote:

> null pointer offset deref.
>
> thats not too unsuprising. Can you follow the instructions in the handbook
> to get a crashdump and use gdb to get a backtrace?

There is a backtrace and more detail in another message I posted to the
list within the last few hours (subject is "-STABLE panic (usually) in
vm_fault")

I still have the dump laying around so if you'd like me to pinpoint some
of the callpoints in the traceback, let me know (but again, this has been
cvsupped in the last 48 hours or so so the line numbers should be fairly
close).

- Forrest W. Christian ([EMAIL PROTECTED]) AC7DE
--
The Innovation Machine Ltd.  P.O. Box 5749
http://www.imach.com/Helena, MT  59604
Home of PacketFlux Technologies and BackupDNS.com   (406)-449-3345
--
  Protect your personal freedoms - visit http://www.lp.org/
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


vnode_pager_putpages hanged my machine

2004-03-08 Thread Rob


Hi,

This is one of my first crashes of FreeBSD on my PC. Having lots of faith in
this OS, I still think it's one too many :).
While using ImageMagick's convert (as a user, NOT as root!), to generate an
mpeg file from a bunch of tiff files, my machine went bezerk (gradually slowed
down until no response at all anymore) and I had to hit PC's reset button to
reboot.
Did the machine end up in an eternal loop and ate up all resources?
A bug in vnode? Or in the pager?
My kernel and world update is from last week, Wed. March 3rd.
All other software is up-to-date with today's ports.
After reboot, I found this in /var/log/messages, before the reboot messages:

[...]
Mar  9 15:25:51 cisr /kernel: pid 57668 (convert), uid 1001, was killed: out of swap 
space
Mar  9 15:27:21 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:21 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 49152 at 400
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 404
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 405
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 406
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 407
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 408
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 409
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 410
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 411
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 412
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 413
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 414
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: pid 3 (pagedaemon), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 415
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 416
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 417
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 418
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 419
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: residual I/O 65536 at 420
Mar  9 15:27:22 cisr /kernel: pid 7 (syncer), uid 0 on /var: file system full
Mar  9 15:27:22 cisr /kernel: vnode_pager_putpages: I/O error 28
Mar  9 15:27:22 cisr /kernel: vnode