System freeze when connecting USB flash drive (4.4 & 4.5 but worked in 4.3)

Hi!

Moved from OpenBSD 4.3 to 4.5.

When i plug in my USB flash drive the system freeze and I can do nothing accept reboot the machine the hard way.
No problem what so ever in 4.3, so I thought, let's try 4.4, same problem there with the system lock up.

I tried with a few diffrent USB drives, same problem with all of them, most of them without U3.

Searched the web and the change logs for hints and clues but found nothing.
I'm pretty much stuck with this problem and hoping someone can point me in the right direction.

dmesg(8) output wraps on systems which do not clear RAM on reboot.... note that the kernel messages start mid-buffer on both of these.

I can see that APM is used on both 4.3 and 4.5, so this is not an ACPI-related problem. ACPI trouble is quite common, see the song for 4.5.

Other than that, I do not see anything obvious or helpful in the dmesgs. Someone else might.

A hung machine can sometimes be in panic and have dropped into the ddb(4) debugger -- yet the operator may not be aware of it, if X is active at the time of the hang. And the machine will really be hung, as there's no way to communicate with X to stop it, and no way to switch to the console, which is stuck in a ddb> prompt. Was X in use at the time of the hang?

A machine which is hung, but looping in the kernel, can be forced into the ddb> debugger if the OS is still able to accept console interrupts, and not in X, and if the sysctl ddb.console=1 is set. This sysctl must be set while in single-user mode, or from /etc/sysctl.conf. The crash(8) man page has additional guidance.

A machine which is hung, but looping in the kernel, can be forced into the ddb> debugger if the OS is still able to accept console interrupts, and not in X, and if the sysctl ddb.console=1 is set. This sysctl must be set while in single-user mode, or from /etc/sysctl.conf. The crash(8) man page has additional guidance.

X is not installed on that machine, running only console and console frooze,
could do nothing with the keyboard, will try the ddb thing if I don't get progress
with the ACPI thing BSDfan666 pointed out.

Quote:

Originally Posted by BSDfan666

I would actually try using ACPI on this system, 4.5 has come a long way since 4.3.. might be worth a shot.

I must say that I'm really impressed by the friendliness of this community/forum.
I'll stick around and hopefully I can contribute in some way.

Thank you for helping me solving this problem.

Quote:

Originally Posted by jggimi

Since you're running i386, the keystrokes (assuming the OS is accepting keyboard interrupts) from a PC's keyboard are Ctrl-Alt-ESC.

You can then run a backtrace to find out where the kernel is looping. You can even take a core dump if you have sufficient swap space, and sufficient storage in /var/crash to save it on reboot.

Since I'm curious by nature I'll go down this road and see if I can find what was causing the problem.
And maybe I learn something along the way. If I find anything useful I'll post it here.
Thanks a lot for your input, really appreciate it.

Edit:
The computer does not accept any keystrokes after the freeze so maybe I just leave it there for now.

Ah, then the OS is truly "hung", and not responding to interrupts. Thanks for letting us know. There are additional options, such as setting breakpoints, but as it is you'd need to be a kernel developer to know where to make them.