On Sun, Jan 09, 2011 at 12:33:10PM +0100, Tom Vijlbrief
wrote:> The last half year I've been installing FreeBSD on several machines.
>
> I installed it on my main desktop system a few weeks ago which
> normally runs Linux, but I get this panic under heavy disk I/O.
>
> It even happened during the initial sysinstall, allthough I also have
> completed several buildworlds without problems.
>
> I can trigger it easily by accessing /usr (UFS) and a linux ext
> partition simultaneously, eg by copying
> large files to the /usr partition.
>
> Just bought a serial cable to enable the serial console of the various
> FreeBSD installations, which is of good use for this problem, because
> a crash dump is not written.
>
> Full boot output in the attachment
>
> Sun Jan 9 10:11:17 CET 2011
> unknown: TIMEOUT - WRITE_DMA48 retrying (1 retry left) LBA=274799820^M
> ata2: timeout waiting to issue command^M
> ata2: error issuing WRITE_DMA48 command^M
> g_vfs_done():ad4s2f[WRITE(offset=28915105792, length=131072)]error = 6^M
> /usr: got error 6 while accessing filesystem^M
> panic: softdep_deallocate_dependencies: unrecovered I/O error^M
> cpuid = 0^M
> KDB: stack backtrace:^M
> #0 0xc08e0f77 at kdb_backtrace+0x47^M
> #1 0xc08b2037 at panic+0x117^M
> #2 0xc0ae2ecd at softdep_deallocate_dependencies+0x3d^M
> #3 0xc0925590 at brelse+0x90^M
> #4 0xc092829a at bufdone_finish+0x3fa^M
> #5 0xc092830d at bufdone+0x4d^M
> #6 0xc092bdf9 at cluster_callback+0x89^M
> #7 0xc09282f7 at bufdone+0x37^M
> #8 0xc0850ad5 at g_vfs_done+0x85^M
> #9 0xc09224d9 at biodone+0xb9^M
> #10 0xc084da69 at g_io_schedule_up+0x79^M
> #11 0xc084e0a8 at g_up_procbody+0x68^M
> #12 0xc0886fc1 at fork_exit+0x91^M
> #13 0xc0bcc144 at fork_trampoline+0x8^M
> Uptime: 2h56m27s^M
> Physical memory: 1515 MB^M
> Dumping 177 MB:ata2: timeout waiting to issue command^M
> ata2: error issuing WRITE_DMA command^M
> ^M
> ** DUMP FAILED (ERROR 5) **^M
> Automatic reboot in 15 seconds - press a key on the console to abort^M
> Rebooting...^M
Can you please provide output from the following commands (after
installing ports/sysutils/smartmontools, which should be version 5.40 or
later (in case you haven't updated your ports tree)):
$ dmesg
$ smartctl -a /dev/ad4
The SMART output should act as a verifier as to whether or not you
really do have a bad block on your disk (which is what READ/WRITE_DMA48
can sometimes indicate).
You may also want to boot the machine in single user mode and do a
manual "fsck /dev/ad4s2f". It's been proven in the past that
background_fsck doesn't manage to address all issues.
--
| Jeremy Chadwick jdc@parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP 4BD6C0CB |