When will we see v. 6.2.5 included in the kernel (2.5 and 2.4, I think)?
The patch to kernel 2.4.17 is available since January. It should fix a
kernel panic at boot that has been in the kernel since November at
least. The bug is in AIC7XXX V. 6.2.4.
Thanks
On Wed, Feb 20 2002, Carlo Scarfoglio wrote:
> When will we see v. 6.2.5 included in the kernel (2.5 and 2.4, I think)?
> The patch to kernel 2.4.17 is available since January. It should fix a
> kernel panic at boot that has been in the kernel since November at
> least. The bug is in AIC7XXX V. 6.2.4.
You should ask Justin whether he has submitted it for inclusion or not.
I offered to port to 2.5 at least, but heard nothing.
--
Jens Axboe
> You should ask Justin whether he has submitted it for inclusion or not.
> I offered to port to 2.5 at least, but heard nothing.
I was sent a patch for it which included some scsi changes, broke support
for the CMD ide controllers and didn't apply in the aic7xxx area. So I
threw it in /dev/null
On Thu, Feb 21 2002, Alan Cox wrote:
> > You should ask Justin whether he has submitted it for inclusion or not.
> > I offered to port to 2.5 at least, but heard nothing.
>
> I was sent a patch for it which included some scsi changes, broke support
> for the CMD ide controllers and didn't apply in the aic7xxx area. So I
> threw it in /dev/null
Right, it was an incredibly strange mix. I just disregarded the cmd
stuff, the scsi stuff looked sane. I trust Justin knows the aic7xxx
parts were sane :-)
--
Jens Axboe
>> You should ask Justin whether he has submitted it for inclusion or not.
>> I offered to port to 2.5 at least, but heard nothing.
>
>I was sent a patch for it which included some scsi changes, broke support
>for the CMD ide controllers and didn't apply in the aic7xxx area. So I
>threw it in /dev/null
All I got from you was an email with the text "Thanks!" in it. I'll
take that to indicate a toss to /dev/null in the future. 8-)
Seriously, if you let me know exactly which version you want my patches
relative to, I'll regenerate them. From a message Jens sent me, it
sounds like his change to fix a bug I fixed differently had already been
included in certain 2.4.18-pre kernels which was the cause of the patch
not working for him. I can only assume you ran into the same problem.
My patch was relative to 2.4.17, not a more recent, yet unblessed, kernel.
As to the CMD640 patch. Can you let me know why you believe it breaks
the CMD640? The current scheme leaks transactions on the bus and *will*
upset certain controllers that don't expect their register spaces to
be uncerimoniously poked. Is your complaint that it only handles the
attachment of a single controller? The old code is no different in this
regard - Scott just had the courtesy to document that this was still not
corrected by this change. If you need us to fix this other bug too in
order to get the other changes into the tree, just let us know and we'll
do the extra work.
Information about the SCSI mid-layer changes were posted to the SCSI list
and I believe CC'd to you. If you need that information again, I'd be
happy to resend it.
--
Justin
> included in certain 2.4.18-pre kernels which was the cause of the patch
> not working for him. I can only assume you ran into the same problem.
> My patch was relative to 2.4.17, not a more recent, yet unblessed, kernel.
Relative to 2.4.18-rc would be good
> As to the CMD640 patch. Can you let me know why you believe it breaks
> the CMD640? The current scheme leaks transactions on the bus and *will*
The CMD640 can't do 32bit config space access stuff - thats why the code
is there to hack around it. That code needs to know or check what pci
config mode it should have used.
> Information about the SCSI mid-layer changes were posted to the SCSI list
> and I believe CC'd to you. If you need that information again, I'd be
> happy to resend it.
The midlayer stuff Im more than happy with
>> included in certain 2.4.18-pre kernels which was the cause of the patch
>> not working for him. I can only assume you ran into the same problem.
>> My patch was relative to 2.4.17, not a more recent, yet unblessed, kernel.
>
>Relative to 2.4.18-rc would be good
Okay. I will do this sometime this weekend. I'm currently in the
middle of a business trip which makes testing a new patch difficult.
>> As to the CMD640 patch. Can you let me know why you believe it breaks
>> the CMD640? The current scheme leaks transactions on the bus and *will*
>
>The CMD640 can't do 32bit config space access stuff - thats why the code
>is there to hack around it. That code needs to know or check what pci
>config mode it should have used.
Right. If you look at the comments added to the code, the PCI APIs always
prefer direct config space access over using the PCI BIOS. The Linux
direct access methods only perform 32 bit cycles for 32bit API calls.
The ony time Linux will use the PCIBIOS (which may do everything as
32bit accesses) is if the direct access method fails. So, the machines
where direct access doesn't work can't be supported by the old, manual,
CMD640 code anyway. On machines that have working direct access, using
the PCI APIs is equivalent to the old method with the added bonus that
you don't blindly attempt to perform an access type that the chipset
does not support. This was the root cause of the "CMD640 driver performs
drive by shootings of other devices" issue.
>> Information about the SCSI mid-layer changes were posted to the SCSI list
>> and I believe CC'd to you. If you need that information again, I'd be
>> happy to resend it.
>
>The midlayer stuff Im more than happy with
Okay.
--
Justin