> So, as far as I can see, there are no conflicts between aha1542
> and aha1740 in the sense that the former would try to handle the latter.
> Conversely, that aha1740 also seems to test that it has the right card
> in aha1740_test_port().
> Maybe there is no ordering restriction?
For 1542/1740 I
On Mon, Oct 09 2000, Alan Cox wrote:
> > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > > and in the 17xx case data corruption risks
> >
> > Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_
> > the other ones. Or did that change in th
On Mon, Oct 09, 2000 at 07:24:03PM +0100, Alan Cox wrote:
> > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > > and in the 17xx case data corruption risks
> >
> > Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_
> > the other ones. Or
> Excellent. But Alan, you wrote earlier that i2o needed to be the last host
> adapter and _before_ the upper layers. This is what made me start this
> patch.
Sorry. Then I was unclear and I sent you off doing un-needed work.
Apologies
-
To unsubscribe from this list: send the line "unsubscrib
On Mon, Oct 09 2000, Alan Cox wrote:
> > Yes, that can be done pretty easy, but Then I2O will link
> >
> > core - hosts - upper - I2O and I'm not sure this is okay.
>
> Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers
> devices on different majors with no ordering
> Yes, that can be done pretty easy, but Then I2O will link
>
> core - hosts - upper - I2O and I'm not sure this is okay.
Thats fine. I2O scsi is the last scsi driver anyway, the rest of i2o registers
devices on different majors with no ordering issues
-
To unsubscribe from this list: send the
On Mon, Oct 09 2000, Linus Torvalds wrote:
>
>
> On Mon, 9 Oct 2000, Torben Mathiasen wrote:
> >
> > My point exactly. The ordering of driver in drivers/scsi is done now,
> > but I don't see a clean way of doing I2O without moving upperlayers
> > into a seperate dir.
>
> Why?
>
I was referrin
> > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > and in the 17xx case data corruption risks
>
> Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after_
> the other ones. Or did that change in the later 2.2.x series?
I will double check th
> Also, we should really finalise the host order thing in scsi/Makefile. If
> it's true that aha17xx must come before aha1542, it's wrong as it stands
> now. Any other gotchas that were caught in 2.2.x?
Those are the only ones I know
Buslogic cards and AHA174x cards both emulate an aha1542 but h
On Mon, Oct 09 2000, Linus Torvalds wrote:
>
>
> On Mon, 9 Oct 2000, Alan Cox wrote:
> >
> > Link scsi as a whole before i2o ?
>
> Yup.
>
> Also, we should really finalise the host order thing in scsi/Makefile. If
> it's true that aha17xx must come before aha1542, it's wrong as it stands
>
On Mon, 9 Oct 2000, Torben Mathiasen wrote:
> >
> > Link scsi as a whole before i2o ?
> >
>
> Yes, that can be done pretty easy, but Then I2O will link
>
> core - hosts - upper - I2O and I'm not sure this is okay.
Think modules. Remember how it has always worked.
The above is pretty much
On Mon, 9 Oct 2000, Alan Cox wrote:
>
> Link scsi as a whole before i2o ?
Yup.
Also, we should really finalise the host order thing in scsi/Makefile. If
it's true that aha17xx must come before aha1542, it's wrong as it stands
now. Any other gotchas that were caught in 2.2.x?
On Mon, 9 Oct 2000, Torben Mathiasen wrote:
>
> My point exactly. The ordering of driver in drivers/scsi is done now,
> but I don't see a clean way of doing I2O without moving upperlayers
> into a seperate dir.
Why?
People would tend to use the i2o ones as modules anyway, so they _have_ to
wo
On Mon, 9 Oct 2000, Alan Cox wrote:
>
> SCSI has real ordering requirements for drivers.
>
> You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> and in the 17xx case data corruption risks
Hmm.. The current order is the same as in 2.2.x, and puts aha17xx _after
On Mon, Oct 09 2000, Alan Cox wrote:
> > > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > > and in the 17xx case data corruption risks
> > > You must do scsi before i2o_scsi or AMI Megaraids break
> > >
> >
> > My point exactly. The ordering of driver in driver
> i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there
> before)
I put it there intentionally. It exports no symbols. I dont want the module
stuff therefore exporting everything in that file.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
th
> > You have to do Buslogic and AHA17xx before AHA15xx or you get a wrong driver
> > and in the 17xx case data corruption risks
> > You must do scsi before i2o_scsi or AMI Megaraids break
> >
>
> My point exactly. The ordering of driver in drivers/scsi is done now,
> but I don't see a clean w
On Mon, Oct 09 2000, Alan Cox wrote:
> > At this point, I would prefer that we just leave the ordering alone - I
> > don' tknow of any actual problems with it, and I don't think it's worth
> > re-organizing things to make it the exact same thing it used to be..
>
> SCSI has real ordering requirem
> At this point, I would prefer that we just leave the ordering alone - I
> don' tknow of any actual problems with it, and I don't think it's worth
> re-organizing things to make it the exact same thing it used to be..
SCSI has real ordering requirements for drivers.
You have to do Buslogic and
On Sun, Oct 08 2000, Linus Torvalds wrote:
>
>
> On Thu, 5 Oct 2000, Torben Mathiasen wrote:
> >
> > This patch is a resend of my other link fix patch that didn't get
> > in test9-pre9. I assume this is because of some other changes
> > to upper layer scsi drivers.
>
> No, I just felt it was t
On Thu, 5 Oct 2000, Torben Mathiasen wrote:
>
> This patch is a resend of my other link fix patch that didn't get
> in test9-pre9. I assume this is because of some other changes
> to upper layer scsi drivers.
No, I just felt it was too big, and with not enough reason for it at all.
At this po
On Thu, Oct 05 2000, Jeff Garzik wrote:
> Please include your patches inline so we can easily quote them via the
> standard e-mail reply feature.
>
> i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there
> before)
I' remove it.
> sg.c: ug. the worst part of the patch. you re
Please include your patches inline so we can easily quote them via the
standard e-mail reply feature.
i2o_block.c: you don't need EXPORT_NO_SYMBOLS (yes, I know it was there
before)
sd.c: why do you add two blank lines, but change nothing else?
sg.c: ug. the worst part of the patch. you rever
Linus,
This patch is a resend of my other link fix patch that didn't get
in test9-pre9. I assume this is because of some other changes
to upper layer scsi drivers.
This patch is a lot smaller because the "moving files around" part
has been omittet.
So please apply this patch and do the followin
- Original Message -
From: "Torben Mathiasen" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>
Sent: Thursday, September 28, 2000 7:59 AM
Subject: [PATCH] link-order of drivers outside drivers/scsi (i2o)
> Ala
On Thu, Sep 28 2000, Alan Cox wrote:
> > Note that for this to work properly, i2o (and the others) needs to
> > be converted to initialization by initcalls. This is trivial? or do the module
> > case differ from builtin?
>
> It shouldnt be a problem. The order inside of i2o just needs to start w
> Note that for this to work properly, i2o (and the others) needs to
> be converted to initialization by initcalls. This is trivial? or do the module
> case differ from builtin?
It shouldnt be a problem. The order inside of i2o just needs to start with core
and pci.
-
To unsubscribe from this l
Alan and others,
The following patch changes the link order of i2o to link:
scsi core - hosts - i2o - upper layers.
The patch moves things around a bit, like all upper layer drivers
going into scsi/upper. Other drivers outside drivers/scsi can
be changed to link in after the other hosts by jus
28 matches
Mail list logo
