#2028 closed bug (fixed)
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/pre-alpha1 |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | All |
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 (1)
Change History (12)
comment:1 by , 17 years ago
by , 17 years ago
Attachment: | serial.txt added |
---|
a part of the serial log starting from the point where the haiku-src volume is mounted
comment:2 by , 17 years ago
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>
comment:3 by , 17 years ago
Milestone: | R1 → 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 comment:4 by , 17 years ago
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
comment:5 by , 17 years ago
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)
comment:6 by , 17 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
Should be fixed with hrev24809. 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.
comment:7 by , 17 years ago
Should be fixed with hrev24809. 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 comment:8 by , 17 years ago
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.
comment:9 by , 17 years ago
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 hrev24806. 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 hrev24775 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 hrev24809, and i will report later:-)
follow-up: 11 comment:10 by , 17 years ago
ok i checked hrev24809 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?
comment:11 by , 17 years ago
Replying to kaoutsis:
so we are moving to 2024, this ticket should be closed?
oh sorry, the ticket is closed
revision is hrev24806, 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