|
Re: trouble with AMANDA server (taper) on amd64 using Debian/AMD64/Sarge
2005-11-16 14:28:12
Thanks Paddy,
I will try this x86_64 mailing list. I also suspect a kernel configuration problem.
I am using the vanilla 2.6.14.2 kernel, with no external drivers of any kind. The tape drive and changer is the sole device on a scsi chain using the Adaptec 29160N Ultra160 SCSI adapter and . The tape changer is the Exabyte "VXA 1x10 1U" packet loader (at scsi id=3) , the tape drive is the Exabyte VXA-2 drive internal to the changer (at scsi id=6). There are also two sata drives on the system that use scsi emulation on scsi chains scsi1 and scsi2 that should have any effect on this scsi chain scsi0. The kernel scsi driver used is the Adaptec AIC7xxx Fast -> U160 support (New Driver) with default settings.
I also enabled the new "SCSI media changer support" but I do not see what it is doing except to print the following message to the kernel messages log on boot:
SCSI Media Changer driver v0.25
ch0: type #1 (mt): 0x56+1 [medium transport]
ch0: type #2 (st): 0x1+10 [storage]
ch0: type #3 (ie): 0x0+0 [import/export]
ch0: type #4 (dt): 0x52+1 [data transfer]
ch0: dt 0x52: ID 6, LUN 0, name: EXABYTE VXA-2 2100
ch0: INITIALIZE ELEMENT STATUS, may take some time ...
ch0: ... finished
Attached scsi changer ch0 at scsi0, channel 0, id 3, lun 0
It may not be a taper problem, but the symptom does show up consistently when taper is running in 64-bit mode, but not in 32-bit mode. The changer seems to work flawlessly. Only the tape drive writes seem to fail the system.
On Wed, 2005-11-16 at 10:53 -0800, Paddy Sreenivasan wrote:
James,
This is not a "taper" problem. What Linux kernel version are you using? Try posting the log messages to
x86_64 mailing list (http://www.x86-64.org/mailinglists). Upgrading to latest kernel might help. Are you
using additional drivers?
Paddy
On 11/16/05, James D. Freels <freelsjd AT ornl DOT gov> wrote:
Hello folks ! I have been using AMANDA now for several years and find it to be a superb backup tool. I just converted one of my AMANDA backup servers (fea5) from an Alpha 64-bit machine running Debian/Sarge to a new AMD64 64-bit machine also running Debian/Sarge. When writing to the tape using the /usr/lib/amanda/taper component of the amanda-server package in 64-bit mode, the machine fails, and eventually hangs to the point of being unusable. However, if I issue the same commands in the chroot 32-bit mode environment, it works fine. Right now, I basically have to run the server in 32-bit mode and the client in 64-bit mode. I would much prefer running the entire system cleanly in 64-bit mode. I am including the taper error messages here for reference. Has anyone else experienced this problem ? If so how can it be corrected ? I have already issued a bug report to the Debian developers, but I have not obtained a solution
Partial list of the error messages (short enough to be able to send this e-mail to this mailing list):
Nov 7 00:12:48 fea8 kernel: Bad page state at free_hot_cold_page (in process 'taper', page ffff810002642348)
Nov 7 00:12:48 fea8 kernel: flags:0x010000000000000c mapping:ffff8100080ec238 mapcount:2 count:0
Nov 7 00:12:48 fea8 kernel: Backtrace:
Nov 7 00:12:48 fea8 kernel:
Nov 7 00:12:48 fea8 kernel: Call Trace:<ffffffff80157613>{bad_page+99} <ffffffff80157fc5>{free_hot_cold_page+101}
Nov 7 00:12:48 fea8 kernel: <ffffffff8015f0c7>{__page_cache_release+151} <ffffffff80354228>{sgl_unmap_user_pages+120}
Nov 7 00:12:48 fea8 kernel: <ffffffff8034fb3b>{release_buffering+27} <ffffffff803501f1>{st_write+1697}
Nov 7 00:12:48 fea8 kernel: <ffffffff80176ec6>{vfs_write+198} <ffffffff80177023>{sys_write+83}
Nov 7 00:12:48 fea8 kernel: <ffffffff8010d77a>{system_call+126}
Nov 7 00:12:48 fea8 kernel: Trying to fix it up, but a reboot is needed
Nov 7 00:12:48 fea8 kernel: Bad page state at free_hot_cold_page (in process 'taper', page ffff8100026131e8)
Nov 7 00:12:48 fea8 kernel: flags:0x010000000000000c mapping:ffff8100080ec238 mapcount:2 count:0
Nov 7 00:12:48 fea8 kernel: Backtrace:
Nov 7 00:12:48 fea8 kernel:
Nov 7 00:12:48 fea8 kernel: Call Trace:<ffffffff80157613>{bad_page+99} <ffffffff80157fc5>{free_hot_cold_page+101}
Nov 7 00:12:48 fea8 kernel: <ffffffff8015f0c7>{__page_cache_release+151} <ffffffff80354228>{sgl_unmap_user_pages+120}
Nov 7 00:12:48 fea8 kernel: <ffffffff8034fb3b>{release_buffering+27} <ffffffff803501f1>{st_write+1697}
Nov 7 00:12:48 fea8 kernel: <ffffffff80176ec6>{vfs_write+198} <ffffffff80177023>{sys_write+83}
Nov 7 00:12:48 fea8 kernel: <ffffffff8010d77a>{system_call+126}
Nov 7 00:12:48 fea8 kernel: Trying to fix it up, but a reboot is needed
Nov 7 00:12:48 fea8 kernel: Bad page state at free_hot_cold_page (in process 'taper', page ffff8100026c87a0)
Nov 7 00:12:48 fea8 kernel: flags:0x010000000000000c mapping:ffff8100080ec238 mapcount:2 count:0
Nov 7 00:12:48 fea8 kernel: Backtrace:
|
|
|
