I have a very old machine (Dell OptiPlex GXa 300M EM+) that I use for several things running OpenBSD. For such an old machine (300 MHz Pentium II CPU), it’s been rock solid for the work I put on it. It started life as either OpenBSD 4.1 or 4.2 and has steadily been upgraded with each release with no issues. Well that was until 5.1. The upgrade for 5.0 to 5.1 happened just as all of the others — completely uneventful. The “fun” began after I booted into the freshly installed 5.1 system. As the kernel was loading, it would almost immediately drop into ddb:
OpenBSD 5.1-stable (GENERIC) #0: Mon May 28 22:28:09 EDT 2012
root@apophis.ext.theory14.net:/usr/src/sys/arch/i386/compile/GENERIC
cpu0: Intel Pentium II ("GenuineIntel" 686-class, 512KB L2 cache) 299 MHz
cpu0: FPU,V86,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,MMX
real mem = 402194432 (383MB)
avail mem = 385519616 (367MB)
mainbus0 at root
bios0 at mainbus0: AT/286+ BIOS, date 12/15/98, BIOS32 rev. 0 @ 0xffe90,
SMBIOS rev. 2.2 @ 0xfaa80 (59 entries)
bios0: vendor Dell Computer Corporation version "A09" date 12/15/98
bios0: Dell Computer Corporation OptiPlex GXa 300M EM+
apm0 at bios0: Power Management spec V1.2
acpi at bios0 function 0x0 not configured
pcibios0 at bios0: rev 2.1 @ 0xf0000/0x10000
pcibios0: PCI IRQ Routing Table rev 1.0 @ 0xfc650/128 (6 entries)
pcibios0: PCI Interrupt Router at 000:07:0 ("Intel 82371AB PIIX4 ISA" rev
0x00)
pcibios0: PCI bus #1 is the last bus
bios0: ROM list: 0xc0000/0x8000 0xc8000/0x8000
cpu0 at mainbus0: (uniprocessor)
pci0 at mainbus0 bus 0: configuration mode 1 (bios)
pchb0 at pci0 dev 0 function 0 "Intel 82443LX AGP" rev 0x03
intelagp0 at pchb0Stopped at pci_conf_write+0xdf: xorl %eax,%eax
pci_conf_write(0,80000000,90,7080,d1317cc0) at pci_conf_write+0xdf
agp_intel_attach(d1317d00,d1317c80,d0b97ca8,d03ead8b,0) at
agp_intel_attach+0x314
config_attach(d1317d00,d09b66a0,d0b97ca8,d070ed40,0) at config_attach+0x1bb
pchbattach(d1317e00,d1317d00,d0b97d54,d03ead8b,d05a2250) at pchbattach+0x19c
config_attach(d1317e00,d09b6600,d0b97d54,d05a43c0,d0b97db4) at
config_attach+0x1bb
pci_probe_device(d1317e00,80000000,0,0,317e00) at pci_probe_device+0x420
pci_enumerate_bus(d1317e00,0,0,d03ead8b,0) at pci_enumerate_bus+0x11c
config_attach(d1316fc0,d09b5040,d0b97e58,d05a1eb0,30000002) at
config_attach+0x1bb
mainbus_attach(0,d1316fc0,0,d09b5020,0) at mainbus_attach+0x213
config_attach(0,d09b5020,0,0,d0a25f40) at config_attach+0x1bb
ddb>
Simply continuing out of ddb would allow the system to finish booting and running as normal. Google searches didn’t really turn up much and my post to the OpenBSD Bug list didn’t get any attention. I’m far from a kernel developer or debugger, but after reading a bunch emails with similar booting issues, reading a number of man pages and some trial and error, it seems that the 5.1 GENERIC kernel and this machines AGP chips don’t get along so well. The solution was to disable the intelagp driver in the kernel. With this disabled, it’s back to booting normally with no ddb fun.
To make the kernel changes I just used config(8) to modify the existing kernel. A summary of the steps I used are (read the man pages before doing this!):
- Boot the system with GENERIC
- Follow the KERNEL_MODIFICATION section of config(8)
-
# config -e -o bsd.new /bsd
-
disable intelagp
-
quit
- Boot the new kernel.
theory14 