> Grand. Well done, son. > The logs have been very instructive. > > Again we're hitting this 'two commands per lun' problem. > For historic reasons the aic7xxx and aic79xx driver accepted two > commands per luns, as they implemented their internal queueing and could > hold the second command on the queue. > With later versions I've removed this internal queueing and relied on > the block-layer for this. > But this also means we can only accept one command per lun. > > Please try the attached patch and see if it helps. > > James, I know that the aic7xxx has some 'next_queued_hscb' pointer which > might be utilized for this sort of thing. But I didn't really figure out > how this thing is supposed to work nor how we could utilize it. > So I figured that the added complexity is not really worth it. > Hi, Some news: I tried the patch and I still get this sort of instant bus freeze with difficult recovery. But there is some interesting new things too: First log: standard boot, netconsole start, echo 32767 > /proc/sys/dev/scsi/scsi ; cdrwtool -t4 -d/dev/sr0 -q ===> scsi bus crash -> lot of log -> Kernel Bug. Second log: standard boot , init 1 to go into single user mode, echo 32767 > /proc/sys/dev/scsi/scsi ; cdrwtool -t4 -d/dev/sr0 -q Bus crash, recovery, cdrwtool command crash, get the shell back. Remount root-fs read-only to suppress completely sd 0:0:0:0 activity. cdrwtool -t4 -d/dev/sr0 -q Lots of recovery logs and .... blablabla "your cd will be completely erased "blablabla"press y to continue" !!!!!!! Y enter -> writer led start to blink, formating is running!!!! But ~30s later, driver recovery or scsi timeout or midlayer timeout (I don't know) is kicking, device is reseted, stopping the disc formating. sniff. cdrwtool report udf filesystem structure initialization but all is discarded by the driver or the midlayer. cdrwtool exit. last log: without reboot: cdrwtool -t4 -d/dev/sr0 -q bus freeze, lots of log, cdrwtool command crash ... All that I could say with my limited understanding of the big picture and what I previously saw: - The aic7xxx recovery path is still very fragile and unable to recover from problems under scsi bus activity. Perhaps the port of your previous work on this path from aic79xx could help. - It seems that the commands send by cdrwtool which confuse the driver are commands to "sense" the properties of the inserted media and not the formating command itself. - The first part: commands which crash the scsi bus before the begin of the media format was not happening before the big driver change (before 2.6.14). - The second part: formating interrupted because driver recovery kicked in was already happening with 2.6.13 and the recovery already fail and never recover.... - Perhaps to worsen all of this, cdrwtool is very crude with my old yamaha cdwriter and help to trigger a chain of worst case events which expose lots of bugs/unhanded cases. (cdrwtool bugs/writer firmware bugs/aic7xxx bugs .....). Hope this could help. The positive thing is that now with the help of Francois Romieu I could use my old pcnet32 card to get the logs ;-) Best regards, Emmanuel. --- Créez votre adresse électronique prenom.nom@xxxxxxxxxxx 1 Go d'espace de stockage, anti-spam et anti-virus intégrés.
Attachment:
log.rafale-new-1.gz
Description: application/gzip
Attachment:
log.rafale-new-2.gz
Description: application/gzip
Attachment:
log.rafale-new-3.gz
Description: application/gzip
