Opened 17 years ago

Closed 17 years ago

#1055 closed bug (fixed)

set_signals() crashes in radeon.accelerant after r20251

Reported by: umccullough Owned by: axeld
Priority: normal Milestone: R1
Component: System/Kernel Version: R1/pre-alpha1
Keywords: Cc: geist
Blocked By: Blocking:
Platform: x86

Description

After updating to hrev20251, radeon.accelerant crashes during set_signals() call on boot. I confirmed that rolling back to hrev20250 resolves the issue.

This is on real hardware: PIII 600 w/256mb RAM and Radeon 9250 AGP

Serial debug log included is actually from hrev20252.

Attachments (1)

haiku_r20252_radeon_accelerant_crash.txt​ (44.7 KB ) - added by umccullough 17 years ago.
hrev20252 radeon.accelerant crash on boot

Download all attachments as: .zip

Change History (4)

by umccullough, 17 years ago

Attachment: haiku_r20252_radeon_accelerant_crash.txt​ added

hrev20252 radeon.accelerant crash on boot

comment:1 by umccullough, 17 years ago

Cc: geist added

For clarification, set_signals() is where the gdb stack trace showed failure - but the gdb output isn't in the serial log (is that possible to do?)

comment:2 by axeld, 17 years ago

Status: new → assigned

I've looked into it (as I can reproduce it on my laptop as well), and I think clone_area() is to blame for this.

IOW it does not care about the wiring/locking mode of the area it clones, it doesn't make any pages available. Since I removed the fault handler from device stores, it suddenly fails.

comment:3 by axeld, 17 years ago

Resolution: → fixed
Status: assigned → closed

clone_area() now inherits the locking/wiring of the source area. Fixed in hrev20283.

Note: See TracTickets for help on using tickets.