> > Apr 3 15:42:57 shawc kernel: ncr53c860-0-<4,0>: phase change 2-3
> > 6@0037ec45 resid=2.
MEANS:
- The device was in PHASE 2 = COMMAND PHASE
- The command was 6 bytes long
- The device accepted 4 bytes and then switched to STATUS PHASE
> > Apr 3 15:42:57 shawc kernel: ncr53c860-0-<4,0>: phase change 2-7
> > 10@0037ee45 resid=4.
MEANS:
- The device was in PHASE 2 = COMMAND PHASE
- The command was 10 bytes long
- The device accepted 6 bytes and then switched to MESSAGE IN PHASE.
Reason could be for example that the device detected bad command data.
This can be due to hardware problem.
Anyway, a device that gives up COMMAND PHASE without accepting the whole
command is an abnormal behaviour and is likely due to some severe problem
detected or encoutered by the device.
> ok, so far well known. When using VFAT (with or without fat-patch-13), I
> get:
>
> kernel: Filesystem panic (dev 08:25).
> kernel: File without EOF
> kernel: File system has been set read-only
> kernel: FAT: fat_truncate called though fs is read-only, uhh...
> kernel: Filesystem panic (dev 08:25).
> kernel: File without EOF
> kernel: FAT: fat_truncate called though fs is read-only, uhh...
>
> ... and a nuked parition table.
>
> Using ext2, I get those "phase change", too, but somehow ext2 apears to
> suffer from no courruption. Note that I haven't thoroughly verified this.
> I guess ext2 isn't as vulnerable as FAT and therefore is more happy with
> tiny defects.
>
> Using ext2 it usually takes longer to get the "phase change" message. FAT
> seems to stress the hardware more intensively.
The FAT system does smaller IOs than the EXT2 in average for the same
amount of data. That means that it sends more SCSI COMMANDS to the device
and doing so, it may well increase the probability of getting the problem.
Gérard.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/