Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
Disclaimer: I know nothing of this device/hw, the scsi protocol or
anything remotely applicable the functioning of this driver. The
stuff below is just nit-picking and PITA-ing :) Pro-active kernel
janitoring, if you like.
On Sat, May 12, 2001 at 11:43:04AM -0500, James Bottomley wrote:
[...]
> +struct Scsi_Host * __init
> +NCR_700_detect(Scsi_Host_Template *tpnt,
> +struct NCR_700_Host_Parameters *hostdata)
> +{
> + __u32 *script = kmalloc(sizeof(SCRIPT), GFP_KERNEL);
> + __u32 pScript;
> + struct Scsi_Host *host;
> + static int banner = 0;
> + int j;
> +
[...]
> +
> + host = scsi_register(tpnt, 4);
> + if(script == NULL) {
> + printk(KERN_ERR "53c700: Failed to allocate script, detatching\n");
> + scsi_unregister(host);
> + return NULL;
> + }
You are not checking if the scsi_register went ok or not.
[...]
> +STATIC void
> +free_slot(struct NCR_700_command_slot *slot,
> + struct NCR_700_Host_Parameters *hostdata)
> +{
> + int hash;
> + struct NCR_700_command_slot **forw, **back;
> +
> +
> + if((slot->state & NCR_700_SLOT_MASK) != NCR_700_SLOT_MAGIC) {
> + printk(" SLOT %p is not MAGIC!!!\n", slot);
> + }
> + if(slot->state == NCR_700_SLOT_FREE) {
> + printk(" SLOT %p is FREE!!!\n", slot);
> + }
Could you be persuaded to add KERN_SOMETHING to the printks above?
[...]
> +STATIC __u32
> +process_extended_message(struct Scsi_Host *host,
> + struct NCR_700_Host_Parameters *hostdata,
> + Scsi_Cmnd *SCp, __u32 dsp, __u32 dsps)
> +{
> + __u32 resume_offset = dsp, temp = dsp + 8;
> + __u8 pun = 0xff, lun = 0xff;
> +
> + if(SCp != NULL) {
> + pun = SCp->target;
> + lun = SCp->lun;
> + }
> +
> + switch(hostdata->msgin[2]) {
[...]
> +
> + default:
> + printk(KERN_INFO "scsi%d (%d:%d): Unexpected message %s: ",
> +host->host_no, pun, lun,
> +NCR_700_phase[(dsps & 0xf00) >> 8]);
> + print_msg(hostdata->msgin);
> + printk("\n");
It would be nice with a KERN_XX before "\n" (yes, I recognize that
print_msg does not do this :( )
[...]
> +STATIC __u32
> +process_script_interrupt(__u32 dsps, __u32 dsp, Scsi_Cmnd *SCp,
> + struct Scsi_Host *host,
> + struct NCR_700_Host_Parameters *hostdata)
> +{
[...]
> + } else if((dsps & 0xf0f0) == A_UNEXPECTED_PHASE) {
> + __u8 i = (dsps & 0xf00) >> 8;
> +
> + printk(KERN_ERR "scsi%d: (%d:%d), UNEXPECTED PHASE %s (%s)\n",
> +host->host_no, pun, lun,
> +NCR_700_phase[i],
> +sbcl_to_string(inb(host->base + SBCL_REG)));
> + printk(" len = %d, cmd =", SCp->cmd_len);
A KERN_ERR prefix?
[...]
> + retry:
> + if(slot == NULL) {
> + struct NCR_700_command_slot *s = find_ITL_Nexus(hostdata,
>reselection_id, lun);
> + printk(KERN_ERR "scsi%d: (%d:%d) RESELECTED but no saved
>command (MSG = %02x %02x %02x)!!\n",
> +host->host_no, reselection_id, lun,
> +hostdata->msgin[0], hostdata->msgin[1],
> +hostdata->msgin[2]);
> + printk(KERN_ERR " OUTSTANDING TAGS:");
> + while(s != NULL) {
> + if(s->cmnd->target == reselection_id &&
> +s->cmnd->lun == lun) {
> + printk("%d ", s->tag);
KERN_ERR?
> + if(s->tag == hostdata->msgin[2]) {
> + printk(" ***FOUND*** \n");
As above.
> + slot = s;
> + goto retry;
> + }
> +
> + }
> + s = s->ITL_back;
> + }
> + printk("\n");
KERN_ERR?
[...]
> +void
> +NCR_700_intr(int irq, void *dev_id, struct pt_regs *regs)
> +{
[...]
> + if(dsp == Ent_SendMessage + 8 + hostdata->pScript) {
> + /* It wants to reply to some part of
> + * our message */
> + __u32 temp = inl(host->base + TEMP_REG);
> +
> + int count = (hostdata->script[Ent_SendMessage/4] &
>0xff) - ((inl(host->base + DBC_REG) & 0xff) + NCR_700_data_residual(host));
> + printk("scsi%d (%d:%d) PHASE MISMATCH IN SEND MESSAGE
>%d remain, return %p[%04x], phase %s\n", host->host_no, pun, lun, count, (void
>*)temp, temp - hostdata->pScript, sbcl_to_string(inb(host->base + SBCL_REG)));
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
> On Sun, May 13, 2001 at 11:40:33PM +0100, Alan Cox wrote: > > > If I am not mistaken, Richard Hirst has also done work on this thing. > > > > He did 53c710+. The 700 and 700/66 are much less capable devices. > > I did 53c700 as well, in the parisc-linux tree. Sounds like James' > driver is more featureful than mine though. I'll skip feeding the driver on to Linus until the two of you figure out the best path then - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
On Sun, May 13, 2001 at 11:40:33PM +0100, Alan Cox wrote: > > If I am not mistaken, Richard Hirst has also done work on this thing. > > He did 53c710+. The 700 and 700/66 are much less capable devices. I did 53c700 as well, in the parisc-linux tree. Sounds like James' driver is more featureful than mine though. Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
Disclaimer: I know nothing of this device/hw, the scsi protocol or
anything remotely applicable the functioning of this driver. The
stuff below is just nit-picking and PITA-ing :) Pro-active kernel
janitoring, if you like.
On Sat, May 12, 2001 at 11:43:04AM -0500, James Bottomley wrote:
[...]
+struct Scsi_Host * __init
+NCR_700_detect(Scsi_Host_Template *tpnt,
+struct NCR_700_Host_Parameters *hostdata)
+{
+ __u32 *script = kmalloc(sizeof(SCRIPT), GFP_KERNEL);
+ __u32 pScript;
+ struct Scsi_Host *host;
+ static int banner = 0;
+ int j;
+
[...]
+
+ host = scsi_register(tpnt, 4);
+ if(script == NULL) {
+ printk(KERN_ERR 53c700: Failed to allocate script, detatching\n);
+ scsi_unregister(host);
+ return NULL;
+ }
You are not checking if the scsi_register went ok or not.
[...]
+STATIC void
+free_slot(struct NCR_700_command_slot *slot,
+ struct NCR_700_Host_Parameters *hostdata)
+{
+ int hash;
+ struct NCR_700_command_slot **forw, **back;
+
+
+ if((slot-state NCR_700_SLOT_MASK) != NCR_700_SLOT_MAGIC) {
+ printk( SLOT %p is not MAGIC!!!\n, slot);
+ }
+ if(slot-state == NCR_700_SLOT_FREE) {
+ printk( SLOT %p is FREE!!!\n, slot);
+ }
Could you be persuaded to add KERN_SOMETHING to the printks above?
[...]
+STATIC __u32
+process_extended_message(struct Scsi_Host *host,
+ struct NCR_700_Host_Parameters *hostdata,
+ Scsi_Cmnd *SCp, __u32 dsp, __u32 dsps)
+{
+ __u32 resume_offset = dsp, temp = dsp + 8;
+ __u8 pun = 0xff, lun = 0xff;
+
+ if(SCp != NULL) {
+ pun = SCp-target;
+ lun = SCp-lun;
+ }
+
+ switch(hostdata-msgin[2]) {
[...]
+
+ default:
+ printk(KERN_INFO scsi%d (%d:%d): Unexpected message %s: ,
+host-host_no, pun, lun,
+NCR_700_phase[(dsps 0xf00) 8]);
+ print_msg(hostdata-msgin);
+ printk(\n);
It would be nice with a KERN_XX before \n (yes, I recognize that
print_msg does not do this :( )
[...]
+STATIC __u32
+process_script_interrupt(__u32 dsps, __u32 dsp, Scsi_Cmnd *SCp,
+ struct Scsi_Host *host,
+ struct NCR_700_Host_Parameters *hostdata)
+{
[...]
+ } else if((dsps 0xf0f0) == A_UNEXPECTED_PHASE) {
+ __u8 i = (dsps 0xf00) 8;
+
+ printk(KERN_ERR scsi%d: (%d:%d), UNEXPECTED PHASE %s (%s)\n,
+host-host_no, pun, lun,
+NCR_700_phase[i],
+sbcl_to_string(inb(host-base + SBCL_REG)));
+ printk( len = %d, cmd =, SCp-cmd_len);
A KERN_ERR prefix?
[...]
+ retry:
+ if(slot == NULL) {
+ struct NCR_700_command_slot *s = find_ITL_Nexus(hostdata,
reselection_id, lun);
+ printk(KERN_ERR scsi%d: (%d:%d) RESELECTED but no saved
command (MSG = %02x %02x %02x)!!\n,
+host-host_no, reselection_id, lun,
+hostdata-msgin[0], hostdata-msgin[1],
+hostdata-msgin[2]);
+ printk(KERN_ERR OUTSTANDING TAGS:);
+ while(s != NULL) {
+ if(s-cmnd-target == reselection_id
+s-cmnd-lun == lun) {
+ printk(%d , s-tag);
KERN_ERR?
+ if(s-tag == hostdata-msgin[2]) {
+ printk( ***FOUND*** \n);
As above.
+ slot = s;
+ goto retry;
+ }
+
+ }
+ s = s-ITL_back;
+ }
+ printk(\n);
KERN_ERR?
[...]
+void
+NCR_700_intr(int irq, void *dev_id, struct pt_regs *regs)
+{
[...]
+ if(dsp == Ent_SendMessage + 8 + hostdata-pScript) {
+ /* It wants to reply to some part of
+ * our message */
+ __u32 temp = inl(host-base + TEMP_REG);
+
+ int count = (hostdata-script[Ent_SendMessage/4]
0xff) - ((inl(host-base + DBC_REG) 0xff) + NCR_700_data_residual(host));
+ printk(scsi%d (%d:%d) PHASE MISMATCH IN SEND MESSAGE
%d remain, return %p[%04x], phase %s\n, host-host_no, pun, lun, count, (void
*)temp, temp - hostdata-pScript, sbcl_to_string(inb(host-base + SBCL_REG)));
KERN_ERR?
Also, some places you have KERN_ERR on debug output and some places
not. If you could be persuaded to put KERN_XX on the debug output too,
it would be nice
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
On Sun, May 13, 2001 at 11:40:33PM +0100, Alan Cox wrote: If I am not mistaken, Richard Hirst has also done work on this thing. He did 53c710+. The 700 and 700/66 are much less capable devices. I did 53c700 as well, in the parisc-linux tree. Sounds like James' driver is more featureful than mine though. Richard - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
On Sun, May 13, 2001 at 11:40:33PM +0100, Alan Cox wrote: If I am not mistaken, Richard Hirst has also done work on this thing. He did 53c710+. The 700 and 700/66 are much less capable devices. I did 53c700 as well, in the parisc-linux tree. Sounds like James' driver is more featureful than mine though. I'll skip feeding the driver on to Linus until the two of you figure out the best path then - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
[EMAIL PROTECTED] said:
> If I am not mistaken, Richard Hirst has also done work on this thing.
> The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now
> works under both 2.2 and 2.4. It also has on-board SCSI (NCR
> 53c700-66), maybe memory mapped, I forget. Maybe nobody knows the
> addresses. It would be somewhat interesting to get that thing to work
> as well.
You're likely to trip across the part of the driver I skimped on: The clock divider
section. Usually you want the async core to run just under 25Mhz and the sync core to
run just under 50Mhz. Therefore, you ususally clock the 700-66 chip at 50Mhz and put
1 into the sync and 2 into the async divider (which is all I do---although you
probably clock a non -66 chip at 25Mhz). However, a combo card may have a rather
different clock speed. I can work on this some more if you want to try to get the
card running. Do you know what the clock speed is?
[EMAIL PROTECTED] said:
> According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the
> NCR 53c700/66 is mapped at 0xCC0-0xCFF.
That would be io mapped? then the 53c700.c chip driver should plug almost straight in.
[EMAIL PROTECTED] said:
> Yes. But long ago he wrote:
> ---
> You need quite a different driver from the 53c710 drivers that exist,
> because 53c700 doesn't have DSA register. I've attached a diff for
> 2.4.0-test9 which adds sim700.{c,h,scr}. That driver is supposed to
> handle 53c700 and 53c710 and be a replacement for sim710.c.
There are several other differences, although the lack of DSA register is the most
annoying:
- They can't manipulate the chip registers in the script.
- Their SCSI-DMA fifo core is only 32 bits (you need to compute the datapath residue
differently)
- The selection model is completely different. You can put the 710 into 700
compatibility mode and run the same selection model, but that's probably not what you
want: the 700 needs two interrupts to resume after a reselection, one to see the
selection and the other to collect the lun and tag. The 710 can wait for the
reselection grab the lun and tag and then interrupt. You can also dispense with the
elaborate selection interrupt section I have to have. I thought of doing a
probabalistic selection for the 700: given the PUN, you guess the lun and tag
(probably use the oldest) and set the script up for these. You take a "wrong guess"
interrupt if you got it incorrect. However, with 8 tags outstanding per device, you'd
probably only see a 13% correct guess, which didn't seem worth it.
I thought, based on these differences, that it made more sense to keep the 700 driver
separate from the 710 one.
The next chip core I'm considering is the 720/770 (I have a nice microchannel card
with 4 of these and 2MB of onboard memory), unless you know of someone who has already
done the extra work (the 53c7xx and 53c7,8xx don't do the wide/ultra features).
James
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
>> If I am not mistaken, Richard Hirst has also done work on this thing.
> He did 53c710+. The 700 and 700/66 are much less capable devices.
Yes. But long ago he wrote:
---
You need quite a different driver from the 53c710 drivers that
exist, because 53c700 doesn't have DSA register. I've attached
a diff for 2.4.0-test9 which adds sim700.{c,h,scr}. That driver
is supposed to handle 53c700 and 53c710 and be a replacement for
sim710.c.
---
> the NCR 53c700/66 is mapped at 0xCC0-0xCFF.
Good! You are well-organized. I also had that someplace.
> system board id ... mac address
I am not quite sure what you mean by System Board Id.
The EISA ID of this thing is INT3061.
Andries
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
> If I am not mistaken, Richard Hirst has also done work on this thing. He did 53c710+. The 700 and 700/66 are much less capable devices. According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the NCR 53c700/66 is mapped at 0xCC0-0xCFF. The system board id looks interesting too. I wonder if its related to the mac address.. Sadly my box is dead so I cant poke - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
> New SCSI driver for 53c700 chip Good! If I am not mistaken, Richard Hirst has also done work on this thing. The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now works under both 2.2 and 2.4. It also has on-board SCSI (NCR 53c700-66), maybe memory mapped, I forget. Maybe nobody knows the addresses. It would be somewhat interesting to get that thing to work as well. Andries - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
If I am not mistaken, Richard Hirst has also done work on this thing. He did 53c710+. The 700 and 700/66 are much less capable devices. According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the NCR 53c700/66 is mapped at 0xCC0-0xCFF. The system board id looks interesting too. I wonder if its related to the mac address.. Sadly my box is dead so I cant poke - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
If I am not mistaken, Richard Hirst has also done work on this thing.
He did 53c710+. The 700 and 700/66 are much less capable devices.
Yes. But long ago he wrote:
---
You need quite a different driver from the 53c710 drivers that
exist, because 53c700 doesn't have DSA register. I've attached
a diff for 2.4.0-test9 which adds sim700.{c,h,scr}. That driver
is supposed to handle 53c700 and 53c710 and be a replacement for
sim710.c.
---
the NCR 53c700/66 is mapped at 0xCC0-0xCFF.
Good! You are well-organized. I also had that someplace.
system board id ... mac address
I am not quite sure what you mean by System Board Id.
The EISA ID of this thing is INT3061.
Andries
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
[EMAIL PROTECTED] said:
If I am not mistaken, Richard Hirst has also done work on this thing.
The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now
works under both 2.2 and 2.4. It also has on-board SCSI (NCR
53c700-66), maybe memory mapped, I forget. Maybe nobody knows the
addresses. It would be somewhat interesting to get that thing to work
as well.
You're likely to trip across the part of the driver I skimped on: The clock divider
section. Usually you want the async core to run just under 25Mhz and the sync core to
run just under 50Mhz. Therefore, you ususally clock the 700-66 chip at 50Mhz and put
1 into the sync and 2 into the async divider (which is all I do---although you
probably clock a non -66 chip at 25Mhz). However, a combo card may have a rather
different clock speed. I can work on this some more if you want to try to get the
card running. Do you know what the clock speed is?
[EMAIL PROTECTED] said:
According to http://www.murphy.nl/~ard/systems/pws/pws/node18.html the
NCR 53c700/66 is mapped at 0xCC0-0xCFF.
That would be io mapped? then the 53c700.c chip driver should plug almost straight in.
[EMAIL PROTECTED] said:
Yes. But long ago he wrote:
---
You need quite a different driver from the 53c710 drivers that exist,
because 53c700 doesn't have DSA register. I've attached a diff for
2.4.0-test9 which adds sim700.{c,h,scr}. That driver is supposed to
handle 53c700 and 53c710 and be a replacement for sim710.c.
There are several other differences, although the lack of DSA register is the most
annoying:
- They can't manipulate the chip registers in the script.
- Their SCSI-DMA fifo core is only 32 bits (you need to compute the datapath residue
differently)
- The selection model is completely different. You can put the 710 into 700
compatibility mode and run the same selection model, but that's probably not what you
want: the 700 needs two interrupts to resume after a reselection, one to see the
selection and the other to collect the lun and tag. The 710 can wait for the
reselection grab the lun and tag and then interrupt. You can also dispense with the
elaborate selection interrupt section I have to have. I thought of doing a
probabalistic selection for the 700: given the PUN, you guess the lun and tag
(probably use the oldest) and set the script up for these. You take a wrong guess
interrupt if you got it incorrect. However, with 8 tags outstanding per device, you'd
probably only see a 13% correct guess, which didn't seem worth it.
I thought, based on these differences, that it made more sense to keep the 700 driver
separate from the 710 one.
The next chip core I'm considering is the 720/770 (I have a nice microchannel card
with 4 of these and 2MB of onboard memory), unless you know of someone who has already
done the extra work (the 53c7xx and 53c7,8xx don't do the wide/ultra features).
James
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [NEW SCSI DRIVER] for 53c700 chip and NCR_D700 card against 2.4.4
New SCSI driver for 53c700 chip Good! If I am not mistaken, Richard Hirst has also done work on this thing. The Panther/lp486e/PWS/... has on-board ethernet (82596) and this now works under both 2.2 and 2.4. It also has on-board SCSI (NCR 53c700-66), maybe memory mapped, I forget. Maybe nobody knows the addresses. It would be somewhat interesting to get that thing to work as well. Andries - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
