Opened 16 years ago
Closed 15 years ago
#2713 closed bug (fixed)
SATA disk problem: "PANIC: could not write back block ### (Device seek error)"
Reported by: | luroh | Owned by: | axeld |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | - General | Version: | R1/pre-alpha1 |
Keywords: | Cc: | dev@… | |
Blocked By: | Blocking: | ||
Platform: | All |
Description
Haiku panics after booting to desktop (complete with terminal, menubar and icons). The bad block number varies, I have seen 2, 8 and 129.
Tried hrev27383 and hrev26827 ("last known good version" before the I/O scheduling changes). I have also tried building with virtual memory disabled, just to rule it out.
The disk is a 320GB SATA with a 4.6 GB Haiku partition at the very beginning of the disk. It also has an ext3 partition, a swap partition and GRUB on the MBR. The disk itself should be good, I've never had any problems with it, at least.
There is a BIOS settning which lets you switch SATA mode between 'RAID' and 'IDE'. However, it makes no difference.
Stack crawl screenshot and hardware list attached.
Attachments (6)
Change History (16)
by , 16 years ago
Attachment: | stack_crawl.jpg added |
---|
by , 16 years ago
comment:1 by , 16 years ago
by , 16 years ago
comment:2 by , 16 years ago
I managed to run 'tail -f /var/log/syslog' before panicking, which listed some interesting 'KERN: check_sense: Hardware error' messages (see syslog picture) that made me add and try another hard disk, this time a WDC WD2000JD-22H Rev. 08.0, dedicated to Haiku. This solved my problem, Haiku is now booting fast and fine on this machine without panicking.
For the record, the problematic hard disk is a fairly new (~2yo) WDC 3200KS-00P Rev. 21.0, which I will continue to use as it has never showed any signs of having problems under Linux (famous last words, perhaps ;).
I believe this ticket can be closed.
by , 16 years ago
Attachment: | syslog.jpg added |
---|
comment:3 by , 16 years ago
It's still a bit suspicious. If there was for example a bad block on that device, you should always get the same panic, with the same block number, not varying ones. Of course it's possible that a whole chunk of blocks is defective. I guess running some disk checker on that drive could confirm something like that. If this doesn't show any signs of a defect, I think it is entirely possible that it is a problem with the combination. Maybe Haiku configures the hardware a slight bit different, which happens to provoke this problem with your specific hardware.
To investigate this, a full syslog would certainly be helpful. Since you obviously cannot get one when booting from that drive, you could boot using the other drive you mention (if you have both connected at the same time), or otherwise from USB. Mounting your problematic partition and writing something to it should provoke it again. If you are able to continue from the panic (using "continue") and shut down cleanly, you should be able to retrieve the syslog from your boot device.
comment:4 by , 16 years ago
Thank you for the advice, yes it is quite suspicious. I now have some more data on the matter; when trying to rename the partition to something other than "Haiku" (to avoid having two partitions with the same name), I noticed that the partition was mounted read-only, despite me selecting read-write. I proceeded to rebuild the partition again from Linux and booting back into the good Haiku partition, thinking it would be useful to try with a fresh partition since something could have messed it up.
Now, when trying to mount it after having rebuilt it, I encountered panics similar to the ones described earlier, but with the difference that I now was able to "continue through" and successfully extract the full syslog as per your instructions above.
comment:5 by , 16 years ago
Seems it has been fixed within the last week or so. Tested on rev 28004.
comment:6 by , 16 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
This might have been fixed with hrev27994 seeing that this was such a large disk. It doesn't really make sense that it would write back something after that barrier though when Haiku is installed at the beginning of the disk. Anyway, closing as it doesn't happen anymore.
by , 16 years ago
Attachment: | haiku-r29120-t500-compat-mode-small.jpg added |
---|
comment:7 by , 16 years ago
Cc: | added |
---|---|
Resolution: | fixed |
Status: | closed → reopened |
Think this one needs to be reopened. Getting the same kind of error on my ThinkPad T500 running the IDE controller in compat mode. Did a compile of blender during that.
I should note that when running the IDE controller in AHCI mode, the system freezes reproduceably after some time of compiling. No sign of error in syslog, nor a panic anywhere. I am not sure the freeze in AHCI mode is related to the block cache panic seen on the attached KDL here.
comment:9 by , 15 years ago
luruh, thanks for bringing this one up again. Haven't seen this for quite some time. Would consider it closeable and fixed in the meantime.
comment:10 by , 15 years ago
Resolution: | → fixed |
---|---|
Status: | reopened → closed |
Closing, assuming it was fixed for real.
There is serious disk thrashing going on before it panics, causing long delays before the terminal, menubar and desktop icons appear. This time (hrev27502), I managed to run 'top' before it crashed just before displaying the desktop icons, see picture.