Hey, newbie here, I had major freezes very early in the CD install process (kbd dead, no log, PC has no serial) because of mistaken softraid detection. It happened on exceptionally crappy hardware: a Dell Vostro 200 w/ Intel "rapid storage RAID", i.e. latest BIOS is still old. BIOS UI has only IDE or RAID, that is, "auto RAID/AHCI", AHCI kicks in implicitly when HDDs are not part of a raid group. No issue in IDE mode. The drives were never in a RAID until OpenBSD joined them (40gb SSD + 2 TB Seagate :).
Fault is obviously with Dell/Intel but possibly of interest is that disabling softraid in UKC seems "too late". To get back to normal I had to wipe HDDs' headers, install obsd with a single drive, boot_config a softraid-less kernel, then plug the 2nd HDD. Maybe a deeper HDD reload is needed when exiting UKC and/or more timid softraid detection, at least during install. While I'm at it: config(8) has "uses IRQ 10 instead of 5" backwards, the same example appears in boot_config(8) which also refers to boot.conf hence driving me in circles. Most confusing is that 'config -b/p/s' is a major operation while 'config -e' a harmless patch whose very point is to avoid recompilation. Looking up my ass I'd say config -e should get its own PG-13 command, away from XXX kernel-compiling (and deranged metaphors). I just got started on OpenBSD so can't be more constructive right now -- how'd you usually expect a developer to contribute? fix it? draw up a proposal? shut the fuck up? -- p >In gmane.os.openbsd.misc, Garry Dolley wrote: >> On Tue, May 08, 2012 at 07:58:30PM -0400, Simon Perreault wrote: >>> On 2012-05-08 19:08, Per-Olov Sjvholm wrote: >>>> It says "em1: watchdog timeout -- resetting" >>> >>> <aol> >>> I saw the same on an amd64 VPS from arpnetworks.com. Network was not >>> functional. Backed out. Did not investigate further. >>> </aol> >>> >>> Simon >> >> I had another customer on amd64 report this problem today. Not sure >> what the solution is. I'm recommending either downgrade to 5.0 or >> use i386 arch for now. > >If possible, tracking down the commit which broke it, or at least >narrow it to a reasonably small date range, would help. I have >an archive of snapshot kernels if you want to work through them >rather than cvs checkouts, contact me if you'd like access to them.
