Filesystem panic in 5.2.1-RELEASE

Oops, posted this to the wrong list.

Summary: I built a new 5.2.1 system yesterday, and it was fine while
building a new kernel. This morning I've had it panic twice while doing
relatively innocuous things, details attached.

I've had it suggested to me that I should disable ACPI, so I have now added
hints.acpi.0.disabled="1"
to /boot/device.hints

I'll see if that makes anything more stable, but otherwise I'd be interested
in other people's comments about the crashes I've seen.

I would have stuck with 4.x, except the nVidia ethernet driver wasn't
supported, so I thought that would be a good reason to try 5.2.1 (answer:
that doesn't support the network driver either! But there's a separate
module available)

Regards,

Brian.

attached mail follows:

Oh dear, my first experience with FreeBSD-5.2.1-RELEASE is not good:

---------------------------------------------------------------------------
...
playdog# mv downloads /v/downloads/nvidia
playdog# ln -s ../v/downloads .
mode = 040700, inum = 82, fs = /u
panic: ffs_valloc: dup alloc

syncing disks, buffers remaining... 131 131 129 129 129 129 129 129 129 129 12
9 129 129 129 129 129 129 129 129 129 129 129
giving up on 90 buffers
Uptime: 18m55s
Shutting down ACPI
Automatic reboot in 15 seconds - press a key on the console to abort
---------------------------------------------------------------------------

This is a freshly-installed machine [*]:
  Soltek EQ3702A
  Athlon 2500+ processor (166MHz FSB), 512MB RAM (166MHz)
  nVidia chipset

/u and /v are two slices on the same Western Digital 80GB IDE drive.

[*] Actually it previously had a 4.8 install on it. I did an install over
and newfs'd all the slices except data slices /u, /v, /w; I noticed that
sysinstall did an fsck_ffs on those slices.

I had compiled and was running my own kernel, which was just GENERIC with
some stuff taken out (removed I486/I586, INET6, most of the SCSI stuff). I
was getting ready to compile an nvidia network driver - I had attached a USB
floppy, copied some files off it, and unmounted the floppy, before doing the
lines shown above.

The system was running for several hours yesterday, including a complete
kernel rebuild, without any crashing - so I'm fairly sure the hardware is
OK.

The only odd thing I have noticed about this system is that when running the
GENERIC kernel (from the install CD or after installation), it locks up just
after mounting the root filesystem, requiring a hard reboot. The only way to
get round this is to choose "safe mode" at boot time. However when running
my own compiled kernel I don't have this problem.

A diff of my kernel against GENERIC is attached. Sorry I don't have anything
else like a crash dump.

I was rather hoping not to see this sort of problem with 5.2.1; maybe I
should just install 4.9 instead :-(

Regards,

Brian.

attached mail follows:

Whoa, another crash, this time when plugging in the USB floppy:

playdog# 
umass0: Y-E DATA FlashBuster-U, rev 1.00/1.14, addr 2
umass0: at uhub1 port 3 (addr 2) disconnected
umass0: detached


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x10
fault code              = supervisor read, page not present
instruction pointer     = 0x8:0xc04a17f0
stack pointer           = 0x10:0xd62b2c90
frame pointer           = 0x10:0xd62b2cb0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, def32 1, gran 1
processr eflags         = interrupt enabled, resume, IPOL = 0
current process         = 28 (swi8: tty:sio clock)
trap number             = 12
panic: page fault

syncing disks, buffers remaining... 265 265 265 265 265 265 265 265 265 265 265
265 265 265 265 265 265 265 265 265
giving up on 191 buffers
Uptime: 17m13s
Shutting down ACPI
Automatic reboot in 15 seconds - press a key on the console to abort

Given the amazingly good track record of 4.x, I guess I really should be
suspecting a hardware problem now. But to be sure I need to downgrade to 4.x
- which I hope doesn't mean losing my ufs2 filesystems :-(

At least my filesystems are being checked in the background now...

Regards,

Brian.