bug report?

bug report?

[Xuan Baldauf]

Hello,

I just want to report what happens if a ide controller (or cabling 
thereof) gets mad. The reiserfs filesystem was not unmountable after 
that event. Maybe reiserfs should not panic in such an event? (It could 
keep buffers dirty and allow unclean unmounts so that the gone 
filesystem could be unlinked from the VFS)

plato:~ # uname -a
Linux plato 2.6.6 #3 Thu May 20 14:27:37 CEST 2004 i686 i686 i386 GNU/Linux
plato:~ #



May 21 19:52:33 plato kernel: hda: dma_timer_expiry: dma status == 0x61
May 21 19:52:43 plato kernel: hda: DMA timeout error
May 21 19:52:43 plato kernel: hda: dma timeout error: status=0xd0 { Busy }
May 21 19:52:43 plato kernel:
May 21 19:52:43 plato kernel: hda: DMA disabled
May 21 19:52:43 plato kernel: hdb: DMA disabled
May 21 19:53:18 plato kernel: ide0: reset timed-out, status=0xd0
May 21 19:53:18 plato kernel: hda: status timeout: status=0xd0 { Busy }
May 21 19:53:18 plato kernel:
May 21 19:53:18 plato kernel: hda: drive not ready for command
May 21 19:53:48 plato kernel: ide0: reset timed-out, status=0xd0
May 21 19:53:48 plato kernel: end_request: I/O error, dev hda, sector 
48023788
May 21 19:53:48 plato kernel: end_request: I/O error, dev hda, sector 
2443300
May 21 19:53:48 plato kernel: Buffer I/O error on device hda3, logical 
block 8210
May 21 19:53:48 plato kernel: lost page write due to I/O error on hda3
May 21 19:53:48 plato kernel: end_request: I/O error, dev hda, sector 
2545732
May 21 19:53:48 plato kernel: reiserfs: journal-837: IO error during 
journal replay
May 21 19:53:48 plato kernel: journal-712: buffer write failed
May 21 19:53:48 plato kernel: ------------[ cut here ]------------
May 21 19:53:48 plato kernel: kernel BUG at fs/reiserfs/prints.c:338!
May 21 19:53:48 plato kernel: invalid operand: 0000 [#1]
May 21 19:53:48 plato kernel: PREEMPT
May 21 19:53:48 plato kernel: CPU:    0
May 21 19:53:48 plato kernel: EIP:    0060:[<c019ba19>]    Not tainted
May 21 19:53:48 plato kernel: EFLAGS: 00010282   (2.6.6)
May 21 19:53:48 plato kernel: EIP is at reiserfs_panic+0x29/0x60
May 21 19:53:48 plato kernel: eax: 00000024   ebx: c134d400   ecx: 
00000000   edx: d285ff60
May 21 19:53:48 plato kernel: esi: d3790d50   edi: 00000001   ebp: 
c138bd40   esp: c138bd30
May 21 19:53:48 plato kernel: ds: 007b   es: 007b   ss: 0068
May 21 19:53:48 plato kernel: Process pdflush (pid: 7, 
threadinfo=c138a000 task=c138f0d0)
May 21 19:53:48 plato kernel: Stack: c02c428f c037b9e0 d3790d50 c134d400 
c138bd54 c01a768a c134d400 c02cd980
May 21 19:53:48 plato kernel:        00000001 c138bd94 c01a7aa9 cc6a4270 
cc6a4840 cc6a4300 ce246b10 ce246b70
May 21 19:53:48 plato kernel:        00000001 00000001 00000001 00000001 
d3790d50 c134d400 d3790d50 d3790d50
May 21 19:53:48 plato kernel: Call Trace:
May 21 19:53:48 plato kernel:  [<c01a768a>] 
update_journal_header_block+0x2a/0x30
May 21 19:53:48 plato kernel:  [<c01a7aa9>] flush_journal_list+0x389/0x580
May 21 19:53:48 plato kernel:  [<c01a8079>] 
flush_used_journal_lists+0xa9/0xc0
May 21 19:53:48 plato kernel:  [<c01ab325>] 
flush_old_journal_lists+0x45/0x70
May 21 19:53:48 plato kernel:  [<c01abcc8>] do_journal_end+0x978/0xa80
May 21 19:53:48 plato kernel:  [<c01aa9a5>] journal_end_sync+0x45/0x90
May 21 19:53:48 plato kernel:  [<c019871d>] reiserfs_sync_fs+0x4d/0xa0
May 21 19:53:48 plato kernel:  [<c015538d>] sync_supers+0x9d/0xb0
May 21 19:53:48 plato kernel:  [<c0139a15>] wb_kupdate+0x45/0x140
May 21 19:53:48 plato kernel:  [<c02a9bc8>] schedule+0x1c8/0x5d0
May 21 19:53:48 plato kernel:  [<c013a380>] __pdflush+0xd0/0x1e0
May 21 19:53:48 plato kernel:  [<c0117b09>] set_user_nice+0x129/0x130
May 21 19:53:48 plato kernel:  [<c013a4ae>] pdflush+0x1e/0x20
May 21 19:53:48 plato kernel:  [<c01399d0>] wb_kupdate+0x0/0x140
May 21 19:53:48 plato kernel:  [<c012b9ca>] kthread+0x8a/0xd0
May 21 19:53:48 plato kernel:  [<c013a490>] pdflush+0x0/0x20
May 21 19:53:48 plato kernel:  [<c012b940>] kthread+0x0/0xd0
May 21 19:53:48 plato kernel:  [<c01032a5>] kernel_thread_helper+0x5/0x10
May 21 19:53:48 plato kernel:
May 21 19:53:48 plato kernel: Code: 0f 0b 52 01 f2 81 2c c0 c7 44 24 08 
e0 b9 37 c0 b8 55 7e 2c
May 21 19:53:48 plato kernel:  end_request: I/O error, dev hda, sector 
2394332
May 21 19:53:48 plato kernel: Buffer I/O error on device hda3, logical 
block 2089
May 21 19:53:48 plato kernel: lost page write due to I/O error on hda3
May 21 19:53:48 plato kernel: end_request: I/O error, dev hda, sector 
2394340
May 21 19:53:48 plato kernel: Buffer I/O error on device hda3, logical 
block 2090
May 21 19:53:48 plato kernel: lost page write due to I/O error on hda3
May 21 19:53:48 plato kernel: journal-601, buffer write failed
May 21 19:53:48 plato kernel: ------------[ cut here ]------------
May 21 19:53:48 plato kernel: kernel BUG at fs/reiserfs/prints.c:338!
May 21 19:53:48 plato kernel: invalid operand: 0000 [#2]
May 21 19:53:48 plato kernel: PREEMPT
May 21 19:53:48 plato kernel: CPU:    0
May 21 19:53:48 plato kernel: EIP:    0060:[<c019ba19>]    Not tainted
May 21 19:53:48 plato kernel: EFLAGS: 00010292   (2.6.6)
May 21 19:53:48 plato kernel: EIP is at reiserfs_panic+0x29/0x60
May 21 19:53:48 plato kernel: eax: 00000024   ebx: c134d400   ecx: 
00000000   edx: d285ff60
May 21 19:53:48 plato kernel: esi: d37900d0   edi: c134d400   ebp: 
c130bf04   esp: c130bef4
May 21 19:53:48 plato kernel: ds: 007b   es: 007b   ss: 0068
May 21 19:53:48 plato kernel: Process reiserfs/0 (pid: 11, 
threadinfo=c130a000 task=d3b85670)
May 21 19:53:48 plato kernel: Stack: c02c428f c037b9e0 d37900d0 c134d400 
c130bf34 c01a7449 c134d400 c02cd860
May 21 19:53:48 plato kernel:        c0302a40 d37900e8 00000001 c134d400 
cc6a4300 c130a000 c134d400 d499d120
May 21 19:53:48 plato kernel:        c130bf44 c01aaa6c d499d11c c130a000 
c130bfc8 c0128537 00003537 000001a4
May 21 19:53:48 plato kernel: Call Trace:
May 21 19:53:48 plato kernel:  [<c01a7449>] flush_commit_list+0x3c9/0x3e0
May 21 19:53:48 plato kernel:  [<c01aaa6c>] flush_async_commits+0x7c/0xc0
May 21 19:53:48 plato kernel:  [<c0128537>] worker_thread+0x197/0x250
May 21 19:53:48 plato kernel:  [<c01aa9f0>] flush_async_commits+0x0/0xc0
May 21 19:53:48 plato kernel:  [<c01177e0>] default_wake_function+0x0/0x10
May 21 19:53:48 plato kernel:  [<c01177e0>] default_wake_function+0x0/0x10
May 21 19:53:48 plato kernel:  [<c012b9ca>] kthread+0x8a/0xd0
May 21 19:53:48 plato kernel:  [<c01283a0>] worker_thread+0x0/0x250
May 21 19:53:48 plato kernel:  [<c012b940>] kthread+0x0/0xd0
May 21 19:53:48 plato kernel:  [<c01032a5>] kernel_thread_helper+0x5/0x10
May 21 19:53:48 plato kernel:
May 21 19:53:48 plato kernel: Code: 0f 0b 52 01 f2 81 2c c0 c7 44 24 08 
e0 b9 37 c0 b8 55 7e 2c
May 21 19:53:48 plato kernel:  <4>vs-13070: reiserfs_read_locked_inode: 
i/o failure occurred trying to find stat data of [5334942 5334984 0x0 SD]
May 21 19:53:48 plato kernel: vs-13070: reiserfs_read_locked_inode: i/o 
failure occurred trying to find stat data of [2 142790 0x0 SD]
May 21 19:53:48 plato kernel: end_request: I/O error, dev hda, sector 
2545732
May 21 19:53:48 plato kernel: vs-13070: reiserfs_read_locked_inode: i/o 
failure occurred trying to find stat data of [2 142792 0x0 SD]


ciao,
Xuân.

Re: bug report?

[Jeff Mahoney]

Xuan Baldauf wrote:
> Hello,
> 
> I just want to report what happens if a ide controller (or cabling 
> thereof) gets mad. The reiserfs filesystem was not unmountable after 
> that event. Maybe reiserfs should not panic in such an event? (It could 
> keep buffers dirty and allow unclean unmounts so that the gone 
> filesystem could be unlinked from the VFS)

This happens if any I/O failure occurs while accessing the journal.

I have patches that allow the filesystem to abort if an I/O failure in 
the journal occurs. The result is that the filesystem is forced 
read-only, processes waiting to start a transaction will be refused, and 
existing transactions will be allowed to complete, but not commit. 
Appropriate error codes are returned to the user.

Once the normal conditions for umounting a filesystem are met (no open 
files, etc), it can be umounted normally. The resulting filesystem will 
be identical do what would happen if the machine were simply unplugged 
at the point of the abort. Committed transactions in the journal will be 
replayed on remount, and life goes on. Obviously, additional action as 
appropriate to the cause of the error may be required.

Chris Mason is in the process of sending these to akpm for inclusion in 
-mm, and ultimately in mainline. There were a number of dependencies 
that these patches required, which have been in the process of being 
accepted. Now that the dependencies are met, these patches can be submitted.

-Jeff

-- 
Jeff Mahoney
SuSE Labs

bug report?!

[Timo.Bolse]

Dear LM-Sensors Team,

I tried to compile i2c and lm_sensors on this machine: 

Linux dhcp230 2.4.21-99-athlon #1 Wed Sep 24 13:34:32 UTC 2003 i686 athlon i386
 GNU/Linux).
gcc version 3.3.1 (SuSE Linux)

While compilation i get on both i2c and lm_sensors the following error:

kernel/i2c-pport.c:154: error: initializer element is not constant
kernel/i2c-pport.c:154: error: (near initialization for `bit_pport_data.timeout'

Not only for i2c-pport.c. I spent some time covering this bug. I found out that
you take the HZ Value out of asm/param.h for the timeouts in many of your 
modules. For me i switch to a hardcoded value so that the element is constant.
I took the value defined for userspace in asm/param.h. (On my system 100) and
everything compiled fine. I'am not a very good c programmer so i don't know how
to cover this i think you need this timeout HZ definition because param.h makes
a difference between kernelmode and userspace.

The other problem i spotted is that your tar.gz archive of i2c-2.8.7 is not a
gzip archive.

dhcp230:~ # file i2c-2.8.7.tar.gz
i2c-2.8.7.tar.gz: POSIX tar archive

A not that much confidant user could be very confused if he is downloading a
tar.gz from you website which is a tar.

Regards,
Timo Bolse

bug report?!

[Jean Delvare]

>I tried to compile i2c and lm_sensors on this machine:
>
>Linux dhcp230 2.4.21-99-athlon #1 Wed Sep 24 13:34:32 UTC 2003 i686 athlon i386
> GNU/Linux).
>gcc version 3.3.1 (SuSE Linux)
>
>While compilation i get on both i2c and lm_sensors the following error:
>
>kernel/i2c-pport.c:154: error: initializer element is not constant
>kernel/i2c-pport.c:154: error: (near initialization for `bit_pport_data.timeout'

Suse hacked their kernel tree in a way which makes it incompatible with
our sources. Several users already reported about that.

We do not support that. Either complain to Suse, or use their packages
for lm_sensors (if such packages exist) or use a vanilla kernel instead
of a Suse one. Our packages are tested to work perfectly with vanilla
kernels.

Jean Delvare

bug report?!

[Jean Delvare]

>The other problem i spotted is that your tar.gz archive of i2c-2.8.7 is not
>a gzip archive.
>
>dhcp230:~ # file i2c-2.8.7.tar.gz
>i2c-2.8.7.tar.gz: POSIX tar archive
>
>A not that much confidant user could be very confused if he is downloading a
>tar.gz from you website which is a tar.

I just checked, the file is really a tar.gz file, sent by the HTTP server
with type application/x-tar. This seems to be reasonably standard
(Savannah does the same for example).

So I suspect that your web browser gunzip'ed the file on the fly. You
most probably can configure it not to do so. Else you can still use an
external download tool such as wget.

At any rate, a web browser gunzip'ing files on the fly without removing
the .gz suffix is obviously not doing the right thing and needs fixing.

Thanks for reporting.
Jean Delvare