* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
@ 2004-10-11 7:07 ` Gene Heskett
2004-10-11 7:23 ` via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches)) Francois Romieu
` (7 subsequent siblings)
8 siblings, 0 replies; 35+ messages in thread
From: Gene Heskett @ 2004-10-11 7:07 UTC (permalink / raw)
To: linux-kernel; +Cc: Linus Torvalds
On Sunday 10 October 2004 23:22, Linus Torvalds wrote:
>Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please
> give this a beating, and if you have pending patches, please hold
> on to them for a bit longer, until after the 2.6.9 release. It
> would be good to have a 2.6.9 that doesn't need a dot-release
> immediately ;)
>
>The appended shortlog gives a pretty good idea of what has been
> going on. Mostly small stuff, with some architecture updates and an
> ACPI update thrown in for good measure.
>
>(The ACPI update fixes broken AML with implied returns, and in
> particular the Compaq Evo notebook fan control. Yay! Guess who has
> one..)
>
> Linus
>
I'm running it, and dl'ing the suse livecd-9.1 to test the burning
sometime tomorrow. About the only unusual thing I see in dmesg is:
-----------------
EXT3 FS on hda8, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
kjournald starting. Commit interval 5 seconds
EXT3 FS on hdd2, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
EXT3-fs warning: maximal mount count reached, running e2fsck is
recommended
kjournald starting. Commit interval 5 seconds
-----------------
but it *didn't* ask me to hit y for the check while it was booting.
Also, the last couple of -rc's seem to be keeping a lock on /usr when
shutting down, so the 3 attempts at a clean umount during the
shutdown phase all fail. I made sure that everything was stopped
except some screen backgrounds that come from /usr, and gkrellm,
which sits on every window here. That hasn't bothered the reboots
until maybe -rc2 but -rc3 for sure is doing it 100% of the time in
the shutdown phase.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
99.27% setiathome rank, not too shabby for a WV hillbilly
Yahoo.com attorneys please note, additions to this message
by Gene Heskett are:
Copyright 2004 by Maurice Eugene Heskett, all rights reserved.
^ permalink raw reply [flat|nested] 35+ messages in thread
* via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches))
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
2004-10-11 7:07 ` Gene Heskett
@ 2004-10-11 7:23 ` Francois Romieu
2004-10-11 13:32 ` Daniel Andersen
2004-10-11 16:53 ` Jerone Young
2004-10-11 9:07 ` Linux 2.6.9-rc4 - pls test (and no more patches) Brice Goglin
` (6 subsequent siblings)
8 siblings, 2 replies; 35+ messages in thread
From: Francois Romieu @ 2004-10-11 7:23 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, Tejun Heo
Linus Torvalds <torvalds@osdl.org> :
[...]
> Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
> ============================================
[...]
> Fran?ois Romieu:
> o via-velocity: properly manage the count of adapters
> o via-velocity: removal of unused velocity_info.xmit_lock
> o via-velocity: velocity_give_rx_desc() removal
> o via-velocity: received ring wrong index and missing barriers
> o via-velocity: early invocation of init_cam_filter()
> o via-velocity: removal of incomplete endianness handling
> o via-velocity: wrong buffer offset in velocity_init_td_ring()
> o via-velocity: comment fixes
The attribution is a bit misleading as Tejun Heo <tj@home-tj.org>
did the real work (he appears in the logs though).
People should really, really, test this code if they have been
experiencing issues with the driver lately.
Test reports welcome here or on netdev@oss.sgi.com.
--
Ueimor
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches))
2004-10-11 7:23 ` via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches)) Francois Romieu
@ 2004-10-11 13:32 ` Daniel Andersen
2004-10-11 16:53 ` Jerone Young
1 sibling, 0 replies; 35+ messages in thread
From: Daniel Andersen @ 2004-10-11 13:32 UTC (permalink / raw)
To: Francois Romieu; +Cc: Kernel Mailing List, Tejun Heo, netdev
Francois Romieu wrote:
> Linus Torvalds <torvalds@osdl.org> :
> [...]
>
>>Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
>>============================================
>
> [...]
>
>>Fran?ois Romieu:
>> o via-velocity: properly manage the count of adapters
>> o via-velocity: removal of unused velocity_info.xmit_lock
>> o via-velocity: velocity_give_rx_desc() removal
>> o via-velocity: received ring wrong index and missing barriers
>> o via-velocity: early invocation of init_cam_filter()
>> o via-velocity: removal of incomplete endianness handling
>> o via-velocity: wrong buffer offset in velocity_init_td_ring()
>> o via-velocity: comment fixes
>
>
> The attribution is a bit misleading as Tejun Heo <tj@home-tj.org>
> did the real work (he appears in the logs though).
>
> People should really, really, test this code if they have been
> experiencing issues with the driver lately.
>
> Test reports welcome here or on netdev@oss.sgi.com.
>
I'm finally able to successfully use my On board VT6122 10/100/1000 Mb
PCI Ethernet Controller on my Abit KV8-Pro. I have not found any
problems with the via-velocity driver yet. Great work! :)
Daniel Andersen
--
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches))
2004-10-11 7:23 ` via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches)) Francois Romieu
2004-10-11 13:32 ` Daniel Andersen
@ 2004-10-11 16:53 ` Jerone Young
1 sibling, 0 replies; 35+ messages in thread
From: Jerone Young @ 2004-10-11 16:53 UTC (permalink / raw)
To: Francois Romieu; +Cc: Kernel Mailing List, netdev
Yes, I also am able to finally use the via-velocity card without it
taking down my router! The patches resolve issues with the card. I
have been heavily using it now without a problem on X86_64 Linux. I
have an Abit A8V with integrated Via Velocity card
On Mon, 11 Oct 2004 09:23:07 +0200, Francois Romieu
<romieu@fr.zoreil.com> wrote:
> Linus Torvalds <torvalds@osdl.org> :
> [...]
> > Summary of changes from v2.6.9-rc3 to v2.6.9-rc4
> > ============================================
> [...]
> > Fran?ois Romieu:
> > o via-velocity: properly manage the count of adapters
> > o via-velocity: removal of unused velocity_info.xmit_lock
> > o via-velocity: velocity_give_rx_desc() removal
> > o via-velocity: received ring wrong index and missing barriers
> > o via-velocity: early invocation of init_cam_filter()
> > o via-velocity: removal of incomplete endianness handling
> > o via-velocity: wrong buffer offset in velocity_init_td_ring()
> > o via-velocity: comment fixes
>
> The attribution is a bit misleading as Tejun Heo <tj@home-tj.org>
> did the real work (he appears in the logs though).
>
> People should really, really, test this code if they have been
> experiencing issues with the driver lately.
>
> Test reports welcome here or on netdev@oss.sgi.com.
>
> --
> Ueimor
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
2004-10-11 7:07 ` Gene Heskett
2004-10-11 7:23 ` via-velocity heads up (was (Re: Linux 2.6.9-rc4 - pls test (and no more patches)) Francois Romieu
@ 2004-10-11 9:07 ` Brice Goglin
2004-10-11 14:57 ` Linus Torvalds
2004-10-11 9:35 ` Andre Tomt
` (5 subsequent siblings)
8 siblings, 1 reply; 35+ messages in thread
From: Brice Goglin @ 2004-10-11 9:07 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
Hi,
> (The ACPI update fixes broken AML with implied returns, and in particular
> the Compaq Evo notebook fan control. Yay! Guess who has one..)
Well, I have one (N600c).
What am I supposed to see ? Is there anything special to do ?
I don't know exactly how fan control is supposed to be fixed.
Automatic wakeup/stop of these fans depending on the temperature
was already working.
Manual stopping of any fan (by writing into /proc/acpi/fan/*/state)
still doesn't work (don't know whether it's supposed to work or not).
By the way, I still see these errors during the boot, don't know if it's
supposed to be fixed :
psparse-1133: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
psparse-1133: *** Error: Method execution failed
[\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
psparse-1133: *** Error: Method execution failed [\_SB_.C19F._BTP]
(Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
Regards,
Brice Goglin
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 9:07 ` Linux 2.6.9-rc4 - pls test (and no more patches) Brice Goglin
@ 2004-10-11 14:57 ` Linus Torvalds
2004-10-11 20:22 ` Kjartan Maraas
0 siblings, 1 reply; 35+ messages in thread
From: Linus Torvalds @ 2004-10-11 14:57 UTC (permalink / raw)
To: Brice.Goglin; +Cc: Kernel Mailing List
On Mon, 11 Oct 2004, Brice Goglin wrote:
>
> Well, I have one (N600c).
> What am I supposed to see ? Is there anything special to do ?
Different Evo, different BIOS, different AML bug. You might try to update
your BIOS, it might be fixed.
> I don't know exactly how fan control is supposed to be fixed.
> Automatic wakeup/stop of these fans depending on the temperature
> was already working.
It wasn't on the N620c.. That one had errors like
ACPI-1133: *** Error: Method execution failed [\_TZ_.C202] (Node c1926af0), AE_AML_NO_RETURN_VA
ACPI-1133: *** Error: Method execution failed [\_TZ_.C20C._STA] (Node c1926cd4), AE_AML_NO_RETU
but yours are different:
> By the way, I still see these errors during the boot, don't know if it's
> supposed to be fixed :
>
> psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
> psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
> psparse-1133: *** Error: Method execution failed [\_SB_.C19F._BTP] (Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
Have you made a acpi bugzilla entry for this?
Linus
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 14:57 ` Linus Torvalds
@ 2004-10-11 20:22 ` Kjartan Maraas
0 siblings, 0 replies; 35+ messages in thread
From: Kjartan Maraas @ 2004-10-11 20:22 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Brice.Goglin, Kernel Mailing List
man, 11,.10.2004 kl. 07.57 -0700, skrev Linus Torvalds:
>
> On Mon, 11 Oct 2004, Brice Goglin wrote:
> >
> > Well, I have one (N600c).
> > What am I supposed to see ? Is there anything special to do ?
>
> Different Evo, different BIOS, different AML bug. You might try to update
> your BIOS, it might be fixed.
>
The latest BIOS didn't make a difference for me at least.
> > I don't know exactly how fan control is supposed to be fixed.
> > Automatic wakeup/stop of these fans depending on the temperature
> > was already working.
>
> It wasn't on the N620c.. That one had errors like
>
> ACPI-1133: *** Error: Method execution failed [\_TZ_.C202] (Node c1926af0), AE_AML_NO_RETURN_VA
> ACPI-1133: *** Error: Method execution failed [\_TZ_.C20C._STA] (Node c1926cd4), AE_AML_NO_RETU
>
> but yours are different:
>
> > By the way, I still see these errors during the boot, don't know if it's
> > supposed to be fixed :
> >
> > psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C12E] (Node e7f9a3a8), AE_AML_UNINITIALIZED_LOCAL
> > psparse-1133: *** Error: Method execution failed [\_SB_.C03E.C053.C0D1.C13D] (Node e7f9bd68), AE_AML_UNINITIALIZED_LOCAL
> > psparse-1133: *** Error: Method execution failed [\_SB_.C19F._BTP] (Node e7fa3348), AE_AML_UNINITIALIZED_LOCAL
>
> Have you made a acpi bugzilla entry for this?
>
I made one a while ago:
http://bugzilla.kernel.org/show_bug.cgi?id=1404
Cheers
Kjartan
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
` (2 preceding siblings ...)
2004-10-11 9:07 ` Linux 2.6.9-rc4 - pls test (and no more patches) Brice Goglin
@ 2004-10-11 9:35 ` Andre Tomt
2004-10-11 15:02 ` Linus Torvalds
2004-10-11 9:54 ` Nick Piggin
` (4 subsequent siblings)
8 siblings, 1 reply; 35+ messages in thread
From: Andre Tomt @ 2004-10-11 9:35 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
Linus Torvalds wrote:
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
The data corruption bug in the new megaraid driver version seems still
not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
"[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 9:35 ` Andre Tomt
@ 2004-10-11 15:02 ` Linus Torvalds
2004-10-11 15:09 ` James Bottomley
0 siblings, 1 reply; 35+ messages in thread
From: Linus Torvalds @ 2004-10-11 15:02 UTC (permalink / raw)
To: Andre Tomt; +Cc: Kernel Mailing List, James Bottomley
On Mon, 11 Oct 2004, Andre Tomt wrote:
>
> The data corruption bug in the new megaraid driver version seems still
> not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
>
> "[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
I think that one is already in the SCSI BK tree, just not pushed to me.
Perhaps because the tree contains other less important patches that James
doesn't think are worthy yet.. James? Should I just take the small
megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
Linus
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 15:02 ` Linus Torvalds
@ 2004-10-11 15:09 ` James Bottomley
2004-10-11 18:22 ` Andre Tomt
2004-10-11 21:37 ` Chris Ricker
0 siblings, 2 replies; 35+ messages in thread
From: James Bottomley @ 2004-10-11 15:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Andre Tomt, Kernel Mailing List
On Mon, 2004-10-11 at 10:02, Linus Torvalds wrote:
>
>
> On Mon, 11 Oct 2004, Andre Tomt wrote:
> >
> > The data corruption bug in the new megaraid driver version seems still
> > not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
> >
> > "[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
>
> I think that one is already in the SCSI BK tree, just not pushed to me.
> Perhaps because the tree contains other less important patches that James
> doesn't think are worthy yet.. James? Should I just take the small
> megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
I have no objections. However, I was planning on pushing it through the
SCSI tree because it's in the new megaraid driver which is experimental
at the moment (the old megaraid driver is still in and still
selectable). It's been in -mm for a few days now with no ill effects, I
think, but I'm not sure how many megaraid owners have actually tested
it.
James
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 15:09 ` James Bottomley
@ 2004-10-11 18:22 ` Andre Tomt
2004-10-11 19:29 ` James Bottomley
2004-10-11 21:37 ` Chris Ricker
1 sibling, 1 reply; 35+ messages in thread
From: Andre Tomt @ 2004-10-11 18:22 UTC (permalink / raw)
To: James Bottomley; +Cc: Linus Torvalds, Kernel Mailing List
James Bottomley wrote:
> On Mon, 2004-10-11 at 10:02, Linus Torvalds wrote:
>>On Mon, 11 Oct 2004, Andre Tomt wrote:
>>>"[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
>>
>>I think that one is already in the SCSI BK tree, just not pushed to me.
>>Perhaps because the tree contains other less important patches that James
>>doesn't think are worthy yet.. James? Should I just take the small
>>megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
>
> I have no objections. However, I was planning on pushing it through the
> SCSI tree because it's in the new megaraid driver which is experimental
> at the moment (the old megaraid driver is still in and still
> selectable). It's been in -mm for a few days now with no ill effects, I
> think, but I'm not sure how many megaraid owners have actually tested
> it.
I've been running 2.20.3.1 + the data corruption bug fix on megaraids
ranging from low-end SATA adapters to the u320scsi ones for a while on a
2.6.8 based kernel, nothing have blown up yet. The old 2.20.3.1 without
the fix have been holding up too though - however having a known data
corruption bug lingering doesn't feel so good :-)
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 18:22 ` Andre Tomt
@ 2004-10-11 19:29 ` James Bottomley
2004-10-11 23:35 ` Linus Torvalds
0 siblings, 1 reply; 35+ messages in thread
From: James Bottomley @ 2004-10-11 19:29 UTC (permalink / raw)
To: Andre Tomt; +Cc: Linus Torvalds, Kernel Mailing List
On Mon, 2004-10-11 at 13:22, Andre Tomt wrote:
> I've been running 2.20.3.1 + the data corruption bug fix on megaraids
> ranging from low-end SATA adapters to the u320scsi ones for a while on a
> 2.6.8 based kernel, nothing have blown up yet. The old 2.20.3.1 without
> the fix have been holding up too though - however having a known data
> corruption bug lingering doesn't feel so good :-)
Yes, well, that's one of the things that worries me slightly ... no-one
has reported the data corruption that the patch claims to fix. That's
one of the reasons I was planning to take it through the normal cycle.
James
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 19:29 ` James Bottomley
@ 2004-10-11 23:35 ` Linus Torvalds
2004-10-12 1:01 ` Lee Revell
` (2 more replies)
0 siblings, 3 replies; 35+ messages in thread
From: Linus Torvalds @ 2004-10-11 23:35 UTC (permalink / raw)
To: James Bottomley; +Cc: Andre Tomt, Kernel Mailing List
On Mon, 11 Oct 2004, James Bottomley wrote:
>
> Yes, well, that's one of the things that worries me slightly ... no-one
> has reported the data corruption that the patch claims to fix. That's
> one of the reasons I was planning to take it through the normal cycle.
Well, as far as I can tell from the patch, the only way to get data
corruption from the bug is when you use the SCSI ioctl's at the same time
as the disk is busy.
In other words, I think you'd have to do some special disk management, or
possibly try to burn a CD on a SCSI CD-ROM (or other special device that
uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
CD-burners any more, I'd think.
Linus
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 23:35 ` Linus Torvalds
@ 2004-10-12 1:01 ` Lee Revell
2004-10-12 4:02 ` William Lee Irwin III
2004-10-12 6:57 ` Jesper Juhl
2 siblings, 0 replies; 35+ messages in thread
From: Lee Revell @ 2004-10-12 1:01 UTC (permalink / raw)
To: Linus Torvalds; +Cc: James Bottomley, Andre Tomt, Kernel Mailing List
On Mon, 2004-10-11 at 19:35, Linus Torvalds wrote:
> Well, as far as I can tell from the patch, the only way to get data
> corruption from the bug is when you use the SCSI ioctl's at the same time
> as the disk is busy.
>
> In other words, I think you'd have to do some special disk management, or
> possibly try to burn a CD on a SCSI CD-ROM (or other special device that
> uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
> CD-burners any more, I'd think.
This is not some far-out scenario. For a long time Plextor SCSI burners
were the best on the market, there are 1000's of them out there.
Lee
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 23:35 ` Linus Torvalds
2004-10-12 1:01 ` Lee Revell
@ 2004-10-12 4:02 ` William Lee Irwin III
2004-10-12 6:57 ` Jesper Juhl
2 siblings, 0 replies; 35+ messages in thread
From: William Lee Irwin III @ 2004-10-12 4:02 UTC (permalink / raw)
To: Linus Torvalds; +Cc: James Bottomley, Andre Tomt, Kernel Mailing List
On Mon, 11 Oct 2004, James Bottomley wrote:
>> Yes, well, that's one of the things that worries me slightly ... no-one
>> has reported the data corruption that the patch claims to fix. That's
>> one of the reasons I was planning to take it through the normal cycle.
On Mon, Oct 11, 2004 at 04:35:50PM -0700, Linus Torvalds wrote:
> Well, as far as I can tell from the patch, the only way to get data
> corruption from the bug is when you use the SCSI ioctl's at the same time
> as the disk is busy.
> In other words, I think you'd have to do some special disk management, or
> possibly try to burn a CD on a SCSI CD-ROM (or other special device that
> uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
> CD-burners any more, I'd think.
Hey! I do. For some reason I've not hit this data corruption. I guess
it's a good question as to why; maybe I trail mainline by long enough
on my "desktop" to have missed where it was introduced.
-- wli
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 23:35 ` Linus Torvalds
2004-10-12 1:01 ` Lee Revell
2004-10-12 4:02 ` William Lee Irwin III
@ 2004-10-12 6:57 ` Jesper Juhl
2 siblings, 0 replies; 35+ messages in thread
From: Jesper Juhl @ 2004-10-12 6:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: James Bottomley, Andre Tomt, Kernel Mailing List
On Mon, 11 Oct 2004, Linus Torvalds wrote:
>
> In other words, I think you'd have to do some special disk management, or
> possibly try to burn a CD on a SCSI CD-ROM (or other special device that
> uses the SCSI ioctl's) on the same controller. And nobody uses SCSI
> CD-burners any more, I'd think.
>
Not so, I personally have a SCSI Plextor burner, and at work we have
several different other brands of SCSI burners, I also have a few friends
who have SCSI burners (the majority have IDE burners, but there are a few
with SCSI).
And personally I'm buying a new SCSI burner if this one dies, I've never
had a burner as troublefree as this one. IDE burners are no longer for me.
--
Jesper Juhl
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 15:09 ` James Bottomley
2004-10-11 18:22 ` Andre Tomt
@ 2004-10-11 21:37 ` Chris Ricker
1 sibling, 0 replies; 35+ messages in thread
From: Chris Ricker @ 2004-10-11 21:37 UTC (permalink / raw)
To: James Bottomley; +Cc: Linus Torvalds, Andre Tomt, Kernel Mailing List
On Mon, 11 Oct 2004, James Bottomley wrote:
> On Mon, 2004-10-11 at 10:02, Linus Torvalds wrote:
> >
> >
> > On Mon, 11 Oct 2004, Andre Tomt wrote:
> > >
> > > The data corruption bug in the new megaraid driver version seems still
> > > not to be fixed. LSI posted a fix some weeks ago, not sure how that went..
> > >
> > > "[PATCH]: megaraid 2.20.4: Fixes a data corruption bug"
> >
> > I think that one is already in the SCSI BK tree, just not pushed to me.
> > Perhaps because the tree contains other less important patches that James
> > doesn't think are worthy yet.. James? Should I just take the small
> > megaraid patch directly (and leave the compat ioctl cleanups etc to you)?
>
> I have no objections. However, I was planning on pushing it through the
> SCSI tree because it's in the new megaraid driver which is experimental
> at the moment (the old megaraid driver is still in and still
> selectable). It's been in -mm for a few days now with no ill effects, I
> think, but I'm not sure how many megaraid owners have actually tested
> it.
No problems here with the 2.20.4....
later,
chris
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
` (3 preceding siblings ...)
2004-10-11 9:35 ` Andre Tomt
@ 2004-10-11 9:54 ` Nick Piggin
2004-10-11 15:17 ` Linus Torvalds
2004-10-11 15:48 ` Linux 2.6.9-rc4 (compile stats) John Cherry
` (3 subsequent siblings)
8 siblings, 1 reply; 35+ messages in thread
From: Nick Piggin @ 2004-10-11 9:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, Brown, Len
[-- Attachment #1: Type: text/plain, Size: 2042 bytes --]
Linus Torvalds wrote:
> Ok,
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
>
> The appended shortlog gives a pretty good idea of what has been going on.
> Mostly small stuff, with some architecture updates and an ACPI update
> thrown in for good measure.
>
> (The ACPI update fixes broken AML with implied returns, and in particular
> the Compaq Evo notebook fan control. Yay! Guess who has one..)
>
> Linus
>
ACPI still explodes on my old PII and stops it booting. (I've reported it
to Len a few times but he seems to be ignoring me).
Anyway, it is oopsing in drivers/acpi/scan.c line 207 where element
(which is NULL) gets dereferenced.
Adding a WARN_ON and return AE_BAD_PARAMETER for the element==NULL case
gives the following:
Badness in acpi_bus_extract_wakeup_device_power_package at drivers/acpi/scan.c:208
[<c021f8bf>] acpi_bus_extract_wakeup_device_power_package+0xfe/0x14b
[<c021f941>] acpi_bus_get_wakeup_device_flags+0x35/0x89
[<c021ff83>] acpi_bus_add+0xd4/0x152
[<c0220105>] acpi_bus_scan+0x104/0x156
[<c03d7742>] acpi_scan_init+0x48/0x5e
[<c03c57f4>] do_initcalls+0x54/0xc0
[<c0100410>] init+0x0/0x100
[<c0100410>] init+0x0/0x100
[<c010043a>] init+0x2a/0x100
[<c0102078>] kernel_thread_helper+0x0/0x18
[<c010207d>] kernel_thread_helper+0x5/0x18
[<c0100410>] init+0x0/0x100
[<c010043a>] init+0x2a/0x100
[<c0102078>] kernel_thread_helper+0x0/0x18
[<c010207d>] kernel_thread_helper+0x5/0x18
The ACPI bios on this thing has always seemed to be pretty broken, but
this at least allows the 'power' button to continue to work (the only
reason why I want ACPI).
Hmm... I don't want to hold up the release for this isolated problem.
Maybe if you're forced to do another -rc I could send in a trivial two
liner? (what's the policy with such a situation?)
[-- Attachment #2: acpi-fix.patch --]
[-- Type: text/x-patch, Size: 646 bytes --]
---
linux-2.6-npiggin/drivers/acpi/scan.c | 2 ++
1 files changed, 2 insertions(+)
diff -puN drivers/acpi/scan.c~acpi-fix drivers/acpi/scan.c
--- linux-2.6/drivers/acpi/scan.c~acpi-fix 2004-10-11 19:44:36.000000000 +1000
+++ linux-2.6-npiggin/drivers/acpi/scan.c 2004-10-11 19:44:51.000000000 +1000
@@ -204,6 +204,8 @@ acpi_bus_extract_wakeup_device_power_pac
return AE_BAD_PARAMETER;
element = &(package->package.elements[0]);
+ if (!element)
+ return AE_BAD_PARAMETER;
if (element->type == ACPI_TYPE_PACKAGE) {
if ((element->package.count < 2) ||
(element->package.elements[0].type != ACPI_TYPE_LOCAL_REFERENCE) ||
_
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 9:54 ` Nick Piggin
@ 2004-10-11 15:17 ` Linus Torvalds
2004-10-11 15:25 ` Linus Torvalds
2004-10-11 23:48 ` Nick Piggin
0 siblings, 2 replies; 35+ messages in thread
From: Linus Torvalds @ 2004-10-11 15:17 UTC (permalink / raw)
To: Nick Piggin; +Cc: Kernel Mailing List, Brown, Len
On Mon, 11 Oct 2004, Nick Piggin wrote:
>
> ACPI still explodes on my old PII and stops it booting. (I've reported it
> to Len a few times but he seems to be ignoring me).
I suspect the "CONFIG_ACPI_BLACKLIST_YEAR" might be the solution they came
up with. Old ACPI stuff tends to be broken.
That said, your patch is small and simple, so..
Linus
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 15:17 ` Linus Torvalds
@ 2004-10-11 15:25 ` Linus Torvalds
2004-10-12 0:11 ` Nick Piggin
2004-10-11 23:48 ` Nick Piggin
1 sibling, 1 reply; 35+ messages in thread
From: Linus Torvalds @ 2004-10-11 15:25 UTC (permalink / raw)
To: Nick Piggin; +Cc: Kernel Mailing List, Brown, Len
On Mon, 11 Oct 2004, Linus Torvalds wrote:
>
> That said, your patch is small and simple, so..
Btw, out of interest, make it print out the "package->type" for the
failure case. It should be ACPI_TYPE_PACKAGE (4), I think, but..
Linus
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 15:25 ` Linus Torvalds
@ 2004-10-12 0:11 ` Nick Piggin
0 siblings, 0 replies; 35+ messages in thread
From: Nick Piggin @ 2004-10-12 0:11 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, Brown, Len
Linus Torvalds wrote:
>
> On Mon, 11 Oct 2004, Linus Torvalds wrote:
>
>>That said, your patch is small and simple, so..
>
>
> Btw, out of interest, make it print out the "package->type" for the
> failure case. It should be ACPI_TYPE_PACKAGE (4), I think, but..
>
ACPI: element was NULL! package = 1
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 15:17 ` Linus Torvalds
2004-10-11 15:25 ` Linus Torvalds
@ 2004-10-11 23:48 ` Nick Piggin
2004-10-12 6:00 ` Barry K. Nathan
1 sibling, 1 reply; 35+ messages in thread
From: Nick Piggin @ 2004-10-11 23:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, Brown, Len
Linus Torvalds wrote:
>
> On Mon, 11 Oct 2004, Nick Piggin wrote:
>
>>ACPI still explodes on my old PII and stops it booting. (I've reported it
>>to Len a few times but he seems to be ignoring me).
>
>
> I suspect the "CONFIG_ACPI_BLACKLIST_YEAR" might be the solution they came
> up with. Old ACPI stuff tends to be broken.
>
True. I am using acpi=force afterall.
> That said, your patch is small and simple, so..
>
OK you've merged it... well thanks. I guess considering I'm the only
one seeing this, it isn't going to impact anyone but me. Probably
avoiding an oops is a good thing even if it is due to broken hardware.
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 23:48 ` Nick Piggin
@ 2004-10-12 6:00 ` Barry K. Nathan
0 siblings, 0 replies; 35+ messages in thread
From: Barry K. Nathan @ 2004-10-12 6:00 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linus Torvalds, Kernel Mailing List, Brown, Len
On Tue, Oct 12, 2004 at 09:48:08AM +1000, Nick Piggin wrote:
> OK you've merged it... well thanks. I guess considering I'm the only
> one seeing this, it isn't going to impact anyone but me. Probably
> avoiding an oops is a good thing even if it is due to broken hardware.
FWIW I think at one point I saw this oops, or a similar one -- but I
just didn't bother reporting it. So, I'm glad that this check has been
added.
-Barry K. Nathan <barryn@pobox.com>
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 (compile stats)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
` (4 preceding siblings ...)
2004-10-11 9:54 ` Nick Piggin
@ 2004-10-11 15:48 ` John Cherry
2004-10-11 15:51 ` John Cherry
2004-10-11 16:24 ` [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors Adrian Bunk
` (2 subsequent siblings)
8 siblings, 1 reply; 35+ messages in thread
From: John Cherry @ 2004-10-11 15:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
Linux 2.6 Compile Statistics (gcc 3.2.2)
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.9-rc3 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc4 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc3 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8-rc2 0w/0e 0w/0e 85w/ 0e 5w/0e 1w/0e 79w/0e
2.6.8-rc1 0w/0e 0w/0e 87w/ 0e 5w/0e 1w/0e 82w/0e
2.6.7 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 102w/0e
2.6.7-rc3 0w/0e 0w/0e 108w/ 0e 5w/0e 2w/0e 104w/0e
2.6.7-rc2 0w/0e 0w/0e 110w/ 0e 5w/0e 2w/0e 106w/0e
2.6.7-rc1 0w/0e 0w/0e 111w/ 0e 6w/0e 2w/0e 107w/0e
2.6.6 0w/0e 0w/0e 123w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc3 0w/0e 0w/0e 124w/ 0e 7w/0e 5w/0e 121w/0e
2.6.6-rc2 0w/0e 0w/0e 122w/ 0e 7w/0e 4w/0e 121w/0e
2.6.6-rc1 0w/0e 0w/0e 125w/ 0e 7w/0e 4w/0e 123w/0e
2.6.5 0w/0e 0w/0e 134w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc3 0w/0e 0w/0e 135w/ 0e 8w/0e 4w/0e 132w/0e
2.6.5-rc2 0w/0e 0w/0e 135w/ 0e 8w/0e 3w/0e 132w/0e
2.6.5-rc1 0w/0e 0w/0e 138w/ 0e 8w/0e 3w/0e 135w/0e
2.6.4 1w/0e 0w/0e 145w/ 0e 7w/0e 3w/0e 142w/0e
2.6.4-rc2 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.4-rc1 1w/0e 0w/0e 148w/ 0e 7w/0e 3w/0e 145w/0e
2.6.3 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
2.6.3-rc4 1w/0e 0w/0e 142w/ 0e 9w/0e 3w/0e 142w/0e
2.6.3-rc3 1w/0e 0w/0e 145w/ 7e 9w/0e 3w/0e 148w/0e
2.6.3-rc2 1w/0e 0w/0e 141w/ 0e 9w/0e 3w/0e 144w/0e
2.6.3-rc1 1w/0e 0w/0e 145w/ 0e 9w/0e 3w/0e 177w/0e
2.6.2 1w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.2-rc3 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.2-rc2 0w/0e 0w/0e 153w/ 8e 12w/0e 3w/0e 188w/0e
2.6.2-rc1 0w/0e 0w/0e 152w/ 0e 12w/0e 3w/0e 187w/0e
2.6.1 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
2.6.1-rc3 0w/0e 0w/0e 158w/ 0e 12w/0e 3w/0e 197w/0e
2.6.1-rc2 0w/0e 0w/0e 166w/ 0e 12w/0e 3w/0e 205w/0e
2.6.1-rc1 0w/0e 0w/0e 167w/ 0e 12w/0e 3w/0e 206w/0e
2.6.0 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e
Daily compiles (ia32):
http://developer.osdl.org/cherry/compile/2.6/linus-tree/running.txt
Latest changes in Linus' bitkeeper tree:
http://linux.bkbits.net:8080/linux-2.5
--
John Cherry
cherry@osdl.org
503-626-2455x29
Open Source Development Labs
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 (compile stats)
2004-10-11 15:48 ` Linux 2.6.9-rc4 (compile stats) John Cherry
@ 2004-10-11 15:51 ` John Cherry
0 siblings, 0 replies; 35+ messages in thread
From: John Cherry @ 2004-10-11 15:51 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
No, we didn't have two rc3 releases. See updated stats...
> 2.6.9-rc3 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
> 2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
> 2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
> 2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
Linux 2.6 Compile Statistics (gcc 3.2.2)
Web page with links to complete details:
http://developer.osdl.org/cherry/compile/
Kernel bzImage bzImage bzImage modules bzImage modules
(defconfig) (allno) (allyes) (allyes) (allmod) (allmod)
----------- ----------- -------- -------- -------- -------- ---------
2.6.9-rc4 0w/0e 0w/0e 1930w/0e 41w/0e 11w/0e 1950w/0e
2.6.9-rc3 0w/0e 0w/0e 2752w/17e 41w/0e 11w/0e 2782w/5e
2.6.9-rc2 0w/0e 0w/0e 3036w/0e 41w/0e 11w/0e 3655w/0e
2.6.9-rc1 0w/0e 0w/0e 77w/10e 4w/0e 3w/0e 68w/0e
2.6.8.1 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
2.6.8 0w/0e 0w/0e 78w/ 0e 4w/0e 1w/0e 72w/0e
--
John Cherry
cherry@osdl.org
503-626-2455x29
Open Source Development Labs
^ permalink raw reply [flat|nested] 35+ messages in thread
* [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
` (5 preceding siblings ...)
2004-10-11 15:48 ` Linux 2.6.9-rc4 (compile stats) John Cherry
@ 2004-10-11 16:24 ` Adrian Bunk
2004-10-11 16:28 ` James Bottomley
2004-10-11 22:04 ` Linux 2.6.9-rc4 - pls test (and no more patches) Tom Rini
2004-10-12 8:05 ` Matthias Andree
8 siblings, 1 reply; 35+ messages in thread
From: Adrian Bunk @ 2004-10-11 16:24 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List, Andrew Morton, James Bottomley
Compiling with gcc 3.4 results in the following compile errors:
<-- snip -->
CC drivers/scsi/qla2xxx/qla_os.o
drivers/scsi/qla2xxx/qla_os.c: In function `qla2x00_queuecommand':
drivers/scsi/qla2xxx/qla_os.c:315: sorry, unimplemented: inlining failed
in call to 'qla2x00_callback': function not considered for inlining
drivers/scsi/qla2xxx/qla_os.c:269: sorry, unimplemented: called from here
drivers/scsi/qla2xxx/qla_os.c:315: sorry, unimplemented: inlining failed
in call to 'qla2x00_callback': function not considered for inlining
drivers/scsi/qla2xxx/qla_os.c:269: sorry, unimplemented: called from here
make[3]: *** [drivers/scsi/qla2xxx/qla_os.o] Error 1
...
CC drivers/scsi/qla2xxx/qla_rscn.o
drivers/scsi/qla2xxx/qla_rscn.c: In function `qla2x00_cancel_io_descriptors':
drivers/scsi/qla2xxx/qla_rscn.c:320: sorry, unimplemented: inlining
failed in call to 'qla2x00_remove_iodesc_timer': function not considered for inlining
drivers/scsi/qla2xxx/qla_rscn.c:257: sorry, unimplemented: called from here
make[3]: *** [drivers/scsi/qla2xxx/qla_rscn.o] Error 1
<-- snip -->
Please apply my patch below which is already for some time in James'
SCSI tree.
diffstat output:
drivers/scsi/qla2xxx/qla_os.c | 122 ++++++++++++++++----------------
drivers/scsi/qla2xxx/qla_rscn.c | 28 +++----
2 files changed, 75 insertions(+), 75 deletions(-)
Signed-off-by: Adrian Bunk <bunk@stusta.de>
--- a/drivers/scsi/qla2xxx/qla_os.c 2004-10-10 22:27:31 -07:00
+++ b/drivers/scsi/qla2xxx/qla_os.c 2004-10-10 22:27:31 -07:00
@@ -235,67 +236,6 @@
static __inline__ void
qla2x00_delete_from_done_queue(scsi_qla_host_t *, srb_t *);
-/**************************************************************************
-* sp_put
-*
-* Description:
-* Decrement reference count and call the callback if we're the last
-* owner of the specified sp. Will get the host_lock before calling
-* the callback.
-*
-* Input:
-* ha - pointer to the scsi_qla_host_t where the callback is to occur.
-* sp - pointer to srb_t structure to use.
-*
-* Returns:
-*
-**************************************************************************/
-static inline void
-sp_put(struct scsi_qla_host * ha, srb_t *sp)
-{
- if (atomic_read(&sp->ref_count) == 0) {
- qla_printk(KERN_INFO, ha,
- "%s(): **** SP->ref_count not zero\n",
- __func__);
- DEBUG2(BUG();)
-
- return;
- }
-
- if (!atomic_dec_and_test(&sp->ref_count)) {
- return;
- }
-
- qla2x00_callback(ha, sp->cmd);
-}
-
-/**************************************************************************
-* sp_get
-*
-* Description:
-* Increment reference count of the specified sp.
-*
-* Input:
-* sp - pointer to srb_t structure to use.
-*
-* Returns:
-*
-**************************************************************************/
-static inline void
-sp_get(struct scsi_qla_host * ha, srb_t *sp)
-{
- atomic_inc(&sp->ref_count);
-
- if (atomic_read(&sp->ref_count) > 2) {
- qla_printk(KERN_INFO, ha,
- "%s(): **** SP->ref_count greater than two\n",
- __func__);
- DEBUG2(BUG();)
-
- return;
- }
-}
-
/*
* qla2x00_callback
* Returns the completed SCSI command to LINUX.
@@ -366,6 +306,67 @@
(*(cmd)->scsi_done)(cmd);
}
+/**************************************************************************
+* sp_put
+*
+* Description:
+* Decrement reference count and call the callback if we're the last
+* owner of the specified sp. Will get the host_lock before calling
+* the callback.
+*
+* Input:
+* ha - pointer to the scsi_qla_host_t where the callback is to occur.
+* sp - pointer to srb_t structure to use.
+*
+* Returns:
+*
+**************************************************************************/
+static inline void
+sp_put(struct scsi_qla_host * ha, srb_t *sp)
+{
+ if (atomic_read(&sp->ref_count) == 0) {
+ qla_printk(KERN_INFO, ha,
+ "%s(): **** SP->ref_count not zero\n",
+ __func__);
+ DEBUG2(BUG();)
+
+ return;
+ }
+
+ if (!atomic_dec_and_test(&sp->ref_count)) {
+ return;
+ }
+
+ qla2x00_callback(ha, sp->cmd);
+}
+
+/**************************************************************************
+* sp_get
+*
+* Description:
+* Increment reference count of the specified sp.
+*
+* Input:
+* sp - pointer to srb_t structure to use.
+*
+* Returns:
+*
+**************************************************************************/
+static inline void
+sp_get(struct scsi_qla_host * ha, srb_t *sp)
+{
+ atomic_inc(&sp->ref_count);
+
+ if (atomic_read(&sp->ref_count) > 2) {
+ qla_printk(KERN_INFO, ha,
+ "%s(): **** SP->ref_count greater than two\n",
+ __func__);
+ DEBUG2(BUG();)
+
+ return;
+ }
+}
+
static inline void
qla2x00_delete_from_done_queue(scsi_qla_host_t *dest_ha, srb_t *sp)
{
--- a/drivers/scsi/qla2xxx/qla_rscn.c 2004-10-10 22:27:29 -07:00
+++ b/drivers/scsi/qla2xxx/qla_rscn.c 2004-10-10 22:27:29 -07:00
@@ -242,6 +242,20 @@
}
/**
+ * qla2x00_remove_iodesc_timer() - Remove an active timer from an IO descriptor.
+ * @iodesc: io descriptor
+ */
+static inline void
+qla2x00_remove_iodesc_timer(struct io_descriptor *iodesc)
+{
+ if (iodesc->timer.function != NULL) {
+ del_timer_sync(&iodesc->timer);
+ iodesc->timer.data = (unsigned long) NULL;
+ iodesc->timer.function = NULL;
+ }
+}
+
+/**
* qla2x00_init_io_descriptors() - Initialize the pool of IO descriptors.
* @ha: HA context
*/
@@ -309,20 +323,6 @@
iodesc->timer.function =
(void (*) (unsigned long)) qla2x00_iodesc_timeout;
add_timer(&iodesc->timer);
-}
-
-/**
- * qla2x00_remove_iodesc_timer() - Remove an active timer from an IO descriptor.
- * @iodesc: io descriptor
- */
-static inline void
-qla2x00_remove_iodesc_timer(struct io_descriptor *iodesc)
-{
- if (iodesc->timer.function != NULL) {
- del_timer_sync(&iodesc->timer);
- iodesc->timer.data = (unsigned long) NULL;
- iodesc->timer.function = NULL;
- }
}
/**
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors
2004-10-11 16:24 ` [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors Adrian Bunk
@ 2004-10-11 16:28 ` James Bottomley
2004-10-11 16:35 ` Adrian Bunk
0 siblings, 1 reply; 35+ messages in thread
From: James Bottomley @ 2004-10-11 16:28 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linus Torvalds, Kernel Mailing List, Andrew Morton
On Mon, 2004-10-11 at 11:24, Adrian Bunk wrote:
> Please apply my patch below which is already for some time in James'
> SCSI tree.
It's waiting in my tree until 2.6.9 goes final because gcc-3.4 fixes are
hardly showstoppers. If you want to compile the kernel with gcc-3.4 use
-mm
James
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors
2004-10-11 16:28 ` James Bottomley
@ 2004-10-11 16:35 ` Adrian Bunk
2004-10-11 17:05 ` James Bottomley
0 siblings, 1 reply; 35+ messages in thread
From: Adrian Bunk @ 2004-10-11 16:35 UTC (permalink / raw)
To: James Bottomley; +Cc: Linus Torvalds, Kernel Mailing List, Andrew Morton
On Mon, Oct 11, 2004 at 11:28:42AM -0500, James Bottomley wrote:
> On Mon, 2004-10-11 at 11:24, Adrian Bunk wrote:
> > Please apply my patch below which is already for some time in James'
> > SCSI tree.
>
> It's waiting in my tree until 2.6.9 goes final because gcc-3.4 fixes are
> hardly showstoppers. If you want to compile the kernel with gcc-3.4 use
> -mm
It's the only compile error with gcc 3.4 I found in 2.6.9-rc4, and the
fix is pretty low-risk.
> James
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors
2004-10-11 16:35 ` Adrian Bunk
@ 2004-10-11 17:05 ` James Bottomley
0 siblings, 0 replies; 35+ messages in thread
From: James Bottomley @ 2004-10-11 17:05 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Linus Torvalds, Kernel Mailing List, Andrew Morton
On Mon, 2004-10-11 at 11:35, Adrian Bunk wrote:
> It's the only compile error with gcc 3.4 I found in 2.6.9-rc4, and the
> fix is pretty low-risk.
But also not essential. If we apply lots of inessential but low risk
fixes, all we end up with is merge problems in the various BK trees and
no real benefit. The fix is queued, it will be in early 2.6.9, just be
patient.
James
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
` (6 preceding siblings ...)
2004-10-11 16:24 ` [patch] 2.6.9-rc4: SCSI qla2xxx gcc 3.4 compile errors Adrian Bunk
@ 2004-10-11 22:04 ` Tom Rini
2004-10-11 23:23 ` Tom Rini
2004-10-12 8:05 ` Matthias Andree
8 siblings, 1 reply; 35+ messages in thread
From: Tom Rini @ 2004-10-11 22:04 UTC (permalink / raw)
To: Linus Torvalds, Petr Vandrovec; +Cc: Kernel Mailing List
On Sun, Oct 10, 2004 at 08:22:54PM -0700, Linus Torvalds wrote:
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
With 2.6.9-rc4, using matroxfb, I can no longer pass
video=1280x1024-8@85. This worked on 2.6.8.1, and I'm trying kernels
inbetween now.
$ cat /proc/cmdline
root=/dev/hda1 ro video=1280x1024-8@85 elevator=cfq
$ zgrep -E CONFIG_\(FB\|VIDEO\).*= /proc/config.gz
CONFIG_FB=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_VIDEO_SELECT=y
CONFIG_FB_MATROX=y
CONFIG_FB_MATROX_G450=y
CONFIG_FB_MATROX_G100=y
CONFIG_FB_MATROX_I2C=y
$ dmesg | grep matrox
matroxfb: Matrox G450 detected
matroxfb: MTRR's turned on
matroxfb: 640x480x8bpp (virtual: 640x26214)
matroxfb: framebuffer at 0xCC000000, mapped to 0xe0880000, size 33554432
matroxfb_crtc2: secondary head of fb0 was registered as fb1
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 22:04 ` Linux 2.6.9-rc4 - pls test (and no more patches) Tom Rini
@ 2004-10-11 23:23 ` Tom Rini
0 siblings, 0 replies; 35+ messages in thread
From: Tom Rini @ 2004-10-11 23:23 UTC (permalink / raw)
To: Linus Torvalds, Petr Vandrovec; +Cc: Kernel Mailing List
On Mon, Oct 11, 2004 at 03:04:49PM -0700, Tom Rini wrote:
> On Sun, Oct 10, 2004 at 08:22:54PM -0700, Linus Torvalds wrote:
>
> > trying to make ready for the real 2.6.9 in a week or so, so please give
> > this a beating, and if you have pending patches, please hold on to them
> > for a bit longer, until after the 2.6.9 release. It would be good to have
> > a 2.6.9 that doesn't need a dot-release immediately ;)
>
> With 2.6.9-rc4, using matroxfb, I can no longer pass
> video=1280x1024-8@85. This worked on 2.6.8.1, and I'm trying kernels
> inbetween now.
The problem happened inbetween -rc1 and -rc2.
--
Tom Rini
http://gate.crashing.org/~trini/
^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Linux 2.6.9-rc4 - pls test (and no more patches)
2004-10-11 3:22 Linux 2.6.9-rc4 - pls test (and no more patches) Linus Torvalds
` (7 preceding siblings ...)
2004-10-11 22:04 ` Linux 2.6.9-rc4 - pls test (and no more patches) Tom Rini
@ 2004-10-12 8:05 ` Matthias Andree
2004-10-12 9:09 ` [PATCH] tcp_output.c: tcp_set_skb_tso_factor ---> tcp_set_skb_tso_segs [Was: Re: Linux 2.6.9-rc4 - pls test (and no more patches)] Sami Farin
8 siblings, 1 reply; 35+ messages in thread
From: Matthias Andree @ 2004-10-12 8:05 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Kernel Mailing List
On Sun, 10 Oct 2004, Linus Torvalds wrote:
> trying to make ready for the real 2.6.9 in a week or so, so please give
> this a beating, and if you have pending patches, please hold on to them
> for a bit longer, until after the 2.6.9 release. It would be good to have
> a 2.6.9 that doesn't need a dot-release immediately ;)
How about Marcelo's policy that the -final version should differ from
the last -rc only in the Makefile VERSION and nothing else (well,
documentation perhaps if someone else has proofread it).
Would you be ready to have the last -rc out for, say, five days, before
releasing the official, final, blessed, however 2.6.9, in order to catch
the showstoppers?
--
Matthias Andree
Encrypted mail welcome: my GnuPG key ID is 0x052E7D95 (PGP/MIME preferred)
^ permalink raw reply [flat|nested] 35+ messages in thread
* [PATCH] tcp_output.c: tcp_set_skb_tso_factor ---> tcp_set_skb_tso_segs [Was: Re: Linux 2.6.9-rc4 - pls test (and no more patches)]
2004-10-12 8:05 ` Matthias Andree
@ 2004-10-12 9:09 ` Sami Farin
0 siblings, 0 replies; 35+ messages in thread
From: Sami Farin @ 2004-10-12 9:09 UTC (permalink / raw)
To: Kernel Mailing List; +Cc: Linus Torvalds
On Tue, Oct 12, 2004 at 10:05:37AM +0200, Matthias Andree wrote:
> On Sun, 10 Oct 2004, Linus Torvalds wrote:
>
> > trying to make ready for the real 2.6.9 in a week or so, so please give
> > this a beating, and if you have pending patches, please hold on to them
> > for a bit longer, until after the 2.6.9 release. It would be good to have
> > a 2.6.9 that doesn't need a dot-release immediately ;)
>
> How about Marcelo's policy that the -final version should differ from
> the last -rc only in the Makefile VERSION and nothing else (well,
> documentation perhaps if someone else has proofread it).
>
> Would you be ready to have the last -rc out for, say, five days, before
> releasing the official, final, blessed, however 2.6.9, in order to catch
> the showstoppers?
Like this one? 2.6.9-rc4 does not build with
gcc-2.95.3 + binutils-2.15.92.0.2.
Signed-Off-By: Sami Farin <7atbggg02@sneakemail.com>
--- linux/net/ipv4/tcp_output.c.bak 2004-10-11 18:24:06.000000000 +0300
+++ linux/net/ipv4/tcp_output.c 2004-10-11 22:12:32.000000000 +0300
@@ -445,7 +445,7 @@ void tcp_set_skb_tso_segs(struct sk_buff
skb_shinfo(skb)->tso_size = mss_std;
}
}
-EXPORT_SYMBOL_GPL(tcp_set_skb_tso_factor);
+EXPORT_SYMBOL_GPL(tcp_set_skb_tso_segs);
/* Function to create two new TCP segments. Shrinks the given segment
* to the specified size and appends a new segment with the rest of the
--
^ permalink raw reply [flat|nested] 35+ messages in thread