Re: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 3:25 PM, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> On Mon, 25 Feb 2008, Michael Buesch wrote:
> > > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24
> > > _regression_. Or maybe I am just too naive to believe Linus' statement
> > > on not letting the kernel regress...
> >
> > So, please sign-off the patch that we have, if you think it's right
> > and doesn't cause more regressions.
>
> I did look at the patch and can gladly add a:
>
> Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
>
Thanks for reviewing. Was it the patch I sent to Larry Finger
with the subject line "[PATCH] Fix the bcm43xx driver breakage in 2.6.24/25"
or the patch I sent with the first email in this thread? The patches are
generally the same, but the one sent to Larry was split into two pieces
and the condition on which the bcm43xx config option was hidden
changed a bit.
> But this seems backwards. It was _your_ commit that broke the setup and
> the patch touches a driver _you're_ maintaining.
>
> So can we just revert commit 753f492093da7a40141bfe083073400f518f4c68
> ("[B44]: port to native ssb support") from 2.6.24 and you can add it back
> to 2.6.25 if the problem indeed does go away?
I'm quite sure my patch won't cause any problems, but if Greg
wants to be 100% sure there won't be any regressions introduced
in -stable, reverting the said commit should be the right thing.
--
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: bcm43xx regression in 2.6.24 (with patch)
On Mon, 25 Feb 2008, Michael Buesch wrote:
> > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24
> > _regression_. Or maybe I am just too naive to believe Linus' statement
> > on not letting the kernel regress...
>
> So, please sign-off the patch that we have, if you think it's right
> and doesn't cause more regressions.
I did look at the patch and can gladly add a:
Reviewed-by: Pekka Enberg <[EMAIL PROTECTED]>
But this seems backwards. It was _your_ commit that broke the setup and
the patch touches a driver _you're_ maintaining.
So can we just revert commit 753f492093da7a40141bfe083073400f518f4c68
("[B44]: port to native ssb support") from 2.6.24 and you can add it back
to 2.6.25 if the problem indeed does go away?
Pekka
--
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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 13:11:04 Pekka Enberg wrote: > On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > Isn't the resolution Michael is suggesting is, "use the different > > driver"? > > > > I have two resolutions. One being: > > rmmod b44 > > rmmod ssb > > modprobe bcm43xx > > modprobe b44 > > > > The other being: Wait for 2.6.25 and use the maintained b43 driver. > > Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24 > _regression_. Or maybe I am just too naive to believe Linus' statement > on not letting the kernel regress... So, please sign-off the patch that we have, if you think it's right and doesn't cause more regressions. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > Isn't the resolution Michael is suggesting is, "use the different driver"? > > I have two resolutions. One being: > rmmod b44 > rmmod ssb > modprobe bcm43xx > modprobe b44 > > The other being: Wait for 2.6.25 and use the maintained b43 driver. Neither of which seem like acceptable solutions for a 2.6.23 -> 2.6.24 _regression_. Or maybe I am just too naive to believe Linus' statement on not letting the kernel regress... -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 11:49:34 Xavier Bestel wrote: > On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: > > [1] bcm43xx is unmaintained. Larry used to be the maintainer until > > he dropped it a few months ago. > > Doesn't that mean that Alexey gets to be the maintainer, as he's the one > patching it ? 1) He is not patching it. 2) Yeah, if he likes to be the bcm43xx maintainer, please go for it. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: > [1] bcm43xx is unmaintained. Larry used to be the maintainer until > he dropped it a few months ago. Doesn't that mean that Alexey gets to be the maintainer, as he's the one patching it ? Xav -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 11:23:02 Alexey Zaytsev wrote: > On Mon, Feb 25, 2008 at 9:49 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > > > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > > > Hi Michael, > > > > > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > > > The ony way I see this was possible, you manually changed the > > > > > module loading order, so that the b43xx module was loaded prior > > > > > to the ssb and b44 modules. Right? > > > > > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > > > > > Lets make this simple: it used to work before and now it doesn't. > > > Therefore it's a regression that must be addressed. Period. > > > > Isn't the resolution Michael is suggesting is, "use the different driver"? > > > > The b43 driver from 2.6.24 does not work with my hardware. The one from > 2.6.25 seems to work, but 2.6.25 is far from being ready yet. > > The only way you can get the old driver working in 2.6.24 is to > compile certain (completely unrelated for an outsider) drivers as > modules and play with the module loading order. I think this is a > bug, and it should be fixed in -stable. It must first go into the 2.6.25 tree and then into -stable. And the patch must be considered to do The Right Thing (tm). > And for 2.6.25, I think the patch should also be included, as the > bcm43xx driver is still there. > > Btw, what are we discussing? The real bcm43xx maintainer > (Larry Finger) reviewed the patch and agreet it should go > into 2.6.24-stable and 2.6.25 . Now we only have to wait for > John Linville and Jeff Garzik to pick it up, right? If someone > still thinks the patch should not go in, he should at least > add them to the CC list. ;) Heh, wait. Larry is neither the bcm43xx maintainer [1], nor does this code touch bcm43xx code. It does touch ssb and b43 code, which I am the maintainer of. Though, as I said, if somebody else is familiar with the code does really understand the patch and does ACK it (which Larry did), I'm probably OK with applying it. As long as I'm not bothered with any followup regressions caused by this. So if the one signing off the patch will handle all this, I'm fine with it. [1] bcm43xx is unmaintained. Larry used to be the maintainer until he dropped it a few months ago. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 9:49 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > > Hi Michael, > > > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > > The ony way I see this was possible, you manually changed the > > > > module loading order, so that the b43xx module was loaded prior > > > > to the ssb and b44 modules. Right? > > > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > > > Lets make this simple: it used to work before and now it doesn't. > > Therefore it's a regression that must be addressed. Period. > > Isn't the resolution Michael is suggesting is, "use the different driver"? > The b43 driver from 2.6.24 does not work with my hardware. The one from 2.6.25 seems to work, but 2.6.25 is far from being ready yet. The only way you can get the old driver working in 2.6.24 is to compile certain (completely unrelated for an outsider) drivers as modules and play with the module loading order. I think this is a bug, and it should be fixed in -stable. And for 2.6.25, I think the patch should also be included, as the bcm43xx driver is still there. Btw, what are we discussing? The real bcm43xx maintainer (Larry Finger) reviewed the patch and agreet it should go into 2.6.24-stable and 2.6.25 . Now we only have to wait for John Linville and Jeff Garzik to pick it up, right? If someone still thinks the patch should not go in, he should at least add them to the CC list. ;) > thanks, > > greg k-h > -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 07:49:35 Greg KH wrote: > On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > > Hi Michael, > > > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > > The ony way I see this was possible, you manually changed the > > > > module loading order, so that the b43xx module was loaded prior > > > > to the ssb and b44 modules. Right? > > > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > > > Lets make this simple: it used to work before and now it doesn't. > > Therefore it's a regression that must be addressed. Period. > > Isn't the resolution Michael is suggesting is, "use the different driver"? I have two resolutions. One being: rmmod b44 rmmod ssb modprobe bcm43xx modprobe b44 The other being: Wait for 2.6.25 and use the maintained b43 driver. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 07:49:35 Greg KH wrote: On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: Hi Michael, On Sun, 24 Feb 2008, Michael Buesch wrote: The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Right. So so I'm left with either no wifi or no ethenet being wrong. Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Isn't the resolution Michael is suggesting is, use the different driver? I have two resolutions. One being: rmmod b44 rmmod ssb modprobe bcm43xx modprobe b44 The other being: Wait for 2.6.25 and use the maintained b43 driver. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 11:23:02 Alexey Zaytsev wrote: On Mon, Feb 25, 2008 at 9:49 AM, Greg KH [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: Hi Michael, On Sun, 24 Feb 2008, Michael Buesch wrote: The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Right. So so I'm left with either no wifi or no ethenet being wrong. Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Isn't the resolution Michael is suggesting is, use the different driver? The b43 driver from 2.6.24 does not work with my hardware. The one from 2.6.25 seems to work, but 2.6.25 is far from being ready yet. The only way you can get the old driver working in 2.6.24 is to compile certain (completely unrelated for an outsider) drivers as modules and play with the module loading order. I think this is a bug, and it should be fixed in -stable. It must first go into the 2.6.25 tree and then into -stable. And the patch must be considered to do The Right Thing (tm). And for 2.6.25, I think the patch should also be included, as the bcm43xx driver is still there. Btw, what are we discussing? The real bcm43xx maintainer (Larry Finger) reviewed the patch and agreet it should go into 2.6.24-stable and 2.6.25 . Now we only have to wait for John Linville and Jeff Garzik to pick it up, right? If someone still thinks the patch should not go in, he should at least add them to the CC list. ;) Heh, wait. Larry is neither the bcm43xx maintainer [1], nor does this code touch bcm43xx code. It does touch ssb and b43 code, which I am the maintainer of. Though, as I said, if somebody else is familiar with the code does really understand the patch and does ACK it (which Larry did), I'm probably OK with applying it. As long as I'm not bothered with any followup regressions caused by this. So if the one signing off the patch will handle all this, I'm fine with it. [1] bcm43xx is unmaintained. Larry used to be the maintainer until he dropped it a few months ago. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 9:49 AM, Greg KH [EMAIL PROTECTED] wrote: On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: Hi Michael, On Sun, 24 Feb 2008, Michael Buesch wrote: The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Right. So so I'm left with either no wifi or no ethenet being wrong. Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Isn't the resolution Michael is suggesting is, use the different driver? The b43 driver from 2.6.24 does not work with my hardware. The one from 2.6.25 seems to work, but 2.6.25 is far from being ready yet. The only way you can get the old driver working in 2.6.24 is to compile certain (completely unrelated for an outsider) drivers as modules and play with the module loading order. I think this is a bug, and it should be fixed in -stable. And for 2.6.25, I think the patch should also be included, as the bcm43xx driver is still there. Btw, what are we discussing? The real bcm43xx maintainer (Larry Finger) reviewed the patch and agreet it should go into 2.6.24-stable and 2.6.25 . Now we only have to wait for John Linville and Jeff Garzik to pick it up, right? If someone still thinks the patch should not go in, he should at least add them to the CC list. ;) thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: [1] bcm43xx is unmaintained. Larry used to be the maintainer until he dropped it a few months ago. Doesn't that mean that Alexey gets to be the maintainer, as he's the one patching it ? Xav -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 11:49:34 Xavier Bestel wrote: On Mon, 2008-02-25 at 11:38 +0100, Michael Buesch wrote: [1] bcm43xx is unmaintained. Larry used to be the maintainer until he dropped it a few months ago. Doesn't that mean that Alexey gets to be the maintainer, as he's the one patching it ? 1) He is not patching it. 2) Yeah, if he likes to be the bcm43xx maintainer, please go for it. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch [EMAIL PROTECTED] wrote: Isn't the resolution Michael is suggesting is, use the different driver? I have two resolutions. One being: rmmod b44 rmmod ssb modprobe bcm43xx modprobe b44 The other being: Wait for 2.6.25 and use the maintained b43 driver. Neither of which seem like acceptable solutions for a 2.6.23 - 2.6.24 _regression_. Or maybe I am just too naive to believe Linus' statement on not letting the kernel regress... -- 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: bcm43xx regression in 2.6.24 (with patch)
On Monday 25 February 2008 13:11:04 Pekka Enberg wrote: On Mon, Feb 25, 2008 at 11:54 AM, Michael Buesch [EMAIL PROTECTED] wrote: Isn't the resolution Michael is suggesting is, use the different driver? I have two resolutions. One being: rmmod b44 rmmod ssb modprobe bcm43xx modprobe b44 The other being: Wait for 2.6.25 and use the maintained b43 driver. Neither of which seem like acceptable solutions for a 2.6.23 - 2.6.24 _regression_. Or maybe I am just too naive to believe Linus' statement on not letting the kernel regress... So, please sign-off the patch that we have, if you think it's right and doesn't cause more regressions. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, 25 Feb 2008, Michael Buesch wrote: Neither of which seem like acceptable solutions for a 2.6.23 - 2.6.24 _regression_. Or maybe I am just too naive to believe Linus' statement on not letting the kernel regress... So, please sign-off the patch that we have, if you think it's right and doesn't cause more regressions. I did look at the patch and can gladly add a: Reviewed-by: Pekka Enberg [EMAIL PROTECTED] But this seems backwards. It was _your_ commit that broke the setup and the patch touches a driver _you're_ maintaining. So can we just revert commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) from 2.6.24 and you can add it back to 2.6.25 if the problem indeed does go away? Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 3:25 PM, Pekka J Enberg [EMAIL PROTECTED] wrote: On Mon, 25 Feb 2008, Michael Buesch wrote: Neither of which seem like acceptable solutions for a 2.6.23 - 2.6.24 _regression_. Or maybe I am just too naive to believe Linus' statement on not letting the kernel regress... So, please sign-off the patch that we have, if you think it's right and doesn't cause more regressions. I did look at the patch and can gladly add a: Reviewed-by: Pekka Enberg [EMAIL PROTECTED] Thanks for reviewing. Was it the patch I sent to Larry Finger with the subject line [PATCH] Fix the bcm43xx driver breakage in 2.6.24/25 or the patch I sent with the first email in this thread? The patches are generally the same, but the one sent to Larry was split into two pieces and the condition on which the bcm43xx config option was hidden changed a bit. But this seems backwards. It was _your_ commit that broke the setup and the patch touches a driver _you're_ maintaining. So can we just revert commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) from 2.6.24 and you can add it back to 2.6.25 if the problem indeed does go away? I'm quite sure my patch won't cause any problems, but if Greg wants to be 100% sure there won't be any regressions introduced in -stable, reverting the said commit should be the right thing. -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi Greg, On Sun, 24 Feb 2008, Greg KH wrote: > > Lets make this simple: it used to work before and now it doesn't. > > Therefore it's a regression that must be addressed. Period. > > Isn't the resolution Michael is suggesting is, "use the different driver"? Alexey said it didn't work but even if it did, we don't let old drivers _regress_ as long as they're in the tree. There are plenty of precedents here so I don't see why this particular Broadcom driver is any different. Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: > Hi Michael, > > On Sun, 24 Feb 2008, Michael Buesch wrote: > > > The ony way I see this was possible, you manually changed the > > > module loading order, so that the b43xx module was loaded prior > > > to the ssb and b44 modules. Right? > > > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. > > Lets make this simple: it used to work before and now it doesn't. > Therefore it's a regression that must be addressed. Period. Isn't the resolution Michael is suggesting is, "use the different driver"? thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi Michael, On Sun, 24 Feb 2008, Michael Buesch wrote: > > The ony way I see this was possible, you manually changed the > > module loading order, so that the b43xx module was loaded prior > > to the ssb and b44 modules. Right? > > Right. So "so I'm left with either no wifi or no ethenet" being wrong. Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sunday 24 February 2008, Alexey Zaytsev wrote: > On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote: > > > The problem is not with enabling both b43 and bcm43xx (will, whis won't > > work > > > anyway, and there is no chance fixing it). The problem is with enabling > > the > > > bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then > > > wrongly autosolects some config options that prevent the bcm43xx > > > driver from loading, so I'm left with either no wifi or no ethenet. > > > > Ok, so I just tested this on a machine and it is _not_ true. > > It works just fine to run b44/ssb with bcm43xx in parallel. > > > > Can you please stop fooling me and spreading this FUD? > > > > The ony way I see this was possible, you manually changed the > module loading order, so that the b43xx module was loaded prior > to the ssb and b44 modules. Right? Right. So "so I'm left with either no wifi or no ethenet" being wrong. > Looks like this, kind of, ruins my statement that is is impossible to get > working wifi in 2.6.24. Sorry, it was not intensinal. ;) Ok, I see. > But there still are lots of valid combinations where the b43xx driver > silently won't work. E.g. when either the ssb or the b44 modules are > loaded prior to it, or when either of them are built statically (building > the b43xx driver staticaly won't help here). And my patch fixes them. With your patch you can still artificially create situations that something doesn't work. My point being: It works just fine without the patch. And as I'm not really sure about the implications of the patch, I won't ack this. But it seems Larry acked it. So that's also fine, if he takes over responsibility for that change then. So the next "You broke my kernel!!11" round can go to his mail address and I won't be bothered by this anymore. ;) -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote: > > The problem is not with enabling both b43 and bcm43xx (will, whis won't > work > > anyway, and there is no chance fixing it). The problem is with enabling the > > bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then > > wrongly autosolects some config options that prevent the bcm43xx > > driver from loading, so I'm left with either no wifi or no ethenet. > > Ok, so I just tested this on a machine and it is _not_ true. > It works just fine to run b44/ssb with bcm43xx in parallel. > > Can you please stop fooling me and spreading this FUD? > The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Or the b43xx driver was built statically and the b44 and the ssb as modules. Looks like this, kind of, ruins my statement that is is impossible to get working wifi in 2.6.24. Sorry, it was not intensinal. ;) But there still are lots of valid combinations where the b43xx driver silently won't work. E.g. when either the ssb or the b44 modules are loaded prior to it, or when either of them are built statically (building the b43xx driver staticaly won't help here). And my patch fixes them. So, my statement goes, the bug stays. Agreed? -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote: > The problem is not with enabling both b43 and bcm43xx (will, whis won't work > anyway, and there is no chance fixing it). The problem is with enabling the > bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then > wrongly autosolects some config options that prevent the bcm43xx > driver from loading, so I'm left with either no wifi or no ethenet. Ok, so I just tested this on a machine and it is _not_ true. It works just fine to run b44/ssb with bcm43xx in parallel. Can you please stop fooling me and spreading this FUD? -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote: The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. Ok, so I just tested this on a machine and it is _not_ true. It works just fine to run b44/ssb with bcm43xx in parallel. Can you please stop fooling me and spreading this FUD? -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote: The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. Ok, so I just tested this on a machine and it is _not_ true. It works just fine to run b44/ssb with bcm43xx in parallel. Can you please stop fooling me and spreading this FUD? The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Or the b43xx driver was built statically and the b44 and the ssb as modules. Looks like this, kind of, ruins my statement that is is impossible to get working wifi in 2.6.24. Sorry, it was not intensinal. ;) But there still are lots of valid combinations where the b43xx driver silently won't work. E.g. when either the ssb or the b44 modules are loaded prior to it, or when either of them are built statically (building the b43xx driver staticaly won't help here). And my patch fixes them. So, my statement goes, the bug stays. Agreed? -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sunday 24 February 2008, Alexey Zaytsev wrote: On Sun, Feb 24, 2008 at 5:29 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 12:32:50 Alexey Zaytsev wrote: The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. Ok, so I just tested this on a machine and it is _not_ true. It works just fine to run b44/ssb with bcm43xx in parallel. Can you please stop fooling me and spreading this FUD? The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Right. So so I'm left with either no wifi or no ethenet being wrong. Looks like this, kind of, ruins my statement that is is impossible to get working wifi in 2.6.24. Sorry, it was not intensinal. ;) Ok, I see. But there still are lots of valid combinations where the b43xx driver silently won't work. E.g. when either the ssb or the b44 modules are loaded prior to it, or when either of them are built statically (building the b43xx driver staticaly won't help here). And my patch fixes them. With your patch you can still artificially create situations that something doesn't work. My point being: It works just fine without the patch. And as I'm not really sure about the implications of the patch, I won't ack this. But it seems Larry acked it. So that's also fine, if he takes over responsibility for that change then. So the next You broke my kernel!!11 round can go to his mail address and I won't be bothered by this anymore. ;) -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi Michael, On Sun, 24 Feb 2008, Michael Buesch wrote: The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Right. So so I'm left with either no wifi or no ethenet being wrong. Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
On Mon, Feb 25, 2008 at 08:16:17AM +0200, Pekka J Enberg wrote: Hi Michael, On Sun, 24 Feb 2008, Michael Buesch wrote: The ony way I see this was possible, you manually changed the module loading order, so that the b43xx module was loaded prior to the ssb and b44 modules. Right? Right. So so I'm left with either no wifi or no ethenet being wrong. Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Isn't the resolution Michael is suggesting is, use the different driver? thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi Greg, On Sun, 24 Feb 2008, Greg KH wrote: Lets make this simple: it used to work before and now it doesn't. Therefore it's a regression that must be addressed. Period. Isn't the resolution Michael is suggesting is, use the different driver? Alexey said it didn't work but even if it did, we don't let old drivers _regress_ as long as they're in the tree. There are plenty of precedents here so I don't see why this particular Broadcom driver is any different. Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 22:32:46 Alexey Zaytsev wrote: > > The insults being? A few quotes, please. > If you really want to know, the > "Because the new driver works, if you just set it up right." > for me was clearly a hint that I'm just an other imcompetent > user, who can't even follow the instructions from linuxwireless.org. Well. That's 99% of all bugreports I receive. You will understand that I won't explain the same crap that's written on linuxwireless.org over and over 20 times each day to random people. And yes, you belong to the group of my "random people", as I don't remember your name from the top of my head. So in 99% of the cases the user did something wrong. But I still don't see the insult. > And you knew that the new driver did no work with the bcm4311 > chips, which is the sad thing. That is not true. It doesn't work with exactly _one_ revision of the bcm4311 card. And that is already fixed in 2.6.25. I'd like to have that in .24-stable, too, but I guess it's too big. It changes some parts of the DMA engine code. > Not true at all. I my first and second emails, there was not a single word > about who broke the driver. There were only the fix, and the explanation, > why the fix is needed. I really appreciate the work done on the b43 driver, > and I'd emmediately switch to it, if only it worked for me*. Yeah. But I don't like that patch. Then people came and said stuff like I _have_ to accept it because it fixes stuff I broke. Excuse me, but nobody can force me to sign off a patch that I am not completely convinced of. _Even_ if it turns out that a commit made by me broke something. Especially, if there's already another fix for the situation queued up in the development kernel. > I'm the one person who investigated the problem, wrote a > patch and sent it to the lkml. After lurking in #bcm-users > for a day, I saw quite a few users asking why the b43 driver > did not work for them, and the best answer they got, was > got read the linuxwireless.org. Are you sure they all were > just unable to upgrade the firmware? Yeah. Experience shows that. Read the archives. > And by the way, the bcm4311 and b44 combination is not > something I assembled just to piss you off. It's what HP puts > in their HP Compaq nx7300 laptops. They were like the > cheapest Core Duo laptops a year ago, and I'm sure they were > not exclusively made. So be it. And you guess what? We already sent a fix for those people upstream a long time ago. It is in 2.6.25. > > So let's > > apply a questionable fix for it that we don't understand. Hopefully > > that fixes it and doesn't break it again for somebody else... . > > > > I provided an alternative fix. In my very first email. > > Sorry, your fix does not work for my hardware. And you know it. Did you _ever_ even try it? http://linuxwireless.org/en/users/Download -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 7:27 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: > > > I have to say, after having observed multiple incidents around b43 in > > the past few months you are one of the worst driver maintainers i've > > ever seen on lkml: you are ignoring regressions, you are frequently > > insulting our testers and now you even have the gall to NAK a patch to > > The insults being? A few quotes, please. > If you really want to know, the "Because the new driver works, if you just set it up right." for me was clearly a hint that I'm just an other imcompetent user, who can't even follow the instructions from linuxwireless.org. And you knew that the new driver did no work with the bcm4311 chips, which is the sad thing. > > > _your own buggy driver code_ without providing an alternative fix. > > Kudos. > > How dare can you break my kernel, yeah... . We know that. > That my patches _fixed_ the kernel for thousands of people doesn't > matter. Not true at all. I my first and second emails, there was not a single word about who broke the driver. There were only the fix, and the explanation, why the fix is needed. I really appreciate the work done on the b43 driver, and I'd emmediately switch to it, if only it worked for me*. > What matters is the one person for whom it broke. I'm the one person who investigated the problem, wrote a patch and sent it to the lkml. After lurking in #bcm-users for a day, I saw quite a few users asking why the b43 driver did not work for them, and the best answer they got, was got read the linuxwireless.org. Are you sure they all were just unable to upgrade the firmware? And by the way, the bcm4311 and b44 combination is not something I assembled just to piss you off. It's what HP puts in their HP Compaq nx7300 laptops. They were like the cheapest Core Duo laptops a year ago, and I'm sure they were not exclusively made. > So let's > apply a questionable fix for it that we don't understand. Hopefully > that fixes it and doesn't break it again for somebody else... . > > I provided an alternative fix. In my very first email. Sorry, your fix does not work for my hardware. And you know it. > Ingo, if you know that this fix is right, then please sign it off > so we can apply it. > > -- > Greetings Michael. > > > -- > 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/ > -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 17:44:33 Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: > > > I have to say, after having observed multiple incidents around b43 in > > > the past few months you are one of the worst driver maintainers i've > > > ever seen on lkml: you are ignoring regressions, you are frequently > > > insulting our testers and now you even have the gall to NAK a patch to > > > > The insults being? A few quotes, please. > > " I'm tired of this "how dare can you break my kernel!?" bullshit. " > ... > " Blah. The people with a bcm4311 revision 1 wireless card plus a > bcm44xx ethernet card. You can count those people on two fingers. " > ... > > http://lkml.org/lkml/2008/2/23/3 Hm, maybe my fault and I don't know the english language enough, but these do not count as personal insults here where I live in Germany. Especially the second one is in no way an insult here. It merely tells you that the number of people having this issue is very low. I'm sorry if that sounded like insults. That wasn't my intention. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
* Michael Buesch <[EMAIL PROTECTED]> wrote: > On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: > > I have to say, after having observed multiple incidents around b43 in > > the past few months you are one of the worst driver maintainers i've > > ever seen on lkml: you are ignoring regressions, you are frequently > > insulting our testers and now you even have the gall to NAK a patch to > > The insults being? A few quotes, please. " I'm tired of this "how dare can you break my kernel!?" bullshit. " ... " Blah. The people with a bcm4311 revision 1 wireless card plus a bcm44xx ethernet card. You can count those people on two fingers. " ... http://lkml.org/lkml/2008/2/23/3 Ingo -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: > I have to say, after having observed multiple incidents around b43 in > the past few months you are one of the worst driver maintainers i've > ever seen on lkml: you are ignoring regressions, you are frequently > insulting our testers and now you even have the gall to NAK a patch to The insults being? A few quotes, please. > _your own buggy driver code_ without providing an alternative fix. > Kudos. How dare can you break my kernel, yeah... . We know that. That my patches _fixed_ the kernel for thousands of people doesn't matter. What matters is the one person for whom it broke. So let's apply a questionable fix for it that we don't understand. Hopefully that fixes it and doesn't break it again for somebody else... . I provided an alternative fix. In my very first email. Ingo, if you know that this fix is right, then please sign it off so we can apply it. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: > > * Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > If this is not a repgession, than I don't know what is. And if it is > > > a regression, it should be fixed at least in the 2.6.24.y series, do > > > you agree? > > > > No. Playing with kconfig SELECT is really _nothing_ for a -stable > > series. I am _not_ going to be responsible for any breakages. [...] > > well, i've reviewed this thread and it's pretty apparent to any outside > observer that you as a maintainer are ignoring Alexey Zaytsev's pretty > reasonable request for a fix. > > Alexey had a problem, he analyzed it, he found a fix which he tested, > and he even has offered to test anything you send his way: > > || I have provided a patch that I believe is trivial, that I have tested > || with all possible config option combinations I thought were possible, > || and that fixes the regression. If you have a reason to believe it is > || wrong, please say it, I won't be offended. If there is a problem with > || the patch, I'll gladly fix and resend it. > > that's about the most friendly tester attitude that is imaginable. > > but what were you able to make out of that positive attitude? The only > things i've seen you send his way were insults and general handwaving > about how his patch breaks stuff (without providing a _shred_ of > evidence). blah: > I have to say, after having observed multiple incidents around b43 in > the past few months you are one of the worst driver maintainers i've > ever seen on lkml: you are ignoring regressions, you are frequently > insulting our testers and now you even have the gall to NAK a patch to > _your own buggy driver code_ without providing an alternative fix. > Kudos. So I am forced to sign-off random patches people send to me? I explained why I do not. If you do not like that, please do sign it off. If you do think the patch is correct, please _do_ sign it off Ingo. This problem will fix itself by switching to b43 and dropping bcm43xx. _That_ is my way to fix the bug. I don't understand all the SELECT implications, so I'm not going to introduce more of them. Because if the next regression appears from I SELECT that I signed off goto blah; -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi,
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > > > So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
> > > > ("[B44]: port to native ssb support") fix the regression?
On Sat, Feb 23, 2008 at 2:17 PM, Alexey Zaytsev
<[EMAIL PROTECTED]> wrote:
> Yes, the problem was caused by this patch. With it reverted, I've got both
> ethernet
> and wifi working.
Michael, I am always glad to help out but I would much appreciate if
you could show some effort on debugging your own bugs in the future.
Perhaps you could now work with Alexey to fix it?
--
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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 2:57 PM, Pekka J Enberg <[EMAIL PROTECTED]> wrote:
> Hi Alexey,
>
>
> On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
>
> > > So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
> > > ("[B44]: port to native ssb support") fix the regression?
> > >
>
>
> On Sat, 23 Feb 2008, Alexey Zaytsev wrote:
> > Compiling it right now.
> >
> > I'm sure it fixes the problem, but I don't feel like we should revert
> > it. I can't
> > be sure it won't cause any other problems, and anyway, this does not look
> > right a solution. Any other driver (rightfully) requiring the SSB_HOST
> would
> > then also break the bcm43xx driver.
> >
> > I'll send an simplified patch in a few minutes.
>
> The point here is that it's Michael's patch and I don't want to start
> blaming anyone until you've verified it actually broke your setup. And if
> the problem was actually caused by that patch, Michael needs to either ACK
> your patch or fix it himself.
Yes, the problem was caused by this patch. With it reverted, I've got
both ethernet
and wifi working.
>
> Pekka
>
--
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: bcm43xx regression in 2.6.24 (with patch)
Hi Alexey,
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
> > ("[B44]: port to native ssb support") fix the regression?
> >
On Sat, 23 Feb 2008, Alexey Zaytsev wrote:
> Compiling it right now.
>
> I'm sure it fixes the problem, but I don't feel like we should revert
> it. I can't
> be sure it won't cause any other problems, and anyway, this does not look
> right a solution. Any other driver (rightfully) requiring the SSB_HOST would
> then also break the bcm43xx driver.
>
> I'll send an simplified patch in a few minutes.
The point here is that it's Michael's patch and I don't want to start
blaming anyone until you've verified it actually broke your setup. And if
the problem was actually caused by that patch, Michael needs to either ACK
your patch or fix it himself.
Pekka
--
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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev
> <[EMAIL PROTECTED]> wrote:
> > The problem is not with enabling both b43 and bcm43xx (will, whis won't
> work
> > anyway, and there is no chance fixing it). The problem is with enabling
> the
> > bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
> > wrongly autosolects some config options that prevent the bcm43xx
> > driver from loading, so I'm left with either no wifi or no ethenet.
>
> So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
> ("[B44]: port to native ssb support") fix the regression?
>
Compiling it right now.
I'm sure it fixes the problem, but I don't feel like we should revert
it. I can't
be sure it won't cause any other problems, and anyway, this does not look
right a solution. Any other driver (rightfully) requiring the SSB_HOST would
then also break the bcm43xx driver.
I'll send an simplified patch in a few minutes.
--
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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev
<[EMAIL PROTECTED]> wrote:
> The problem is not with enabling both b43 and bcm43xx (will, whis won't work
> anyway, and there is no chance fixing it). The problem is with enabling the
> bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then
> wrongly autosolects some config options that prevent the bcm43xx
> driver from loading, so I'm left with either no wifi or no ethenet.
So does reverting commit 753f492093da7a40141bfe083073400f518f4c68
("[B44]: port to native ssb support") fix the regression?
--
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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 2:24 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > > * Pekka Enberg <[EMAIL PROTECTED]> wrote: > > > Agreed. Alexey, did you identify a specific git commit that caused the > > regression? Can we just revert that from 2.6.24? Michael, even if > > _you're_ planning to remove bcm43xx we must not let it regress until > > it's gone. > > btw., if the best answer is: "do not enable b43 and bcm43xx at once in > the .config because we messed up the dependencies and fixing it in > 2.6.24-stable is unfortunately too risky", then that's a perfectly fine > answer for -stable. Then the fix would be to exclude each other in the > Kconfig space (which is not risky). But just ignoring bugreports and > NAK-ing a fix is not a valid answer. > The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. > Ingo > > > -- > 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/ > -- 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: bcm43xx regression in 2.6.24 (with patch)
* Pekka Enberg <[EMAIL PROTECTED]> wrote: > Agreed. Alexey, did you identify a specific git commit that caused the > regression? Can we just revert that from 2.6.24? Michael, even if > _you're_ planning to remove bcm43xx we must not let it regress until > it's gone. btw., if the best answer is: "do not enable b43 and bcm43xx at once in the .config because we messed up the dependencies and fixing it in 2.6.24-stable is unfortunately too risky", then that's a perfectly fine answer for -stable. Then the fix would be to exclude each other in the Kconfig space (which is not risky). But just ignoring bugreports and NAK-ing a fix is not a valid answer. Ingo -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 1:07 PM, Ingo Molnar <[EMAIL PROTECTED]> wrote: > I have to say, after having observed multiple incidents around b43 in > the past few months you are one of the worst driver maintainers i've > ever seen on lkml: you are ignoring regressions, you are frequently > insulting our testers and now you even have the gall to NAK a patch to > _your own buggy driver code_ without providing an alternative fix. > Kudos. Agreed. Alexey, did you identify a specific git commit that caused the regression? Can we just revert that from 2.6.24? Michael, even if _you're_ planning to remove bcm43xx we must not let it regress until it's gone. -- 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: bcm43xx regression in 2.6.24 (with patch)
* Michael Buesch <[EMAIL PROTECTED]> wrote: > > If this is not a repgession, than I don't know what is. And if it is > > a regression, it should be fixed at least in the 2.6.24.y series, do > > you agree? > > No. Playing with kconfig SELECT is really _nothing_ for a -stable > series. I am _not_ going to be responsible for any breakages. [...] well, i've reviewed this thread and it's pretty apparent to any outside observer that you as a maintainer are ignoring Alexey Zaytsev's pretty reasonable request for a fix. Alexey had a problem, he analyzed it, he found a fix which he tested, and he even has offered to test anything you send his way: || I have provided a patch that I believe is trivial, that I have tested || with all possible config option combinations I thought were possible, || and that fixes the regression. If you have a reason to believe it is || wrong, please say it, I won't be offended. If there is a problem with || the patch, I'll gladly fix and resend it. that's about the most friendly tester attitude that is imaginable. but what were you able to make out of that positive attitude? The only things i've seen you send his way were insults and general handwaving about how his patch breaks stuff (without providing a _shred_ of evidence). I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to _your own buggy driver code_ without providing an alternative fix. Kudos. Ingo -- 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: bcm43xx regression in 2.6.24 (with patch)
* Michael Buesch [EMAIL PROTECTED] wrote: If this is not a repgession, than I don't know what is. And if it is a regression, it should be fixed at least in the 2.6.24.y series, do you agree? No. Playing with kconfig SELECT is really _nothing_ for a -stable series. I am _not_ going to be responsible for any breakages. [...] well, i've reviewed this thread and it's pretty apparent to any outside observer that you as a maintainer are ignoring Alexey Zaytsev's pretty reasonable request for a fix. Alexey had a problem, he analyzed it, he found a fix which he tested, and he even has offered to test anything you send his way: || I have provided a patch that I believe is trivial, that I have tested || with all possible config option combinations I thought were possible, || and that fixes the regression. If you have a reason to believe it is || wrong, please say it, I won't be offended. If there is a problem with || the patch, I'll gladly fix and resend it. that's about the most friendly tester attitude that is imaginable. but what were you able to make out of that positive attitude? The only things i've seen you send his way were insults and general handwaving about how his patch breaks stuff (without providing a _shred_ of evidence). I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to _your own buggy driver code_ without providing an alternative fix. Kudos. Ingo -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 1:07 PM, Ingo Molnar [EMAIL PROTECTED] wrote: I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to _your own buggy driver code_ without providing an alternative fix. Kudos. Agreed. Alexey, did you identify a specific git commit that caused the regression? Can we just revert that from 2.6.24? Michael, even if _you're_ planning to remove bcm43xx we must not let it regress until it's gone. -- 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: bcm43xx regression in 2.6.24 (with patch)
* Pekka Enberg [EMAIL PROTECTED] wrote: Agreed. Alexey, did you identify a specific git commit that caused the regression? Can we just revert that from 2.6.24? Michael, even if _you're_ planning to remove bcm43xx we must not let it regress until it's gone. btw., if the best answer is: do not enable b43 and bcm43xx at once in the .config because we messed up the dependencies and fixing it in 2.6.24-stable is unfortunately too risky, then that's a perfectly fine answer for -stable. Then the fix would be to exclude each other in the Kconfig space (which is not risky). But just ignoring bugreports and NAK-ing a fix is not a valid answer. Ingo -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 2:24 PM, Ingo Molnar [EMAIL PROTECTED] wrote: * Pekka Enberg [EMAIL PROTECTED] wrote: Agreed. Alexey, did you identify a specific git commit that caused the regression? Can we just revert that from 2.6.24? Michael, even if _you're_ planning to remove bcm43xx we must not let it regress until it's gone. btw., if the best answer is: do not enable b43 and bcm43xx at once in the .config because we messed up the dependencies and fixing it in 2.6.24-stable is unfortunately too risky, then that's a perfectly fine answer for -stable. Then the fix would be to exclude each other in the Kconfig space (which is not risky). But just ignoring bugreports and NAK-ing a fix is not a valid answer. The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. Ingo -- 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/ -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev [EMAIL PROTECTED] wrote: The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. So does reverting commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) fix the regression? -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote: On Sat, Feb 23, 2008 at 1:32 PM, Alexey Zaytsev [EMAIL PROTECTED] wrote: The problem is not with enabling both b43 and bcm43xx (will, whis won't work anyway, and there is no chance fixing it). The problem is with enabling the bcm43xx wifi driver and the b44 Ethernet driver. The ethernet driver then wrongly autosolects some config options that prevent the bcm43xx driver from loading, so I'm left with either no wifi or no ethenet. So does reverting commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) fix the regression? Compiling it right now. I'm sure it fixes the problem, but I don't feel like we should revert it. I can't be sure it won't cause any other problems, and anyway, this does not look right a solution. Any other driver (rightfully) requiring the SSB_HOST would then also break the bcm43xx driver. I'll send an simplified patch in a few minutes. -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi Alexey, On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote: So does reverting commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) fix the regression? On Sat, 23 Feb 2008, Alexey Zaytsev wrote: Compiling it right now. I'm sure it fixes the problem, but I don't feel like we should revert it. I can't be sure it won't cause any other problems, and anyway, this does not look right a solution. Any other driver (rightfully) requiring the SSB_HOST would then also break the bcm43xx driver. I'll send an simplified patch in a few minutes. The point here is that it's Michael's patch and I don't want to start blaming anyone until you've verified it actually broke your setup. And if the problem was actually caused by that patch, Michael needs to either ACK your patch or fix it himself. Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 2:57 PM, Pekka J Enberg [EMAIL PROTECTED] wrote: Hi Alexey, On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote: So does reverting commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) fix the regression? On Sat, 23 Feb 2008, Alexey Zaytsev wrote: Compiling it right now. I'm sure it fixes the problem, but I don't feel like we should revert it. I can't be sure it won't cause any other problems, and anyway, this does not look right a solution. Any other driver (rightfully) requiring the SSB_HOST would then also break the bcm43xx driver. I'll send an simplified patch in a few minutes. The point here is that it's Michael's patch and I don't want to start blaming anyone until you've verified it actually broke your setup. And if the problem was actually caused by that patch, Michael needs to either ACK your patch or fix it himself. Yes, the problem was caused by this patch. With it reverted, I've got both ethernet and wifi working. Pekka -- 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: bcm43xx regression in 2.6.24 (with patch)
Hi, On Sat, Feb 23, 2008 at 2:37 PM, Pekka Enberg [EMAIL PROTECTED] wrote: So does reverting commit 753f492093da7a40141bfe083073400f518f4c68 ([B44]: port to native ssb support) fix the regression? On Sat, Feb 23, 2008 at 2:17 PM, Alexey Zaytsev [EMAIL PROTECTED] wrote: Yes, the problem was caused by this patch. With it reverted, I've got both ethernet and wifi working. Michael, I am always glad to help out but I would much appreciate if you could show some effort on debugging your own bugs in the future. Perhaps you could now work with Alexey to fix it? -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: If this is not a repgession, than I don't know what is. And if it is a regression, it should be fixed at least in the 2.6.24.y series, do you agree? No. Playing with kconfig SELECT is really _nothing_ for a -stable series. I am _not_ going to be responsible for any breakages. [...] well, i've reviewed this thread and it's pretty apparent to any outside observer that you as a maintainer are ignoring Alexey Zaytsev's pretty reasonable request for a fix. Alexey had a problem, he analyzed it, he found a fix which he tested, and he even has offered to test anything you send his way: || I have provided a patch that I believe is trivial, that I have tested || with all possible config option combinations I thought were possible, || and that fixes the regression. If you have a reason to believe it is || wrong, please say it, I won't be offended. If there is a problem with || the patch, I'll gladly fix and resend it. that's about the most friendly tester attitude that is imaginable. but what were you able to make out of that positive attitude? The only things i've seen you send his way were insults and general handwaving about how his patch breaks stuff (without providing a _shred_ of evidence). blah: I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to _your own buggy driver code_ without providing an alternative fix. Kudos. So I am forced to sign-off random patches people send to me? I explained why I do not. If you do not like that, please do sign it off. If you do think the patch is correct, please _do_ sign it off Ingo. This problem will fix itself by switching to b43 and dropping bcm43xx. _That_ is my way to fix the bug. I don't understand all the SELECT implications, so I'm not going to introduce more of them. Because if the next regression appears from I SELECT that I signed off goto blah; -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to The insults being? A few quotes, please. _your own buggy driver code_ without providing an alternative fix. Kudos. How dare can you break my kernel, yeah... . We know that. That my patches _fixed_ the kernel for thousands of people doesn't matter. What matters is the one person for whom it broke. So let's apply a questionable fix for it that we don't understand. Hopefully that fixes it and doesn't break it again for somebody else... . I provided an alternative fix. In my very first email. Ingo, if you know that this fix is right, then please sign it off so we can apply it. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
* Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to The insults being? A few quotes, please. I'm tired of this how dare can you break my kernel!? bullshit. ... Blah. The people with a bcm4311 revision 1 wireless card plus a bcm44xx ethernet card. You can count those people on two fingers. ... http://lkml.org/lkml/2008/2/23/3 Ingo -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 17:44:33 Ingo Molnar wrote: * Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to The insults being? A few quotes, please. I'm tired of this how dare can you break my kernel!? bullshit. ... Blah. The people with a bcm4311 revision 1 wireless card plus a bcm44xx ethernet card. You can count those people on two fingers. ... http://lkml.org/lkml/2008/2/23/3 Hm, maybe my fault and I don't know the english language enough, but these do not count as personal insults here where I live in Germany. Especially the second one is in no way an insult here. It merely tells you that the number of people having this issue is very low. I'm sorry if that sounded like insults. That wasn't my intention. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 7:27 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Saturday 23 February 2008 12:07:51 Ingo Molnar wrote: I have to say, after having observed multiple incidents around b43 in the past few months you are one of the worst driver maintainers i've ever seen on lkml: you are ignoring regressions, you are frequently insulting our testers and now you even have the gall to NAK a patch to The insults being? A few quotes, please. If you really want to know, the Because the new driver works, if you just set it up right. for me was clearly a hint that I'm just an other imcompetent user, who can't even follow the instructions from linuxwireless.org. And you knew that the new driver did no work with the bcm4311 chips, which is the sad thing. _your own buggy driver code_ without providing an alternative fix. Kudos. How dare can you break my kernel, yeah... . We know that. That my patches _fixed_ the kernel for thousands of people doesn't matter. Not true at all. I my first and second emails, there was not a single word about who broke the driver. There were only the fix, and the explanation, why the fix is needed. I really appreciate the work done on the b43 driver, and I'd emmediately switch to it, if only it worked for me*. What matters is the one person for whom it broke. I'm the one person who investigated the problem, wrote a patch and sent it to the lkml. After lurking in #bcm-users for a day, I saw quite a few users asking why the b43 driver did not work for them, and the best answer they got, was got read the linuxwireless.org. Are you sure they all were just unable to upgrade the firmware? And by the way, the bcm4311 and b44 combination is not something I assembled just to piss you off. It's what HP puts in their HP Compaq nx7300 laptops. They were like the cheapest Core Duo laptops a year ago, and I'm sure they were not exclusively made. So let's apply a questionable fix for it that we don't understand. Hopefully that fixes it and doesn't break it again for somebody else... . I provided an alternative fix. In my very first email. Sorry, your fix does not work for my hardware. And you know it. Ingo, if you know that this fix is right, then please sign it off so we can apply it. -- Greetings Michael. -- 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/ -- 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: bcm43xx regression in 2.6.24 (with patch)
On Saturday 23 February 2008 22:32:46 Alexey Zaytsev wrote: The insults being? A few quotes, please. If you really want to know, the Because the new driver works, if you just set it up right. for me was clearly a hint that I'm just an other imcompetent user, who can't even follow the instructions from linuxwireless.org. Well. That's 99% of all bugreports I receive. You will understand that I won't explain the same crap that's written on linuxwireless.org over and over 20 times each day to random people. And yes, you belong to the group of my random people, as I don't remember your name from the top of my head. So in 99% of the cases the user did something wrong. But I still don't see the insult. And you knew that the new driver did no work with the bcm4311 chips, which is the sad thing. That is not true. It doesn't work with exactly _one_ revision of the bcm4311 card. And that is already fixed in 2.6.25. I'd like to have that in .24-stable, too, but I guess it's too big. It changes some parts of the DMA engine code. Not true at all. I my first and second emails, there was not a single word about who broke the driver. There were only the fix, and the explanation, why the fix is needed. I really appreciate the work done on the b43 driver, and I'd emmediately switch to it, if only it worked for me*. Yeah. But I don't like that patch. Then people came and said stuff like I _have_ to accept it because it fixes stuff I broke. Excuse me, but nobody can force me to sign off a patch that I am not completely convinced of. _Even_ if it turns out that a commit made by me broke something. Especially, if there's already another fix for the situation queued up in the development kernel. I'm the one person who investigated the problem, wrote a patch and sent it to the lkml. After lurking in #bcm-users for a day, I saw quite a few users asking why the b43 driver did not work for them, and the best answer they got, was got read the linuxwireless.org. Are you sure they all were just unable to upgrade the firmware? Yeah. Experience shows that. Read the archives. And by the way, the bcm4311 and b44 combination is not something I assembled just to piss you off. It's what HP puts in their HP Compaq nx7300 laptops. They were like the cheapest Core Duo laptops a year ago, and I'm sure they were not exclusively made. So be it. And you guess what? We already sent a fix for those people upstream a long time ago. It is in 2.6.25. So let's apply a questionable fix for it that we don't understand. Hopefully that fixes it and doesn't break it again for somebody else... . I provided an alternative fix. In my very first email. Sorry, your fix does not work for my hardware. And you know it. Did you _ever_ even try it? http://linuxwireless.org/en/users/Download -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008, Alexey Zaytsev wrote: > Well, it looks like Michael is not the bcm43xx maintaner. I sent the > patch to him, > because it was his code that broke the driver, and I thought it would > be easy for him to review my patch, as it touches his code. See? I'm tired of this "how dare can you break my kernel!?" bullshit. That's exactly the reason why I NACKed this patch. I do _not_ understand the KConfig SELECT logic. And I do think almost nobody does understand how that all works together. In the past people came with similiar patches like yours that looked obviously OK. They said sentences like "it is trivial to get the SELECT logics right". But it turned out they were wrong and it introduced other regressions that I was made responsible for. SELECT is _extremely_ difficult to get right, as it completely ignores dependencies. See all this FOOBAR_POSSIBLE select logic that we use in SSB to get SELECT working correctly with dependencies. So my solution for this particular breakage you are seeing here is to wait for the bcm43xx removal, which will happen soon. That will fix it and will have almost zero chance to introduce new bugs. > Well, if you read my first email, that is exactly what I intended to > do, but even if > Michael would be able to fix the b43 driver to work with my hardware, the code > will only show up in 2.6.25, leaving some 2.6.24 users with broken > wifi. So I thought Blah. The people with a bcm4311 revision 1 wireless card plus a bcm44xx ethernet card. You can count those people on two fingers. > it would be a good thing to add my simple fix that enabled the old driver to > the > -stable tree, so that we could have working wifi soon. > > This is still my intension, I'll resend to the proper maintainters. Ok thanks. We'll see if it really was a simple fix then. If it turns out to break something you will get mail. :) You can send this patch to a netdev maintainer or the wireless maintainer. Maybe one of those will sign it off. Good luck. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 1:12 AM, Greg KH <[EMAIL PROTECTED]> wrote: > > On Fri, Feb 22, 2008 at 11:38:34PM +0300, Alexey Zaytsev wrote: > > On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: > > > > > It is not my problem, if you refuse to use b43. > > > > > You also still refuse to tell me details about your card and _what_ > > > > > does not work. I do own lots of different card and they > > > > > all work fine with b43. There's one exception, the 4311 rev 3 (or > something, > > > > > don't quite remember). But patches are available and will ship in > 2.6.25. > > > > > bcm43xx won't get removed until that shipped. > > > > > > > > Yes, it's a 4311 rev 01, but I'm probably was just too lame to > upgrade the > > > > firmware or something. :E > > > > > > > > I really don't get it, what is going on here? You state that the new > b32 driver > > > > has problems on some hardware, where the old bcm43xx driver just > works. > > > > And at the same time, you are surprised that I "refuse" to use the > b43 driver > > > > and push patches for the bcm43xx driver you broke... Oh, really, why?! > > > > > > So, please find someone who will sign-off your patch. I won't. > > > What's so hard to understand about that? Do I _have_ to sign off all > patches > > > random people send to me? > > > I do _not_ want to be made responsible for that patch by signing it off. > > > It is as simple as that. > > > And I officially do not care about bcm43xx since a year and a half > anymore. > > > So why should I ACK it or sign it off? > > > > > > > I thought that there was a rule that if you break something in the kernel, > you > > normally would be the one who fixes things up. Sorry, it looks I was wrong. > > > > I'll resend the patch directly to Greg KH and Jeff Garzik for -stable and > 2.6.25 > > inclusion. > > One of the rules for the -stable tree is that the patch is accepted by > the maintainer and it is already in the upstream kernel version. Both > of these requirements do not seem to be met here. Well, it looks like Michael is not the bcm43xx maintaner. I sent the patch to him, because it was his code that broke the driver, and I thought it would be easy for him to review my patch, as it touches his code. I'll resend the patch to the proper maintainers now. > > I suggest you work _with_ Michael instead of against him to try to > determine why your device doesn't work properly with the recommended > driver. Well, if you read my first email, that is exactly what I intended to do, but even if Michael would be able to fix the b43 driver to work with my hardware, the code will only show up in 2.6.25, leaving some 2.6.24 users with broken wifi. So I thought it would be a good thing to add my simple fix that enabled the old driver to the -stable tree, so that we could have working wifi soon. This is still my intension, I'll resend to the proper maintainters. > > thanks, > > greg k-h > -- 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: bcm43xx regression in 2.6.24 (with patch)
On Fri, Feb 22, 2008 at 11:38:34PM +0300, Alexey Zaytsev wrote: > On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: > > > > It is not my problem, if you refuse to use b43. > > > > You also still refuse to tell me details about your card and _what_ > > > > does not work. I do own lots of different card and they > > > > all work fine with b43. There's one exception, the 4311 rev 3 (or > > something, > > > > don't quite remember). But patches are available and will ship in > > 2.6.25. > > > > bcm43xx won't get removed until that shipped. > > > > > > Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade > > the > > > firmware or something. :E > > > > > > I really don't get it, what is going on here? You state that the new b32 > > driver > > > has problems on some hardware, where the old bcm43xx driver just works. > > > And at the same time, you are surprised that I "refuse" to use the b43 > > driver > > > and push patches for the bcm43xx driver you broke... Oh, really, why?! > > > > So, please find someone who will sign-off your patch. I won't. > > What's so hard to understand about that? Do I _have_ to sign off all > > patches > > random people send to me? > > I do _not_ want to be made responsible for that patch by signing it off. > > It is as simple as that. > > And I officially do not care about bcm43xx since a year and a half anymore. > > So why should I ACK it or sign it off? > > > > I thought that there was a rule that if you break something in the kernel, you > normally would be the one who fixes things up. Sorry, it looks I was wrong. > > I'll resend the patch directly to Greg KH and Jeff Garzik for -stable and > 2.6.25 > inclusion. One of the rules for the -stable tree is that the patch is accepted by the maintainer and it is already in the upstream kernel version. Both of these requirements do not seem to be met here. I suggest you work _with_ Michael instead of against him to try to determine why your device doesn't work properly with the recommended driver. thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
On Fri, Feb 22, 2008 at 06:56:14PM +0100, Michael Buesch wrote: > On Friday 22 February 2008 18:51:32 Gabriel C wrote: > > > I'm not going to play these kconfig SELECT tricks anymore. > > > > Fix it different then. > > Please do so. > > > Yes it is but that is still not a valid reason to NACK that patch , I'm > > sorry. > > NACK means I (being the maintainer of the modified code) won't > sign-off this patch. Nothing more or less. If some upstream maintainer > decides to bypass me and apply the patch nevertheless is not of > my business. But I will not sign-off or ack this patch. As the maintainer will not accept this, I'm not going to take it for the -stable tree either, sorry. thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: > > > It is not my problem, if you refuse to use b43. > > > You also still refuse to tell me details about your card and _what_ > > > does not work. I do own lots of different card and they > > > all work fine with b43. There's one exception, the 4311 rev 3 (or > something, > > > don't quite remember). But patches are available and will ship in > 2.6.25. > > > bcm43xx won't get removed until that shipped. > > > > Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the > > firmware or something. :E > > > > I really don't get it, what is going on here? You state that the new b32 > driver > > has problems on some hardware, where the old bcm43xx driver just works. > > And at the same time, you are surprised that I "refuse" to use the b43 > driver > > and push patches for the bcm43xx driver you broke... Oh, really, why?! > > So, please find someone who will sign-off your patch. I won't. > What's so hard to understand about that? Do I _have_ to sign off all patches > random people send to me? > I do _not_ want to be made responsible for that patch by signing it off. > It is as simple as that. > And I officially do not care about bcm43xx since a year and a half anymore. > So why should I ACK it or sign it off? > I thought that there was a rule that if you break something in the kernel, you normally would be the one who fixes things up. Sorry, it looks I was wrong. I'll resend the patch directly to Greg KH and Jeff Garzik for -stable and 2.6.25 inclusion. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: > > It is not my problem, if you refuse to use b43. > > You also still refuse to tell me details about your card and _what_ > > does not work. I do own lots of different card and they > > all work fine with b43. There's one exception, the 4311 rev 3 (or > > something, > > don't quite remember). But patches are available and will ship in 2.6.25. > > bcm43xx won't get removed until that shipped. > > Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the > firmware or something. :E > > I really don't get it, what is going on here? You state that the new b32 > driver > has problems on some hardware, where the old bcm43xx driver just works. > And at the same time, you are surprised that I "refuse" to use the b43 driver > and push patches for the bcm43xx driver you broke... Oh, really, why?! So, please find someone who will sign-off your patch. I won't. What's so hard to understand about that? Do I _have_ to sign off all patches random people send to me? I do _not_ want to be made responsible for that patch by signing it off. It is as simple as that. And I officially do not care about bcm43xx since a year and a half anymore. So why should I ACK it or sign it off? -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
[replying from my non-work account] On Fri, Feb 22, 2008 at 8:48 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > On Friday 22 February 2008 19:10:39 Alexey Zaytsev wrote: > > Sorry, I don't get it. You are going to remove the (somehow) > > working driver, while there are known problems with the new > > one? Why? > > Because the new driver works, if you just set it up right. > Until now every "breakage" was just a usage error. > > > > And please look at the problem from a user's view point. I'm > > happily using the 2.6.23 kernel. The bcm43xx driver is the > > only one available. And it works somehow (well, no s2ram). > > b43 supports s2ram and s2disk. > > > > If this is not a repgession, than I don't know what is. > > And if it is a regression, it should be fixed at least in the > > 2.6.24.y series, do you agree? > > No. Playing with kconfig SELECT is really _nothing_ for a -stable > series. I am _not_ going to be responsible for any > breakages. And using SELECT _does_ break things. We had dozens of bugs > until all the damn dependencies were right. Even "Obviously Correct (tm)" > changes to SELECT _do_ break on weird configurations. > See the bcm43xx mail archives for examples. > Well, someone obviously played with the SELECTs, and broke the bcm43xx driver. Now I've got a patch that I believe gets the SELECTs right and fixes the driver, so what is wrong? > If you need that patch for some reason, please apply it locally. > The problem will automatically get fixed when bcm43xx goes away, soon. > > > > I have provided a patch that I believe is trivial, that I have > > tested with all possible config option combinations I thought > > were possible, and that fixes the regression. If you have a > > reason to believe it is wrong, please say it, I won't be > > offended. If there is a problem with the patch, I'll gladly > > fix and resend it. > > > > This Nack leaves me with one option - to switch back to 2.6.23. > > Sorry, no testing, probably more bugs not found in 2.6.24. ;( > > It is not my problem, if you refuse to use b43. > You also still refuse to tell me details about your card and _what_ > does not work. I do own lots of different card and they > all work fine with b43. There's one exception, the 4311 rev 3 (or something, > don't quite remember). But patches are available and will ship in 2.6.25. > bcm43xx won't get removed until that shipped. Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the firmware or something. :E I really don't get it, what is going on here? You state that the new b32 driver has problems on some hardware, where the old bcm43xx driver just works. And at the same time, you are surprised that I "refuse" to use the b43 driver and push patches for the bcm43xx driver you broke... Oh, really, why?! -- 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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 18:51:32 Gabriel C wrote: > > I'm not going to play these kconfig SELECT tricks anymore. > > Fix it different then. Please do so. > Yes it is but that is still not a valid reason to NACK that patch , I'm sorry. NACK means I (being the maintainer of the modified code) won't sign-off this patch. Nothing more or less. If some upstream maintainer decides to bypass me and apply the patch nevertheless is not of my business. But I will not sign-off or ack this patch. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
Michael Buesch wrote:
> On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
>> Hello.
>>
>> The bcm43xx driver won't work any more, if the b44 Ethernet
>> driver is enabled. This happens because the b44 driver
>> needlessly enables the b43_pci_bridge code, which claims
>> the same pci ids as the bcm43xx driver. The b43_pci_bridge
>> code is needed for the b43{legacy} drivers, but for the
>> b44, only the "ssb pci core" is needed.
>>
>> This patch separates the ssb b43 pci bridge and the ssb pci
>> core config options and enables only the needed ones.
>
> Nack. Switch to b43. bcm43xx is going to be removed anyway.
Since when this is a valid reason to NACK a patch which fixes
a regression in the 'stable' kernel ?
Probably you may want to ask first whatever 'b43' works for Alexey ?
and most probably the answer will be 'no' because that is the only reason
one would want to fix the *old* one when *both* drivers are enabled.
Really 'Switch to foo' and 'foo_old will be removed sometimes'
is not a 'valid' reason to NACK anything as long you 'have foo and foo_old'
*supported* in that kernel.
> I'm not going to play these kconfig SELECT tricks anymore.
Fix it different then.
> We had _lots_ of bugs there. People submitted patches that
> obviously looked OK and still they turned out to break
> some dependencies. KConfig SELECT is a feature from hell.
>
Yes it is but that is still not a valid reason to NACK that patch , I'm sorry.
Regards,
Gabriel
--
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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 19:10:39 Alexey Zaytsev wrote: > Sorry, I don't get it. You are going to remove the (somehow) > working driver, while there are known problems with the new > one? Why? Because the new driver works, if you just set it up right. Until now every "breakage" was just a usage error. > And please look at the problem from a user's view point. I'm > happily using the 2.6.23 kernel. The bcm43xx driver is the > only one available. And it works somehow (well, no s2ram). b43 supports s2ram and s2disk. > If this is not a repgession, than I don't know what is. > And if it is a regression, it should be fixed at least in the > 2.6.24.y series, do you agree? No. Playing with kconfig SELECT is really _nothing_ for a -stable series. I am _not_ going to be responsible for any breakages. And using SELECT _does_ break things. We had dozens of bugs until all the damn dependencies were right. Even "Obviously Correct (tm)" changes to SELECT _do_ break on weird configurations. See the bcm43xx mail archives for examples. If you need that patch for some reason, please apply it locally. The problem will automatically get fixed when bcm43xx goes away, soon. > I have provided a patch that I believe is trivial, that I have > tested with all possible config option combinations I thought > were possible, and that fixes the regression. If you have a > reason to believe it is wrong, please say it, I won't be > offended. If there is a problem with the patch, I'll gladly > fix and resend it. > > This Nack leaves me with one option - to switch back to 2.6.23. > Sorry, no testing, probably more bugs not found in 2.6.24. ;( It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
Michael Buesch wrote:
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
Hello.
The bcm43xx driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The b43_pci_bridge
code is needed for the b43{legacy} drivers, but for the
b44, only the "ssb pci core" is needed.
This patch separates the ssb b43 pci bridge and the ssb pci
core config options and enables only the needed ones.
Nack. Switch to b43. bcm43xx is going to be removed anyway.
I'm not going to play these kconfig SELECT tricks anymore.
We had _lots_ of bugs there. People submitted patches that
obviously looked OK and still they turned out to break
some dependencies. KConfig SELECT is a feature from hell.
Sorry, I don't get it. You are going to remove the (somehow)
working driver, while there are known problems with the new
one? Why? To me it sounds like _breaking old but working code_
to get _more bug reports on the new code_. But, what was the
goal providing users with working drivers, or getting more
bug reports?
And please look at the problem from a user's view point. I'm
happily using the 2.6.23 kernel. The bcm43xx driver is the
only one available. And it works somehow (well, no s2ram).
Now I upgrade to the 2.6.24 kernel. I see there is a new
b43 driver and try it.
For some reason it does not work, even after I follow the
firmware upgrading instructions. Not a big deal, I clearly
understand that you have to work with reverse-engineered
specs and even with good specs, bugs happen, no problem.
I'll try to debug it in the weekend and maybe will send a
bug report or patch.
But right now I have other business, sorry. The problem is,
now also the old (but not now marked as deprecated) driver
stops working.
If this is not a repgession, than I don't know what is.
And if it is a regression, it should be fixed at least in the
2.6.24.y series, do you agree?
I have provided a patch that I believe is trivial, that I have
tested with all possible config option combinations I thought
were possible, and that fixes the regression. If you have a
reason to believe it is wrong, please say it, I won't be
offended. If there is a problem with the patch, I'll gladly
fix and resend it.
This Nack leaves me with one option - to switch back to 2.6.23.
Sorry, no testing, probably more bugs not found in 2.6.24. ;(
--
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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
>
> Hello.
>
> The bcm43xx driver won't work any more, if the b44 Ethernet
> driver is enabled. This happens because the b44 driver
> needlessly enables the b43_pci_bridge code, which claims
> the same pci ids as the bcm43xx driver. The b43_pci_bridge
> code is needed for the b43{legacy} drivers, but for the
> b44, only the "ssb pci core" is needed.
>
> This patch separates the ssb b43 pci bridge and the ssb pci
> core config options and enables only the needed ones.
Nack. Switch to b43. bcm43xx is going to be removed anyway.
I'm not going to play these kconfig SELECT tricks anymore.
We had _lots_ of bugs there. People submitted patches that
obviously looked OK and still they turned out to break
some dependencies. KConfig SELECT is a feature from hell.
--
Greetings Michael.
--
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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
Hello.
The bcm43xx driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The b43_pci_bridge
code is needed for the b43{legacy} drivers, but for the
b44, only the ssb pci core is needed.
This patch separates the ssb b43 pci bridge and the ssb pci
core config options and enables only the needed ones.
Nack. Switch to b43. bcm43xx is going to be removed anyway.
I'm not going to play these kconfig SELECT tricks anymore.
We had _lots_ of bugs there. People submitted patches that
obviously looked OK and still they turned out to break
some dependencies. KConfig SELECT is a feature from hell.
--
Greetings Michael.
--
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: bcm43xx regression in 2.6.24 (with patch)
Michael Buesch wrote:
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
Hello.
The bcm43xx driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The b43_pci_bridge
code is needed for the b43{legacy} drivers, but for the
b44, only the ssb pci core is needed.
This patch separates the ssb b43 pci bridge and the ssb pci
core config options and enables only the needed ones.
Nack. Switch to b43. bcm43xx is going to be removed anyway.
I'm not going to play these kconfig SELECT tricks anymore.
We had _lots_ of bugs there. People submitted patches that
obviously looked OK and still they turned out to break
some dependencies. KConfig SELECT is a feature from hell.
Sorry, I don't get it. You are going to remove the (somehow)
working driver, while there are known problems with the new
one? Why? To me it sounds like _breaking old but working code_
to get _more bug reports on the new code_. But, what was the
goal providing users with working drivers, or getting more
bug reports?
And please look at the problem from a user's view point. I'm
happily using the 2.6.23 kernel. The bcm43xx driver is the
only one available. And it works somehow (well, no s2ram).
Now I upgrade to the 2.6.24 kernel. I see there is a new
b43 driver and try it.
For some reason it does not work, even after I follow the
firmware upgrading instructions. Not a big deal, I clearly
understand that you have to work with reverse-engineered
specs and even with good specs, bugs happen, no problem.
I'll try to debug it in the weekend and maybe will send a
bug report or patch.
But right now I have other business, sorry. The problem is,
now also the old (but not now marked as deprecated) driver
stops working.
If this is not a repgession, than I don't know what is.
And if it is a regression, it should be fixed at least in the
2.6.24.y series, do you agree?
I have provided a patch that I believe is trivial, that I have
tested with all possible config option combinations I thought
were possible, and that fixes the regression. If you have a
reason to believe it is wrong, please say it, I won't be
offended. If there is a problem with the patch, I'll gladly
fix and resend it.
This Nack leaves me with one option - to switch back to 2.6.23.
Sorry, no testing, probably more bugs not found in 2.6.24. ;(
--
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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 19:10:39 Alexey Zaytsev wrote: Sorry, I don't get it. You are going to remove the (somehow) working driver, while there are known problems with the new one? Why? Because the new driver works, if you just set it up right. Until now every breakage was just a usage error. And please look at the problem from a user's view point. I'm happily using the 2.6.23 kernel. The bcm43xx driver is the only one available. And it works somehow (well, no s2ram). b43 supports s2ram and s2disk. If this is not a repgession, than I don't know what is. And if it is a regression, it should be fixed at least in the 2.6.24.y series, do you agree? No. Playing with kconfig SELECT is really _nothing_ for a -stable series. I am _not_ going to be responsible for any breakages. And using SELECT _does_ break things. We had dozens of bugs until all the damn dependencies were right. Even Obviously Correct (tm) changes to SELECT _do_ break on weird configurations. See the bcm43xx mail archives for examples. If you need that patch for some reason, please apply it locally. The problem will automatically get fixed when bcm43xx goes away, soon. I have provided a patch that I believe is trivial, that I have tested with all possible config option combinations I thought were possible, and that fixes the regression. If you have a reason to believe it is wrong, please say it, I won't be offended. If there is a problem with the patch, I'll gladly fix and resend it. This Nack leaves me with one option - to switch back to 2.6.23. Sorry, no testing, probably more bugs not found in 2.6.24. ;( It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
Michael Buesch wrote:
On Friday 22 February 2008 12:17:15 Alexey Zaytsev wrote:
Hello.
The bcm43xx driver won't work any more, if the b44 Ethernet
driver is enabled. This happens because the b44 driver
needlessly enables the b43_pci_bridge code, which claims
the same pci ids as the bcm43xx driver. The b43_pci_bridge
code is needed for the b43{legacy} drivers, but for the
b44, only the ssb pci core is needed.
This patch separates the ssb b43 pci bridge and the ssb pci
core config options and enables only the needed ones.
Nack. Switch to b43. bcm43xx is going to be removed anyway.
Since when this is a valid reason to NACK a patch which fixes
a regression in the 'stable' kernel ?
Probably you may want to ask first whatever 'b43' works for Alexey ?
and most probably the answer will be 'no' because that is the only reason
one would want to fix the *old* one when *both* drivers are enabled.
Really 'Switch to foo' and 'foo_old will be removed sometimes'
is not a 'valid' reason to NACK anything as long you 'have foo and foo_old'
*supported* in that kernel.
I'm not going to play these kconfig SELECT tricks anymore.
Fix it different then.
We had _lots_ of bugs there. People submitted patches that
obviously looked OK and still they turned out to break
some dependencies. KConfig SELECT is a feature from hell.
Yes it is but that is still not a valid reason to NACK that patch , I'm sorry.
Regards,
Gabriel
--
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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 18:51:32 Gabriel C wrote: I'm not going to play these kconfig SELECT tricks anymore. Fix it different then. Please do so. Yes it is but that is still not a valid reason to NACK that patch , I'm sorry. NACK means I (being the maintainer of the modified code) won't sign-off this patch. Nothing more or less. If some upstream maintainer decides to bypass me and apply the patch nevertheless is not of my business. But I will not sign-off or ack this patch. -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the firmware or something. :E I really don't get it, what is going on here? You state that the new b32 driver has problems on some hardware, where the old bcm43xx driver just works. And at the same time, you are surprised that I refuse to use the b43 driver and push patches for the bcm43xx driver you broke... Oh, really, why?! So, please find someone who will sign-off your patch. I won't. What's so hard to understand about that? Do I _have_ to sign off all patches random people send to me? I do _not_ want to be made responsible for that patch by signing it off. It is as simple as that. And I officially do not care about bcm43xx since a year and a half anymore. So why should I ACK it or sign it off? I thought that there was a rule that if you break something in the kernel, you normally would be the one who fixes things up. Sorry, it looks I was wrong. I'll resend the patch directly to Greg KH and Jeff Garzik for -stable and 2.6.25 inclusion. -- 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: bcm43xx regression in 2.6.24 (with patch)
[replying from my non-work account] On Fri, Feb 22, 2008 at 8:48 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Friday 22 February 2008 19:10:39 Alexey Zaytsev wrote: Sorry, I don't get it. You are going to remove the (somehow) working driver, while there are known problems with the new one? Why? Because the new driver works, if you just set it up right. Until now every breakage was just a usage error. And please look at the problem from a user's view point. I'm happily using the 2.6.23 kernel. The bcm43xx driver is the only one available. And it works somehow (well, no s2ram). b43 supports s2ram and s2disk. If this is not a repgession, than I don't know what is. And if it is a regression, it should be fixed at least in the 2.6.24.y series, do you agree? No. Playing with kconfig SELECT is really _nothing_ for a -stable series. I am _not_ going to be responsible for any breakages. And using SELECT _does_ break things. We had dozens of bugs until all the damn dependencies were right. Even Obviously Correct (tm) changes to SELECT _do_ break on weird configurations. See the bcm43xx mail archives for examples. Well, someone obviously played with the SELECTs, and broke the bcm43xx driver. Now I've got a patch that I believe gets the SELECTs right and fixes the driver, so what is wrong? If you need that patch for some reason, please apply it locally. The problem will automatically get fixed when bcm43xx goes away, soon. I have provided a patch that I believe is trivial, that I have tested with all possible config option combinations I thought were possible, and that fixes the regression. If you have a reason to believe it is wrong, please say it, I won't be offended. If there is a problem with the patch, I'll gladly fix and resend it. This Nack leaves me with one option - to switch back to 2.6.23. Sorry, no testing, probably more bugs not found in 2.6.24. ;( It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the firmware or something. :E I really don't get it, what is going on here? You state that the new b32 driver has problems on some hardware, where the old bcm43xx driver just works. And at the same time, you are surprised that I refuse to use the b43 driver and push patches for the bcm43xx driver you broke... Oh, really, why?! -- 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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the firmware or something. :E I really don't get it, what is going on here? You state that the new b32 driver has problems on some hardware, where the old bcm43xx driver just works. And at the same time, you are surprised that I refuse to use the b43 driver and push patches for the bcm43xx driver you broke... Oh, really, why?! So, please find someone who will sign-off your patch. I won't. What's so hard to understand about that? Do I _have_ to sign off all patches random people send to me? I do _not_ want to be made responsible for that patch by signing it off. It is as simple as that. And I officially do not care about bcm43xx since a year and a half anymore. So why should I ACK it or sign it off? -- Greetings Michael. -- 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: bcm43xx regression in 2.6.24 (with patch)
On Fri, Feb 22, 2008 at 06:56:14PM +0100, Michael Buesch wrote: On Friday 22 February 2008 18:51:32 Gabriel C wrote: I'm not going to play these kconfig SELECT tricks anymore. Fix it different then. Please do so. Yes it is but that is still not a valid reason to NACK that patch , I'm sorry. NACK means I (being the maintainer of the modified code) won't sign-off this patch. Nothing more or less. If some upstream maintainer decides to bypass me and apply the patch nevertheless is not of my business. But I will not sign-off or ack this patch. As the maintainer will not accept this, I'm not going to take it for the -stable tree either, sorry. thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
On Fri, Feb 22, 2008 at 11:38:34PM +0300, Alexey Zaytsev wrote: On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the firmware or something. :E I really don't get it, what is going on here? You state that the new b32 driver has problems on some hardware, where the old bcm43xx driver just works. And at the same time, you are surprised that I refuse to use the b43 driver and push patches for the bcm43xx driver you broke... Oh, really, why?! So, please find someone who will sign-off your patch. I won't. What's so hard to understand about that? Do I _have_ to sign off all patches random people send to me? I do _not_ want to be made responsible for that patch by signing it off. It is as simple as that. And I officially do not care about bcm43xx since a year and a half anymore. So why should I ACK it or sign it off? I thought that there was a rule that if you break something in the kernel, you normally would be the one who fixes things up. Sorry, it looks I was wrong. I'll resend the patch directly to Greg KH and Jeff Garzik for -stable and 2.6.25 inclusion. One of the rules for the -stable tree is that the patch is accepted by the maintainer and it is already in the upstream kernel version. Both of these requirements do not seem to be met here. I suggest you work _with_ Michael instead of against him to try to determine why your device doesn't work properly with the recommended driver. thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
On Sat, Feb 23, 2008 at 1:12 AM, Greg KH [EMAIL PROTECTED] wrote: On Fri, Feb 22, 2008 at 11:38:34PM +0300, Alexey Zaytsev wrote: On Fri, Feb 22, 2008 at 11:12 PM, Michael Buesch [EMAIL PROTECTED] wrote: On Friday 22 February 2008 21:06:00 Alexey Zaytsev wrote: It is not my problem, if you refuse to use b43. You also still refuse to tell me details about your card and _what_ does not work. I do own lots of different card and they all work fine with b43. There's one exception, the 4311 rev 3 (or something, don't quite remember). But patches are available and will ship in 2.6.25. bcm43xx won't get removed until that shipped. Yes, it's a 4311 rev 01, but I'm probably was just too lame to upgrade the firmware or something. :E I really don't get it, what is going on here? You state that the new b32 driver has problems on some hardware, where the old bcm43xx driver just works. And at the same time, you are surprised that I refuse to use the b43 driver and push patches for the bcm43xx driver you broke... Oh, really, why?! So, please find someone who will sign-off your patch. I won't. What's so hard to understand about that? Do I _have_ to sign off all patches random people send to me? I do _not_ want to be made responsible for that patch by signing it off. It is as simple as that. And I officially do not care about bcm43xx since a year and a half anymore. So why should I ACK it or sign it off? I thought that there was a rule that if you break something in the kernel, you normally would be the one who fixes things up. Sorry, it looks I was wrong. I'll resend the patch directly to Greg KH and Jeff Garzik for -stable and 2.6.25 inclusion. One of the rules for the -stable tree is that the patch is accepted by the maintainer and it is already in the upstream kernel version. Both of these requirements do not seem to be met here. Well, it looks like Michael is not the bcm43xx maintaner. I sent the patch to him, because it was his code that broke the driver, and I thought it would be easy for him to review my patch, as it touches his code. I'll resend the patch to the proper maintainers now. I suggest you work _with_ Michael instead of against him to try to determine why your device doesn't work properly with the recommended driver. Well, if you read my first email, that is exactly what I intended to do, but even if Michael would be able to fix the b43 driver to work with my hardware, the code will only show up in 2.6.25, leaving some 2.6.24 users with broken wifi. So I thought it would be a good thing to add my simple fix that enabled the old driver to the -stable tree, so that we could have working wifi soon. This is still my intension, I'll resend to the proper maintainters. thanks, greg k-h -- 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: bcm43xx regression in 2.6.24 (with patch)
On Friday 22 February 2008, Alexey Zaytsev wrote: Well, it looks like Michael is not the bcm43xx maintaner. I sent the patch to him, because it was his code that broke the driver, and I thought it would be easy for him to review my patch, as it touches his code. See? I'm tired of this how dare can you break my kernel!? bullshit. That's exactly the reason why I NACKed this patch. I do _not_ understand the KConfig SELECT logic. And I do think almost nobody does understand how that all works together. In the past people came with similiar patches like yours that looked obviously OK. They said sentences like it is trivial to get the SELECT logics right. But it turned out they were wrong and it introduced other regressions that I was made responsible for. SELECT is _extremely_ difficult to get right, as it completely ignores dependencies. See all this FOOBAR_POSSIBLE select logic that we use in SSB to get SELECT working correctly with dependencies. So my solution for this particular breakage you are seeing here is to wait for the bcm43xx removal, which will happen soon. That will fix it and will have almost zero chance to introduce new bugs. Well, if you read my first email, that is exactly what I intended to do, but even if Michael would be able to fix the b43 driver to work with my hardware, the code will only show up in 2.6.25, leaving some 2.6.24 users with broken wifi. So I thought Blah. The people with a bcm4311 revision 1 wireless card plus a bcm44xx ethernet card. You can count those people on two fingers. it would be a good thing to add my simple fix that enabled the old driver to the -stable tree, so that we could have working wifi soon. This is still my intension, I'll resend to the proper maintainters. Ok thanks. We'll see if it really was a simple fix then. If it turns out to break something you will get mail. :) You can send this patch to a netdev maintainer or the wireless maintainer. Maybe one of those will sign it off. Good luck. -- 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/
