LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* Kernel BUG at fs/mpage.c:489
@ 2008-02-12 19:45 Bart Dopheide
  2008-02-12 21:50 ` Alan Cox
  0 siblings, 1 reply; 9+ messages in thread
From: Bart Dopheide @ 2008-02-12 19:45 UTC (permalink / raw)
  To: linux-kernel

[-- Attachment #1: Type: text/plain, Size: 11845 bytes --]

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, dopheide@fmf.nl.
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/    :)*/

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-12 19:45 Kernel BUG at fs/mpage.c:489 Bart Dopheide
@ 2008-02-12 21:50 ` Alan Cox
  2008-02-13  1:05   ` Nick Piggin
  0 siblings, 1 reply; 9+ messages in thread
From: Alan Cox @ 2008-02-12 21:50 UTC (permalink / raw)
  To: Bart Dopheide; +Cc: linux-kernel

> 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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-12 21:50 ` Alan Cox
@ 2008-02-13  1:05   ` Nick Piggin
  2008-02-13  7:26     ` Bart Dopheide
  0 siblings, 1 reply; 9+ messages in thread
From: Nick Piggin @ 2008-02-13  1:05 UTC (permalink / raw)
  To: Alan Cox; +Cc: Bart Dopheide, linux-kernel

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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-13  1:05   ` Nick Piggin
@ 2008-02-13  7:26     ` Bart Dopheide
  2008-02-13  9:01       ` Andrew Morton
  0 siblings, 1 reply; 9+ messages in thread
From: Bart Dopheide @ 2008-02-13  7:26 UTC (permalink / raw)
  To: Nick Piggin; +Cc: Alan Cox, linux-kernel

[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]

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

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-13  7:26     ` Bart Dopheide
@ 2008-02-13  9:01       ` Andrew Morton
  2008-02-13  9:24         ` Nick Piggin
  2008-02-13 17:40         ` OGAWA Hirofumi
  0 siblings, 2 replies; 9+ messages in thread
From: Andrew Morton @ 2008-02-13  9:01 UTC (permalink / raw)
  To: Bart Dopheide
  Cc: Nick Piggin, Alan Cox, linux-kernel, OGAWA Hirofumi, Jens Axboe,
	Bartlomiej Zolnierkiewicz

On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <dopheide@fmf.nl> 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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-13  9:01       ` Andrew Morton
@ 2008-02-13  9:24         ` Nick Piggin
  2008-02-13  9:32           ` Andrew Morton
  2008-02-13 17:40         ` OGAWA Hirofumi
  1 sibling, 1 reply; 9+ messages in thread
From: Nick Piggin @ 2008-02-13  9:24 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Bart Dopheide, Alan Cox, linux-kernel, OGAWA Hirofumi,
	Jens Axboe, Bartlomiej Zolnierkiewicz

On Wednesday 13 February 2008 20:01, Andrew Morton wrote:
> On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <dopheide@fmf.nl> 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?

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-13  9:24         ` Nick Piggin
@ 2008-02-13  9:32           ` Andrew Morton
  2008-02-13  9:39             ` Nick Piggin
  0 siblings, 1 reply; 9+ messages in thread
From: Andrew Morton @ 2008-02-13  9:32 UTC (permalink / raw)
  To: Nick Piggin
  Cc: Bart Dopheide, Alan Cox, linux-kernel, OGAWA Hirofumi,
	Jens Axboe, Bartlomiej Zolnierkiewicz

On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 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.


^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-13  9:32           ` Andrew Morton
@ 2008-02-13  9:39             ` Nick Piggin
  0 siblings, 0 replies; 9+ messages in thread
From: Nick Piggin @ 2008-02-13  9:39 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Bart Dopheide, Alan Cox, linux-kernel, OGAWA Hirofumi,
	Jens Axboe, Bartlomiej Zolnierkiewicz

On Wednesday 13 February 2008 20:32, Andrew Morton wrote:
> On Wed, 13 Feb 2008 20:24:03 +1100 Nick Piggin <nickpiggin@yahoo.com.au> 
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.

^ permalink raw reply	[flat|nested] 9+ messages in thread

* Re: Kernel BUG at fs/mpage.c:489
  2008-02-13  9:01       ` Andrew Morton
  2008-02-13  9:24         ` Nick Piggin
@ 2008-02-13 17:40         ` OGAWA Hirofumi
  1 sibling, 0 replies; 9+ messages in thread
From: OGAWA Hirofumi @ 2008-02-13 17:40 UTC (permalink / raw)
  To: Andrew Morton
  Cc: Bart Dopheide, Nick Piggin, Alan Cox, linux-kernel, Jens Axboe,
	Bartlomiej Zolnierkiewicz

Andrew Morton <akpm@linux-foundation.org> writes:

> On Wed, 13 Feb 2008 08:26:27 +0100 Bart Dopheide <dopheide@fmf.nl> 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 <hirofumi@mail.parknet.co.jp>

^ permalink raw reply	[flat|nested] 9+ messages in thread

end of thread, other threads:[~2008-02-13 17:40 UTC | newest]

Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-02-12 19:45 Kernel BUG at fs/mpage.c:489 Bart Dopheide
2008-02-12 21:50 ` Alan Cox
2008-02-13  1:05   ` Nick Piggin
2008-02-13  7:26     ` Bart Dopheide
2008-02-13  9:01       ` Andrew Morton
2008-02-13  9:24         ` Nick Piggin
2008-02-13  9:32           ` Andrew Morton
2008-02-13  9:39             ` Nick Piggin
2008-02-13 17:40         ` OGAWA Hirofumi

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).