- Community Home
- >
- Servers and Operating Systems
- >
- Operating Systems
- >
- Operating System - Linux
- >
- ml350 internal 72i scsi tape problem
Categories
Company
Local Language
Forums
Discussions
Forums
- Data Protection and Retention
- Entry Storage Systems
- Legacy
- Midrange and Enterprise Storage
- Storage Networking
- HPE Nimble Storage
Discussions
Forums
Discussions
Discussions
Discussions
Forums
Discussions
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
- BladeSystem Infrastructure and Application Solutions
- Appliance Servers
- Alpha Servers
- BackOffice Products
- Internet Products
- HPE 9000 and HPE e3000 Servers
- Networking
- Netservers
- Secure OS Software for Linux
- Server Management (Insight Manager 7)
- Windows Server 2003
- Operating System - Tru64 Unix
- ProLiant Deployment and Provisioning
- Linux-Based Community / Regional
- Microsoft System Center Integration
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Discussion Boards
Community
Resources
Forums
Blogs
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2004 01:28 AM
04-19-2004 01:28 AM
ml350 internal 72i scsi tape problem
I got a problem with an ML350G3 (2 processors, 2,5 GB ram, Redhat ES 2.1 kernel 2.4.9-e27, PSP 7).
performing a full backup of about 30GB I got this message (after about 1,5 hours)
kernel: scsi : aborting command due to timeout : pid 0, scsi1, channel 0, id 5, lun 0 Write (6) 00 00 28 00 00
three times, then system hang, so that I can't even reboot it.
internal scsi is seen as Adaptec AIC-7899 (driver aic7xxxx)
tape is a C7438A
Thanks a lot
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2004 01:54 AM
04-19-2004 01:54 AM
Re: ml350 internal 72i scsi tape problem
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-19-2004 03:41 AM
04-19-2004 03:41 AM
Re: ml350 internal 72i scsi tape problem
1) Problem with drive.
2) problem with cable
3) problem with scsi termination
4) problem with scsi card.
You need to check all of these things with utilities or eyeballs.
SEP
Owner of ISN Corporation
http://isnamerica.com
http://hpuxconsulting.com
Sponsor: http://hpux.ws
Twitter: http://twitter.com/hpuxlinux
Founder http://newdatacloud.com
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2004 05:34 PM
04-21-2004 05:34 PM
Re: ml350 internal 72i scsi tape problem
that there was no reply from the device on
the status of write command and driver
has timed out on that write resulting in kernel panic. You can do the following
1. Try backup for a small GB and see if it
is successful
2. Update the tape device firmware and driver
update.
Most probably i feel its a device problem
rather then a termination or cable issue.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-21-2004 07:31 PM
04-21-2004 07:31 PM
Re: ml350 internal 72i scsi tape problem
Anyway after tape substitution the system hanged on Tuesday night, before the backup.
Tonight backup was successfull, dispite the fact I found "kernel: scsi : aborting command due to timeout" in /var/log/messages.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
04-25-2004 09:55 PM
04-25-2004 09:55 PM
Re: ml350 internal 72i scsi tape problem
what's happening?
the hardware test was successfull.
P.S. I found
mtrr: your CPUs had inconsistent fixed MTRR settings
mtrr: probably your BIOS does not setup all CPUs
in /var/log/messages.