#3261 closed bug (fixed)
multi_audio KDL: page fault with interrupts disabled
Reported by: | umccullough | Owned by: | korli |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Audio/auich | Version: | R1/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
Description
Experienced a KDL while compiling some stuff on a machine I use regularly for porting stuff on Haiku.
PANIC: page fault, but interrupts were disabled. Touching address 0x70102f40 from eip 0x832ad165
Welcome to Kernel Debugging Land... Thread 149 "multi_audio audio output" running on CPU 0 kdebug>
Stack trace is attached as jpg. Machine is still sitting at the crash and I'll hook up the serial cable to get text info next. I'll leave it like this as long as possible if anyone has any additional things to check.
The machine has probably been on for > 24 hours, with some compiling here and there, testing of some software, and running of dnetc for a few hours. Was compiling when it happened.
Attachments (4)
Change History (23)
by , 16 years ago
Attachment: | KDL_multi_audio_dellgx200.jpg added |
---|
follow-up: 7 comment:1 by , 16 years ago
It seems the data parameter passed to the ioctl() is not valid. Maybe it's a bad idea to copy to userland with interrupts disabled.
comment:2 by , 16 years ago
Anything further I can get from the KDL (it's still sitting there) - I can run more commands from KDL later on if desired - about 4 hours from now.
comment:5 by , 16 years ago
I attached the text output from "area -m 0x70102f40" to the ticket.
Let me know if there's anything else that would help
follow-up: 8 comment:7 by , 16 years ago
Replying to korli:
Maybe it's a bad idea to copy to userland with interrupts disabled.
I can assure that this is indeed a bad idea. You either need to lock the memory (using lock_memory()) before copying (and turning off interrupts), or use user_memcpy() with enabled interrupts.
comment:8 by , 16 years ago
Replying to axeld:
Maybe it's a bad idea to copy to userland with interrupts disabled.
I can assure that this is indeed a bad idea. You either need to lock the memory (using lock_memory()) before copying (and turning off interrupts), or use user_memcpy() with enabled interrupts.
I can do that, but I don't see many drivers which use user_memcpy(). This might need be reviewed globally then. What do you think ?
comment:10 by , 16 years ago
You always need to use user_memcpy() in the kernel for memory that has not been locked. The reason is simple that it could go away at any time; since an eventual page could not be resolved, the kernel would crash with memcpy() where it would just return an error with user_memcpy().
And yes, you are right in that we have to review lots of drivers to do that correctly.
We could follow BeOS that locked the buffers for read/write calls. There, only ioctl() was completely unsafe and each app could easily crash the system by passing an invalid buffer to an ioctl. Unfortunately, there is no way to automatically make sure the buffers passed to ioctl are safe to be used.
In any case, if you need to copy a buffer with interrupts disabled, you have to use lock_memory() to protect it from going away at the wrong time.
follow-up: 12 comment:11 by , 16 years ago
Will there be anything else I need to post - or can I reboot that machine tonight? :)
comment:12 by , 16 years ago
Replying to umccullough:
Will there be anything else I need to post - or can I reboot that machine tonight? :)
No, you can reboot. Thanks a lot.
follow-up: 15 comment:14 by , 16 years ago
I'm not sure I can reproduce the error at will - this was the first time I've ever seen it while using this rev of Haiku pretty regularly on this machine for several weeks now.
With that, I'd say close this issue if you believe it's resolved...
comment:15 by , 16 years ago
Replying to umccullough:
I'm not sure I can reproduce the error at will - this was the first time I've ever seen it while using this rev of Haiku pretty regularly on this machine for several weeks now.
Understood
With that, I'd say close this issue if you believe it's resolved...
I'm not sure at all, at least check it still works normally :)
comment:16 by , 16 years ago
Listening to audio on that machine at this very moment :)
One thing of note, when I was compiling before, I had no audio playing that I knew of (didn't even have speakers hooked up at the time).
comment:17 by , 16 years ago
Oops - forgot to mention that the above comment made while using hrev28868
comment:18 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Nice! Could you also check with hrev28887?
comment:19 by , 13 years ago
Component: | Drivers/Audio → Drivers/Audio/auich |
---|
KDL and backtrace