Messages in this thread |  | | | Date | Mon, 16 Oct 2006 14:45:18 +0200 (CEST) | | From | Jiri Kosina <> | | Subject | Re: dwarf2 stuck Re: lockdep warning in i2c_transfer() with dibx000 DVB - input tree merge plans? |
On Mon, 16 Oct 2006, Jan Beulich wrote:
> >> [<c0103b69>] dump_trace+0x65/0x1a2 > >> [<c0103cb6>] show_trace_log_lvl+0x10/0x20 > >> [<c0103f84>] show_trace+0xa/0xc > >> [<c0103f99>] dump_stack+0x13/0x15 > >> [<c0132ea4>] __lock_acquire+0x7bd/0xa05 > >> [<c01333c1>] lock_acquire+0x5c/0x7b > >> [<c034b683>] __mutex_lock_slowpath+0xab/0x1de > >> [<f8902177>] i2c_transfer+0x23/0x40 [i2c_core] > >> [<f88fa1bf>] dibx000_i2c_gated_tuner_xfer+0x166/0x185 [dibx000_common] > >> [<f8902183>] i2c_transfer+0x2f/0x40 [i2c_core] > >> [<f891f04b>] mt2060_readreg+0x4b/0x69 [mt2060] > >> [<f891f45e>] mt2060_attach+0x40/0x1ea [mt2060] > >> [<f895f468>] dibusb_dib3000mc_tuner_attach+0x126/0x16c > >> [dvb_usb_dibusb_common] > >> [<d10ea000>] 0xd10ea000 > >> DWARF2 unwinder stuck at 0xd10ea000 > >Hmm, no assembly code or anything. Jan, do you have any ideas? This > >looks just like a simple callback that goes over a module boundary. > No, except if this was compiled with gcc 4.0.x (or maybe earlier), in which > case inspection of the unwind data might be needed to tell if it's one of the > mis-generated cases that we saw earlier.
Hi,
(strippped CC list a bit)
Yes, it was compiled using gcc 4.0.2, specifically gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8). I can easily reproduce this, what additional information do you need? Or should I just try with newer gcc?
-- Jiri Kosina - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
|  |