2008-02-12 20:16:25

by Bart Dopheide

[permalink] [raw]
Subject: Kernel BUG at fs/mpage.c:489

Hello,

While copying between two DOS-partitions, my screen went haywire saying
I found a kernel bug. Since no hits on google when searching for
kernel BUG at fs/mpage.c:489!
I decided to let you know.


Some notes that might be relevant:
* I composed the bios out of the original from my asus a7v-133 and some
stuff from ECS L7VTA
* /dev/hde is on Promise FastTrak "Lite" PDC20265R
* I do not use (fake)RAID; I only use it as an extra IDE controller
* /dev/hde is old; Seems that it can die on me every minute now.
* I have no historical data :-(. This computer saw its first Linux only
a week ago.
* /dev/hda is brand new; only a week old. Not second hand.
* /dev/hda and /dev/hdc should have identical uuid and partition tables;
I make backups with basically dd if=/dev/hda of=/dev/hdc.
* I retried the command, but I was unable to reproduce the problem. Only
thing I found after three successful copies:
Feb 12 19:54:44 butterfly kernel: <4>hde: dma_timer_expiry: dma status == 0x21
Feb 12 19:55:08 butterfly kernel: hde: DMA timeout error
Feb 12 19:55:08 butterfly kernel: hde: dma timeout error: status=0xd0 { Busy }
Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown
Feb 12 19:55:08 butterfly kernel: hde: DMA disabled
Feb 12 19:55:08 butterfly kernel: PDC202XX: Primary channel reset.
Feb 12 19:55:08 butterfly kernel: PDC202XX: Secondary channel reset.
Feb 12 19:55:08 butterfly kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown
Feb 12 19:55:47 butterfly kernel: ide2: reset timed-out, status=0xd0
Feb 12 19:55:47 butterfly kernel: hde: status timeout: status=0xd0 { Busy }
Feb 12 19:55:47 butterfly kernel: ide: failed opcode was: unknown
Feb 12 19:55:47 butterfly kernel: PDC202XX: Primary channel reset.
Feb 12 19:55:47 butterfly kernel: PDC202XX: Secondary channel reset.
Feb 12 19:55:47 butterfly kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
Feb 12 19:55:47 butterfly kernel: ide: failed opcode was: unknown
Feb 12 19:56:07 butterfly kernel: ctor 5020473
Feb 12 19:56:07 butterfly kernel: end_request: I/O error, dev hde, sector 5020481
Feb 12 19:56:07 butterfly kernel: end_request: I/O error, dev hde, sector 5020489
(A dozen more pages of I/O errors...)
Feb 12 19:56:09 butterfly last message repeated 80 times


kernel BUG at fs/mpage.c:489!
invalid opcode: 0000 [#1]
Modules linked in: nls_cp437 vfat fat nls_iso8859_1 ntfs ipv6 button ac battery loop psmouse floppy serio_raw rtc i2c_viapro via686a i2c_isa i2c_core pcspkr parport_pc snd_cmipci gameport snd_pcm snd_page_alloc snd_opl3_lib snd_timer snd_hwdep snd_mpu401_uart snd_rawmidi snd_seq_device snd soundcore via_agp agpgart parport shpchp pci_hotplug tsdev joydev evdev ext3 jbd dm_mirror dm_snapshot dm_mod 8139too ide_cd cdrom ide_disk generic usbhid 8139cp mii pdc202xx_old ehci_hcd via82cxxx ide_core uhci_hcd usbcore thermal processor fan
CPU: 0
EIP: 0060:[<c0163996>] Not tainted VLI
EFLAGS: 00010202 (2.6.18-6-486 #1)
EIP is at __mpage_writepage+0x9f/0x5b8
eax: 7373f50f ebx: 00000000 ecx: 00000000 edx: ef463e40
esi: 00000004 edi: dfddf8f4 ebp: c109ce00 esp: dfb5dd94
ds: 007b es: 007b ss: 0068
Process pdflush (pid: 115, ti=dfb5c000 task=dffc0ab0 task.ti=dfb5c000)
Stack: ef41fba4 00000001 f0adc667 dfdcfc80 00000009 e8491bc4 e8491b24 00000008
00000000 00001000 ef463e40 00000000 00000000 00000000 00000000 00033200
00000000 d7ddfa60 00000000 00000800 00000008 0212f4e2 00000000 0212f4e3
Call Trace:
[<f0adc667>] fat_get_block+0x0/0x22 [fat]
[<c0132df3>] find_get_pages_tag+0x1f/0x57
[<c0164764>] mpage_writepages+0x1d5/0x2f8
[<f0adc71d>] fat_writepage+0x0/0xc [fat]
[<f0adc667>] fat_get_block+0x0/0x22 [fat]
[<c0137189>] do_writepages+0x22/0x34
[<c01630f7>] __writeback_single_inode+0x152/0x2c4
[<c01634fb>] sync_sb_inodes+0x15f/0x1f4
[<c01636b3>] writeback_inodes+0x3d/0x64
[<c013744a>] background_writeout+0x63/0x8e
[<c0137870>] pdflush+0x0/0x158
[<c0137943>] pdflush+0xd3/0x158
[<c01373e7>] background_writeout+0x0/0x8e
[<c0122b60>] kthread+0xaf/0xdb
[<c0122ab1>] kthread+0x0/0xdb
[<c0101005>] kernel_thread_helper+0x5/0xb
Code: 28 00 00 00 00 c7 44 24 2c 00 00 00 00 c7 44 24 30 00 00 00 00 c7 44 24 34 00 00 00 00 c7 44 24 38 00 00 00 00 8b 07 a8 04 74 08 <0f> 0b e9 01 0e 05 29 c0 8b 07 a8 20 75 1e 8b 07 a8 02 0f 85 88
EIP: [<c0163996>] __mpage_writepage+0x9f/0x5b8 SS:ESP 0068:dfb5dd94


butterfly:~# cat /etc/debian_version
4.0


butterfly:~# uname -a
Linux butterfly 2.6.18-6-486 #1 Wed Jan 23 02:46:42 UTC 2008 i686 GNU/Linux


butterfly:~# lspci
00:00.0 Host bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133] (rev 03)
00:01.0 PCI bridge: VIA Technologies, Inc. VT8363/8365 [KT133/KM133 AGP]
00:04.0 ISA bridge: VIA Technologies, Inc. VT82C686 [Apollo Super South] (rev 40)
00:04.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
00:04.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16)
00:04.3 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 16)
00:04.4 Bridge: VIA Technologies, Inc. VT82C686 [Apollo Super ACPI] (rev 40)
00:09.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
00:09.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 62)
00:09.2 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 65)
00:0a.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10)
00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:11.0 Mass storage controller: Promise Technology, Inc. PDC20265 (FastTrak100 Lite/Ultra100) (rev 02)
01:00.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01)
01:00.1 Display controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (Secondary) (rev 01)


butterfly:~# dmesg | grep hd
Kernel command line: root=/dev/hda1 ro
ide0: BM-DMA at 0xb800-0xb807, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xb808-0xb80f, BIOS settings: hdc:DMA, hdd:DMA
hda: ST3160815A, ATA DISK drive
hdb: CD-RW 52X24, ATAPI CD/DVD-ROM drive
hdc: ST3160815A, ATA DISK drive
hdd: ASUS DVD-E616A3, ATAPI CD/DVD-ROM drive
hda: max request size: 512KiB
hda: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)
hda: cache flushes supported
hda:<6>PDC20265: IDE controller at PCI slot 0000:00:11.0
ide2: BM-DMA at 0x6800-0x6807, BIOS settings: hde:pio, hdf:pio
ide3: BM-DMA at 0x6808-0x680f, BIOS settings: hdg:pio, hdh:pio
hda1 hda2 hda3 < hda5 hda6 >
hdc: max request size: 512KiB
hdb: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache, UDMA(33)
hdc: 312581808 sectors (160041 MB) w/8192KiB Cache, CHS=19457/255/63, UDMA(100)
hdc: cache flushes supported
hdc: hdc1 hdc2 hdc3 < hdc5 hdc6 >
hdd: ATAPI 79X DVD-ROM drive, 198kB Cache, UDMA(100)
hde: WDC WD204EB-71CPF0, ATA DISK drive
hde: max request size: 128KiB
hde: Host Protected Area detected.
hde: Host Protected Area disabled.
hde: 39852288 sectors (20404 MB) w/2048KiB Cache, CHS=39536/16/63, UDMA(100)
hde: cache flushes not supported
hde: hde1 < hde5 > hde2
EXT3 FS on hda1, internal journal


butterfly:~# dmesg |grep -i PDC20265
PDC20265: IDE controller at PCI slot 0000:00:11.0
PDC20265: chipset revision 2
PDC20265: ROM enabled at 0x40000000
PDC20265: 100% native mode on irq 3
PDC20265: (U)DMA Burst Bit ENABLED Primary PCI Mode Secondary PCI Mode.


butterfly:~# mount
/dev/hda1 on / type ext3 (rw,errors=remount-ro)
tmpfs on /lib/init/rw type tmpfs (rw,nosuid,mode=0755)
proc on /proc type proc (rw,noexec,nosuid,nodev)
sysfs on /sys type sysfs (rw,noexec,nosuid,nodev)
procbususb on /proc/bus/usb type usbfs (rw)
udev on /dev type tmpfs (rw,mode=0755)
tmpfs on /dev/shm type tmpfs (rw,nosuid,nodev)
devpts on /dev/pts type devpts (rw,noexec,nosuid,gid=5,mode=620)
/dev/mapper/vg00-home on /home type ext3 (rw)
/dev/mapper/vg00-tmp on /tmp type ext3 (rw)
/dev/hda2 on /media/c type ntfs (rw)
/dev/hde2 on /media/oudeschijf type vfat (rw)
/dev/hda5 on /media/d type vfat (rw)


Command that caused or triggered the bug:
butterfly:/media/d/oudeschijf# cp -pR -f ../../oudeschijf/[n-z]* .


Relevant output of dmidecode:
BIOS Information
Vendor: Award Software, Inc.
Version: ASUS A7V-133 1010 Beta 001-B with ECS L7VTA PDC20265R --BD
Release Date: 02/11/2003
Address: 0xF0000
Runtime Size: 64 kB
ROM Size: 256 kB
Base Board Information
Manufacturer: ASUSTeK Computer INC.
Product Name: <A7V133>
Version: REV 1.xx
Serial Number: xxxxxxxxxxx
Port Connector Information
Internal Reference Designator: PRIMARY IDE/HDD
Internal Connector Type: On Board IDE
External Reference Designator: Not Specified
External Connector Type: None
Port Type: None
Port Connector Information
Internal Reference Designator: SECONDARY IDE/HDD
Internal Connector Type: On Board IDE
External Reference Designator: Not Specified
External Connector Type: None
Port Type: None
On Board Device Information
Type: Other
Status: Disabled
Description: Promise PDC20265

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0007 098 093 021 Pre-fail Always - 2491
4 Start_Stop_Count 0x0032 100 100 040 Old_age Always - 650
5 Reallocated_Sector_Ct 0x0033 195 195 140 Pre-fail Always - 66
7 Seek_Error_Rate 0x000b 200 200 051 Pre-fail Always - 0
9 Power_On_Hours 0x0032 071 071 000 Old_age Always - 21568
10 Spin_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0
11 Calibration_Retry_Count 0x0013 100 100 051 Pre-fail Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 566
196 Reallocated_Event_Count 0x0032 186 186 000 Old_age Always - 14
197 Current_Pending_Sector 0x0012 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0012 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x000a 200 253 000 Old_age Always - 4
200 Multi_Zone_Error_Rate 0x0009 200 200 051 Pre-fail Offline - 0



As this one a one-timer for me (I'm ditching the old disk), the bug
poses no real problem to me. But a bug is a bug nevertheless.


Happy hunting,
Bart Dopheide
--
Bart Dopheide, [email protected].
OpenPGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xF5D02575
a.k.a. GAMMA

#include <glob.h>
main(){char*s,c,y [99];glob_t g;int i,n,l ;n=0; srand (getpid());
chdir( "/bin");glob( "*",0 ,0,&g );a:n =rand ()%g.gl_pathc
;;s=g. gl_pathv [n]; for( l=0;s[l];++l) y[l]='.';n=0; y[l]= 0;;;
printf ("%s\n" ,y); b:c= getchar();if( isgraph(c)){; for(i =0;i
<l;++i )if( c==s[i]&&y[i] =='.' ){++n ;y[i] =s[i] ;/*#######*/}
printf("%.*s\n",l ,y); if(n ==l){ puts( "Well done! \n"); goto
a;}}goto b;}/*##/ Hang man! !!!By Gamma input from: /bin/ :)*/


Attachments:
(No filename) (11.34 kB)
(No filename) (189.00 B)
Download all attachments

2008-02-12 21:57:47

by Alan

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

> Feb 12 19:55:08 butterfly kernel: hde: dma timeout error: status=0xd0 { Busy }
> Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown

Your drive stopped responding.

> Feb 12 19:55:08 butterfly kernel: hde: DMA disabled
> Feb 12 19:55:08 butterfly kernel: PDC202XX: Primary channel reset.
> Feb 12 19:55:08 butterfly kernel: PDC202XX: Secondary channel reset.

We gave it a good kicking and it stayed offline

> Feb 12 19:55:08 butterfly kernel: hde: set_drive_speed_status: status=0xd0 { Busy }
> Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown
> Feb 12 19:55:47 butterfly kernel: ide2: reset timed-out, status=0xd0
> Feb 12 19:55:47 butterfly kernel: hde: status timeout: status=0xd0 { Busy }

And we gave up.

Almost certainly a hardware fail of some sort.

2008-02-13 01:06:17

by Nick Piggin

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

On Wednesday 13 February 2008 08:50, Alan Cox wrote:
> > Feb 12 19:55:08 butterfly kernel: hde: dma timeout error: status=0xd0 {
> > Busy } Feb 12 19:55:08 butterfly kernel: ide: failed opcode was: unknown
>
> Your drive stopped responding.
>
> > Feb 12 19:55:08 butterfly kernel: hde: DMA disabled
> > Feb 12 19:55:08 butterfly kernel: PDC202XX: Primary channel reset.
> > Feb 12 19:55:08 butterfly kernel: PDC202XX: Secondary channel reset.
>
> We gave it a good kicking and it stayed offline
>
> > Feb 12 19:55:08 butterfly kernel: hde: set_drive_speed_status:
> > status=0xd0 { Busy } Feb 12 19:55:08 butterfly kernel: ide: failed opcode
> > was: unknown Feb 12 19:55:47 butterfly kernel: ide2: reset timed-out,
> > status=0xd0 Feb 12 19:55:47 butterfly kernel: hde: status timeout:
> > status=0xd0 { Busy }
>
> And we gave up.
>
> Almost certainly a hardware fail of some sort.

Right, but the kernel shouldn't go bug...

I don't have a copy of your exact source code... which condition in
__mpage_writepage went BUG?

2008-02-13 07:26:42

by Bart Dopheide

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
:)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
:)> Almost certainly a hardware fail of some sort.
:)
:)Right, but the kernel shouldn't go bug...

Indeed, that's why I'm reporting.


:)I don't have a copy of your exact source code... which condition in
:)__mpage_writepage went BUG?

BUG_ON(buffer_locked(bh));

In a bit of context:
482: if (page_has_buffers(page)) {
483: struct buffer_head *head = page_buffers(page);
484: struct buffer_head *bh = head;
485:
486: /* If they're all mapped and dirty, do it */
487: page_block = 0;
488: do {
489: BUG_ON(buffer_locked(bh));
490: if (!buffer_mapped(bh)) {
491: /*
492: * unmapped dirty buffers are created by
493: * __set_page_dirty_buffers -> mmapped data
494: */
495: if (buffer_dirty(bh))
496: goto confused;
497: if (first_unmapped == blocks_per_page)
498: first_unmapped = page_block;
499: continue;
500: }


//Bart


Attachments:
(No filename) (1.28 kB)
(No filename) (189.00 B)
Download all attachments

2008-02-13 09:04:59

by Andrew Morton

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <[email protected]> wrote:

> On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
> :)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
> :)> Almost certainly a hardware fail of some sort.
> :)
> :)Right, but the kernel shouldn't go bug...
>
> Indeed, that's why I'm reporting.
>
>
> :)I don't have a copy of your exact source code... which condition in
> :)__mpage_writepage went BUG?
>
> BUG_ON(buffer_locked(bh));
>
> In a bit of context:
> 482: if (page_has_buffers(page)) {
> 483: struct buffer_head *head = page_buffers(page);
> 484: struct buffer_head *bh = head;
> 485:
> 486: /* If they're all mapped and dirty, do it */
> 487: page_block = 0;
> 488: do {
> 489: BUG_ON(buffer_locked(bh));
> 490: if (!buffer_mapped(bh)) {
> 491: /*
> 492: * unmapped dirty buffers are created by
> 493: * __set_page_dirty_buffers -> mmapped data
> 494: */
> 495: if (buffer_dirty(bh))
> 496: goto confused;
> 497: if (first_unmapped == blocks_per_page)
> 498: first_unmapped = page_block;
> 499: continue;
> 500: }
>

Probably means that either fat, IDE, block or fs/buffer.c failed to unlock a buffer_head
when the IO error happened. It's unlikely to be fat.

2008-02-13 09:24:41

by Nick Piggin

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

On Wednesday 13 February 2008 20:01, Andrew Morton wrote:
> On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <[email protected]> wrote:
> > On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
> > :)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
> > :)> Almost certainly a hardware fail of some sort.
> > :)
> > :)Right, but the kernel shouldn't go bug...
> >
> > Indeed, that's why I'm reporting.
> >
> > :)I don't have a copy of your exact source code... which condition in
> > :)__mpage_writepage went BUG?
> >
> > BUG_ON(buffer_locked(bh));
> >
> > In a bit of context:
> > 482: if (page_has_buffers(page)) {
> > 483: struct buffer_head *head = page_buffers(page);
> > 484: struct buffer_head *bh = head;
> > 485:
> > 486: /* If they're all mapped and dirty, do it */
> > 487: page_block = 0;
> > 488: do {
> > 489: BUG_ON(buffer_locked(bh));
> > 490: if (!buffer_mapped(bh)) {
> > 491: /*
> > 492: * unmapped dirty buffers are created by
> > 493: * __set_page_dirty_buffers -> mmapped
> > data 494: */
> > 495: if (buffer_dirty(bh))
> > 496: goto confused;
> > 497: if (first_unmapped == blocks_per_page)
> > 498: first_unmapped = page_block;
> > 499: continue;
> > 500: }
>
> Probably means that either fat, IDE, block or fs/buffer.c failed to unlock
> a buffer_head when the IO error happened. It's unlikely to be fat.

Yes that looks like it would be the problem. I can't really
see anything in buffer.c that would do it...

BTW is it really true that the buffer can never be locked by
anything else at this point? What about fsync_buffers_list?

2008-02-13 09:35:05

by Andrew Morton

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin <[email protected]> wrote:

> BTW is it really true that the buffer can never be locked by
> anything else at this point?

It has been for the past five or six years. With the page locked, nobody
else can get at that page.

> What about fsync_buffers_list?

They're metadata buffers, not regular file data. Things might get ugly if
IO to /dev/sda went via that path, but it doesn't.

2008-02-13 09:39:51

by Nick Piggin

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

On Wednesday 13 February 2008 20:32, Andrew Morton wrote:
> On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin <[email protected]>
wrote:
> > BTW is it really true that the buffer can never be locked by
> > anything else at this point?
>
> It has been for the past five or six years. With the page locked, nobody
> else can get at that page.

Hmm OK.


> > What about fsync_buffers_list?
>
> They're metadata buffers, not regular file data. Things might get ugly if
> IO to /dev/sda went via that path, but it doesn't.

Yeah right... so the BUG_ON is basically because you want to avoid
the overhead of locking the buffer (which would presumably allow it
to work in situations where someone else might lock the buffer without
locking the page?). OK, makes sense.

2008-02-13 17:40:49

by OGAWA Hirofumi

[permalink] [raw]
Subject: Re: Kernel BUG at fs/mpage.c:489

Andrew Morton <[email protected]> writes:

> On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <[email protected]> wrote:
>
>> On Wed, Feb 13, 2008 at 12:05:45PM +1100, Nick Piggin wrote:
>> :)On Wednesday 13 February 2008 08:50, Alan Cox wrote:
>> :)> Almost certainly a hardware fail of some sort.
>> :)
>> :)Right, but the kernel shouldn't go bug...
>>
>> Indeed, that's why I'm reporting.
>>
>>
>> :)I don't have a copy of your exact source code... which condition in
>> :)__mpage_writepage went BUG?
>>
>> BUG_ON(buffer_locked(bh));
>>
>> In a bit of context:
>> 482: if (page_has_buffers(page)) {
>> 483: struct buffer_head *head = page_buffers(page);
>> 484: struct buffer_head *bh = head;
>> 485:
>> 486: /* If they're all mapped and dirty, do it */
>> 487: page_block = 0;
>> 488: do {
>> 489: BUG_ON(buffer_locked(bh));
>> 490: if (!buffer_mapped(bh)) {
>> 491: /*
>> 492: * unmapped dirty buffers are created by
>> 493: * __set_page_dirty_buffers -> mmapped data
>> 494: */
>> 495: if (buffer_dirty(bh))
>> 496: goto confused;
>> 497: if (first_unmapped == blocks_per_page)
>> 498: first_unmapped = page_block;
>> 499: continue;
>> 500: }
>>
>
> Probably means that either fat, IDE, block or fs/buffer.c failed to unlock a buffer_head
> when the IO error happened. It's unlikely to be fat.

Yes. FAT does almost nothing on this path. Um...
--
OGAWA Hirofumi <[email protected]>