Ticket #1055 (closed bug: fixed)

Opened 23 months ago

Last modified 23 months ago

set_signals() crashes in radeon.accelerant after r20251

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

Description

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

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

Serial debug log included is actually from r20252.

Attachments

haiku_r20252_radeon_accelerant_crash.txt (44.7 KB) - added by umccullough 23 months ago.
r20252 radeon.accelerant crash on boot

Change History

Changed 23 months ago by umccullough

r20252 radeon.accelerant crash on boot

Changed 23 months ago by umccullough

  • 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?)

Changed 23 months ago by axeld

  • status changed from new to 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.

Changed 23 months ago by axeld

  • status changed from assigned to closed
  • resolution set to fixed

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

Note: See TracTickets for help on using tickets.