Opened 10 years ago

Closed 9 years ago

#3619 closed bug (fixed)

USB input related 'Bad address' on fault at 0xdeadbf0f with KVM

Reported by: kallisti5 Owned by: mmlr
Priority: normal Milestone:
Component: Drivers/USB Version: R1/Development
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

I have a usb mouse and keyboard plugged into a kvm hooked upto a machine running Haiku hrev29748

If I change systems on the KVM a few times with about 5-10 seconds in between. Haiku will panic on the third or fourth removal with:

'Bad address' on fault at 0xdeadbf0f

Lots of USB errors are also present.

A serial dump of the logs is attached. I made Haiku panic twice in these logs.

I think this should be a blocker for R1, as usb device addition/removal should never lead to a system crash.

Attachments (1)

haiku-usb.txt (136.8 KB ) - added by kallisti5 10 years ago.
Log, crashes at line 1195 and 2701

Download all attachments as: .zip

Change History (7)

by kallisti5, 10 years ago

Attachment: haiku-usb.txt added

Log, crashes at line 1195 and 2701

comment:1 by kallisti5, 10 years ago

Just noting complete crash messages so others may be able to find:

1195:PANIC: vm_page_fault: unhandled page fault in kernel space at 0xdeadbf0f, ip 0x800744f7

2701:PANIC: vm_page_fault: unhandled page fault in kernel space at 0xdeadbf0f, ip 0x800744f7

comment:2 by stippi, 10 years ago

I saw this one too. I was able to make it happen much less likely when adding a delay in the MouseInputDevice between ioctl()s. This should just lower the frequency of ioctl()s a bit and make the bug less likely to be triggered. It looks to me like the device is already removed, even though MouseInputDevice has it still open. The ioctl() should then simply fail. Most of the times, this works just fine.

comment:3 by mmlr, 10 years ago

Sorry but I really need a stack trace here (sc command in KDL). This could stem from anywhere between the host controller driver up to and including usb_hid. Likely it is in usb_hid though. In any case the errors that get printed are ok and can be ignored. They come from the time between the removal of the device and the notification of removal.

comment:4 by mmlr, 10 years ago

The usb_hid driver has been reworked since which quite likely fixed this. Could you please check?

comment:5 by kallisti5, 9 years ago

Milestone: R1
Version: R1/pre-alpha1R1/Development

I haven't seen any USB related crashes for a long time. I say this one is resolved.

comment:6 by mmlr, 9 years ago

Resolution: fixed
Status: newclosed

Ok, most likely fixed during one of the usb_hid rewrites.

Note: See TracTickets for help on using tickets.