Context Navigation

#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)

KDL_multi_audio_dellgx200.jpg (349.2 KB ) - added by umccullough 15 years ago.: KDL and backtrace
multi_audio_backtrace.txt (2.7 KB ) - added by umccullough 15 years ago.: Backtrace from serial connection
area_70102f40.txt (3.1 KB ) - added by umccullough 15 years ago.: area -m 0x70102f40 output
page_8217b978_50.txt (667 bytes ) - added by umccullough 15 years ago.: page 0x8217b978 and 0x8217b950

Download all attachments as: .zip

Change History (23)

by umccullough, 15 years ago

Attachment:	KDL_multi_audio_dellgx200.jpg added

KDL and backtrace

by umccullough, 15 years ago

Attachment:	multi_audio_backtrace.txt added

Backtrace from serial connection

follow-up: 7 comment:1 by korli, 15 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 umccullough, 15 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:3 by korli, 15 years ago

Could you type "area 0x70102f40" and copy the result here ?

comment:4 by korli, 15 years ago

even more "area -m 0x70102f40"

by umccullough, 15 years ago

Attachment:	area_70102f40.txt added

area -m 0x70102f40 output

comment:5 by umccullough, 15 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

comment:6 by korli, 15 years ago

"page 0x8217b978" and "page 0x8217b950"

in reply to: 1 ; follow-up: 8 comment:7 by axeld, 15 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.

in reply to: 7 comment:8 by korli, 15 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 ?

by umccullough, 15 years ago

Attachment:	page_8217b978_50.txt added

page 0x8217b978 and 0x8217b950

comment:9 by umccullough, 15 years ago

Added output from the two page commands

comment:10 by axeld, 15 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 umccullough, 15 years ago

Will there be anything else I need to post - or can I reboot that machine tonight? :)

in reply to: 11 comment:12 by korli, 15 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.

comment:13 by korli, 15 years ago

Applied a patch in hrev28861. Could you check please ?

follow-up: 15 comment:14 by umccullough, 15 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...

in reply to: 14 comment:15 by korli, 15 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