On Thu, 2010-12-30 at 10:08 +0100, Andrea Spadaccini wrote: > Hi, > > >> Justification: breaks the whole system > > > > This does *not* break the whole system - the package works for other > > people and even you are able to reboot into another kernel version. > > Sorry, I misinterpreted the options. > > [cut] > > >> Dec 28 11:33:38 beriserv kernel: [ 20.820173] [<ffffffffa000f6b8>] ? > >> usb_control_msg+0x124/0x135 [usbcore] > >> Dec 28 11:33:38 beriserv kernel: [ 20.820173] [<ffffffff8104800d>] ? > >> finish_task_switch+0x3a/0xaf > >> Dec 28 11:33:38 beriserv kernel: [ 20.820173] [<ffffffffa031bd2e>] ? > >> rtl818x_ioread8+0x61/0x7e [rtl8187] > >> Dec 28 11:33:38 beriserv kernel: [ 20.820173] [<ffffffffa031bd6f>] ? > >> rtl8187_is_radio_enabled+0x24/0xc0 [rtl8187] > >> Dec 28 11:33:38 beriserv kernel: [ 20.820173] [<ffffffffa031be30>] ? > >> rtl8187_rfkill_poll+0x25/0x78 [rtl8187] > > [...] > > > > This is presumably caused by a bug in rtl8187. However, it is not a > > general protection fault so there may be two different bugs here. > > Yes, the GPF is around sec 30. After that bug, I blacklisted rtl8187, > and resulted in the other GPFs at boot time that are not logged.
Can you try blacklisting the radeon driver? Ben. -- Ben Hutchings Once a job is fouled up, anything done to improve it makes it worse.
signature.asc
Description: This is a digitally signed message part
