Thought I'd finally report this, seeing it still around with 2.6.16-rc6-mm1. With every 2.6.16-rc-mm version I can remember (sorry, no precise records) my development machine (a Dell OptiPlex GX110, Intel P3/933, Intel chipset) has been producing the following three BUG messages while booting: <6>[ 36.528181] md: Autodetecting RAID arrays. <3>[ 36.528263] BUG: sleeping function called from invalid context at mm/slab.c:2758 <4>[ 36.528270] in_atomic():1, irqs_disabled():1 <4>[ 36.528277] kmem_cache_alloc+0x20/0x77 i810fb_cursor+0x1bd/0x2c9 <4>[ 36.528317] search_by_key+0x1a5/0xe04 bit_cursor+0x467/0x48a <4>[ 36.528357] fbcon_cursor+0x226/0x25b bit_cursor+0x0/0x48a <4>[ 36.528373] hide_cursor+0x1d/0x53 vt_console_print+0x8b/0x21e <4>[ 36.528399] vt_console_print+0x0/0x21e __call_console_drivers+0x34/0x40 <4>[ 36.528422] release_console_sem+0xeb/0x185 vprintk+0x298/0x2d9 <4>[ 36.528439] d_splice_alias+0xa5/0xe5 reiserfs_lookup+0xed/0xf8 <4>[ 36.528461] printk+0x12/0x16 md_ioctl+0xc3/0x1289 <4>[ 36.528492] _spin_unlock+0xf/0x23 _spin_unlock+0xf/0x23 <4>[ 36.528525] inode_init_once+0x1a3/0x1cd blkdev_driver_ioctl+0x49/0x59 <4>[ 36.528557] blkdev_ioctl+0x6b6/0x6d6 __mutex_lock_slowpath+0x2ca/0x39a <4>[ 36.528576] debug_mutex_add_waiter+0x14/0x24 do_open+0x5b/0x32a <4>[ 36.528607] __mutex_lock_slowpath+0x2ca/0x39a do_open+0x5b/0x32a <4>[ 36.528622] _spin_unlock+0xf/0x23 _read_unlock_irq+0x10/0x24 <4>[ 36.528638] find_get_page+0x35/0x3a filemap_nopage+0x1a1/0x31f <4>[ 36.528655] _spin_unlock+0xf/0x23 __handle_mm_fault+0x3e5/0x757 <4>[ 36.528688] block_ioctl+0x13/0x16 block_ioctl+0x0/0x16 <4>[ 36.528701] do_ioctl+0x1c/0x5d vfs_ioctl+0x255/0x268 <4>[ 36.528727] sys_ioctl+0x46/0x5f sysenter_past_esp+0x54/0x75 <6>[ 36.682209] md: autorun ... <6>[ 36.689499] md: ... autorun DONE. <6>[ 40.081658] device-mapper: 4.5.0-ioctl (2005-10-04) initialised: dm-devel@redhat.com <3>[ 40.081742] BUG: sleeping function called from invalid context at mm/slab.c:2758 <4>[ 40.081749] in_atomic():1, irqs_disabled():1 <4>[ 40.081756] kmem_cache_alloc+0x20/0x77 i810fb_cursor+0x1bd/0x2c9 <4>[ 40.081802] bit_cursor+0x467/0x48a __switch_to+0x19/0x1b4 <4>[ 40.081835] fbcon_cursor+0x226/0x25b bit_cursor+0x0/0x48a <4>[ 40.081851] hide_cursor+0x1d/0x53 vt_console_print+0x8b/0x21e <4>[ 40.081882] vt_console_print+0x0/0x21e __call_console_drivers+0x34/0x40 <4>[ 40.081906] release_console_sem+0xeb/0x185 vprintk+0x298/0x2d9 <4>[ 40.081925] class_device_add+0x234/0x25b printk+0x12/0x16 <4>[ 40.081956] dm_interface_init+0x51/0x58 [dm_mod] dm_init+0x12/0x39 [dm_mod] <4>[ 40.082023] sys_init_module+0x1252/0x139e sysenter_past_esp+0x54/0x75 <6>[ 41.934599] NTFS driver 2.1.26 [Flags: R/W MODULE]. <3>[ 41.934682] BUG: sleeping function called from invalid context at mm/slab.c:2758 <4>[ 41.934689] in_atomic():1, irqs_disabled():1 <4>[ 41.934697] kmem_cache_alloc+0x20/0x77 i810fb_cursor+0x1bd/0x2c9 <4>[ 41.934742] __alloc_pages+0x2c0/0x2d2 bit_cursor+0x467/0x48a <4>[ 41.934783] _spin_unlock+0xf/0x23 fbcon_cursor+0x226/0x25b <4>[ 41.934816] bit_cursor+0x0/0x48a hide_cursor+0x1d/0x53 <4>[ 41.934845] vt_console_print+0x8b/0x21e vt_console_print+0x0/0x21e <4>[ 41.934860] __call_console_drivers+0x34/0x40 release_console_sem+0xeb/0x185 <4>[ 41.934886] vprintk+0x298/0x2d9 free_pages_bulk+0x27/0x234 <4>[ 41.934904] printk+0x12/0x16 init_ntfs_fs+0xb/0x1a1 [ntfs] <4>[ 41.934941] sys_init_module+0x1252/0x139e sysenter_past_esp+0x54/0x75 At first glance, it looks to me like perhaps i810fb_cursor() shouldn't kmalloc(~, GFP_KERNEL) at drivers/video/i810/i810_main.c:2216 if it may be called with in_atomic() && irqs_disabled(). Apart from those messages, the system runs fine. HTH Tilman -- Tilman Schmidt E-Mail: tilman@imap.cc Bonn, Germany In theory, there is no difference between theory and practice. In practice, there is.