[replies sent directly to me may timeout and bounce, since I'm not
 online as often as I should be, but I'll check the list archives]

Aiee, aiee.  One hardware-related failure resulted in the root
filesystem getting hosed, with trashed inodes for a couple
links, a couple empty directories, a couple kernel modules, and a
couple loader-related files in /boot going missing.

The result of this is that when the normal bootblocks couldn't
find the missing (corrupt/bad format) /boot/loader, it defaulted to
booting as happens when one gives a keypress and (as seen in manpage)
     >> FreeBSD/i386 BOOT
     Default: 0:ad(0,a)/kernel
appears, but of course one has to specify /boot/kernel/kernel
(or more likely /boot/loader.old, if one has it and actually knows
enough to do so rather than trying the kernel, which I didn't)

Which is fine until the kernel loads and starts booting.  Then
it appears to change to a block cursor as normal except that no
kernel messages are appearing on the screen.

If I'm not mistaken, this is what happens when the hints file is
missing.  (I've been offline for many months and haven't downloaded
all the archives to brush up on that discussion.)  No booting
single-user or nuthin.  I couldn't think of a workaround, other
than to replace the missing /boot/loader which worked.

Am I correct that without statically compiling hints into the
kernel proper, you can't boot a kernel directly from the above
prompt with -current, as one used to in the past, or if one loses
the loader like I did?  (Looking at the archive, it seems someone
else has just experienced similar)

Other non-panic but leftover from the panic that affected /var
described above was the kernel message
  Jan  3 01:37:52 dastardly kernel: /var: mount pending error: blocks 40 files 9
(I had just fsck -p'ed /var from -stable, which resulted in a spew
of messages but no claim as with the hosed root filesystem that I
had to run fsck by hand.)  I don;t know if this is something worth

Also of note, these messages when I attempt to play an mp3 file
with mpg123 through an ES1868 sound card:
Jan  3 01:43:56 dastardly kernel: lock order reversal
Jan  3 01:43:56 dastardly kernel: 1st 0xc13dbf80 sbc0 @ 
Jan  3 01:43:56 dastardly kernel: 2nd 0xc13ef340 pcm0:play:0 @ 

No problems (other than sounding like crap, being a 75MHz machine)
were obvious.  If this means anything, I can provide more details.
(Actually, it only sounds like crap because I give an option that
seems to need more CPU -- without it, the machine actually has some
5% idle time and the mp3 sounds fine)

I've mentioned earlier that I've had some panics when playing with
unionfs mounts under -current, probably to be expected.  I've been
able to panic NetBSD doing union mount things that I haven't yet
tried under FreeBSD, although some things work there which fail
under FreeBSD, such as the cursed getcwd() problem.  And some things
don't work, so I need to verify if it's a common problem in the unionfs
code on both systems.  More about this later.  (Okay, it's later,
and no, these things are not problems under freebsd)

On the subject of kernel messages, I'm guessing that
swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 272, size: 4096
swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 256, size: 4096
swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 256, size: 4096
swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 264, size: 4096
swap_pager: indefinite wait buffer: device: #ad/0x40001, blkno: 264, size: 4096
is not of great concern, and is a result of the disk being very busy
doing a copy of a large file or something similar I was doing at the
same time.  No panic resulted.  (that might have been -stable)

acpi0: AcpiHwObtainSleepTypeRegisterData failed - AE_NOT_FOUND
this happens when I hit ctrl-alt-space with -current, of course no

FWIW, I've got device `apm' defined in the -current kernel config
but it never seems to appear on three machines, one of which has
the above acpi0, and all three of which have `apm' without problems
in -stable...  Probably not a concern, because in spite of this, I
can still get results from the command `apm' and I am able to power
down the machine automagically at shutdown.

As usual, these are just observations, and I could be stumbling
upon something well-known or discussed to death when I Had a Life.

barry bouwsma

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to