Ticket #2028 (closed bug: fixed)

Opened 6 months ago

Last modified 6 months ago

KDL: get_writable_cached_block: invalid block number 119165821333100 (max 2618594)

Reported by: kaoutsis Owned by: axeld
Priority: normal Milestone: R1/alpha1
Component: System/Kernel Version: R1 development
Cc: Blocked By:
Platform: All Blocking:

Description

'haiku-src' is mounted read-only, as it may contains bad data. I took the naive approach: copy from that volume to the home dir the 'develop' dir via tracker (~280000 files) 

kdebug> where
stack trace for thread 217 "MoveTask"
    kernel stack: 0x92ffa000 to 0x92ffe000
      user stack: 0x7028a000 to 0x702ca000
frame            caller     <image>:function + offset
92ffda2c (+  52) 8008907f   <kernel>:invoke_debugger_command + 0x00cf
92ffda60 (+  64) 80089e20   <kernel>:_ParseCommand__16ExpressionParserRi + 0x01f8
92ffdaa0 (+  48) 80089812   <kernel>:EvaluateCommand__16ExpressionParserPCcRi + 0x01de
92ffdad0 (+ 228) 8008af34   <kernel>:evaluate_debug_command + 0x0088
92ffdbb4 (+  64) 80087bc2   <kernel>:kernel_debugger_loop__Fv + 0x017a
92ffdbf4 (+  48) 8008886d   <kernel>:kernel_debugger + 0x010d
92ffdc24 (+ 192) 80088755   <kernel>:panic + 0x0029
92ffdce4 (+  64) 800681ef   <kernel>:get_writable_cached_block__FP11block_cachexxxlb + 0x003f
92ffdd24 (+  80) 8006b260   <kernel>:block_cache_get_writable_etc + 0x0070
92ffdd74 (+ 128) 8055efb2   <bfs>:_ShrinkStream__5InodeR11Transactionx + 0x01ee
92ffddf4 (+  48) 8055f330   <bfs>:TrimPreallocation__5InodeR11Transaction + 0x0030
92ffde24 (+  96) 8056aa15   <bfs>:bfs_free_cookie__FPvN20 + 0x0215
92ffde84 (+  48) 8004e455   <kernel>:file_free_fd__FP15file_descriptor + 0x0031
92ffdeb4 (+  48) 80047174   <kernel>:put_fd + 0x0038
92ffdee4 (+  64) 80047b97   <kernel>:common_close__Fib + 0x004b
92ffdf24 (+  32) 800483e8   <kernel>:_user_close + 0x0018
92ffdf44 (+ 100) 8009ac62   <kernel>:pre_syscall_debug_done + 0x0002 (nearest)
iframe at 0x92ffdfa8 (end = 0x92ffe000)
 eax 0x77           ebx 0x42c818        ecx 0x2          edx 0x43d560
 esi 0x702c7c64     edi 0x702c7c64      ebp 0x702c774c   esp 0x92ffdfdc
 eip 0xffff0102  eflags 0x207
 vector: 0x63, error code: 0x0
92ffdfa8 (+   0) ffff0102
702c774c (+  48) 0037286d   </boot/beos/system/lib/libbe.so@0x00202000>:unknown + 0x17086d
702c777c (+  48) 003726b1   </boot/beos/system/lib/libbe.so@0x00202000>:unknown + 0x1706b1
702c77ac (+  48) 00385674   </boot/beos/system/lib/libbe.so@0x00202000>:unknown + 0x183674
702c77dc (+1312) 0050540a   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc440a
702c7cfc (+ 464) 00504f89   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc3f89
702c7ecc (+ 688) 0050624a   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc524a
702c817c (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c842c (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c86dc (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c898c (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c8c3c (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c8eec (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c919c (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c944c (+ 688) 0050621e   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc521e
702c96fc (+1680) 00506c23   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc5c23
702c9d8c (+ 400) 00504916   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xc3916
702c9f1c (+  48) 0051122b   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0xd022b
702c9f4c (+  48) 005a21f3   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0x1611f3
702c9f7c (+  48) 005a2038   </boot/beos/system/lib/libtracker.so@0x00441000>:unknown + 0x161038
702c9fac (+  48) 0064cb20   </boot/beos/system/lib/libroot.so@0x00629000>:unknown + 0x23b20
702c9fdc (+   0) 702c9fec   1822:MoveTask_217_stack@0x7028a000 + 0x3ffec
kdebug>

Attachments

serial.txt (25.6 kB) - added by kaoutsis 6 months ago.
a part of the serial log starting from the point where the haiku-src volume is mounted

Change History

  Changed 6 months ago by kaoutsis

revision is r24806, Haiku boot volume is a newly created partition /dev/hda8 and the haiku installation have been created from a linux machine with jam -q @disk

Changed 6 months ago by kaoutsis

a part of the serial log starting from the point where the haiku-src volume is mounted

  Changed 6 months ago by kaoutsis 

kdebug> thread 217
THREAD: 0x90da8800
id:                 217 (0xd9)
name:               "MoveTask"
all_next:           0x90d26000
team_next:          0x90e7d800
q_next:             0x800ebb60
priority:           10 (next 10)
state:              running
next_state:         ready
cpu:                0x800fed40 (0)
sig_pending:        0x0 (blocked: 0x0)
in_kernel:          1
  sem.blocking:     3880
  sem.count:        0
  sem.acquire_status: 0x0
  sem.flags:        0x11
condition variables:
fault_handler:      0x80089094
args:               0x005a2010 0x1801a600
entry:              0x0064cb00
team:               0x90d5e180, "Tracker"
  exit.sem:         7007
  exit.status:      0x0 (No error)
  exit.reason:      0x0
  exit.signal:      0x0
  exit.waiters:
kernel_stack_area:  1821
kernel_stack_base:  0x92ffa000
user_stack_area:    1822
user_stack_base:    0x7028a000
user_local_storage: 0x702ca000
kernel_errno:       0x0 (No error)
kernel_time:        38741476
user_time:          48425055
flags:              0x0
architecture dependant section:
        esp: 0x92ffdc08
        ss: 0x92ff0010
        fpu_state at 0x90da8b60
kdebug>

  Changed 6 months ago by axeld

  • milestone changed from R1 to R1/alpha1

That's just a panic used for debugging - it just shows that your disk indeed was corrupted, and therefore should be mounted read-only indeed.

However, judging from the stack crawl, there seem to be some code paths that will try to write to a disk even though it's mounted read-only. Will have a look at that.

follow-up: ↓ 5   Changed 6 months ago by kaoutsis

i rebooted the machine, and boot again to Haiku from the same as previously partition (grub terminology hd0,7): What i see now is, the desktop starts with the Installer program

in reply to: ↑ 4   Changed 6 months ago by kaoutsis

Replying to kaoutsis:

What i see now is, the desktop starts with the Installer program

it looks like the root device is now read-only, the replay log failed, a part from syslog (after the reboot) 'Haiku' is the name of the root device i wanted to boot as previously 

bfs: Replay log, disk was not correctly unmounted...
run count: 1002310361, array max: 15, max runs: 126
bfs: Log entry has broken header!
bfs: replaying log entry from 656 failed: Bad data
bfs: Replaying log failed, data may be corrupted, volume read-only.
bfs: mounted "Haiku" (root node at 524288, device = /dev/disk/ata/0/master/1_3)

  Changed 6 months ago by axeld

  • status changed from new to closed
  • resolution set to fixed

Should be fixed with r24809. Note, you might still experience this panic with a corrupt disk, though. If it's a read-only volume, it just shouldn't try to get a writable block this way :-)

If it annoys you, you can safely turn that panic into a dprintf - we'll need to do that before an eventual release anyway.

  Changed 6 months ago by axeld

Should be fixed with r24809. Note, you might still experience this panic with a corrupt disk, though. If it's a read-only volume, it just shouldn't try to get a writable block this way :-)

If it annoys you, you can safely turn that panic into a dprintf - we'll need to do that before an eventual release anyway.

follow-up: ↓ 9   Changed 6 months ago by axeld

Damn Trac! What I meant to say was: We might want to refine the way how the Bootscript detects a CD boot (or find a better way on what happens when a volume might be corrupt) :-)

Either way, was the Haiku volume freshly created with a current revision (after all those block cache changes)? If so, please reopen #2024, as the log corruption should have been fixed already.

in reply to: ↑ 8   Changed 6 months ago by kaoutsis

Replying to axeld:

Either way, was the Haiku volume freshly created with a current revision (after all those block cache changes)?

I'm afraid yes, this 'Haiku' volume was created with r24806. The corruption happen during the copying process. NOTE: this 'Haiku' device is hd0,7 and has nothing to do with 'Haiku' device hd1,7 from ticket #2024 which was created by r24775 also by i clean install jam -q @disk (i have already sent you the superblock and the log region for this partition) However the two partitions have one common characteristic: have been corrupted by haiku, during a copying process.

If so, please reopen #2024, as the log corruption should have been fixed already.

Ok, ticket #2024 is open. I will check if the corruption still occurs with r24809, and i will report later:-)

follow-up: ↓ 11   Changed 6 months ago by kaoutsis

ok i checked r24809 fresh Haiku partition: the replaying log failed: 

bfs: Replay log, disk was not correctly unmounted...
run count: 1002310361, array max: -1, max runs: 126
bfs: Log entry has broken header!
bfs: replaying log entry from 656 failed: Bad data
bfs: Replaying log failed, data may be corrupted, volume read-only.
bfs: mounted "Haiku" (root node at 524288, device = /dev/disk/ata/0/master/1_3)
module: Search for file_cache/launch_speedup/v1 failed.
bfs: volume reports 418982 used blocks, correct is 401812

so we are moving to 2024, this ticket should be closed?

in reply to: ↑ 10   Changed 6 months ago by kaoutsis

Replying to kaoutsis:

so we are moving to 2024, this ticket should be closed?

oh sorry, the ticket is closed

Note: See TracTickets for help on using tickets.