Re: TMSCSIM [2.6]

Re: TMSCSIM [2.6]

[Matthias Andree]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

> @@ -47,8 +47,9 @@
>      DC390_write8 (CtrlReg4, pDCB->CtrlR4);
>      DC390_write8 (ScsiCmd, CLEAR_FIFO_CMD);		/* Flush FIFO */
>      DEBUG1(printk (KERN_INFO "DC390: Start SCSI command: %02x (Sync:%02x)\n",\
> -	    pSRB->pcmd->cmnd[0], pDCB->SyncMode);)
> -    disc_allowed = pDCB->DevMode & EN_DISCONNECT_; try_sync_nego = 0;
> +	    pSRB->pcmd->cmnd[0], pDCB->SyncMode));
> +    disc_allowed = pDCB->DevMode & EN_DISCONNECT_;
> +    try_sync_nego = 0;
>      /* Don't disconnect on AUTO_REQSENSE, cause it might be an
>       * Contingent Allegiance Condition (6.6), where no tags should be used.
>       * All other have to be allowed to disconnect to prevent Incorrect

Out if interest: Why "try_sync_nego = 0"?

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

On Sun, 23 Nov 2003, Matthias Andree wrote:

> Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:
>
> > @@ -47,8 +47,9 @@
> >      DC390_write8 (CtrlReg4, pDCB->CtrlR4);
> >      DC390_write8 (ScsiCmd, CLEAR_FIFO_CMD);		/* Flush FIFO */
> >      DEBUG1(printk (KERN_INFO "DC390: Start SCSI command: %02x (Sync:%02x)\n",\
> > -	    pSRB->pcmd->cmnd[0], pDCB->SyncMode);)
> > -    disc_allowed = pDCB->DevMode & EN_DISCONNECT_; try_sync_nego = 0;
> > +	    pSRB->pcmd->cmnd[0], pDCB->SyncMode));
> > +    disc_allowed = pDCB->DevMode & EN_DISCONNECT_;
> > +    try_sync_nego = 0;
> >      /* Don't disconnect on AUTO_REQSENSE, cause it might be an
> >       * Contingent Allegiance Condition (6.6), where no tags should be used.
> >       * All other have to be allowed to disconnect to prevent Incorrect
>
> Out if interest: Why "try_sync_nego = 0"?

No idea. I didn't change it - just broke the line. Actually, such
changes shouldn't go into patches, but it goes almost automatic, you
know:-(

Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 546 bytes --]

Hi Matthias,

On Sun, Nov 23, 2003 at 09:26:02PM +0100, Matthias Andree wrote:
> Out if interest: Why "try_sync_nego = 0"?

It's just the default for this variable.
It's later set to 1 if we're issueing an INQUIRY or if we're talking to
LUN0, the target did report to support SyncTransfers and the Sync 
Negotiation has not beend done yet and we're issueing a REQUEST_SENSE.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: TMSCSIM [2.6] (was: Re: [PATCH] Re: AMD 53c974 SCSI driver in 2.6)

[Guennadi Liakhovetski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 466 bytes --]

Didn't pass uncompressed through - bigger than 100K? Attaching compressed.

On Mon, 24 Nov 2003, Guennadi Liakhovetski wrote:

> Ghm, here's the patch. But I decided not to compress it, just send it as
> attachment, instead of inlining it - after all, this is how it should be
> done, isn't it?:-)
>
> And - now it includes one more fix - replaced deprecated check_region()
> with request_region() - noticed by Ishikawa, Chiaki.

Guennadi
---
Guennadi Liakhovetski


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 16996 bytes --]

Re: TMSCSIM [2.6]

[Chiaki]

Guennadi Liakhovetski wrote:
> Didn't pass uncompressed through - bigger than 100K? Attaching compressed.
> 
> On Mon, 24 Nov 2003, Guennadi Liakhovetski wrote:
> 
> 
>>Ghm, here's the patch. But I decided not to compress it, just send it as
>>attachment, instead of inlining it - after all, this is how it should be
>>done, isn't it?:-)
>>
>>And - now it includes one more fix - replaced deprecated check_region()
>>with request_region() - noticed by Ishikawa, Chiaki.

Hello,

Thank you for the renewed patch.

I am using TEKRAM dc390. I use tmscsim driver as a module.
There is a PD/CD combo on the dc390 scsi bus. (PD is
a somewhat outdated optomagnetic drive. The drive has
two LUNs, one for CD, and one for PD. PD side is recognized as
rewritable removable media at least under 2.4.22.)

With the modified tmscsim driver under 2.6.0-test10,
(the bzipped patch submitted to linux-scsi worked without rejection)
I got a panic after module insertion during booting.
tmscsim is mentioned in /etc/modules and so inserted automatically
during booting.

(More background: related stuff I can think of.
       kernel 2.6.0-test10.
       tmscsim ... used as module
       sr ... module as sr_mod
       event mechanism enabled in the kernel.
       gcc 3.3 used...)

Here is the panic message left on the screen which I scribbed down
manually.

	... anything above is scrolled and disappeared but I saw the
         module insertion began. ...
esi: ef63a2f0 edi: 00000001 ebp: c03a5e4c esp: c03a5e3c
ds: 007b es: 007b ss: 0068

Process swapper (pid:0, threadinfo = c03a4000, task=c0338680)

Stack: 00000000 ef63a2f0 efc617c0 ef5e92c0 c0ea5e8c f09451d1 ef63a2f0 
ef63a2f0
        ef5e92c0 ef5e92c0 c03a5ea4 f09451d1 ef63a2f0 4f89f21d 00000021 
00000001
        cc000092 ef63a2f0 efc617c0 ef63a208 c03a5ec4 f0946e36 ef63a208 
ef5e92c0

Call trace:
   [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
   [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
   [<f0946e36>] dc390_SRBdone+0x306/0x5b0      [tmscsim]
   [<f09472f3>] dc390_RequestSense+0x53/0x90   [tmscsim]
   [<f0946714>] dc390_Disconnect+0x104/0x160    [tmscsim]
   [<f094574a>] do_DC390_Interrupt:0x28d/0x350 [tmscsim]
   [<c025dc88>] scsi_softirq+0xe8/0x240
   [<c010da4b>] handle_IRQ_event:0x3b/0x70
   [<c010e060>] do_IRQ+0x140/0x390
   [<c0105000>] _stext+0x0/0xf0
   [<c010c0ec>] common_interrupt:0x18/0x20
   [<c0105000>] _stext+0x0/0xf0
   [<c0108ea6>] default_idel+0x26/0x30
   [<c0108f24>] cpu_idle+0x34/0x40
   [<c03a6797>] start_kernel+0x1e7/0x270
   [<c03a6480>] unknown_bootoption+0x0/0x100

Code: 0f 0b 28 00 77 9d 94 f0 eb c5 0f 0b 25 00 77 9d 94 f0 eb e8

<0> Kernel panic: Fatal exception in interrupt
     In interrupt handler --- not syncing




OBSERVATION:

	alt sysreq magic key combination worked.
	I could run emergency sync and reboot.

	From the kernel panic message, and the call trace, it looks to
	me that the interrupt is recursively entered somehow.
	(Or unexpected interrupt came in.)


So what next?
I can enable debugging macro if necessary and re-try.

Or, I can disable tmscsim module insertion during booting,
and try "insmod tmscsim" after the kernel is up and running and
see if it makes difference.

(Under 2.6.0-test9, and manually fixed patched tmscsim files (due to
whitespace problems of the patch), I could insert the tmscsim module
but "insmod tmscsim" took unusually long time, but eventually
returned. However, /proc/scsi/ didn't show the 2nd LUN of the
PD/CD combo I have on dc390 bus. Maybe it was a problem of
insertion of sr_mod due to my misconfiguration of module set up
for 2.6.0-testXX which I believe is now corrected.
Since immediately
afterward when I tried automatic insertion of dc390 during booting,
I got a similar panic which I reported above, I didn't pursue
the insertion testing after the kernel is up and running.
I thought fixing the panic of auto insertion needs to be handled first.
But maybe I should re-try under test10 if this gives more insight.)




-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: TMSCSIM [2.6]

[Chiaki]

Chiaki wrote:
> Guennadi Liakhovetski wrote:
> 
>> Didn't pass uncompressed through - bigger than 100K? Attaching 
>> compressed.
>>
>> On Mon, 24 Nov 2003, Guennadi Liakhovetski wrote:
>>
>>
>>> Ghm, here's the patch. But I decided not to compress it, just send it as
>>> attachment, instead of inlining it - after all, this is how it should be
>>> done, isn't it?:-)
>>>
>>> And - now it includes one more fix - replaced deprecated check_region()
>>> with request_region() - noticed by Ishikawa, Chiaki.
> 
> 
> Hello,
> 
> Thank you for the renewed patch.
> 
> I am using TEKRAM dc390. I use tmscsim driver as a module.
> There is a PD/CD combo on the dc390 scsi bus. (PD is
> a somewhat outdated optomagnetic drive. The drive has
> two LUNs, one for CD, and one for PD. PD side is recognized as
> rewritable removable media at least under 2.4.22.)
> 
> With the modified tmscsim driver under 2.6.0-test10,
> (the bzipped patch submitted to linux-scsi worked without rejection)
> I got a panic after module insertion during booting.
> tmscsim is mentioned in /etc/modules and so inserted automatically
> during booting.
> 
> (More background: related stuff I can think of.
>       kernel 2.6.0-test10.
>       tmscsim ... used as module
>       sr ... module as sr_mod
>       event mechanism enabled in the kernel.
>       gcc 3.3 used...)

I should add that the PD/CD combo drive has only
one drive mechanism.
The drive detects the media and decides to
operate either as CD or PD drive at a time.
LUN 0 ... PD drive
LUN 1 ... CD drive
If I insert PD media, LUN 0 acts ad PD drive and
LUN 1 reports that CD is absent.
If I have CD media inside, then LUN 0 reports
that no writable media is inside and LUN 1 acts
as CD drive with media inside.
I have a CD media inside the combo drive and
so it is possible that the media detection might
play a role here (PD media is missing and
so the LUN0 reports no media inside.).


> 
> Here is the panic message left on the screen which I scribbed down
> manually.
> 
>     ... anything above is scrolled and disappeared but I saw the
>         module insertion began. ...
> esi: ef63a2f0 edi: 00000001 ebp: c03a5e4c esp: c03a5e3c
> ds: 007b es: 007b ss: 0068
> 
> Process swapper (pid:0, threadinfo = c03a4000, task=c0338680)
> 
> Stack: 00000000 ef63a2f0 efc617c0 ef5e92c0 c0ea5e8c f09451d1 ef63a2f0 
> ef63a2f0
>        ef5e92c0 ef5e92c0 c03a5ea4 f09451d1 ef63a2f0 4f89f21d 00000021 
> 00000001
>        cc000092 ef63a2f0 efc617c0 ef63a208 c03a5ec4 f0946e36 ef63a208 
> ef5e92c0
> 
> Call trace:
>   [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
>   [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
>   [<f0946e36>] dc390_SRBdone+0x306/0x5b0      [tmscsim]
>   [<f09472f3>] dc390_RequestSense+0x53/0x90   [tmscsim]
>   [<f0946714>] dc390_Disconnect+0x104/0x160    [tmscsim]
>   [<f094574a>] do_DC390_Interrupt:0x28d/0x350 [tmscsim]
>   [<c025dc88>] scsi_softirq+0xe8/0x240
>   [<c010da4b>] handle_IRQ_event:0x3b/0x70
>   [<c010e060>] do_IRQ+0x140/0x390
>   [<c0105000>] _stext+0x0/0xf0
>   [<c010c0ec>] common_interrupt:0x18/0x20
>   [<c0105000>] _stext+0x0/0xf0
>   [<c0108ea6>] default_idel+0x26/0x30
>   [<c0108f24>] cpu_idle+0x34/0x40
>   [<c03a6797>] start_kernel+0x1e7/0x270
>   [<c03a6480>] unknown_bootoption+0x0/0x100
> 
> Code: 0f 0b 28 00 77 9d 94 f0 eb c5 0f 0b 25 00 77 9d 94 f0 eb e8
> 
> <0> Kernel panic: Fatal exception in interrupt
>     In interrupt handler --- not syncing
> 
> 
> 
> 
> OBSERVATION:
> 
>     alt sysreq magic key combination worked.
>     I could run emergency sync and reboot.
> 
>     From the kernel panic message, and the call trace, it looks to
>     me that the interrupt is recursively entered somehow.
>     (Or unexpected interrupt came in.)
> 
> 
> So what next?
> I can enable debugging macro if necessary and re-try.
> 
> Or, I can disable tmscsim module insertion during booting,
> and try "insmod tmscsim" after the kernel is up and running and
> see if it makes difference.
> 
> (Under 2.6.0-test9, and manually fixed patched tmscsim files (due to
> whitespace problems of the patch), I could insert the tmscsim module
> but "insmod tmscsim" took unusually long time, but eventually
> returned. However, /proc/scsi/ didn't show the 2nd LUN of the
> PD/CD combo I have on dc390 bus. Maybe it was a problem of
> insertion of sr_mod due to my misconfiguration of module set up
> for 2.6.0-testXX which I believe is now corrected.
> Since immediately
> afterward when I tried automatic insertion of dc390 during booting,
> I got a similar panic which I reported above, I didn't pursue
> the insertion testing after the kernel is up and running.
> I thought fixing the panic of auto insertion needs to be handled first.
> But maybe I should re-try under test10 if this gives more insight.)
> 
> 
> 
> 


-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

On Wed, 26 Nov 2003, Chiaki wrote:

> I am using TEKRAM dc390. I use tmscsim driver as a module.
> There is a PD/CD combo on the dc390 scsi bus. (PD is
> a somewhat outdated optomagnetic drive. The drive has
> two LUNs, one for CD, and one for PD. PD side is recognized as
> rewritable removable media at least under 2.4.22.)
>
> With the modified tmscsim driver under 2.6.0-test10,
> (the bzipped patch submitted to linux-scsi worked without rejection)
> I got a panic after module insertion during booting.
> tmscsim is mentioned in /etc/modules and so inserted automatically
> during booting.
>
> (More background: related stuff I can think of.
>        kernel 2.6.0-test10.
>        tmscsim ... used as module
>        sr ... module as sr_mod
>        event mechanism enabled in the kernel.
>        gcc 3.3 used...)
>
> Here is the panic message left on the screen which I scribbed down
> manually.
>
> 	... anything above is scrolled and disappeared but I saw the
>          module insertion began. ...
> esi: ef63a2f0 edi: 00000001 ebp: c03a5e4c esp: c03a5e3c
> ds: 007b es: 007b ss: 0068
>
> Process swapper (pid:0, threadinfo = c03a4000, task=c0338680)
>
> Stack: 00000000 ef63a2f0 efc617c0 ef5e92c0 c0ea5e8c f09451d1 ef63a2f0
> ef63a2f0
>         ef5e92c0 ef5e92c0 c03a5ea4 f09451d1 ef63a2f0 4f89f21d 00000021
> 00000001
>         cc000092 ef63a2f0 efc617c0 ef63a208 c03a5ec4 f0946e36 ef63a208
> ef5e92c0
>
> Call trace:
>    [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
>    [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
>    [<f0946e36>] dc390_SRBdone+0x306/0x5b0      [tmscsim]
>    [<f09472f3>] dc390_RequestSense+0x53/0x90   [tmscsim]
>    [<f0946714>] dc390_Disconnect+0x104/0x160    [tmscsim]
>    [<f094574a>] do_DC390_Interrupt:0x28d/0x350 [tmscsim]
>    [<c025dc88>] scsi_softirq+0xe8/0x240
>    [<c010da4b>] handle_IRQ_event:0x3b/0x70
>    [<c010e060>] do_IRQ+0x140/0x390
>    [<c0105000>] _stext+0x0/0xf0
>    [<c010c0ec>] common_interrupt:0x18/0x20
>    [<c0105000>] _stext+0x0/0xf0
>    [<c0108ea6>] default_idel+0x26/0x30
>    [<c0108f24>] cpu_idle+0x34/0x40
>    [<c03a6797>] start_kernel+0x1e7/0x270
>    [<c03a6480>] unknown_bootoption+0x0/0x100
>
> Code: 0f 0b 28 00 77 9d 94 f0 eb c5 0f 0b 25 00 77 9d 94 f0 eb e8
>
> <0> Kernel panic: Fatal exception in interrupt
>      In interrupt handler --- not syncing

Aha, now that's getting interesting - or I was started to feel borref
already:-) A couple of things, that would definitely help:

1) is this the only computer you have? If you had another one - could you
attach a serial console and get a complete Oops?

2) gcc-3.3 could be ok, but I don't really feel quite secure about it...
If we don't find an obvious bug somewhere, I'll ask you to try recompile
it with 2.95.3, ok?

3) are you sure you copied the Oops exactly from the terminal? It didn't
get into /var/log/messages, I presume. Some things in that Oops above look
a bit strange... E.g. the double

I'll try to think about it a bit, but without a complete and exact Oops it
is a bit difficult, also, that the code, generated by your 3.3 seems to be
very different, from what 2.95.3 produces. Your .config (bzipped) could be
useful too. I guess, you have the multiple LUNs option enabled, I'll try
that too, but my hardware is very different from what you have there -
just a AM53C974 and a single hard-drive on it.

Thanks
Guennadi

> OBSERVATION:
>
> 	alt sysreq magic key combination worked.
> 	I could run emergency sync and reboot.
>
> 	From the kernel panic message, and the call trace, it looks to
> 	me that the interrupt is recursively entered somehow.
> 	(Or unexpected interrupt came in.)
>
>
> So what next?
> I can enable debugging macro if necessary and re-try.
>
> Or, I can disable tmscsim module insertion during booting,
> and try "insmod tmscsim" after the kernel is up and running and
> see if it makes difference.
>
> (Under 2.6.0-test9, and manually fixed patched tmscsim files (due to
> whitespace problems of the patch), I could insert the tmscsim module
> but "insmod tmscsim" took unusually long time, but eventually
> returned. However, /proc/scsi/ didn't show the 2nd LUN of the
> PD/CD combo I have on dc390 bus. Maybe it was a problem of
> insertion of sr_mod due to my misconfiguration of module set up
> for 2.6.0-testXX which I believe is now corrected.
> Since immediately
> afterward when I tried automatic insertion of dc390 during booting,
> I got a similar panic which I reported above, I didn't pursue
> the insertion testing after the kernel is up and running.
> I thought fixing the panic of auto insertion needs to be handled first.
> But maybe I should re-try under test10 if this gives more insight.)


---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Chiaki]

Guennadi Liakhovetski wrote:
> On Wed, 26 Nov 2003, Chiaki wrote:
> 
> 
>>I am using TEKRAM dc390. I use tmscsim driver as a module.
>>There is a PD/CD combo on the dc390 scsi bus. (PD is
>>a somewhat outdated optomagnetic drive. The drive has
>>two LUNs, one for CD, and one for PD. PD side is recognized as
>>rewritable removable media at least under 2.4.22.)
>>
>>With the modified tmscsim driver under 2.6.0-test10,
>>(the bzipped patch submitted to linux-scsi worked without rejection)
>>I got a panic after module insertion during booting.
>>tmscsim is mentioned in /etc/modules and so inserted automatically
>>during booting.
>>
>>(More background: related stuff I can think of.
>>       kernel 2.6.0-test10.
>>       tmscsim ... used as module
>>       sr ... module as sr_mod
>>       event mechanism enabled in the kernel.
>>       gcc 3.3 used...)
>>
>>Here is the panic message left on the screen which I scribbed down
>>manually.
>>
>>	... anything above is scrolled and disappeared but I saw the
>>         module insertion began. ...
>>esi: ef63a2f0 edi: 00000001 ebp: c03a5e4c esp: c03a5e3c
>>ds: 007b es: 007b ss: 0068
>>
>>Process swapper (pid:0, threadinfo = c03a4000, task=c0338680)
>>
>>Stack: 00000000 ef63a2f0 efc617c0 ef5e92c0 c0ea5e8c f09451d1 ef63a2f0
>>ef63a2f0
>>        ef5e92c0 ef5e92c0 c03a5ea4 f09451d1 ef63a2f0 4f89f21d 00000021
>>00000001
>>        cc000092 ef63a2f0 efc617c0 ef63a208 c03a5ec4 f0946e36 ef63a208
>>ef5e92c0
>>
>>Call trace:
>>   [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
>>   [<f09451d1>] dc390_StartSCCSI+0x41/0x330    [tmscsim]
>>   [<f0946e36>] dc390_SRBdone+0x306/0x5b0      [tmscsim]
>>   [<f09472f3>] dc390_RequestSense+0x53/0x90   [tmscsim]
>>   [<f0946714>] dc390_Disconnect+0x104/0x160    [tmscsim]
>>   [<f094574a>] do_DC390_Interrupt:0x28d/0x350 [tmscsim]
>>   [<c025dc88>] scsi_softirq+0xe8/0x240
>>   [<c010da4b>] handle_IRQ_event:0x3b/0x70
>>   [<c010e060>] do_IRQ+0x140/0x390
>>   [<c0105000>] _stext+0x0/0xf0
>>   [<c010c0ec>] common_interrupt:0x18/0x20
>>   [<c0105000>] _stext+0x0/0xf0
>>   [<c0108ea6>] default_idel+0x26/0x30
>>   [<c0108f24>] cpu_idle+0x34/0x40
>>   [<c03a6797>] start_kernel+0x1e7/0x270
>>   [<c03a6480>] unknown_bootoption+0x0/0x100
>>
>>Code: 0f 0b 28 00 77 9d 94 f0 eb c5 0f 0b 25 00 77 9d 94 f0 eb e8
>>
>><0> Kernel panic: Fatal exception in interrupt
>>     In interrupt handler --- not syncing
> 
> 
> Aha, now that's getting interesting - or I was started to feel borref
> already:-) A couple of things, that would definitely help:
> 

Hi,

> 1) is this the only computer you have? If you had another one - could you
> attach a serial console  and get a complete Oops?

I will try this later today.

> 2) gcc-3.3 could be ok, but I don't really feel quite secure about it...
> If we don't find an obvious bug somewhere, I'll ask you to try recompile
> it with 2.95.3, ok?

No problem. I will try this also.


> 3) are you sure you copied the Oops exactly from the terminal? It didn't
> get into /var/log/messages, I presume. Some things in that Oops above look
> a bit strange... E.g. the double

As far as manual copying goes, I did my best.
Indeed, I noticed the duplicate lines and I thought that was quite strange!
I suspect that it might lead to the cause of the problem.


> I'll try to think about it a bit, but without a complete and exact Oops it
> is a bit difficult, also, that the code, generated by your 3.3 seems to be
> very different, from what 2.95.3 produces. Your .config (bzipped) could be
> useful too. I guess, you have the multiple LUNs option enabled, I'll try
> that too, but my hardware is very different from what you have there -
> just a AM53C974 and a single hard-drive on it.
> 

I will try to capture the complete oops and
send it as well as the .config file together.

Yes, my hardware is a rather quirky kind for home use
and it has found a few problems in the kernel and driver before.

I will get back with the information
hopefully in 24 hours.


>>OBSERVATION:
>>
>>	alt sysreq magic key combination worked.
>>	I could run emergency sync and reboot.
>>
>>	From the kernel panic message, and the call trace, it looks to
>>	me that the interrupt is recursively entered somehow.
>>	(Or unexpected interrupt came in.)
>>
>>
>>So what next?
>>I can enable debugging macro if necessary and re-try.
>>
>>Or, I can disable tmscsim module insertion during booting,
>>and try "insmod tmscsim" after the kernel is up and running and
>>see if it makes difference.
>>
>>(Under 2.6.0-test9, and manually fixed patched tmscsim files (due to
>>whitespace problems of the patch), I could insert the tmscsim module
>>but "insmod tmscsim" took unusually long time, but eventually
>>returned. However, /proc/scsi/ didn't show the 2nd LUN of the
>>PD/CD combo I have on dc390 bus. Maybe it was a problem of
>>insertion of sr_mod due to my misconfiguration of module set up
>>for 2.6.0-testXX which I believe is now corrected.
>>Since immediately
>>afterward when I tried automatic insertion of dc390 during booting,
>>I got a similar panic which I reported above, I didn't pursue
>>the insertion testing after the kernel is up and running.
>>I thought fixing the panic of auto insertion needs to be handled first.
>>But maybe I should re-try under test10 if this gives more insight.)
> 
> 
> 





-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: TMSCSIM [2.6]

[Chiaki]

[-- Attachment #1: Type: text/plain, Size: 8310 bytes --]

Hi,

Here is the record of messages shown during boot using
serial console when the module loading of tmscsim fails
under 2.6.0-test10.
(Sorry, I am still using gcc 3.3. One step at a time.)

It seems that the system triggered a bug detection code in the
dma-mapping code.

LUN 1 connected to dc390 is now being scanned
as far as the message is correct, but maybe during the scan
and handling of CDROM, the system crashed?
The reason I suspect this is that I don't see the "lun 1"
message line, following the
"Type:	  CD-ROM			     ANSI SCSI revision: 02"
line in the log. For "lun 0",
"Attached scsi removable disk sdc at scsi1, channel 0, id 5, lun 0
Attached scsi generic sg2 at scsi1, channel 0, id 5, lun 0,  type 7"
followed immediately after the detection.

I wonder if anyone has SCSI CDROM driver as a module,
namely sr_mod, up and running under 2.6.0-testXX series.

 From the log, I excerpted interesting part and show it below here. The
full log is attached together with my config.

--- except from the log starts here
Loading modules...
     hpfs
warning: process `update' used the obsolete bdflush system call
Fix your initscripts?
     nls_cp437
     sg
Attached scsi generic sg0 at scsi0, channel 0, id 4, lun 0,  type 0
Attached scsi generic sg1 at scsi0, channel 0, id 6, lun 0,  type 0
     sr_mod
     tmscsim
PCI: Found IRQ 11 for device 0000:00:0d.0
PCI: Sharing IRQ 11 with 0000:00:0f.0
DC390: 1 adapters found
scsi1 : Tekram DC390/AM53C974 V2.0f 2000-12-20
DC390: Target 5: Sync transfer 5.0 MHz, Offset 8
   Vendor: MATSHITA  Model: PD-1 LF-1000	     Rev: A111
   Type:	  Optical Device		     ANSI SCSI revision: 02
Attached scsi removable disk sdc at scsi1, channel 0, id 5, lun 0
Attached scsi generic sg2 at scsi1, channel 0, id 5, lun 0,  type 7
   Vendor: MATSHITA  Model: PD-1 LF-1000	     Rev: A111
   Type:	  CD-ROM			     ANSI SCSI revision: 02
------------[ cut here ]------------
kernel BUG at include/asm/dma-mapping.h:40!
invalid operand: 0000 [#1]
CPU:	0
EIP:	0060:[<f09445c1>]    Not tainted
EFLAGS: 00010046
EIP is at dc390_pci_map+0xc1/0x140 [tmscsim]
eax: 00000000	ebx: 00000000	ecx: c0404e00	edx: 00000000
esi: ef62a2f0	edi: 00000001	ebp: c03a5e4c	esp: c03a5e3c
ds: 007b   es: 007b   ss: 0068
Process swapper (pid: 0, threadinfo=c03a4000 task=c0338680)
Stack: 00000000 ef62a2f0 efc61940 efc99380 c03a5e8c f09451d1 ef62a2f0 
ef62a2f0
        efc99380 efc99380 c03a5ea4 f09451d1 ef62a2f0 982b34e5 0000001e 
00000001
        cc000092 ef62a2f0 efc61940 ef62a208 c03a5ec4 f0946e36 ef62a208 
efc99380
Call Trace:
  [<f09451d1>] dc390_StartSCSI+0x41/0x330 [tmscsim]
  [<f09451d1>] dc390_StartSCSI+0x41/0x330 [tmscsim]
  [<f0946e36>] dc390_SRBdone+0x306/0x5b0 [tmscsim]
  [<f09472f3>] dc390_RequestSense+0x53/0x90 [tmscsim]
  [<f0946714>] dc390_Disconnect+0x104/0x160 [tmscsim]
  [<f094574d>] do_DC390_Interrupt+0x28d/0x350 [tmscsim]
  [<c0113f4c>] timer_interrupt+0x8c/0x260
  [<c025dc88>] scsi_softirq+0xe8/0x240
  [<c010da4b>] handle_IRQ_event+0x3b/0x70
  [<c010e060>] do_IRQ+0x140/0x390
  [<c0105000>] _stext+0x0/0xf0
  [<c010c0ec>] common_interrupt+0x18/0x20
  [<c0105000>] _stext+0x0/0xf0
  [<c0108ea6>] default_idle+0x26/0x30
  [<c0108f24>] cpu_idle+0x34/0x40
  [<c03a6797>] start_kernel+0x1e7/0x270
  [<c03a6480>] unknown_bootoption+0x0/0x100

Code: 0f 0b 28 00 77 9d 94 f0 eb c5 0f 0b 25 00 77 9d 94 f0 eb a8
  <0>Kernel panic: Fatal exception in interrupt
In interrupt handler - not syncing
  <6>SysRq : Emergency Sync
SysRq : Resetting
--- except from the log ends


dma_mapping_on:40 is the following line.

    31	static inline int
    32	dma_map_sg(struct device *dev, struct scatterlist *sg, int nents,
    33		   enum dma_data_direction direction)
    34	{
    35		int i;
    36	
    37		BUG_ON(direction == DMA_NONE);
    38	
    39		for (i = 0; i < nents; i++ ) {
=> 40			BUG_ON(!sg[i].page);
    41	
    42			sg[i].dma_address = page_to_phys(sg[i].page) + sg[i].offset;
    43		}
    44	
    45		flush_write_buffers();
    46		return nents;
    47	}


PS: Note on serial console setup with loadlin.

I studied the excellent guide posted to linux-kernel in August
regarding how to set up the serial console.

However, I am using LOADLIN and this boot utiltiy seems to
require a certain modification to the setup mentioned in the post.
(The post assumed "lilo").

--- quote from the post and my comment ---
 >      Your need a NULL modem serial cable available
 >      from any computer store.
 >
 >    Install uucp - I use on the HOST :
 >
 >    uucp-1.06.1-33.7.2.
 >
 >    Also , LILO is broken on some machines and ignores
 >    serial input so make sure you use at least
 >
 >    lilo-21.6-71
 >
 >    On the TARGET
 >
 >    1. Connect the serial ports together ( COM1->COM1 ) with
 >	the serial cable .
 >
 >    2. Modify LILO to use serial line on the TARGET
 >	add to lilo.conf:
 >	   append="console=ttyS0,9600n8  console=tty0 "
 >	   serial=0,9600N8
 >
 >	Run lilo

CI's comment starts here: I needed to change this part for loadlin
and kernel 2.4.22 as follows. [I tested the serial
console setup under 2.4.22 and it took me a long time to set this up.]

I needed to omit console=tty0 portion for testing the setup under 2.4.22.
If the second console= part is present, the initial portion shown
on the screen namely,

   BIOS-provided physical RAM map:
    BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
    ... omitted ..

disappeared somewhere and not seen on the CRT of the original PC
nor on the serial console screen. They simply disappeared and
so the setup was useless! (All I got was the login prompt: after a while.)

Under 2.4.22, if I remove the later command options, and use a command
line like this, (omitting console=tty0 serial=0,9600N8. serial=
... must be a command option to "lilo" itself.)

loadlin lin2422.ip6 root=/dev/sda6 ro vga=3 scsihosts=sym53c8xx:tmscsim 
console=ttyS0,9600n8

I DID get a partial portion of the messages originally shown on the
original PC on the serial console, but only partially.  ONLY the
messages AFTER `init' starts are shown on serial console.  So
"BIOS-provided ..." message lines and those many lines that follow
until `init' starts are not shown.  Why? I have no idea.

The second best solution for me then is to add
"kern.*[tab]/dev/console" and hope that syslogd will pickup kernel
messages and show it explicitly under /dev/console which is now turned
into /dev/ttyS0 in the step 4 below. (But this may not work well if
the system gets hung BEFORE `init' starts and syslogd is active.
Also, even if such messages like "BIOS -provided ..." are shown using
syslogd, then they are shown AFTER init starts and syslogd daemon
starts. So their position in the recorded message on the serial
console is a little strange.)

However, it turns out 2.6.0-test10 handles the kernel message
output to serial console in a slightly different manner, and
"BIOS-provided ..." messages and all lines that follow are dumped to serial
console immediately without any problem after
my setup [ step 4 below included ].
Again I have no idea why, but as you can see in
the attached log, the serial console for message dumping purposes
seems to work just fine with 2.6.0-test10.  (In any case,
/etc/syslog.conf DID have kern.* /dev/ttyS0 for the log.)

 >    3. Add to /etc/inittab on the HOST
 >
 >	   S0:s12345:respawn:/sbin/agetty 9600 ttyS0
 >
 >    4. To see ALL THE CONSOLE MESSAGES during boot on the TARGET
 >
 >	mv /dev/console /dev/console.org
 >	ln  /dev/ttyS0 /dev/console

CI's comment: This had to be done AFTER disabling devfs and rebooting
2.4.22 on my PC.
(for obvious reasons to those who use devfs. /dev directory
after devfsd is invoked is a "virtual directory" and mv and other
modifications are NOT allowed.)


 >    5. Start uucp on the HOST:
 >
 >	 cu -l /dev/ttyS0 -s 9600
 >

	My second PC is a window98 PC. I disabled the TTY ports
	on that PC long time ago, and so it took me a while
	to enable the tty ports, and configure it under win98.
	Hyperterminal happily tries to open non-functioning com1 and
	com2 ports and simply crashed under that platform and so
	it took me a while to figure out that the tty ports were not
	configured at all!

 >    6. Boot your target
 >
 >    ///
 >
 >    John Donnelly AT HP DOT com
--- end quote ---

Hope this helps.


Ishikawa, Chiaki

[-- Attachment #2: bug-log.zip --]
[-- Type: application/zip, Size: 11337 bytes --]

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

Please, try this:

diff -u linux-2.6.0-test10/drivers/scsi/scsiiom.c~ linux-2.6.0-test10/drivers/scsi/scsiiom.c
--- linux-2.6.0-test10/drivers/scsi/scsiiom.c~  Mon Nov 24 23:47:29 2003
+++ linux-2.6.0-test10/drivers/scsi/scsiiom.c   Thu Nov 27 23:02:35 2003
@@ -1749,7 +1749,7 @@
     pSRB->AdaptStatus = 0;
     pSRB->TargetStatus = 0; /* CHECK_CONDITION<<1; */

-    pcmd = pSRB->pcmd;
+//    pcmd = pSRB->pcmd;

     /* We are called from SRBdone, original PCI mapping has been removed
      * already, new one is set up from StartSCSI */

Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6] (cards)

[Guennadi Liakhovetski]

Hi

What are the best (for testing) tmscsim-supported cards (tekram (t) /
dawicontrol / ...)? My on-board am53c974 is way too simple... Or does the
probability of getting bugs depend of what devices hang on it?

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Chiaki]

Guennadi Liakhovetski wrote:
> Please, try this:
> 
> diff -u linux-2.6.0-test10/drivers/scsi/scsiiom.c~ linux-2.6.0-test10/drivers/scsi/scsiiom.c
> --- linux-2.6.0-test10/drivers/scsi/scsiiom.c~  Mon Nov 24 23:47:29 2003
> +++ linux-2.6.0-test10/drivers/scsi/scsiiom.c   Thu Nov 27 23:02:35 2003
> @@ -1749,7 +1749,7 @@
>      pSRB->AdaptStatus = 0;
>      pSRB->TargetStatus = 0; /* CHECK_CONDITION<<1; */
> 
> -    pcmd = pSRB->pcmd;
> +//    pcmd = pSRB->pcmd;
> 
>      /* We are called from SRBdone, original PCI mapping has been removed
>       * already, new one is set up from StartSCSI */
> 
> Guennadi
> ---
> Guennadi Liakhovetski
> 

I am afraid that it didn't solve the problem.
I got the same kernel bug triggered at the same place.

I will try gcc 2.9x.y next to see if it makes a difference
and also it seems that test11 is out and so it will be tested as well.

Thank you again for your attention.




-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: TMSCSIM [2.6] (cards)

[Chiaki]

Guennadi Liakhovetski wrote:
> Hi
> 
> What are the best (for testing) tmscsim-supported cards (tekram (t) /
> dawicontrol / ...)? My on-board am53c974 is way too simple... Or does the
> probability of getting bugs depend of what devices hang on it?
> 
> Thanks
> Guennadi
> ---
> Guennadi Liakhovetski
> 
> 
I have been using TEKRAM dc390 for some years with good result.

If I recall correctly, Kurt Garloff used dawicontrol card during
early debugging sessions with me on the driver.

I DO suspect that the different
devices on the bus may trigger different bugs.

Does someone use SCSI CDROM with DC390 as I do?
Maybe such person might want to test this driver under 2.6.0-testXX.


-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

On Fri, 28 Nov 2003, Chiaki wrote:

> I am afraid that it didn't solve the problem.
> I got the same kernel bug triggered at the same place.

Ok, then, please, try this one (on the top of yesterday's):

diff -u linux/drivers/scsi/scsiiom.c~ linux/drivers/scsi/scsiiom.c
--- linux/drivers/scsi/scsiiom.c~	Thu Nov 27 23:02:35 2003
+++ linux/drivers/scsi/scsiiom.c	Fri Nov 28 08:29:40 2003
@@ -1439,7 +1439,7 @@
 		goto ckc_e;
 	    }
 	    SET_RES_DRV(pcmd->result,DRIVER_SENSE);
-//	    pcmd->use_sg	 = pSRB->SavedSGCount;
+	    pcmd->use_sg	 = pSRB->SavedSGCount;
 	    //pSRB->ScsiCmdLen	 = (UCHAR) (pSRB->Segment1[0] >> 8);
 	    DEBUG0 (printk ("DC390: RETRY pid %li (%02x), target %02i-%02i\n", pcmd->pid, pcmd->cmnd[0], pcmd->device->id, pcmd->device->lun));
 	    pSRB->SGIndex = 0;
@@ -1734,22 +1734,22 @@
 static void __inline__
 dc390_RequestSense( PACB pACB, PDCB pDCB, PSRB pSRB )
 {
-//    PSCSICMD  pcmd;
+    PSCSICMD  pcmd;
+
+    pcmd = pSRB->pcmd;

     REMOVABLEDEBUG(printk (KERN_INFO "DC390: RequestSense (Cmd %02x, Id %02x, LUN %02x)\n",\
-	    pSRB->pcmd->cmnd[0], pDCB->TargetID, pDCB->TargetLUN));
+	    pcmd->cmnd[0], pDCB->TargetID, pDCB->TargetLUN));

     pSRB->SRBFlag |= AUTO_REQSENSE;
     //pSRB->Segment0[0] = (UINT) pSRB->CmdBlock[0];
     //pSRB->Segment0[1] = (UINT) pSRB->CmdBlock[4];
-    //pSRB->Segment1[0] = ((UINT)(pSRB->pcmd->cmd_len) << 8) + pSRB->SGcount;
+    //pSRB->Segment1[0] = ((UINT)(pcmd->cmd_len) << 8) + pSRB->SGcount;
     //pSRB->Segment1[1] = pSRB->TotalXferredLen;
-    pSRB->SavedSGCount = pSRB->SGcount;
+    pSRB->SavedSGCount = pcmd->use_sg;
     pSRB->SavedTotXLen = pSRB->TotalXferredLen;
     pSRB->AdaptStatus = 0;
     pSRB->TargetStatus = 0; /* CHECK_CONDITION<<1; */
-
-//    pcmd = pSRB->pcmd;

     /* We are called from SRBdone, original PCI mapping has been removed
      * already, new one is set up from StartSCSI */

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

Sorry, you'll eventually get this patch twice - couldn't send from home
(provider busy:-().

Also, could you try compiling it without preemption (don't know, uf you,
Torsten, have it on too). Not that I suspected a bug there - rather
tmscsim's incompatibility with it (although I also have it on).

I think, also, it would make it easier for me, if we agree on the same key
configuea-options for the testing - no SMP, no preemption and the
following hacking options on:
CONFIG_DEBUG_KERNEL
CONFIG_MAGIC_SYSRQ
CONFIG_FRAME_POINTER
Not sure if there are any other options in the kernel, that will change
macros / inlines? And the 2.95.3. compiler, please. I want to try to make
our binaries compatible, so, that I can follow your backtrace on my
compiled binaries. Also, the CPU optimisation could be important. Should
we agree on some minimum common CPU, say, Pentium Classic? But, anyway,
try the patch below first.

Guennadi
---------------------------------
Guennadi Liakhovetski, Ph.D.
DSA Daten- und Systemtechnik GmbH
Pascalstr. 28
D-52076 Aachen
Germany

diff -u linux/drivers/scsi/scsiiom.c~ linux/drivers/scsi/scsiiom.c
--- linux/drivers/scsi/scsiiom.c~	Thu Nov 27 23:02:35 2003
+++ linux/drivers/scsi/scsiiom.c	Fri Nov 28 08:29:40 2003
@@ -1439,7 +1439,7 @@
 		goto ckc_e;
 	    }
 	    SET_RES_DRV(pcmd->result,DRIVER_SENSE);
-//	    pcmd->use_sg	 = pSRB->SavedSGCount;
+	    pcmd->use_sg	 = pSRB->SavedSGCount;
 	    //pSRB->ScsiCmdLen	 = (UCHAR) (pSRB->Segment1[0] >> 8);
 	    DEBUG0 (printk ("DC390: RETRY pid %li (%02x), target %02i-%02i\n", pcmd->pid, pcmd->cmnd[0], pcmd->device->id, pcmd->device->lun));
 	    pSRB->SGIndex = 0;
@@ -1734,22 +1734,22 @@
 static void __inline__
 dc390_RequestSense( PACB pACB, PDCB pDCB, PSRB pSRB )
 {
-//    PSCSICMD  pcmd;
+    PSCSICMD  pcmd;
+
+    pcmd = pSRB->pcmd;

     REMOVABLEDEBUG(printk (KERN_INFO "DC390: RequestSense (Cmd %02x, Id %02x, LUN %02x)\n",\
-	    pSRB->pcmd->cmnd[0], pDCB->TargetID, pDCB->TargetLUN));
+	    pcmd->cmnd[0], pDCB->TargetID, pDCB->TargetLUN));

     pSRB->SRBFlag |= AUTO_REQSENSE;
     //pSRB->Segment0[0] = (UINT) pSRB->CmdBlock[0];
     //pSRB->Segment0[1] = (UINT) pSRB->CmdBlock[4];
-    //pSRB->Segment1[0] = ((UINT)(pSRB->pcmd->cmd_len) << 8) + pSRB->SGcount;
+    //pSRB->Segment1[0] = ((UINT)(pcmd->cmd_len) << 8) + pSRB->SGcount;
     //pSRB->Segment1[1] = pSRB->TotalXferredLen;
-    pSRB->SavedSGCount = pSRB->SGcount;
+    pSRB->SavedSGCount = pcmd->use_sg;
     pSRB->SavedTotXLen = pSRB->TotalXferredLen;
     pSRB->AdaptStatus = 0;
     pSRB->TargetStatus = 0; /* CHECK_CONDITION<<1; */
-
-//    pcmd = pSRB->pcmd;

     /* We are called from SRBdone, original PCI mapping has been removed
      * already, new one is set up from StartSCSI */

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

Further to your tests, Thorsten: just tried cdecord v. 2.00.3 under 2.4.21
and (the same command) under 2.6.0-test7. Worked under 2.4, failed under
2.6. However, I tried it with an ATAPI CDRW, but still, it indicates, that
cdrecord is still not quite functional under 2.6. I did get some error
messages under 2.4:

Error: Illegal request -- (Sense key=0x05)

which, presumably, means some unsupported command, but still it worked. I
should look through LKML archives regarding cdrecord under 2.6, or anybody
can give a short info?

Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Chiaki]

Guennadi Liakhovetski wrote:
> On Fri, 28 Nov 2003, Chiaki wrote:
> 
> 
>>I am afraid that it didn't solve the problem.
>>I got the same kernel bug triggered at the same place.
> 
> 
> Ok, then, please, try this one (on the top of yesterday's):
> 
> diff -u linux/drivers/scsi/scsiiom.c~ linux/drivers/scsi/scsiiom.c
> --- linux/drivers/scsi/scsiiom.c~	Thu Nov 27 23:02:35 2003
> +++ linux/drivers/scsi/scsiiom.c	Fri Nov 28 08:29:40 2003
> @@ -1439,7 +1439,7 @@
>  		goto ckc_e;
>  	    }
>  	    SET_RES_DRV(pcmd->result,DRIVER_SENSE);
> -//	    pcmd->use_sg	 = pSRB->SavedSGCount;
> +	    pcmd->use_sg	 = pSRB->SavedSGCount;
>  	    //pSRB->ScsiCmdLen	 = (UCHAR) (pSRB->Segment1[0] >> 8);
>  	    DEBUG0 (printk ("DC390: RETRY pid %li (%02x), target %02i-%02i\n", pcmd->pid, pcmd->cmnd[0], pcmd->device->id, pcmd->device->lun));
>  	    pSRB->SGIndex = 0;
> @@ -1734,22 +1734,22 @@
>  static void __inline__
>  dc390_RequestSense( PACB pACB, PDCB pDCB, PSRB pSRB )
>  {
> -//    PSCSICMD  pcmd;
> +    PSCSICMD  pcmd;
> +
> +    pcmd = pSRB->pcmd;
> 
>      REMOVABLEDEBUG(printk (KERN_INFO "DC390: RequestSense (Cmd %02x, Id %02x, LUN %02x)\n",\
> -	    pSRB->pcmd->cmnd[0], pDCB->TargetID, pDCB->TargetLUN));
> +	    pcmd->cmnd[0], pDCB->TargetID, pDCB->TargetLUN));
> 
>      pSRB->SRBFlag |= AUTO_REQSENSE;
>      //pSRB->Segment0[0] = (UINT) pSRB->CmdBlock[0];
>      //pSRB->Segment0[1] = (UINT) pSRB->CmdBlock[4];
> -    //pSRB->Segment1[0] = ((UINT)(pSRB->pcmd->cmd_len) << 8) + pSRB->SGcount;
> +    //pSRB->Segment1[0] = ((UINT)(pcmd->cmd_len) << 8) + pSRB->SGcount;
>      //pSRB->Segment1[1] = pSRB->TotalXferredLen;
> -    pSRB->SavedSGCount = pSRB->SGcount;
> +    pSRB->SavedSGCount = pcmd->use_sg;
>      pSRB->SavedTotXLen = pSRB->TotalXferredLen;
>      pSRB->AdaptStatus = 0;
>      pSRB->TargetStatus = 0; /* CHECK_CONDITION<<1; */
> -
> -//    pcmd = pSRB->pcmd;
> 
>      /* We are called from SRBdone, original PCI mapping has been removed
>       * already, new one is set up from StartSCSI */
> 

(My mail feed from linux-scsi list was flakey for the last 24 hours, and
Guennadi Liakohovetski kindly sent me scsiiom.c file entirely after my 
asking for it.)

Hi,

A good news, and a strange observation (not fatal I think...).

I applied the latest patch to scsiiom.c: actually I used the source
file you kindly sent me.

Also, I disabled kernel preemption after reading your post.
 From my .config:
   # CONFIG_PREEMPT is not set

Also, please note that I upgraded to 2.6.0-test11.
(I am still using gcc 3.3.2)

Now the tmscsim module loaded without a problem!

Attached is the initial portion of the message recorded during booting.
The PD drive at lun 0, and CD drive at lun 1 are both recognized, and
I later could mount a joliet CD and list its directory using "ls -R"
and so the driver seems to work fine more or less!

A strange observation is this.  The very first time after I set up the
new kernel and tmscsim module and tried to run 2.6.0-test11, the
module Oopsed again.
But at that time, I was not using serial console :-(
[I thought if the new patch worked for someone else, it might work for 
me.]
I looked at the address where Oops occurred on the screen.
It was slightly different from the one reported earlier.  Obviously,
the patch changed the absolute addresses. However, the symptoms (stack
trace, with a duplication.) was essentially the same from the report I
gave earlier.

However, after this, when I tried the serial console booting afresh, the
system worked withtout a hitch. The attached log was recorded at the time.
Afterward, I also tried the CRT-console booting again. The
system worked just fine this time around. Hmm...

So there *could* be a timing related race or somthing that might
trigger a problem in a rare situation.

On the other hand, since the problem occurred only at the very first
time so far, it may be due to a setup error : like the object file was
not copied correctly although I think that is highly unlikely due to
the nature of "make bzImage; make modules; make modules_install".
Anyway, I will report to you if such an error occurs again.  (Well, I
am not using 2.6.0-testXX regularly, but will try to exercise the new
kernel test versions now and then. Oh, maybe I should test HP DAT
drive, too.).

(The single isolated failure could be even related to my rather
lengthy loadlin command line.  MS-DOS command.com ignores characters
after 128(?) characters and that may have played a role: I shortened
my loadlin command line just in case. I could also use
@additional.bat construct to avoid this, but not used it so far.).

So many variables to eliminate from the equation, so to speak.

Anyway, here is the successful log: again, I tried to remove Japanese
characters from it.


Linux version 2.6.0-test11 (root@duron) (gcc ... 3.3.2 (Debian)) #4 Sat 
Nov 29 09:11:21 JST 2003
BIOS-provided physical RAM map:
  BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
  BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
  BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
  BIOS-e820: 0000000000100000 - 000000002fff0000 (usable)
  BIOS-e820: 000000002fff0000 - 000000002fff3000 (ACPI NVS)
  BIOS-e820: 000000002fff3000 - 0000000030000000 (ACPI data)
  BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
767MB LOWMEM available.
On node 0 totalpages: 196592
   DMA zone: 4096 pages, LIFO batch:1
   Normal zone: 192496 pages, LIFO batch:16
   HighMem zone: 0 pages, LIFO batch:1
DMI 2.2 present.
Building zonelist for node : 0
Kernel command line: root=/dev/sda6 ro scsihosts=sym53c8xx:tmscsim 
console=ttyS0
,9600n8 BOOT_IMAGE=260t9
Initializing CPU#0
PID hash table entries: 4096 (order 12: 32768 bytes)
Detected 1535.151 MHz processor.
Console: colour VGA+ 80x28
Memory: 774720k/786368k available (1888k kernel code, 10880k reserved, 
703k data
, 136k init, 0k highmem)
Calibrating delay loop... 3022.84 BogoMIPS
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
CPU: L2 Cache: 256K (64 bytes/line)
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: AMD Athlon(tm) XP 1800+ stepping 02
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xfb690, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
Linux Plug and Play Support v0.97 (c) Adam Belay
PnPBIOS: Scanning system for PnP BIOS support...
PnPBIOS: Found PnP BIOS installation structure at 0xc00fc030
PnPBIOS: PnP BIOS version 1.0, entry 0xf0000:0xc060, dseg 0xf0000
PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Using IRQ router VIA [1106/0686] at 0000:00:07.0
Machine check exception polling timer started.
ikconfig 0.7 with /proc/config*
devfs: v1.22 (20021013) Richard Gooch (rgooch@atnf.csiro.au)
devfs: devfs_debug: 0x0
devfs: boot_options: 0x0
Initializing Cryptographic API
isapnp: Scanning for PnP cards...
isapnp: No Plug & Play device found
pty: 256 Unix98 ptys configured
Real Time Clock Driver v1.12
Linux agpgart interface v0.100 (c) Dave Jones
agpgart: Detected AMD 761 chipset
agpgart: Maximum main memory to use for agp memory: 690M
agpgart: AGP aperture is 64M @ 0xf0000000
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ttyS1 at I/O 0x2f8 (irq = 3) is a 16550A
Using anticipatory io scheduler
Floppy drive(s): fd0 is 1.44M
FDC 0 is a post-1991 82077
RAMDISK driver initialized: 16 RAM disks of 4096K size 1024 blocksize
Intel(R) PRO/100 Network Driver - version 2.3.30-k1
Copyright (c) 2003 Intel Corporation

PCI: Found IRQ 11 for device 0000:00:0f.0
PCI: Sharing IRQ 11 with 0000:00:0d.0
e100: eth0: Intel(R) PRO/100 Network Connection

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: IDE controller at PCI slot 0000:00:07.1
VP_IDE: chipset revision 6
VP_IDE: not 100% native mode: will probe irqs later
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
VP_IDE: VIA vt82c686b (rev 40) IDE UDMA100 controller on pci0000:00:07.1
     ide0: BM-DMA at 0xb400-0xb407, BIOS settings: hda:DMA, hdb:pio
     ide1: BM-DMA at 0xb408-0xb40f, BIOS settings: hdc:DMA, hdd:pio
hda: ST320423A, ATA DISK drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
hdc: MATSHITA CR-583, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
HPT370A: IDE controller at PCI slot 0000:00:13.0
PCI: Found IRQ 5 for device 0000:00:13.0
HPT370A: chipset revision 4
HPT37X: using 33MHz PCI clock
HPT370A: 100% native mode on irq 5
     ide2: BM-DMA at 0xe400-0xe407, BIOS settings: hde:pio, hdf:pio
     ide3: BM-DMA at 0xe408-0xe40f, BIOS settings: hdg:pio, hdh:pio
hda: max request size: 128KiB
hda: 40011300 sectors (20485 MB) w/512KiB Cache, CHS=39693/16/63, UDMA(66)
  /dev/ide/host0/bus0/target0/lun0: p1 p2 < p5 p6 p7 p8 p9 p10 p11 p12 
p13 p14 >
PCI: Found IRQ 10 for device 0000:00:0b.0
PCI: Sharing IRQ 10 with 0000:00:07.2
PCI: Sharing IRQ 10 with 0000:00:07.3
PCI: Sharing IRQ 10 with 0000:00:08.0
sym0: <895> rev 0x1 at pci 0000:00:0b.0 irq 10
sym0: Tekram NVRAM, ID 7, Fast-40, SE, parity checking
sym0: SCSI BUS has been reset.
sym0: SCSI BUS mode change from SE to SE.
sym0: SCSI BUS has been reset.
scsi0 : sym-2.1.18b
   Vendor: HITACHI   Model: DK318H-91WS	     Rev: B2BQ
   Type:	  Direct-Access			     ANSI SCSI revision: 02
sym0:4:0: tagged command queuing enabled, command queue depth 16.
   Vendor: IBM	    Model: DNES-318350Y	     Rev: SA60
   Type:	  Direct-Access			     ANSI SCSI revision: 03
sym0:6:0: tagged command queuing enabled, command queue depth 16.
sym0:6: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 31)
sym0:6:0:phase change 2-3 12@2fc5cf60 resid=11.
sym0:4: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 15)
SCSI device sda: 17773980 512-byte hdwr sectors (9100 MB)
SCSI device sda: drive cache: write through
  /dev/scsi/host0/bus0/target4/lun0: p1 < p5 p6 p7 p8 >
Attached scsi disk sda at scsi0, channel 0, id 4, lun 0
SCSI device sdb: 35566501 512-byte hdwr sectors (18210 MB)
SCSI device sdb: drive cache: write through
  /dev/scsi/host0/bus0/target6/lun0: p1 < p5 p6 p7 >
Attached scsi disk sdb at scsi0, channel 0, id 6, lun 0
mice: PS/2 mouse device common for all mice
input: PS/2 Logitech Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
I2O Core - (C) Copyright 1999 Red Hat Software
I2O: Event thread created as pid 12
i2o: Checking for PCI I2O controllers...
I2O configuration manager v 0.04.
   (C) Copyright 1999 Red Hat Software
NET: Registered protocol family 2
IP: routing cache hash table of 2048 buckets, 64Kbytes
TCP: Hash tables configured (established 262144 bind 37449)
NET: Registered protocol family 1
NET: Registered protocol family 17
VFS: Mounted root (ext2 filesystem) readonly.
Freeing unused kernel memory: 136k freed
INIT: version 2.84 booting
Loading /etc/console/boottime.kmap.gz
Activating swap.
Adding 2000052k swap on /dev/hda12.  Priority:-1 extents:1
Checking root file system...
fsck 1.34-WIP (21-May-2003)
/dev/sda6: clean, 212160/895840 files, 1634625/1791484 blocks
/etc/isapnp.conf:20 -- Fatal - Error occurred executing request 'ISOLATE 
PRESERV
E' --- further action aborted
System time was Sat Nov 29 00:58:21 UTC 2003.
Setting the System Clock using the Hardware Clock as reference...
System Clock set. System local time is now Sat Nov 29 09:58:23 JST 2003.
Calculating module dependencies... done.
Loading modules...
     hpfs
warning: process `update' used the obsolete bdflush system call
Fix your initscripts?
     nls_cp437
     sg
Attached scsi generic sg0 at scsi0, channel 0, id 4, lun 0,  type 0
Attached scsi generic sg1 at scsi0, channel 0, id 6, lun 0,  type 0
     sr_mod
     tmscsim
PCI: Found IRQ 11 for device 0000:00:0d.0
PCI: Sharing IRQ 11 with 0000:00:0f.0
DC390: 1 adapters found
scsi1 : Tekram DC390/AM53C974 V2.0f 2000-12-20
DC390: Target 5: Sync transfer 5.0 MHz, Offset 8
   Vendor: MATSHITA  Model: PD-1 LF-1000	     Rev: A111
   Type:	  Optical Device		     ANSI SCSI revision: 02
Attached scsi removable disk sdc at scsi1, channel 0, id 5, lun 0
Attached scsi generic sg2 at scsi1, channel 0, id 5, lun 0,  type 7
   Vendor: MATSHITA  Model: PD-1 LF-1000	     Rev: A111
   Type:	  CD-ROM			     ANSI SCSI revision: 02
sr0: scsi-1 drive
Uniform CD-ROM driver Revision: 3.12
Attached scsi generic sg3 at scsi1, channel 0, id 5, lun 1,  type 5
     ide-cd
hdc: ATAPI 8X CD-ROM drive, 128kB Cache, DMA
     radeon
[drm] Initialized radeon 1.9.0 20020828 on minor 0
     ecc
FATAL: Module ecc not found.
     ipv6
NET: Registered protocol family 10
IPv6 over IPv4 tunneling driver
All modules loaded.
Checking all file systems...
fsck 1.34-WIP (21-May-2003)
/dev/sdb5: clean, 167104/770048 files, 1449390/1537272 blocks
/dev/hda11: clean, 13/250368 files, 455595/500015 blocks
/dev/hda10: clean, 12/250368 files, 129092/500015 blocks
Setting kernel variables..
Mounting local filesystems...
/dev/sdb5 on /u2 type ext2 (rw)
mount: none already mounted or /dev/pts busy
mount: according to mtab, devpts is already mounted on /dev/pts
mount: fs type shm not supported by kernel
/dev/hda11 on /dos-vmware-dir type ext2 (rw)
/dev/hda10 on /dos-vmware-2-dir type ext2 (rw)
/dev/hda1 on /dos-c-drive type vfat (rw)

	  ... omitted ...

Later from the command line.

ishikawa@duron$ cat /proc/scsi/
device_info  scsi	  sg	       sym53c8xx    tmscsim
ishikawa@duron$ cat /proc/scsi/scsi
Attached devices:
Host: scsi0 Channel: 00 Id: 04 Lun: 00
   Vendor: HITACHI  Model: DK318H-91WS	   Rev: B2BQ
   Type:	  Direct-Access			   ANSI SCSI revision: 02
Host: scsi0 Channel: 00 Id: 06 Lun: 00
   Vendor: IBM	   Model: DNES-318350Y	   Rev: SA60
   Type:	  Direct-Access			   ANSI SCSI revision: 03
Host: scsi1 Channel: 00 Id: 05 Lun: 00
   Vendor: MATSHITA Model: PD-1 LF-1000	   Rev: A111
   Type:	  Optical Device		   ANSI SCSI revision: 02
Host: scsi1 Channel: 00 Id: 05 Lun: 01
   Vendor: MATSHITA Model: PD-1 LF-1000	   Rev: A111
   Type:	  CD-ROM			   ANSI SCSI revision: 02
ishikawa@duron$ cat /proc/scsi/tmscsim/1
Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f 2000-12-20
SCSI Host Nr 1, DC390 Adapter Nr 0
IOPortBase 0xcc00, IRQ 11
MaxID 7, MaxLUN 8, AdapterID 7, SelTimeout 250 ms, DelayReset 3 s
TagMaxNum 16, Status 0x00, ACBFlag 0x00, GlitchEater 24 ns
Statistics: Cmnds 28, Cmnds not sent directly 0, Out of SRB conds 0
	    Lost arbitrations 0, Sel. connected 0, Connected: No
Nr of attached devices: 4, Nr of DCBs: 2
Map of attached LUNs: 00 00 00 00 00 03 00 00
Idx ID LUN Prty Sync DsCn SndS TagQ NegoPeriod SyncSpeed SyncOffs MaxCmd
00  05	00  Yes	 Yes  Yes  Yes	No    200 ns	 5.0 M	    08	    01
01  05	01  Yes	 Yes  Yes  Yes	No    200 ns	 5.0 M	    08	    01
Commands in Queues: Query: 0:
ishikawa@duron$ ls /dev/cdrom*
/dev/cdrom@
ishikawa@duron$ ls -l /dev/cdroms
ishikawa@duron$ ls -l /dev/sr*
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr0 -> scd0
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr1 -> scd1
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr2 -> scd2
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr3 -> scd3
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr4 -> scd4
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr5 -> scd5
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr6 -> scd6
lrwxrwxrwx    1 root	 root		 4 2000-11-24 05:31 /dev/sr7 -> scd7
ishikawa@duron$ dmesg | grep sr
sr0: scsi-1 drive
Attached scsi CD-ROM sr0 at scsi1, channel 0, id 5, lun 1
ishikawa@duron$ su
Password:
duron:/home/ishikawa# mount /dev/sr0 /mnt
mount: block device /dev/sr0 is write-protected, mounting read-only
duron:/home/ishikawa# ls -l /mnt
  2992
dr-xr-xr-x    1 root	 root	      2048 2003-05-07 14:25 DATA
-r-xr-xr-x    1 root	 root	   3061340 2003-05-07 14:25 prog.exe

	     ... later I could recursively list DATA ...


Thank you agai for your help.


PS: now that the driver seems to be in better shape, you might want to
bump the driver version number  reported in the banner,
"Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f 
2000-12-20".
The new version banner will help you and users in keeping track of the new
drivers which will solve problems encountered in the future versions
of 2.6.x kernel. Numbering probably should be coordinated with
Kurt Garloff.

PPS: also someone might want to run
	indent -kr -i8
on the source files after the cleanup (or before cleanup).





-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

On Sat, 29 Nov 2003, Chiaki wrote:

> Also, I disabled kernel preemption after reading your post.
>  From my .config:
>    # CONFIG_PREEMPT is not set

Ok, then it worked (except for that misterious first try). Can you switch
preemption on again, so we can check for sure that it's my last
modification, that fixed your problem and not switching preemption off.

> I looked at the address where Oops occurred on the screen.
> It was slightly different from the one reported earlier.  Obviously,
> the patch changed the absolute addresses. However, the symptoms (stack
> trace, with a duplication.) was essentially the same from the report I
> gave earlier.

That is very strange. Let's keep an eye on this...

> So there *could* be a timing related race or somthing that might
> trigger a problem in a rare situation.

You load the driver always on boot, right? So, consitions are always more
or less the same...

> kernel test versions now and then. Oh, maybe I should test HP DAT
> drive, too.).

Yes, please do. Thorsten still has problems burning CDs on a tmscsim
attached CDRW. You don't have one to test, do you?

> PS: now that the driver seems to be in better shape, you might want to
> bump the driver version number  reported in the banner,
> "Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f
> 2000-12-20".

Yep. Kurt, Christian, shall I increment the version number (2.0g / 2.1a?),
adding a Changelog entry? Also, how shall it be maintained now, until it
is included in the stock 2.6 (hopefully)? Is there a linux-scsi tree,
where this driver could be merged in, or just an ftp site, where the patch
could be uploaded? I am not using BK (don't think it would make much sense
with a 56K modem dial-up:-)).

> PPS: also someone might want to run
> 	indent -kr -i8
> on the source files after the cleanup (or before cleanup).

No, wouldn't do that. It would unnecessarily blow the patch up...
Although, I didn't really follow the original indentation everywhere, but
I wouldn't chenge it all just for the sake of it. The patch already has
more than enough "non-functionality-related" modifications.

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

> Yep. Kurt, Christian, shall I increment the version number (2.0g / 2.1a?),

Oops, apologize, I certainly meant to address Christoph Hellwig, sorry.

Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Thorsten Leemhuis]

[Hi linux-scsi, I mailed with Guennadi in private before as I tried the
driver before it was posted to the list] 

Am Fr, den 28.11.2003 schrieb Guennadi Liakhovetski um 21:25: 
> Further to your tests, Thorsten: just tried cdecord v. 2.00.3 under 2.4.21
> and (the same command) under 2.6.0-test7. Worked under 2.4, failed under
> 2.6. However, I tried it with an ATAPI CDRW, but still, it indicates, that
> cdrecord is still not quite functional under 2.6. I did get some error
> messages under 2.4:
> 
> Error: Illegal request -- (Sense key=0x05)
> 
> which, presumably, means some unsupported command, but still it worked. I
> should look through LKML archives regarding cdrecord under 2.6, or anybody
> can give a short info?

PEBKAC

I just found the problem, was my fault -- the module sg was not loaded,
in 2.4 this was done automatically. Will have to check my
module-configuration...

Will try to burn now. Sorry for the noise.

CU
thl

Re: TMSCSIM [2.6]

[Thorsten Leemhuis]

Am Sa, den 29.11.2003 schrieb Thorsten Leemhuis um 12:03:
> [Hi linux-scsi, I mailed with Guennadi in private before as I tried the
> driver before it was posted to the list] 
> 
> Am Fr, den 28.11.2003 schrieb Guennadi Liakhovetski um 21:25: 
> > Further to your tests, Thorsten: just tried cdecord v. 2.00.3 under 2.4.21
> > and (the same command) under 2.6.0-test7. Worked under 2.4, failed under
> > 2.6. However, I tried it with an ATAPI CDRW, but still, it indicates, that
> > cdrecord is still not quite functional under 2.6. I did get some error
> > messages under 2.4:
> > 
> > Error: Illegal request -- (Sense key=0x05)
> > 
> > which, presumably, means some unsupported command, but still it worked. I
> > should look through LKML archives regarding cdrecord under 2.6, or anybody
> > can give a short info?
> 
> PEBKAC
> 
> I just found the problem, was my fault -- the module sg was not loaded,
> in 2.4 this was done automatically. Will have to check my
> module-configuration...
> 
> Will try to burn now. Sorry for the noise.

Burning went fine without problems, a bit-wise compare was fine. 

Tried to scan, there the machine locks up. But this happens in 2.4 also,
maybe it's hardware-problem. From my point of view I think investigating
further here is lost time.

Thanks for your work Guennadi!

CU
thl

Re: TMSCSIM [2.6]

[Matthias Andree]

Guennadi Liakhovetski <g.liakhovetski@gmx.de> writes:

>> PS: now that the driver seems to be in better shape, you might want to
>> bump the driver version number  reported in the banner,
>> "Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f
>> 2000-12-20".
>
> Yep. Kurt, Christian, shall I increment the version number (2.0g / 2.1a?),
> adding a Changelog entry? Also, how shall it be maintained now, until it
> is included in the stock 2.6 (hopefully)? Is there a linux-scsi tree,
> where this driver could be merged in, or just an ftp site, where the patch
> could be uploaded? I am not using BK (don't think it would make much sense
> with a 56K modem dial-up:-)).

Guennadi,

Please bump the version, I'd choose 2.0f-gl1 (where gl are your initials
and 1 is the first "release" you deem stable).

If some maintainer (Kurt? 2.6-SCSI-bugfixes maintainer?) wants a
different version, he shall have the last word and can still choose a
different version string.

Thanks,

-- 
Matthias Andree

Encrypt your mail: my GnuPG key ID is 0x052E7D95

Re: TMSCSIM [2.6]

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 1415 bytes --]

On Sat, Nov 29, 2003 at 10:46:24AM +0100, Guennadi Liakhovetski wrote:
> > PS: now that the driver seems to be in better shape, you might want to
> > bump the driver version number  reported in the banner,
> > "Tekram DC390/AM53C974 PCI SCSI Host Adapter, Driver Version 2.0f
> > 2000-12-20".
> 
> Yep. Kurt, Christian, shall I increment the version number (2.0g / 2.1a?),
> adding a Changelog entry? Also, how shall it be maintained now, until it
> is included in the stock 2.6 (hopefully)? Is there a linux-scsi tree,
> where this driver could be merged in, or just an ftp site, where the patch
> could be uploaded? I am not using BK (don't think it would make much sense
> with a 56K modem dial-up:-)).

Well, 2.1a seems a reasonable version number.
Please add a changelog entry. You should get the credits for doing all
the work for porting the driver! Thanks again!

I can put it for download on my site; 
we should try to push it into 2.6.0/1, of course.

> No, wouldn't do that. It would unnecessarily blow the patch up...

I wouldn't do it either.
Then better have two patches, one doing only functional changes, one
only changing formatting.

Regards,
-- 
Kurt Garloff                   <kurt@garloff.de>             [Koeln, DE]
Physics:Plasma modeling <garloff@plasimo.phys.tue.nl> [TU Eindhoven, NL]
Linux:SCSI, Security           <garloff@suse.de>    [SUSE Nuernberg, DE]

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: TMSCSIM [2.6] (cards)

[Kurt Garloff]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

Guennadi,

On Thu, Nov 27, 2003 at 11:43:03PM +0100, Guennadi Liakhovetski wrote:
> What are the best (for testing) tmscsim-supported cards (tekram (t) /
> dawicontrol / ...)? 

Dawi2974, TekramDC390(T), onboard 53c974/79c974 chipsets.
I doubt you can easily find new hardware with this chipset nowadays ...

> My on-board am53c974 is way too simple... 

They are all the same ...

> Or does the
> probability of getting bugs depend of what devices hang on it?

Yep. Scanners did tend to trigger bugs in the driver in the past.

Regards,
-- 
Kurt Garloff  <garloff@suse.de>                            Cologne, DE 
SUSE LINUX AG, Nuernberg, DE                          SUSE Labs (Head)

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]

Re: TMSCSIM [2.6]

[James Bottomley]

On Sat, 2003-11-29 at 12:11, Kurt Garloff wrote:
> I can put it for download on my site; 
> we should try to push it into 2.6.0/1, of course.

It's too late for 2.6.0, I'm afraid.  I'll keep it in the queue for
scsi-misc-2.7.

I anticipate the driver updates gate opening again before 2.7 begins, so
it may be able to go into 2.6.1 or later, but that depends on Andrew's
policy.

James

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

On Sat, 29 Nov 2003, Matthias Andree wrote:

> Please bump the version, I'd choose 2.0f-gl1 (where gl are your initials
> and 1 is the first "release" you deem stable).

Yeah-yeah, I know what "gl" means - as well as anybody living / working in
Germany does:-) It's one of favorite jokes in the company, I am working
for (see my working email address in the CC-list).

> If some maintainer (Kurt? 2.6-SCSI-bugfixes maintainer?) wants a
> different version, he shall have the last word and can still choose a
> different version string.

Ok, version string is one of the smallest problems, the real question is -
what to do with the patch? Just post it to the list, so that one of
maintainers could pick it up and include in his / her tree?

Also, would be nice if somebody could test this driver on a highmem-PC,
and on non i386 platforms...

Well, it has been fun. I guess, I could try to fill in those "TODOs" Kurt
has inserted in the code. But that will be for -gl2. Otherwise, there are
quite a few more SCSI drivers, depending on BROKEN. Do any of them need
fixing and currently have nobody to do the work or they are there just
waiting to be removed? Anyway, I don't have any of that hardware at
hand...

Thanks
Guennadi
---
Guennadi Liakhovetski

Re: TMSCSIM [2.6]

[Guennadi Liakhovetski]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 482 bytes --]

On Sat, 29 Nov 2003, Kurt Garloff wrote:

> Well, 2.1a seems a reasonable version number.
> Please add a changelog entry. You should get the credits for doing all
> the work for porting the driver! Thanks again!

...with the help from you and others - in code improvement and testing!

> I can put it for download on my site;
> we should try to push it into 2.6.0/1, of course.

Attached is the current version of the patch.

Thanks again to all
Guennadi
---
Guennadi Liakhovetski


[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 18066 bytes --]

Re: TMSCSIM [2.6]

[Chiaki]

Guennadi Liakhovetski wrote:
> On Sat, 29 Nov 2003, Chiaki wrote:
> 
> 
>>Also, I disabled kernel preemption after reading your post.
>> From my .config:
>>   # CONFIG_PREEMPT is not set
> 
> 
> Ok, then it worked (except for that misterious first try). Can you switch
> preemption on again, so we can check for sure that it's my last
> modification, that fixed your problem and not switching preemption off.
> 
Hello,

I recompiled the kernel with preemption enabled this time.

tmscsim module loaded successfully.
So it was your patch that corrected the problem.

Thank you again!


PS: As for indentation, as others suggested,

  - functional patch.
  - incorporation into the main tree.
  - possible indentation patch afterward.

seems to be the best steps to follow.



-- 
int main(void){int j=2003;/*(c)2003 cishikawa. */
char t[] ="<CI> @abcdefghijklmnopqrstuvwxyz.,\n\"";
char *i ="g>qtCIuqivb,gCwe\np@.ietCIuqi\"tqkvv is>dnamz";
while(*i)((j+=strchr(t,*i++)-(int)t),(j%=sizeof t-1),
(putchar(t[j])));return 0;}/* under GPL */