Quick OpenBSD question

H3X4D3C1M4L · Feb 27, 2007, 12:42 PM

I'm running OpenBSD on an old IBM desktop machine (P3 1GHz, 320MB SDRAM, newly installed power supply, 10GB primary HDD, CDROM and 100GB WD1000BB for storage). It has 3 network cards in it, 1 intel one and 2 DLink 10/100s (DFE-TX530's I think). Now, I've run every hardware test in the world, everything hardware wise checks out fine. At first I thought it was the custom kernel I built but as soon as I put the release 4.0 kernel in, fresh install, it was still unstable. I'm running a compltetely stock OBSD stable install compiled from source, and I disabled PnP in the bios (which seemed to mess with hotplug and make it alot more unstable).

The problem I have now is I can't leave it on overnight or it reboots itself, and there's nothing in /var/log/* that tells me anything. How can I enable error logging (or at least make it more verbose) and figure out what's making the machine unstable?

Malus · Mar 5, 2007, 04:20 PM

Have you solved this yet? Your best bet is to see if you can get it to crash and drop into the kernel debugger. To do so, I believe you just need to ensure that the kernel was built with "option DEBUG" in the kernel configuration file. Also, make sure the sysctl "dbb.panic" is set to 1 so that a panicking kernel will drop into ddb. If you can get any sort of crash dump, report it to OpenBSD and someone can probably fix it for you.

H3X4D3C1M4L · Mar 7, 2007, 03:45 PM

The thing is I've tried to get it to do that but I don't think its a kernel panic, I'll leave the machine for 4 hours and its fine, but I come back the next morning and its back at the login screen. Uptime shows its crashed and I can see the fsck in the dmesg! This is no good because the machine is a server, if I can't leave it running what good is it?

I'll try again and see if those options are enabled. I'll also try running just a stock 4.0BSD or maybe see if FreeBSD does the same thing, or if the current branch works better. (Right now I'm using stable)

Malus · Mar 8, 2007, 01:38 AM

Quote:

Originally Posted by H3X4D3C1M4L

I'll try again and see if those options are enabled. I'll also try running just a stock 4.0BSD or maybe see if FreeBSD does the same thing, or if the current branch works better. (Right now I'm using stable)

My desktop has a similar issue under FreeBSD, though it is not nearly as frequent; it only occurs once in a while. It doesn't panic either, implying that it is solely a hardware issue. It really should panic if it is a bug in the kernel.

H3X4D3C1M4L · Mar 12, 2007, 02:13 AM

The thing is I've run every hardware test in the book and then some... the poor machine has survived 1 week straight of the most intense burn ins I could concoct and it didn't once flinch!

Would it have anything to do with IRQ's and the fact that I don't have ACPI turned on in kernel? I disabled it when I built the kernel (I think its usually disabled by default) because it never seemed to work. I did notice after disabling some interrupt options for video and turning off the audio it got a little more stable... any idea on that one?

Malus · Mar 12, 2007, 03:21 PM

Quote:

Originally Posted by H3X4D3C1M4L

The thing is I've run every hardware test in the book and then some... the poor machine has survived 1 week straight of the most intense burn ins I could concoct and it didn't once flinch!

Would it have anything to do with IRQ's and the fact that I don't have ACPI turned on in kernel? I disabled it when I built the kernel (I think its usually disabled by default) because it never seemed to work. I did notice after disabling some interrupt options for video and turning off the audio it got a little more stable... any idea on that one?

If you think it is an IRQ problem, try "vmstat -i" and see how many interrupts have occurred thus far. If one device looks like it is way out of line compared to the others, it probably has some kind of issue. I think my stability problems are related to Nvidia's shitty binary blob driver, which happens to cause a lot of interrupts as well.

I don't think ACPI should matter too much; OpenBSD's ACPI support is undergoing a lot of work and probably won't be mature until 4.1 or 4.2. I don't think you will miss much by not using it.

H3X4D3C1M4L · Mar 17, 2007, 09:57 PM

OK I've tried all that, no avail BUT I did turn up some interesting stuff...
The machine is an IBM desktop machine with a P3 1GHz in it, and the BIOS I found out is geared entirely for windows.

I disabled IDE Performance mode (put it on compatible mode), disabled read prefetching and PCI bus parity and so far 13 hours and it was fine. The only thing I have problems with now is CVS causing the same kinds of crashes but at least no more spontaneous reboots. I think the CVS thing is due to the fact that my src tree is in poor poor shape after taking some damage and an accidental cp without a destination hehe.... but it seems to do it if I run CVS twice without rebooting.

Malus, what do you think of the CVS situation? I've just wiped the drives and I'm about to reinstall so any suggestions you have would be most welcome as your help so far has been quite valuable to me

Malus · Mar 19, 2007, 12:28 AM

Quote:

Originally Posted by H3X4D3C1M4L

OK I've tried all that, no avail BUT I did turn up some interesting stuff...
The machine is an IBM desktop machine with a P3 1GHz in it, and the BIOS I found out is geared entirely for windows.

I disabled IDE Performance mode (put it on compatible mode), disabled read prefetching and PCI bus parity and so far 13 hours and it was fine.

Yeah, a lot of drive performance options can cause problems on a lot of operating systems.

Quote:

Originally Posted by H3X4D3C1M4L

The only thing I have problems with now is CVS causing the same kinds of crashes but at least no more spontaneous reboots. I think the CVS thing is due to the fact that my src tree is in poor poor shape after taking some damage and an accidental cp without a destination hehe.... but it seems to do it if I run CVS twice without rebooting.

Malus, what do you think of the CVS situation?

Using cp without a destination should not cause any harm. It should only provide a nice error message. Sounds like serious corruption of the drive. If fsck didn't fix it, I would probably consider running some drive diagnostic utilities before reinstalling. There could be bad sectors on the disk.

Next time you break your source tree, just delete and redownload src. There's no point it repairing a broken source tree when you can just download it again.

Quote:

Originally Posted by H3X4D3C1M4L

I've just wiped the drives and I'm about to reinstall so any suggestions you have would be most welcome as your help so far has been quite valuable to me

I would run some diagnostic tests on the drives, install the newest release, and see what happens.

Usually, when I install a new OS, I:

Make a user account and use it with sudo when I need root privledges.
Update my system sources to the latest security release or stable branch.
Harden the OS by enabling relevant security features. I usually throw up a pf firewall and enable some security related sysctls.
Double check your ssh configuration and make sure it doesn't allow for root logins. It used to be allowed in the default OpenBSD install, but I'm not sure if that is the case anymore.
Disable any daemons I do not need (usually not a problem on BSD systems) and enable the ones I like.
Update the sources for ports and install whatever I feel like.

The best advice I can give is to read the manual and FAQ on OpenBSD's website. It answers just about every question for you.

H3X4D3C1M4L · Mar 26, 2007, 12:53 AM

Oh I've read all the man pages I could get my hands on, FAQ's guides etc but I'm still stumped.

I've got some interesting ideas though and I'll post back when I'm about to tear all my hair out.

I think it may be timer related at this point.

All the hardware passes fine but even still I can't help but wonder why Linux has the exact same problems....

H3X4D3C1M4L · Apr 18, 2007, 03:23 PM

So far nothing has helped. Next step is to try allowing the O/S to reassign IRQ's and such and try getting ACPI to work with the current branch (which has some new stuff from the upcoming 4.1 I think so worth a try).

Malus · Apr 22, 2007, 08:24 PM

Quote:

Originally Posted by H3X4D3C1M4L

So far nothing has helped. Next step is to try allowing the O/S to reassign IRQ's and such and try getting ACPI to work with the current branch (which has some new stuff from the upcoming 4.1 I think so worth a try).

Well, you could wait till May 1st, when 4.1 will be released.

H3X4D3C1M4L · May 1, 2007, 10:35 PM

Quote:

Originally Posted by Malus

Well, you could wait till May 1st, when 4.1 will be released.

Just so happens I've done that. We'll see if the machine survives building 4.1 stable then building the userland overnight and letting it idle all day.

Malus · May 7, 2007, 12:51 AM

Quote:

Originally Posted by H3X4D3C1M4L

Just so happens I've done that. We'll see if the machine survives building 4.1 stable then building the userland overnight and letting it idle all day.

Any luck?

H3X4D3C1M4L · May 15, 2007, 02:41 PM

Not as such. That motherboard is totally and completely useless so I scrapped it and built a whole new system. Completely stable for a few weeks now, running some stress and compiling the userland over and over.

You wouldn't happen to know if there's an additional APM module/daemon I need to spin down a SCSI hard drive... all the other IDE drives spin down in the time I've set in the BIOS but the SCSI drive doesn't spin down period. I looked through /usr/ports/sysutils but saw nothing on a cursory glance.

Malus · May 16, 2007, 02:34 AM

Quote:

Originally Posted by H3X4D3C1M4L

Not as such. That motherboard is totally and completely useless so I scrapped it and built a whole new system. Completely stable for a few weeks now, running some stress and compiling the userland over and over.

You wouldn't happen to know if there's an additional APM module/daemon I need to spin down a SCSI hard drive... all the other IDE drives spin down in the time I've set in the BIOS but the SCSI drive doesn't spin down period. I looked through /usr/ports/sysutils but saw nothing on a cursory glance.

You can use the scsi(8) command to spin up/down the disks manually (the spin down command is actually on the manpage), but I don't know of anything offhand that does it automagically in OpenBSD. I would search Google or check on a mailing list to see if anyone else has or knows a way of doing it. Worst case scenario would be that you have to write a patch to add support for it to apmd (which is pretty easy if you know C).

I'll probably be setting up an OpenBSD router in the next week or so; perhaps I won't be so rusty with it after I set that up. However, it will run off a CF Card and not a SCSI disk, so it won't be quite the same.