Darren Pilgrim wrote:
I'm going to try a few more things, like plugging and unplugging the hub with the monitor on, as well as plugging and unplugging devices from both the root hub and the hub in the monitor to see if it's more general, or if it's just something wrong with the uhub detach routine.I tried various patterns of plugging and unplugging devices and the hub, as well as booting with and without the hub connected and with and without additional devices connected to the hub. The additional device was a Microsoft Wireless Intellimouse Explorer. I should note that I have /etc/usbd.conf modified to not run moused when a ums device is attached.
In all cases, panics only occured when the hub was detached without anything attached to it. In all other cases the hub and the ums device attached to the hub it detached and reattached repeatedly without problems.
While doing this testing, the fault information was different in two places: the stack and frame pointer values in the second (after the "syncing disks" message) fault information block were different, but consistent for all panics:
stack pointer = 0x10:0xc0250dd0
frame pointer = 0x10:0xc0250dd8
The first fault's information block and the remaining information from the second block was the same as previously reported.
I also looked through my logs and found that, until this afternoon, the ums device was always attached when I had turned the monitor off. My logs cover 4.7-R, 4.7p2, and 4.7p3, with over 20 reboots between 1am Friday morning and 5pm today, the time of the first panic.
I suppose the question now is: why does uhub cause a page fault when an unused hub is detached? Unused meaning there are no devices hanging off it.
I'd also like to take this moment to thank all the hackers who made FreeBSD so damned robust that I could deliberately panic the machine over and over and have all the filesystems come up fine every time.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-questions" in the body of the message
