Slow Boot from OpenBSD 3.4

email toby...

I have noticed that my new 3.4 systems do come up a bit slower. Its not ten minutes, but it is 45 seconds of drive detection that I cannot bypass.

Once it starts, its peppy as sin, its honestly the only problem I have had 3.4, if I can even call it that.

You may want to "cvs diff" /usr/src/sys/stand/boot/ from 3.0 to -current to see what changes were made, and how they might impact your system.

What you're seeing is the /boot program (which is loaded from biosboot, and is in charge of setting up a few baseline i/o devices, and most importantly booting the actual kernel) doing something different in its disk detection.

I've had the same problem and in the installation procces, when ask to install in the whole disk, I responded no, then the first partition would be number 0 or what we'll wish. In case we chose full disk the system install in partition 3 and the boot process check all partition from 0 to 3.
May be this is not the right solution but it work for now.

I'm having the same problem on my laptop (p3-850), but not on my desktop (p2-266)...
Maybe some change broke something on certain hardware configurations. Is there a way we can gather useful information for the developers?

Is that "black fade-out" problem still present in OpenBSD 3.4? This is the one where you start X, and when you change to a text terminal (Ctrl+Alt+F1) you get darkened text... which keeps getting darker and darker till you can't see a thing.

Is it still there? If it is, what can I do to fix it?

When I went from 3.2 to 3.3, I found that boot hung for a long time on the IDE CDROM drive (a really old one in my 133 MHz P5 gateway machine).

In my kernel config file, I commented out the line that started with 'atapciscsi* at pciide?' and replaced it with 'atapciscsi0 at pciide? channel 1 flags 0x0fac'. I left a comment to myself "force PCI mode 3 for cdrom" (back in May '03).

It doesn't hang for (about a minute) on boot, anymore. I vaguely recall searching google for related things and diff'ing the 3.2 vs. 3.3 PCI code, and somehow stumbling on the PCI mode change after trying a few different versions of the flags (and the related re-compile!).

Might be worth a try...

I have no probles doing 3.4 on my laptop, nor on desktop ... Just try reinstaling /boot from src

you might help yourself with more info ... dmesg, here's an example . More info, the more likely a result.

you might help yourself with more info ... dmesg, here's an example - http://slashdot.org/~goon/journal/49959. More info, the more likely a result.

I appreciate the suggestions and apologize for not including the dmesg which would have at least included my BIOS version. The BIOS is a little strange, and that's probably why it gave me a problem. It's an AMI BIOS dated 10/10/94 and the CMOS setup allows for setting parameters for the 2 primary IDE devices, but for the secondary IDE it only has enable/disable and turning 32 bit and block mode on and off. I don't think anything in the kernel configuration would affect it since the problem happens before the kernel starts to load.

I ended up doing a hack on the boot code. I looked at biosboot.S and boot.c and didn't see anything that looked like probing for drives, not that I really understood what I was looking at. I then did a grep for "probing" which it prints out before it gets to the point where it pauses for such a long time. One of the places grep found it was /usr/src/sys/arch/i386/stand/libsa/diskprobe.c which sounded like a likely spot to check. There was a section with the comment /* Probe for all BIOS hard disks */. It looked like I was on the right track. A for loop looked like it was checking for up to 8 devices going from 0x80 to
wd0: 128-sector PIO, LBA, 516MB, 1048 cyl, 16 head, 63 sec, 1056992 sectors
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
vga0 at isa0 port 0x3b0/48 iomem 0xa0000/131072
wsdisplay0 at vga0: console (80x25, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ne1 at isa0 port 0x300/32 irq 10
ne1: NE2000 Ethernet
ne1: address 00:00:b4:67:f8:33
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask 4040 netmask 5440 ttymask 54c2
pctr: no performance counters in CPU
dkcsum: wd0 matched BIOS disk 80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302

Thanks Again,
Jim
.

Sorry for that last post, I wasn't thinking and used a "less than" symbol and it looks like it was interpreted as the start of a html tag and prevented a bunch of what I was saying from showing up.

I appreciate the suggestions and apologize for not including the dmesg which would have at least included my BIOS version.
The BIOS is a little strange, and that's probably why it gave me a problem. It's an AMI BIOS dated 10/10/94 and the CMOS
setup allows for setting parameters for the 2 primary IDE devices, but for the secondary IDE it only has enable/disable and
turning 32 bit and block mode on and off. I don't think anything in the kernel configuration would affect it since the problem
happens before the kernel starts to load.

I ended up doing a hack on the boot code. I looked at biosboot.S and boot.c and didn't see anything that looked like probing for
drives, not that I really understood what I was looking at. I then did a grep for "probing" which it prints out before it gets to the
point where it pauses for such a long time. One of the places grep found it was /usr/src/sys/arch/i386/stand/libsa/diskprobe.c
which sounded like a likely spot to check. There was a section with the comment /* Probe for all BIOS hard disks */. It looked
like I was on the right track. A for loop looked like it was checking for up to 8 devices going from 0x80 to less than 0x88 and anding the number with 0xf7 when it printed out the drive
number. I changed the 88 to 82. There was a Makefile in the directory so
I tried a make and got errors. I went to the parent directory "stand"
and there was not only a Makefile but a README as well. I read the
README which was about making and installing boot. I ran make and copied
the resulting boot the floppy I had used to install OpenBSD 3.4. I tried
running installboot as instructed by the README file, but it told me the
device was busy. I'm not sure if it was the README or the installboot
man page, but one of them told me I had to be in single user mode to
rewrite the MBR/PBR. Since the MBR/PBR on the floppy was already calling
for it to run /boot, I figured that installboot probably wasn't needed
and I rebooted. The floppy worked; no long pauses. I went to the shell
and copied the boot from the floppy to the hard drive (after backing up
the original boot) and rebooted. It seems like the hack worked fine. I
just have to remember what I did in case I want to use the secondary IDE
sometime.

If anyone has a more elegant solution, one which would allow me to use the default boot, I would apreciate hearing it. But, for now I'm satisfied with this hack.

dmesg:
OpenBSD 3.4 (BERK) #3: Fri Nov 7 10:10:29 EST 2003
root@berk.d.hpe:/usr/src/sys/arch/i386/compile/BERK
cpu0: AMD Am5x86 W/B 133/160 ("AuthenticAMD" 486-class)
cpu0: FPU
real mem = 49922048 (48752K)
avail mem = 43409408 (42392K)
using 635 buffers containing 2600960 bytes (2540K) of memory
mainbus0 (root)
bios0 at mainbus0: AT/286+(00) BIOS, date 10/10/94, BIOS32 rev. 0 @ 0xf6f20
pcibios0 at bios0: rev. 2.1 @ 0xf0000/0x10000
pcibios0: PCI BIOS has 3 Interrupt Routing table entries
pcibios0: no compatible PCI ICU found
pcibios0: Warning, unable to fix up PCI interrupt routing
pcibios0: PCI bus #0 is the last bus
bios0: ROM list: 0xc0000/0x8000
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
ne3 at pci0 dev 14 function 0 "Realtek 8029" rev 0x00: irq 12
ne3: address 00:a0:76:a0:10:72
pchb0 at pci0 dev 16 function 0 "UMC UM8881F PCI-Host" rev 0x04
pcib0 at pci0 dev 18 function 0 "UMC UM8886" rev 0x0e
pciide0 at pci0 dev 18 function 1 "UMC UM8886BF" rev 0x10: DMA (unsupported), channel 0 configured to compatibility, channel 1 configured to compatibility
wd0 at pciide0 channel 0 drive 0:
wd0: 128-sector PIO, LBA, 516MB, 1048 cyl, 16 head, 63 sec, 1056992 sectors
pciide0: channel 1 ignored (not responding; disabled or no drives?)
pckbc0: using irq 1 for kbd slot
wskbd0 at pckbd0: console keyboard
vga0 at isa0 port 0x3b0/48 iomem 0xa0000/131072
wsdisplay0 at vga0: console (80x25, vt100 emulation), using wskbd0
wsdisplay0: screen 1-5 added (80x25, vt100 emulation)
ne1 at isa0 port 0x300/32 irq 10
ne1: NE2000 Ethernet
ne1: address 00:00:b4:67:f8:33
pcppi0 at isa0 port 0x61
spkr0 at pcppi0
sysbeep0 at pcppi0
lpt0 at isa0 port 0x378/4 irq 7
npx0 at isa0 port 0xf0/16: using exception 16
pccom0 at isa0 port 0x3f8/8 irq 4: ns16550a, 16 byte fifo
pccom1 at isa0 port 0x2f8/8 irq 3: ns16550a, 16 byte fifo
fdc0 at isa0 port 0x3f0/6 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB 80 cyl, 2 head, 18 sec
biomask 4040 netmask 5440 ttymask 54c2
pctr: no performance counters in CPU
dkcsum: wd0 matched BIOS disk 80
root on wd0a
rootdev=0x0 rrootdev=0x300 rawdev=0x302

Thanks Again,
jim
.

When I bootup 3.4 I get,

disks: hd0+ hd1+
>> OpenBSD Boot Loader 2.02
- (This normally moves, but now it doesnt)

In 3.3 it works flawless ..
I also tried to bootup from the cdrom and then boot the kernel on the hdd ..
But then I get a bootloader prompt and when I type boot wd0a:/bsd it saiz "Booting wd0a:/bsd /(this normally moves but now it doesnt)" and it seem to freeze :s
Don't know what the problem is ..

I had exactly the same problem, and similar environment, old Pentium Pro 200, ancient cdrom, ancient AMI BIOS,...

Nothing seemed to work until I noticed the master/slave jumper on the cdrom was set to slave.

Usually it doesn't seem to make any difference but setting it to master fixed the problem immediately - booting now passes the hd detection part instantly.

I tested it a few times by rebooting with the jumper in either setting, the slow hd detection problem always came back when set to slave.