[2.6] kernel BUG at arch/i386/mm/highmem.c:14!

This BUG immediately followed my turning off DMA on hda (with a mounted partition and dirty buffers). Register and stack info are available upon request (screenshot). 2.6.0-test4.

Roger

kernel BUG at arch/i386/mm/highmem.c:14!

invalid operand: 0000 [#1]
CPU:    0
EIP:    0060:[<c011bc36>]   Not tainted
EFLAGS: 00010206

EIP is at kunmap+0x16/0x30
[...]
Process pdflush [...]

 [<c0158f69>] __blk_queue_bounce+0x1e9/0x230
 [<c0158fe7>] blk_queue_bounce+0x37/0x60
 [<c022be20>] __make_request+0x50/0x670
 [<c023ccb0>] task_mulout_intr+0x0/0x290
 [<c022c584>] generic_make_request+0x144/0x1e0
 [<c0176fec>] bio_alloc+0xcc/0x1a0
 [<c022c65d>] submit_bio+0x3d/0x70
 [<c01c80e0>] reiserfs_write_full_page+0x210/0x350
 [<c01c8265>] reiserfs_writepage+0x25/0x40
 [<c019ed3f>] mpage_writepages+0x38f/0x4d0
 [<c01c8240>] reiserfs_writepage+0x0/0x40
 [<c014e375>] do_writepages+0x35/0x40
 [<c019c644>] __sync_single_inode+0x194/0x470
 [<c010a10c>] common_interrupt+0x18/0x20
 [<c019cce1>] sync_sb_inodes+0x1d1/0x3d0
 [<c019d041>] writeback_inodes+0x161/0x420
 [<c014d0a9>] get_page_state+0x19/0x20
 [<c014e1bc>] wb_kupdate+0xdc/0x160
 [<c014eb0c>] __pdflush+0x21c/0x5f0
 [<c014eee0>] pdflush+0x0/0x20
 [<c014eef1>] pdflush+0x11/0x20
 [<c014e0e0>] wb_kupdate+0x0/0x160
 [<c0107259>] kernel_thread_helper+0x5/0xc

Funky, it is indeed strictly forbidden to enter this path with interrupts disabled.

Possibly some artifact of using read/write multiple on IDE, does it work if you disable that with -m0 on the device? I'm guessing the error is 100% reproducible?

Jens Axboe

I'm guessing you're right (small sample size, though).

I made one (successful) attempt at reproducing the BUG (copy some 300 MB of data to a partition, then disable DMA on the target disk).

I made two further attempts but with all kernel output on the serial console, one with -m16 and one with -m0. Both resulted in a flood of "bad:
scheduling while atomic!", but no BUG. The -m0 version looked like a flood in slow motion (line by line).

I suppose the first BUG had the scheduling messages, too, but I didn't see them because they had scrolled past by the time I got to the console. I did see those "bad: scheduling while atomic!" messages, tough, when I reproduced the BUG.

Call traces would look like this:
----------------------------------------------------------------------------
hda: DMA disabled
bad: scheduling while atomic!

Call Trace:
 [<c011ce00>] schedule+0x510/0x520
 [<c022a820>] blk_run_queues+0x120/0x300
 [<c0147e50>] find_get_page+0x70/0x140
 [<c011ed6e>] io_schedule+0xe/0x20
 [<c0171f7f>] __wait_on_buffer+0xcf/0xe0
 [<c011fa80>] autoremove_wake_function+0x0/0x50
 [<c011fa80>] autoremove_wake_function+0x0/0x50
 [<c01de17a>] flush_commit_list+0x31a/0x440
 [<c01e28fb>] do_journal_end+0x5fb/0xc00
 [<c01e1b79>] flush_old_commits+0x139/0x1d0
 [<c01cf940>] reiserfs_write_super+0x30/0x40
 [<c01791bf>] sync_supers+0x1ef/0x280
 [<c014e143>] wb_kupdate+0x63/0x160
 [<c011cae2>] schedule+0x1f2/0x520
 [<c014eb0c>] __pdflush+0x21c/0x5f0
 [<c014eee0>] pdflush+0x0/0x20
 [<c014eef1>] pdflush+0x11/0x20
 [<c014e0e0>] wb_kupdate+0x0/0x160
 [<c0107259>] kernel_thread_helper+0x5/0xc

bad: scheduling while atomic!

Call Trace:
 [<c011ce00>] schedule+0x510/0x520

[...]
----------------------------------------------------------------------------

Or this:

----------------------------------------------------------------------------
hda: DMA disabled
bad: scheduling while atomic!

Call Trace:
 [<c011ce00>] schedule+0x510/0x520
 [<c014ea26>] __pdflush+0x136/0x5f0
 [<c014eee0>] pdflush+0x0/0x20
 [<c014eef1>] pdflush+0x11/0x20
 [<c0107259>] kernel_thread_helper+0x5/0xc

bad: scheduling while atomic!

Call Trace:
 [<c011ce00>] schedule+0x510/0x520
 [<c010babb>] handle_IRQ_event+0x3b/0x70
 [<c012d7cc>] schedule_timeout+0x8c/0xe0
 [<c012d730>] process_timeout+0x0/0x10
 [<c011ed91>] io_schedule_timeout+0x11/0x20
 [<c022bb1b>] blk_congestion_wait+0x8b/0xa0
 [<c011fa80>] autoremove_wake_function+0x0/0x50
 [<c011fa80>] autoremove_wake_function+0x0/0x50
 [<c019cee1>] writeback_inodes+0x1/0x420
 [<c014e1e4>] wb_kupdate+0x104/0x160
 [<c014eb0c>] __pdflush+0x21c/0x5f0
 [<c014eee0>] pdflush+0x0/0x20
 [<c014eef1>] pdflush+0x11/0x20
 [<c014e0e0>] wb_kupdate+0x0/0x160
 [<c0107259>] kernel_thread_helper+0x5/0xc

bad: scheduling while atomic!

Call Trace:

[...]
----------------------------------------------------------------------------

Strange, I cannot reproduce the problem here locally... A look over of the code doesn't reveal any problems either. I'll keep it in mind, though.

These traces look suspicious. Are you using a standard kernel? What options?

Jens Axboe

This trace has been reported several times, and it always correlates with an IDE error message of some form.

I'm suspecting that something in the IDE error handling path either forgets to undo a spinlock or leaves interrupts disabled.