Hey Greg/Gerd, in 2.6.0-test1, I'm sometimes getting these logs in my dmesg output with my driver: bad: scheduling while atomic! Call Trace: [<c011871d>] schedule+0x3d/0x360 [<c01a5ad8>] __udelay+0x28/0x30 [<d395d2bd>] i2c_outb+0xad/0x290 [i2c_algo_bit] [<c01a5aad>] __delay+0xd/0x10 [<c01a5ad8>] __udelay+0x28/0x30 [<c01a5aad>] __delay+0xd/0x10 [<c01a5ad8>] __udelay+0x28/0x30 [<d395d03c>] gcc2_compiled.+0x3c/0x50 [i2c_algo_bit] [<d395d047>] gcc2_compiled.+0x47/0x50 [i2c_algo_bit] [<c01a5aad>] __delay+0xd/0x10 [<c01a5ad8>] __udelay+0x28/0x30 [<d395dec1>] bit_xfer+0x391/0x6c0 [i2c_algo_bit] [<d3b69a2b>] __nvsym01359+0x2b/0x34 [nvidia] [<d3b4bd64>] __nvsym01482+0x58/0x68 [nvidia] [<d3925aef>] i2c_transfer+0x2f/0x50 [i2c_core] [<d3926b69>] i2c_smbus_xfer_emulated+0x2e9/0x3a0 [i2c_core] [<d3c5159f>] __nvsym00429+0x4af/0x4e8 [nvidia] [<c011804c>] try_to_wake_up+0x17c/0x190 [<c010c129>] do_IRQ+0x119/0x160 [<c0118aa9>] default_wake_function+0x19/0x20 [<c011a016>] autoremove_wake_function+0x16/0x40 [<d3926d75>] i2c_smbus_xfer+0x155/0x1c0 [i2c_core] [<d3926453>] i2c_smbus_read_byte+0x23/0x40 [i2c_core] [<c0118af0>] __wake_up_common+0x40/0x60 [<c0118b2c>] __wake_up+0x1c/0x40 [<d39564ac>] saa7110_command+0xcc/0x4d0 [saa7110] [<c011804c>] try_to_wake_up+0x17c/0x190 [<d3ab5aaf>] decoder_command+0x6f/0x80 [zoran] [<d3ab5233>] error_handler+0x2f3/0x390 [zoran] [<c0118b2c>] __wake_up+0x1c/0x40 [<d3ab577a>] zoran_irq+0x4aa/0x570 [zoran] [<c01e09f0>] ide_do_request+0x80/0x3b0 [<c01e11ca>] ide_intr+0x17a/0x190 [<c01ef300>] ide_dma_intr+0x0/0xa0 [<c010bdbe>] handle_IRQ_event+0x3e/0x70 [<c010c0d1>] do_IRQ+0xc1/0x160 [<c0108910>] default_idle+0x0/0x30 [<c0108910>] default_idle+0x0/0x30 [<c010aa3c>] common_interrupt+0x18/0x20 [<c0108910>] default_idle+0x0/0x30 [<c0108910>] default_idle+0x0/0x30 [<c0108934>] default_idle+0x24/0x30 [<c01089b2>] cpu_idle+0x32/0x50 [<c0105000>] _stext+0x0/0x50 [<c03126a0>] start_kernel+0x170/0x180 zoran_irq() is my driver's IRQ handler. I'm not getting these in 2.4.x. It seems like there's some scheduling or so going on in the i2c core, which is being called from my driver's i2c client, which is being called from within the interrupt context. (We turn off the raw grab bit in the i2c chip, because our buffers are full - I'd prefer to keep doing this within the interrupt context to prevent ugly hacks and/or races (if I do it outside the interrupt context)). Question: who is wrong? My driver or i2c? Thanks, Ronald -- Ronald Bultje <rbultje@xxxxxxxxxxxxxxxxxxx>