Hi,

I'm having problems with an external firewire disk that I want to use for backups. Initially everything works fine (I did the initial rsyncs of 45GB of file systems without any problem), but when I get cron to rsync the file systems to back up, I get myriad errors:


Jan 24 06:17:36 emma kernel: attempt to access beyond end of device
Jan 24 06:17:36 emma kernel: sda1: rw=0, want=455828328, limit=160071597
Jan 24 06:17:36 emma kernel: attempt to access beyond end of device
Jan 24 06:17:36 emma kernel: sda1: rw=0, want=1937460136, limit=160071597
Jan 24 06:17:36 emma kernel: attempt to access beyond end of device
Jan 24 06:17:36 emma kernel: sda1: rw=0, want=1001087624, limit=160071597
Jan 24 06:18:38 emma kernel: ieee1394: sbp2: aborting sbp2 command
Jan 24 06:18:38 emma kernel: Read (10) 00 04 44 4e 47 00 00 f8 00
Jan 24 06:19:15 emma kernel: ieee1394: sbp2: aborting sbp2 command
Jan 24 06:19:15 emma kernel: Read (10) 00 04 47 f3 6f 00 00 f8 00
Jan 24 06:19:49 emma kernel: ieee1394: sbp2: aborting sbp2 command
Jan 24 06:19:49 emma kernel: Read (10) 00 04 4c 3d e7 00 00 f8 00
Jan 24 06:21:02 emma kernel: ieee1394: sbp2: aborting sbp2 command

There is plenty of space on the device and it worked initially, so I find the 'attempt to access beyond the end of device' messages quite worrying. The aborting sbp2 commands are from the scsi subsystem, as far as I can make out, and I used to see lots of those with earlier kernels.

I'm running a 2.6.0 kernel with firewire enabled. There are ext2 file systems on the backup disk. I've upgraded through all the kernels from 2.4.20 in the hope that the problem would go away, but am at the end of the line with that approach now ;-)

The firewire card is an Adaptec AUA-3020, the enclosure is 3.5" external enclosure from a company called Back-up Q, and the disk is an 80GB Maxtor disk.

Somewhere I saw a message that there were problems with the Maxtor disks falling asleep, and that that is the cause of the problem. That would explain why I do not have any problems initially, but the cron backup at 1am does. Does anybody have anymore information on this? Any pointers to other places to ask would be welcome as well.

Thanks!

Adriaan

First I would check to see if the partition information is actually correct, there might be some bogus resizing going on that is making the mess. "dmesg" should give a c/h/s reading on the disk, if not cfdisk or fdisk should report the info. I hate this ide to scsi through firewire emulation stuff so auto-matic geometry resizing isn't really an option since its only IDE if I remember right. Also, might want to make sure the disk is jumpered right in the enclosure.

Cheers,

Finegan

Hi Finnegan,

thank you for your mail! I re-checked the disk jumpers and it is a master disk, which is right as far as I can figure out. I checked the partition (I only have a single partition as this is for backups) and that seems ok.

I've redone everything from scratch, so I'll have another go with cron tonight and see what happens.

If anything else comes to mind, plese let me know.

Thanks!

Adriaan

This is what's bugging me:sda1: rw=0, want=1001087624, limit=160071597

That screams to me bogus geometry reporting.

The only kernel option I can find is to enable verbose scsi reporting AND verbose firewire reporting. Don't run this kid normally, but at least to get some good debugging. Now, if this is anything like USB mass storage error reporting, you're going to get a butload of debugging.

This one may be a bit of a hastle... I would check the firewire sb2 site for info... doesn't look like much, but I didn't dig too deep:

http://www.linux1394.org/sbp2.html

Cheers,

Finegan

Well, I reformatted the disk again, downgraded to 2.24 and switched on debugging (hundreds of megs of logs) and it seems to be working now. Now to switch debugging off and try again.... Thanks for the help.

Adriaan