Kernel Panic when trying to copy from other hard drive

Grell

Grell

Hello, I have an old hard drive (SATA) UFS that has all my music files stored on it. I also have a new computer that I would like to copy the music files to. When I plug in the old one via SATA connection and attempt to copy the files over I get a general protection fault. Before I can even mount the old hard drive I must do a fsck each time. Then when I try to copy my files over after copying a few gigs the computer resets with a kernel panic. Here is a portion of the txt core dump file. Thanks again.

Code: 
Sat Mar  9 14:27:04 EST 2013

FreeBSD BrickHouse.home 9.1-RELEASE FreeBSD 9.1-RELEASE #0 r243825: Tue Dec  4 09:23:10 UTC 2012     [email]root@farrell.cse.buffalo.edu[/email]:/usr/obj/usr/src/sys/GENERI
C  amd64

panic: general protection fault

GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...

Unread portion of the kernel message buffer:


Fatal trap 9: general protection fault while in kernel mode
cpuid = 1; apic id = 11
instruction pointer     = 0x20:0xffffffff80b04daa
stack pointer           = 0x28:0xffffff822e5b81d0
frame pointer           = 0x28:0xffffff822e5b81e0
code segment            = base 0x0, limit 0xfffff, type 0x1b
                        = DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags        = interrupt enabled, resume, IOPL = 0
current process         = 1847 (cp)
trap number             = 9
panic: general protection fault
cpuid = 1
KDB: stack backtrace:
#0 0xffffffff809208a6 at kdb_backtrace+0x66
#1 0xffffffff808ea8be at panic+0x1ce
#2 0xffffffff80bd8240 at trap_fatal+0x290
#3 0xffffffff80bd88d5 at trap+0x105
#4 0xffffffff80bc315f at calltrap+0x8
#5 0xffffffff80b077e5 at newblk_lookup+0x65
#6 0xffffffff80b103d0 at softdep_setup_blkmapdep+0x80
#7 0xffffffff80af604f at ffs_alloccgblk+0x24f
#8 0xffffffff80af7700 at ffs_alloccg+0x260
#9 0xffffffff80af3f7c at ffs_hashalloc+0x2c
#10 0xffffffff80af6da9 at ffs_alloc+0x79
#11 0xffffffff80afaa65 at ffs_balloc_ufs2+0x1235
#12 0xffffffff80b22671 at ffs_write+0x1f1
#13 0xffffffff80c68602 at VOP_WRITE_APV+0xb2
#14 0xffffffff8099203c at vn_write+0x38c
#15 0xffffffff809327cb at dofilewrite+0x8b
#16 0xffffffff80932afc at kern_writev+0x6c
#17 0xffffffff80932b84 at sys_write+0x64
Uptime: 6m33s
Dumping 1354 out of 8074 MB:..2%..11%..21%..31%..41%..51%..61%..71%..81%..91%

Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
done.
Loaded symbols for /boot/kernel/linprocfs.ko
Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko
#0  doadump (textdump=Variable "textdump" is not available.
) at pcpu.h:224
224     pcpu.h: No such file or directory.
        in pcpu.h
(kgdb) #0  doadump (textdump=Variable "textdump" is not available.
) at pcpu.h:224
#1  0xffffffff808ea3a1 in kern_reboot (howto=260)
    at /usr/src/sys/kern/kern_shutdown.c:448
#2  0xffffffff808ea897 in panic (fmt=0x1 <Address 0x1 out of bounds>)
    at /usr/src/sys/kern/kern_shutdown.c:636
#3  0xffffffff80bd8240 in trap_fatal (frame=0x9, eva=Variable "eva" is not available.
)
    at /usr/src/sys/amd64/amd64/trap.c:857
#4  0xffffffff80bd88d5 in trap (frame=0xffffff822e5b8120)
    at /usr/src/sys/amd64/amd64/trap.c:599
#5  0xffffffff80bc315f in calltrap ()
    at /usr/src/sys/amd64/amd64/exception.S:228
#6  0xffffffff80b04daa in newblk_find (newblkhd=0xffffff800281b6d0, 
    mp=0xfffffe00094e6c60, newblkno=187763264, flags=Variable "flags" is not available.
)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2166
#7  0xffffffff80b077e5 in newblk_lookup (mp=0xfffffe00094e6c60, 
    newblkno=187763264, flags=1, newblkpp=0xffffff822e5b8260)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:2204
#8  0xffffffff80b103d0 in softdep_setup_blkmapdep (bp=0xffffff81e84c1be0, 
    mp=0xfffffe00094e6c60, newblkno=187763264, frags=8, oldfrags=0)
    at /usr/src/sys/ufs/ffs/ffs_softdep.c:4800
#9  0xffffffff80af604f in ffs_alloccgblk (ip=0xfffffe00373bf7e0, 
    bp=0xffffff81e84c1be0, bpref=Variable "bpref" is not available.
) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1598
#10 0xffffffff80af7700 in ffs_alloccg (ip=0xfffffe00373bf7e0, cg=1171, 
    bpref=187763264, size=32768, rsize=32768)
    at /usr/src/sys/ufs/ffs/ffs_alloc.c:1487
#11 0xffffffff80af3f7c in ffs_hashalloc (ip=0xfffffe00373bf7e0, cg=1171, pref=Variable "pref" is not available.

) at /usr/src/sys/ufs/ffs/ffs_alloc.c:1308
#12 0xffffffff80af6da9 in ffs_alloc (ip=0xfffffe00373bf7e0, lbn=Variable "lbn" is not available.
)
    at /usr/src/sys/ufs/ffs/ffs_alloc.c:200
#13 0xffffffff80afaa65 in ffs_balloc_ufs2 (vp=0xfffffe0037ebf960, startoffset=Variable "startoffset" is not available.

) at /usr/src/sys/ufs/ffs/ffs_balloc.c:905
#14 0xffffffff80b22671 in ffs_write (ap=0xffffff822e5b8810)
    at /usr/src/sys/ufs/ffs/ffs_vnops.c:721
#15 0xffffffff80c68602 in VOP_WRITE_APV (vop=0xffffffff811c3e60, 
    a=0xffffff822e5b8810) at vnode_if.c:951
#16 0xffffffff8099203c in vn_write (fp=0xfffffe01d6262dc0,
 
I usually use rsync with the bwlimit parameter to slow it down so the filesystem/kernel crash is very very less likely. "Full disk speed" is typically 10000 at that, so
Code: 
rsync -vaH ... ... --bwlimit=1000 /src /dest
The other threads I've posted have the complete command line. Note it is best run *from* the /src using just a "dot" to represent the source directory, and no trailing slash at the destination directory (OTOH, I just settled on the first way that always works, it may be good-to-go
with other methodology.)
 
Is the receiving filesystem ZFS? Then this could be a lack of memory. Otherwise, a crash like that indicates a serious problem. Run memtest on the the system, for a start. Is either drive external, and if so, do they have their own power supplies?
 
wblock@ said:
Is the receiving filesystem ZFS? Then this could be a lack of memory. Otherwise, a crash like that indicates a serious problem. Run memtest on the the system, for a start. Is either drive external, and if so, do they have their own power supplies?
Click to expand...
Unless there's something the user didn't tell us, something very strange is going on if he has to fsck(8) the source drive each time. The traceback shows that the panic was caused by a filesystem write operation. I could understand some writes to the source drive to update the atime, but not ffs_alloccg() which would seem to indicate that files are being created and filled on the source disk, or that the write is failing on the target disk. The second seems unlikely, given that it is the source drive that needs to be fsck(8)'d each time. Hopefully the original poster can clarify.

I'd suggest mounting the source drive as read-only by adding "-o ro" to the mount(8) command line and seeing what happens.
 
Well actually I have since installed Debian instead of FreeBSD. However when I ran memtest I did get a lot of errors which I was able to fix only by removing one of my memory modules. Also it did work when I mounted it read-only but when I tried to copy all the files it gave me the kernel panic.
 
You must log in or register to reply here.
Back
Top