On Sun, Oct 15 2000, David S. Miller wrote:
>Date: Sun, 15 Oct 2000 11:19:24 +0200
>From: Torben Mathiasen <[EMAIL PROTECTED]>
>
>It seems reasonable. We'd been thinking of makeing proc_name part
>of the host structure, but no need for that if we just do the
>above.
>
>
Date: Sun, 15 Oct 2000 11:19:24 +0200
From: Torben Mathiasen <[EMAIL PROTECTED]>
It seems reasonable. We'd been thinking of makeing proc_name part
of the host structure, but no need for that if we just do the
above.
Either fix is ok by me, but it does seem that enforcing
On Sat, Oct 14 2000, Linus Torvalds wrote:
>
>
> On Sat, 14 Oct 2000, David S. Miller wrote:
> >
> > The loop would be a no-op but the remove_proc_entry call would not.
> > Perhaps you didn't notice that there too? It's pretty close to the
> > loop :-)
>
> Ok.
>
> In fact, it's in the
On Sat, Oct 14 2000, Linus Torvalds wrote:
On Sat, 14 Oct 2000, David S. Miller wrote:
The loop would be a no-op but the remove_proc_entry call would not.
Perhaps you didn't notice that there too? It's pretty close to the
loop :-)
Ok.
In fact, it's in the _wrong_ part.
Date: Sun, 15 Oct 2000 11:19:24 +0200
From: Torben Mathiasen [EMAIL PROTECTED]
It seems reasonable. We'd been thinking of makeing proc_name part
of the host structure, but no need for that if we just do the
above.
Either fix is ok by me, but it does seem that enforcing proc_name
On Sun, Oct 15 2000, David S. Miller wrote:
Date: Sun, 15 Oct 2000 11:19:24 +0200
From: Torben Mathiasen [EMAIL PROTECTED]
It seems reasonable. We'd been thinking of makeing proc_name part
of the host structure, but no need for that if we just do the
above.
Either fix is
On Sat, 14 Oct 2000, David S. Miller wrote:
>
> The loop would be a no-op but the remove_proc_entry call would not.
> Perhaps you didn't notice that there too? It's pretty close to the
> loop :-)
Ok.
In fact, it's in the _wrong_ part.
That remove_proc_entry() should be there in the same
On Sat, 14 Oct 2000, Torben Mathiasen wrote:
> On Sat, Oct 14 2000, David S. Miller wrote:
> >Date: Sat, 14 Oct 2000 11:43:09 +0200
> >From: Torben Mathiasen <[EMAIL PROTECTED]>
> >
> >David, why is tpnt->proc_name NULL on sparc for devices not
> >existing? Every driver has
On Sat, Oct 14 2000, David S. Miller wrote:
>Date: Sat, 14 Oct 2000 12:12:39 +0200
>From: Torben Mathiasen <[EMAIL PROTECTED]>
>
>Are there any reason why sym53c8xx and others initialize proc_name
>only if an adapter was actually found (or in the sym case, if a
>pcibus
Date:Sat, 14 Oct 2000 12:12:39 +0200
From: Torben Mathiasen <[EMAIL PROTECTED]>
Are there any reason why sym53c8xx and others initialize proc_name
only if an adapter was actually found (or in the sym case, if a
pcibus was found)?
I see no particular reason. Why not code
On Sat, Oct 14 2000, David S. Miller wrote:
>Date: Sat, 14 Oct 2000 11:43:09 +0200
>From: Torben Mathiasen <[EMAIL PROTECTED]>
>
>David, why is tpnt->proc_name NULL on sparc for devices not
>existing? Every driver has this as part of their tpnt struct, so
>it doesn't matter
Date: Sat, 14 Oct 2000 11:43:09 +0200
From: Torben Mathiasen <[EMAIL PROTECTED]>
David, why is tpnt->proc_name NULL on sparc for devices not
existing? Every driver has this as part of their tpnt struct, so
it doesn't matter if the underlying device really exists.
In the
On Sat, Oct 14 2000, David S. Miller wrote:
>Date: Fri, 13 Oct 2000 20:37:46 -0700 (PDT)
>From: Linus Torvalds <[EMAIL PROTECTED]>
>
>Why would it crash the sparc?
>
>If it wasn't there originally, the loop will not find it, and the
>loop will be a no-op.
>
> The loop would
Date: Fri, 13 Oct 2000 20:37:46 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
Why would it crash the sparc?
If it wasn't there originally, the loop will not find it, and the
loop will be a no-op.
The loop would be a no-op but the remove_proc_entry call would not.
Perhaps
Date: Fri, 13 Oct 2000 20:37:46 -0700 (PDT)
From: Linus Torvalds [EMAIL PROTECTED]
Why would it crash the sparc?
If it wasn't there originally, the loop will not find it, and the
loop will be a no-op.
The loop would be a no-op but the remove_proc_entry call would not.
Perhaps
On Sat, Oct 14 2000, David S. Miller wrote:
Date: Fri, 13 Oct 2000 20:37:46 -0700 (PDT)
From: Linus Torvalds [EMAIL PROTECTED]
Why would it crash the sparc?
If it wasn't there originally, the loop will not find it, and the
loop will be a no-op.
The loop would be a no-op
Date: Sat, 14 Oct 2000 11:43:09 +0200
From: Torben Mathiasen [EMAIL PROTECTED]
David, why is tpnt-proc_name NULL on sparc for devices not
existing? Every driver has this as part of their tpnt struct, so
it doesn't matter if the underlying device really exists.
In the mentioned
Date:Sat, 14 Oct 2000 12:12:39 +0200
From: Torben Mathiasen [EMAIL PROTECTED]
Are there any reason why sym53c8xx and others initialize proc_name
only if an adapter was actually found (or in the sym case, if a
pcibus was found)?
I see no particular reason. Why not code up
On Sat, Oct 14 2000, David S. Miller wrote:
Date: Sat, 14 Oct 2000 12:12:39 +0200
From: Torben Mathiasen [EMAIL PROTECTED]
Are there any reason why sym53c8xx and others initialize proc_name
only if an adapter was actually found (or in the sym case, if a
pcibus was
On Sat, 14 Oct 2000, Torben Mathiasen wrote:
On Sat, Oct 14 2000, David S. Miller wrote:
Date: Sat, 14 Oct 2000 11:43:09 +0200
From: Torben Mathiasen [EMAIL PROTECTED]
David, why is tpnt-proc_name NULL on sparc for devices not
existing? Every driver has this as part of
On Sat, 14 Oct 2000, David S. Miller wrote:
The loop would be a no-op but the remove_proc_entry call would not.
Perhaps you didn't notice that there too? It's pretty close to the
loop :-)
Ok.
In fact, it's in the _wrong_ part.
That remove_proc_entry() should be there in the same place
On Fri, 13 Oct 2000, David S. Miller wrote:
>
> Linus, why did you apply his patch to _only_ reverse the if condition?
>
> What you applied will crash Sparc again, whereas mine does not crash
> the original Sparc case _and_ it fixes Torben's bug too.
Why woul dit crash the sparc?
If it
Date: Fri, 13 Oct 2000 12:14:29 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
>
> Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
>
> Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
patch palatable to me.
Linus
-
To unsubscribe from this list: send the line "unsubscribe
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
patch palatable to me.
Linus
-
To unsubscribe from this list: send the line "unsubscribe
Date: Fri, 13 Oct 2000 12:14:29 -0700 (PDT)
From: Linus Torvalds [EMAIL PROTECTED]
On Fri, 13 Oct 2000, Torben Mathiasen wrote:
Yes it works, its not all that different from my patch ;).
Yeah.
The thing I actually cared most about was the comment, which makes the
Date:Thu, 12 Oct 2000 12:48:27 -0700 (PDT)
From: Linus Torvalds <[EMAIL PROTECTED]>
David, you know this code, would you mind giving it another pair of
eyes? I hate code that doesn't make sense.
Ok, the deal is that the tpnt->present handling during unregister is
really
On Thu, 12 Oct 2000, Torben Mathiasen wrote:
>
> We want to make sure that all hostadapters have been unregistered
> befor we pull it out of the scsi_hosts list. We do tpnt->present--
> for every hostadaper we unregister.
>
> Prior to the new init code, we'd just do something like,
>
>
On Thu, Oct 12 2000, Linus Torvalds wrote:
>
>
> On Thu, 12 Oct 2000, Torben Mathiasen wrote:
> >
> > Attached patch should fix the oops's people have been getting
> > while using /proc/scsi.
>
> This patch makes no sense. Why
>
> if (!present)
>
> when that is obviously the wrong way
On Thu, 12 Oct 2000, Torben Mathiasen wrote:
>
> Attached patch should fix the oops's people have been getting
> while using /proc/scsi.
This patch makes no sense. Why
if (!present)
when that is obviously the wrong way around.
I'm sure it fixes an oops - I just want to understand
Linus,
Attached patch should fix the oops's people have been getting
while using /proc/scsi.
Patch is against test10p1.
--
Torben Mathiasen <[EMAIL PROTECTED]>
Linux ThunderLAN maintainer
http://tlan.kernel.dk
--- linux-test10p1/drivers/scsi/scsi.c Thu Oct 12 20:18:47 2000
+++
Linus,
Attached patch should fix the oops's people have been getting
while using /proc/scsi.
Patch is against test10p1.
--
Torben Mathiasen [EMAIL PROTECTED]
Linux ThunderLAN maintainer
http://tlan.kernel.dk
--- linux-test10p1/drivers/scsi/scsi.c Thu Oct 12 20:18:47 2000
+++
On Thu, 12 Oct 2000, Torben Mathiasen wrote:
Attached patch should fix the oops's people have been getting
while using /proc/scsi.
This patch makes no sense. Why
if (!present)
when that is obviously the wrong way around.
I'm sure it fixes an oops - I just want to understand why
On Thu, Oct 12 2000, Linus Torvalds wrote:
On Thu, 12 Oct 2000, Torben Mathiasen wrote:
Attached patch should fix the oops's people have been getting
while using /proc/scsi.
This patch makes no sense. Why
if (!present)
when that is obviously the wrong way around.
We
On Thu, 12 Oct 2000, Torben Mathiasen wrote:
We want to make sure that all hostadapters have been unregistered
befor we pull it out of the scsi_hosts list. We do tpnt-present--
for every hostadaper we unregister.
Prior to the new init code, we'd just do something like,
if
Date:Thu, 12 Oct 2000 12:48:27 -0700 (PDT)
From: Linus Torvalds [EMAIL PROTECTED]
David, you know this code, would you mind giving it another pair of
eyes? I hate code that doesn't make sense.
Ok, the deal is that the tpnt-present handling during unregister is
really
36 matches
Mail list logo
