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 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 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 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 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 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 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 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 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 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 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 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: [PATCH] Fix the bcm43xx driver breakage in 2.6.24/25.
On Saturday 23 February 2008 14:17:55 Alexey Zaytsev wrote: > diff --git a/drivers/net/wireless/bcm43xx/Kconfig > b/drivers/net/wireless/bcm43xx/Kconfig > index 0159701..afb8f43 100644 > --- a/drivers/net/wireless/bcm43xx/Kconfig > +++ b/drivers/net/wireless/bcm43xx/Kconfig > @@ -1,6 +1,6 @@ > config BCM43XX > tristate "Broadcom BCM43xx wireless support (DEPRECATED)" > - depends on PCI && IEEE80211 && IEEE80211_SOFTMAC && WLAN_80211 && > EXPERIMENTAL > + depends on PCI && IEEE80211 && IEEE80211_SOFTMAC && WLAN_80211 && > (!SSB_B43_PCI_BRIDGE || SSB != y) && EXPERIMENTAL so if SSB is m it will break module auto-loading, right? -- 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/
[PATCH] hwrng: Remove me as a HWRNG maintainer
It turns out that I rewrote the HWRNG core once to make it pluggable, but I'm not a crypto-expert at all. So I'm certainly the wrong person for being a maintainer of the HWRNG core. Let's orphan it. Signed-off-by: Michael Buesch <[EMAIL PROTECTED]> Index: wireless-testing/MAINTAINERS === --- wireless-testing.orig/MAINTAINERS 2008-02-16 19:08:05.0 +0100 +++ wireless-testing/MAINTAINERS2008-02-23 17:13:36.0 +0100 @@ -1721,9 +1721,7 @@ T:git lm-sensors.org:/kernel/mhoffman/h S: Maintained HARDWARE RANDOM NUMBER GENERATOR CORE -P: Michael Buesch -M: [EMAIL PROTECTED] -S: Maintained +S: Orphaned HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER P: Robert Love -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Saturday 23 February 2008 11:14:23 Gordon Farquharson wrote:
> On Fri, Feb 22, 2008 at 10:51 PM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > A big fat comment is something like that:
> >
> > /* Explicit padding to support a broken sanity check in file2alias.c.
> > * The check will compare the size of the structure in the kernel
> > * object file to the userspace the kernel is compiled on.
> > * This breaks on cross-compilation. This padding is a workaround
> > * for this. */
>
> ---
>
> Align the members of the SSB device structure to a 32 bit boundary so
> that the b43 driver can be built for arm using a cross compiler. This
> alignment is required so that the test in scripts/mod/file2alias.c
> that checks that the size of the device ID type against the size of
> the section in the object file succeeds (see comment and
> http://lkml.org/lkml/2008/2/18/481 for explanation).
>
> Signed-off-by: Gordon Farquharson <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 139d49d..208d49a 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -351,7 +351,13 @@ struct sdio_device_id {
> struct ssb_device_id {
> __u16 vendor;
> __u16 coreid;
> - __u8revision;
> + /* Explicit padding to support a broken sanity check in file2alias.c.
> + * The check compares the size of the structure in the kernel
> + * object file to the size of the structure reported in userspace for
> + * the system on which the kernel is compiled. The check breaks on
> + * cross-compilation, and the padding is a workaround for this. */
> + __u8revision
> + __attribute__((aligned(sizeof(__u32;
> };
> #define SSB_DEVICE(_vendor, _coreid, _revision) \
> { .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
>
--
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/
[PATCH] hwrng: Remove me as a HWRNG maintainer
It turns out that I rewrote the HWRNG core once to make it pluggable, but I'm not a crypto-expert at all. So I'm certainly the wrong person for being a maintainer of the HWRNG core. Let's orphan it. Signed-off-by: Michael Buesch [EMAIL PROTECTED] Index: wireless-testing/MAINTAINERS === --- wireless-testing.orig/MAINTAINERS 2008-02-16 19:08:05.0 +0100 +++ wireless-testing/MAINTAINERS2008-02-23 17:13:36.0 +0100 @@ -1721,9 +1721,7 @@ T:git lm-sensors.org:/kernel/mhoffman/h S: Maintained HARDWARE RANDOM NUMBER GENERATOR CORE -P: Michael Buesch -M: [EMAIL PROTECTED] -S: Maintained +S: Orphaned HARD DRIVE ACTIVE PROTECTION SYSTEM (HDAPS) DRIVER P: Robert Love -- 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: [PATCH] Fix the bcm43xx driver breakage in 2.6.24/25.
On Saturday 23 February 2008 14:17:55 Alexey Zaytsev wrote: diff --git a/drivers/net/wireless/bcm43xx/Kconfig b/drivers/net/wireless/bcm43xx/Kconfig index 0159701..afb8f43 100644 --- a/drivers/net/wireless/bcm43xx/Kconfig +++ b/drivers/net/wireless/bcm43xx/Kconfig @@ -1,6 +1,6 @@ config BCM43XX tristate Broadcom BCM43xx wireless support (DEPRECATED) - depends on PCI IEEE80211 IEEE80211_SOFTMAC WLAN_80211 EXPERIMENTAL + depends on PCI IEEE80211 IEEE80211_SOFTMAC WLAN_80211 (!SSB_B43_PCI_BRIDGE || SSB != y) EXPERIMENTAL so if SSB is m it will break module auto-loading, right? -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Saturday 23 February 2008 11:14:23 Gordon Farquharson wrote:
On Fri, Feb 22, 2008 at 10:51 PM, Michael Buesch [EMAIL PROTECTED] wrote:
A big fat comment is something like that:
/* Explicit padding to support a broken sanity check in file2alias.c.
* The check will compare the size of the structure in the kernel
* object file to the userspace the kernel is compiled on.
* This breaks on cross-compilation. This padding is a workaround
* for this. */
---
Align the members of the SSB device structure to a 32 bit boundary so
that the b43 driver can be built for arm using a cross compiler. This
alignment is required so that the test in scripts/mod/file2alias.c
that checks that the size of the device ID type against the size of
the section in the object file succeeds (see comment and
http://lkml.org/lkml/2008/2/18/481 for explanation).
Signed-off-by: Gordon Farquharson [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 139d49d..208d49a 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -351,7 +351,13 @@ struct sdio_device_id {
struct ssb_device_id {
__u16 vendor;
__u16 coreid;
- __u8revision;
+ /* Explicit padding to support a broken sanity check in file2alias.c.
+ * The check compares the size of the structure in the kernel
+ * object file to the size of the structure reported in userspace for
+ * the system on which the kernel is compiled. The check breaks on
+ * cross-compilation, and the padding is a workaround for this. */
+ __u8revision
+ __attribute__((aligned(sizeof(__u32;
};
#define SSB_DEVICE(_vendor, _coreid, _revision) \
{ .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
--
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)
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 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: [RFC] [PATCH] Fix b43 driver build for arm
On Saturday 23 February 2008, Gordon Farquharson wrote:
> On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch <[EMAIL PROTECTED]> wrote:
> > On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
> > > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > >
> > > > Option 1) is the worst of the three as that can cost
> > > > of many hours bug-hunting.
> > > > Option 3) may seem optimal but I do not like to add more
> > > > complexity to this part of the build. And really I do not
> > > > know a reliable way to detech when we do cross builds anyway.
> > > >
> > > > Leaving us with option 2) that is simple, strighforward and harmless.
> > >
> > > Are you willing to sign off on and commit the patch?
> >
> > Only with a big fat comment added that the alignment is only needed
> > because of a broken sanity check in file2alias.c.
>
> How about this?
>
> ---
>
> Align the members of the SSB device structure to a 32 bit boundary so
> that the b43 driver can be built for arm using a cross compiler. This
> change is required so that the test in scripts/mod/file2alias.c that
> checks that the size of the device ID type against the size of the
> section in the object file succeeds (see
> http://lkml.org/lkml/2008/2/18/481 for discussion).
>
> Signed-off-by: Gordon Farquharson <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
> index 139d49d..93083ad 100644
> --- a/include/linux/mod_devicetable.h
> +++ b/include/linux/mod_devicetable.h
> @@ -351,7 +351,9 @@ struct sdio_device_id {
> struct ssb_device_id {
> __u16 vendor;
> __u16 coreid;
> - __u8revision;
> + /* Explicit padding to support cross-compilation. */
A big fat comment is something like that:
/* Explicit padding to support a broken sanity check in file2alias.c.
* The check will compare the size of the structure in the kernel
* object file to the userspace the kernel is compiled on.
* This breaks on cross-compilation. This padding is a workaround
* for this. */
> + __u8revision
> + __attribute__((aligned(sizeof(__u32;
> };
> #define SSB_DEVICE(_vendor, _coreid, _revision) \
> { .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
>
--
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 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 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)
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: [RFC] [PATCH] Fix b43 driver build for arm
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote: > Hi Sam > > On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg <[EMAIL PROTECTED]> wrote: > > > Option 1) is the worst of the three as that can cost > > of many hours bug-hunting. > > Option 3) may seem optimal but I do not like to add more > > complexity to this part of the build. And really I do not > > know a reliable way to detech when we do cross builds anyway. > > > > Leaving us with option 2) that is simple, strighforward and harmless. > > Are you willing to sign off on and commit the patch? Only with a big fat comment added that the alignment is only needed because of a broken sanity check in file2alias.c. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote: Hi Sam On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg [EMAIL PROTECTED] wrote: Option 1) is the worst of the three as that can cost of many hours bug-hunting. Option 3) may seem optimal but I do not like to add more complexity to this part of the build. And really I do not know a reliable way to detech when we do cross builds anyway. Leaving us with option 2) that is simple, strighforward and harmless. Are you willing to sign off on and commit the patch? Only with a big fat comment added that the alignment is only needed because of a broken sanity check in file2alias.c. -- 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)
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)
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 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 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: [RFC] [PATCH] Fix b43 driver build for arm
On Saturday 23 February 2008, Gordon Farquharson wrote:
On Fri, Feb 22, 2008 at 7:07 AM, Michael Buesch [EMAIL PROTECTED] wrote:
On Friday 22 February 2008 05:24:32 Gordon Farquharson wrote:
On Wed, Feb 20, 2008 at 12:37 PM, Sam Ravnborg [EMAIL PROTECTED] wrote:
Option 1) is the worst of the three as that can cost
of many hours bug-hunting.
Option 3) may seem optimal but I do not like to add more
complexity to this part of the build. And really I do not
know a reliable way to detech when we do cross builds anyway.
Leaving us with option 2) that is simple, strighforward and harmless.
Are you willing to sign off on and commit the patch?
Only with a big fat comment added that the alignment is only needed
because of a broken sanity check in file2alias.c.
How about this?
---
Align the members of the SSB device structure to a 32 bit boundary so
that the b43 driver can be built for arm using a cross compiler. This
change is required so that the test in scripts/mod/file2alias.c that
checks that the size of the device ID type against the size of the
section in the object file succeeds (see
http://lkml.org/lkml/2008/2/18/481 for discussion).
Signed-off-by: Gordon Farquharson [EMAIL PROTECTED]
---
diff --git a/include/linux/mod_devicetable.h b/include/linux/mod_devicetable.h
index 139d49d..93083ad 100644
--- a/include/linux/mod_devicetable.h
+++ b/include/linux/mod_devicetable.h
@@ -351,7 +351,9 @@ struct sdio_device_id {
struct ssb_device_id {
__u16 vendor;
__u16 coreid;
- __u8revision;
+ /* Explicit padding to support cross-compilation. */
A big fat comment is something like that:
/* Explicit padding to support a broken sanity check in file2alias.c.
* The check will compare the size of the structure in the kernel
* object file to the userspace the kernel is compiled on.
* This breaks on cross-compilation. This padding is a workaround
* for this. */
+ __u8revision
+ __attribute__((aligned(sizeof(__u32;
};
#define SSB_DEVICE(_vendor, _coreid, _revision) \
{ .vendor = _vendor, .coreid = _coreid, .revision = _revision, }
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote: > Hi Michael > > On Feb 19, 2008 3:41 AM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > [2] > > > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff > > > > > > > That doesn't cause me to magically sign off this sort of patches, too. > > The sanity check is clearly broken in file2alias.c, as it checks something > > from the target kernel against the host environment it is compiled on. > > That doesn't make any sense at all. > > I think that you make some good points, but I'm at a loss as to how to > fix the problem. Do you have any suggestions? Remove the broken sanity check, if it's not possible the check there. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Wednesday 20 February 2008 01:44:38 Gordon Farquharson wrote: Hi Michael On Feb 19, 2008 3:41 AM, Michael Buesch [EMAIL PROTECTED] wrote: [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff That doesn't cause me to magically sign off this sort of patches, too. The sanity check is clearly broken in file2alias.c, as it checks something from the target kernel against the host environment it is compiled on. That doesn't make any sense at all. I think that you make some good points, but I'm at a loss as to how to fix the problem. Do you have any suggestions? Remove the broken sanity check, if it's not possible the check there. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 05:59:21 Gordon Farquharson wrote: > Does this thread [1] provide any clues as to the Right Thing (TM) to do? > > It should be noted that Linus and Andrew signed off on the m68k fix > [2]. I'm CC'ing them and Al Viro on this email to solicit their input. > > Gordon > > [1] http://www.gossamer-threads.com/lists/linux/kernel/801528 > [2] > http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff > That doesn't cause me to magically sign off this sort of patches, too. The sanity check is clearly broken in file2alias.c, as it checks something from the target kernel against the host environment it is compiled on. That doesn't make any sense at all. I also don't see why we want to compare the size of the struct in kernel and userland. It is not used in userland. So NACK for this SSB 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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 09:37:05 Geert Uytterhoeven wrote: > On Tue, 19 Feb 2008, Michael Buesch wrote: > > Still I can't see why this structure will cause alignment issues, as the > > compiler will pad it up to the right boundary automagically, as you said > > above. Why doesn't the ARM compiler do this? > > The ARM compiler handles it correctly. > > But the ugly hacks to get useful information about the module device > table using the _host_ compiler fail. Ok, fine. So I'm not going to apply this patch. We need to fix the sanity check instead. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 09:37:05 Geert Uytterhoeven wrote: On Tue, 19 Feb 2008, Michael Buesch wrote: Still I can't see why this structure will cause alignment issues, as the compiler will pad it up to the right boundary automagically, as you said above. Why doesn't the ARM compiler do this? The ARM compiler handles it correctly. But the ugly hacks to get useful information about the module device table using the _host_ compiler fail. Ok, fine. So I'm not going to apply this patch. We need to fix the sanity check instead. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 05:59:21 Gordon Farquharson wrote: Does this thread [1] provide any clues as to the Right Thing (TM) to do? It should be noted that Linus and Andrew signed off on the m68k fix [2]. I'm CC'ing them and Al Viro on this email to solicit their input. Gordon [1] http://www.gossamer-threads.com/lists/linux/kernel/801528 [2] http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=7492d4a416d68ab4bd254b36ffcc4e0138daa8ff That doesn't cause me to magically sign off this sort of patches, too. The sanity check is clearly broken in file2alias.c, as it checks something from the target kernel against the host environment it is compiled on. That doesn't make any sense at all. I also don't see why we want to compare the size of the struct in kernel and userland. It is not used in userland. So NACK for this SSB 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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 00:42:12 Sam Ravnborg wrote:
> On Tue, Feb 19, 2008 at 12:17:04AM +0100, Michael Buesch wrote:
> > On Tuesday 19 February 2008 00:00:58 Russell King wrote:
> > > > > Why can't we have an array of this structure on ARM?
> > > > >
> > > > > struct ssb_device_id {
> > > > >__u16 vendor;
> > > >
> > > > 2 bytes
> > > >
> > > > >__u16 coreid;
> > > >
> > > > 2 bytes
> > > >
> > > > >__u8revision;
> > > >
> > > > 1 byte
> > > >
> > > > > };
> > > >
> > > > and therefore sizeof this structure will be 5 bytes, but because of the
> > > > ABI rules (which are _explicitly_ allowed by the C standard), it'll
> > > > become 8 bytes due to padding afterwards.
> > >
> > > Another guess might be that, if using AEABI, this structure might
> > > be 6 bytes in size, but the linker will align structures to 4 bytes.
> >
> > If the struct is padded to 6 bytes and the linker aligns it to 4 byte
> > everything will be naturally aligned, as far as I can see.
> >
> > > FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
> > > not a modulo of the size of section __mod_ssb_device_table=64.
> > > Fix definition of struct ssb_device_id in mod_devicetable.h
> >
> > So this message tells me the table size is 64 bytes. There are 8 entries,
> > so it seems the structure is padded to 8 bytes.
> > But above that it says that sizeof(struct ssb_device_id)=6
> >
> > IMO this sanity check is broken and not the code.
> >
> > Where does this sanity check message come from? The linker?
> $ git grep 'not a modulo'
> scripts/mod/file2alias.c: fatal("%s: sizeof(struct
> %s_device_id)=%lu is not a modulo "
>
> It is a consistencycheck between host and target
> layout of data.
> You need to pad the structure so it becomes 8 byte in size.
Ok, I looked at the code and it is hightly questionable to me that this
check does work in a crosscompile environment (which the ARM build
most likely is).
It seems to check the size of the structure in the .o file against
the size of the structure on the _host_ where it is compiled.
I can't see why we would want to check _anything_ of the target stuff
to the host this stuff is compiled on.
I can compile an ARM kernel on any machine I want.
There actually is a comment:
* Check that sizeof(device_id type) are consistent with size of section
* in .o file. If in-consistent then userspace and kernel does not agree
* on actual size which is a bug.
So it seems what this check _wants_ to compare the sizeof the structure
in the kernel to the size of the stucture in the userland of the target system.
But it does _not_ do that.
It does compare the size of the structure in the kernel against the size of
the stucture in userland on the machine it is _compiled_ on.
That is wrong.
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 00:00:58 Russell King wrote:
> > > Why can't we have an array of this structure on ARM?
> > >
> > > struct ssb_device_id {
> > >__u16 vendor;
> >
> > 2 bytes
> >
> > >__u16 coreid;
> >
> > 2 bytes
> >
> > >__u8revision;
> >
> > 1 byte
> >
> > > };
> >
> > and therefore sizeof this structure will be 5 bytes, but because of the
> > ABI rules (which are _explicitly_ allowed by the C standard), it'll
> > become 8 bytes due to padding afterwards.
>
> Another guess might be that, if using AEABI, this structure might
> be 6 bytes in size, but the linker will align structures to 4 bytes.
If the struct is padded to 6 bytes and the linker aligns it to 4 byte
everything will be naturally aligned, as far as I can see.
> FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
> not a modulo of the size of section __mod_ssb_device_table=64.
> Fix definition of struct ssb_device_id in mod_devicetable.h
So this message tells me the table size is 64 bytes. There are 8 entries,
so it seems the structure is padded to 8 bytes.
But above that it says that sizeof(struct ssb_device_id)=6
IMO this sanity check is broken and not the code.
Where does this sanity check message come from? The linker?
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:53:54 Russell King wrote:
> I get extremely pissed off everytime I have to try to explain random
> alignment issues to people. "It doesn't work like i386 so it must be
> broken" is a rediculous position to take.
I did _not_ ask for a general description of alignment. I did
_just_ ask why ARM is special and why the compiler didn't handle
it there. I do develop code for MIPS, so I do know what alignment is about.
> > Can you _please_ explain what makes ARM so special here?
>
> No because I don't really know.
>
> > Why can't we have an array of this structure on ARM?
> >
> > struct ssb_device_id {
> >__u16 vendor;
>
> 2 bytes
>
> >__u16 coreid;
>
> 2 bytes
>
> >__u8revision;
>
> 1 byte
>
> > };
>
> and therefore sizeof this structure will be 5 bytes, but because of the
> ABI rules (which are _explicitly_ allowed by the C standard), it'll
> become 8 bytes due to padding afterwards.
So that would be fine. I don't see what would be unaligned then.
Even if it would pad only one byte after the "revision" it would all
be aligned in a natural way.
> At a _guess_ and its only a guess, the linker will enforce this rule
> between compilation units, otherwise the implications are disgusting
> (would probably result in all loads having to be individual byte loads
> and instructions to combine the result - since ARM has strict alignment
> requirements.)
Yeah. As I said. The code does work on MIPS, which has strict alignment
requirements as well.
> What I can say is that the ABI will not be changed because someone in the
> kernel decides they don't like it. So the options are: either fix it so
> it works, or accept that the code is broken and will never work on ARM.
I did never ask to change some ABI, sorry.
Still I can't see why this structure will cause alignment issues, as the
compiler will pad it up to the right boundary automagically, as you said
above. Why doesn't the ARM compiler do this?
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:50:30 Harvey Harrison wrote:
> On Mon, 2008-02-18 at 23:43 +0100, Michael Buesch wrote:
> > On Monday 18 February 2008 23:34:10 Russell King wrote:
> > >
> > > Well, don't expect this driver to work until you fix your broken
> > > assumptions about alignment requirements.
> >
> > Mr King, I'm not an idiot!
> >
> > Can you _please_ explain what makes ARM so special here?
> > Why can't we have an array of this structure on ARM?
> >
> > struct ssb_device_id {
> >__u16 vendor;
> >__u16 coreid;
> >__u8revision;
> > };
> >
> > I will not apply any patches that I don't understand.
> > Why doesn't the compiler handle this? What's special? Can you please
> > explain?
> >
>
> I believe this is a good place to start (although I could be totally
> off-base)
>
> http://lkml.org/lkml/2007/11/22/120
I know very well what unaligned access is. As I said the code
works on MIPS, which can't do unaligned accesses.
The _real_ question is, why doesn't align the compiler the stuff properly
on ARM? It does the right thing on x86_32/64, powerpc and MIPS. Why doesn't
it do the right thing on ARM and we have to manually align stuff?
See section "Code that doesn't cause unaligned access"
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:34:10 Russell King wrote:
> On Mon, Feb 18, 2008 at 11:24:44PM +0100, Michael Buesch wrote:
> > On Monday 18 February 2008 23:13:24 Russell King wrote:
> > > On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote:
> > > > On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote:
> > > > > The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64
> > > > > box using a cross-compiler:
> > > > >
> > > > > FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
> > > > > not a modulo of the size of section __mod_ssb_device_table=64.
> > > > > Fix definition of struct ssb_device_id in mod_devicetable.h
> > > >
> > > > Why does ARM have this special requirement and what is it about?
> > >
> > > Because ARM is a 32 bit architecture.
> >
> > Ehm, I didn't see this warning on any other architecture nor did we
> > have _any_ problem with it on any other architecture.
> > This code runs fine on x86_32, x86_64, powerpc and mips, at least.
>
> Well, don't expect this driver to work until you fix your broken
> assumptions about alignment requirements.
Mr King, I'm not an idiot!
Can you _please_ explain what makes ARM so special here?
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
__u16 coreid;
__u8revision;
};
I will not apply any patches that I don't understand.
Why doesn't the compiler handle this? What's special? Can you please explain?
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:13:24 Russell King wrote: > On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote: > > On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote: > > > The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64 > > > box using a cross-compiler: > > > > > > FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is > > > not a modulo of the size of section __mod_ssb_device_table=64. > > > Fix definition of struct ssb_device_id in mod_devicetable.h > > > > Why does ARM have this special requirement and what is it about? > > Because ARM is a 32 bit architecture. Ehm, I didn't see this warning on any other architecture nor did we have _any_ problem with it on any other architecture. This code runs fine on x86_32, x86_64, powerpc and mips, at least. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote: > The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64 > box using a cross-compiler: > > FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is > not a modulo of the size of section __mod_ssb_device_table=64. > Fix definition of struct ssb_device_id in mod_devicetable.h Why does ARM have this special requirement and what is it about? -- 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: [PATCH] [SSB] PCI core driver: use new SPROM data structure
On Monday 18 February 2008 11:02:57 Aurelien Jarno wrote: > Switch the SSB PCI core driver to the new SPROM data structure now that > the old one has been removed. > > Signed-off-by: Aurelien Jarno <[EMAIL PROTECTED]> Acked-by: Michael Buesch <[EMAIL PROTECTED]> John, can you please apply this? > --- > drivers/ssb/driver_pcicore.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c > index 2faaa90..191db7a 100644 > --- a/drivers/ssb/driver_pcicore.c > +++ b/drivers/ssb/driver_pcicore.c > @@ -362,7 +362,7 @@ static int pcicore_is_in_hostmode(struct ssb_pcicore *pc) > chipid_top != 0x5300) > return 0; > > - if (bus->sprom.r1.boardflags_lo & SSB_PCICORE_BFL_NOPCI) > + if (bus->sprom.boardflags_lo & SSB_PCICORE_BFL_NOPCI) > return 0; > > /* The 200-pin BCM4712 package does not bond out PCI. Even when > -- > 1.5.4.1 > -- 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: [PATCH] [SSB] PCI core driver: use new SPROM data structure
On Monday 18 February 2008 11:02:57 Aurelien Jarno wrote: Switch the SSB PCI core driver to the new SPROM data structure now that the old one has been removed. Signed-off-by: Aurelien Jarno [EMAIL PROTECTED] Acked-by: Michael Buesch [EMAIL PROTECTED] John, can you please apply this? --- drivers/ssb/driver_pcicore.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/ssb/driver_pcicore.c b/drivers/ssb/driver_pcicore.c index 2faaa90..191db7a 100644 --- a/drivers/ssb/driver_pcicore.c +++ b/drivers/ssb/driver_pcicore.c @@ -362,7 +362,7 @@ static int pcicore_is_in_hostmode(struct ssb_pcicore *pc) chipid_top != 0x5300) return 0; - if (bus-sprom.r1.boardflags_lo SSB_PCICORE_BFL_NOPCI) + if (bus-sprom.boardflags_lo SSB_PCICORE_BFL_NOPCI) return 0; /* The 200-pin BCM4712 package does not bond out PCI. Even when -- 1.5.4.1 -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote: The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64 box using a cross-compiler: FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is not a modulo of the size of section __mod_ssb_device_table=64. Fix definition of struct ssb_device_id in mod_devicetable.h Why does ARM have this special requirement and what is it about? -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:34:10 Russell King wrote:
On Mon, Feb 18, 2008 at 11:24:44PM +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:13:24 Russell King wrote:
On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote:
The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64
box using a cross-compiler:
FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
not a modulo of the size of section __mod_ssb_device_table=64.
Fix definition of struct ssb_device_id in mod_devicetable.h
Why does ARM have this special requirement and what is it about?
Because ARM is a 32 bit architecture.
Ehm, I didn't see this warning on any other architecture nor did we
have _any_ problem with it on any other architecture.
This code runs fine on x86_32, x86_64, powerpc and mips, at least.
Well, don't expect this driver to work until you fix your broken
assumptions about alignment requirements.
Mr King, I'm not an idiot!
Can you _please_ explain what makes ARM so special here?
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
__u16 coreid;
__u8revision;
};
I will not apply any patches that I don't understand.
Why doesn't the compiler handle this? What's special? Can you please explain?
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:13:24 Russell King wrote: On Mon, Feb 18, 2008 at 11:08:56PM +0100, Michael Buesch wrote: On Monday 18 February 2008 23:03:10 Gordon Farquharson wrote: The b43 driver in 2.6.25-rc[12] fails to build for arm on an x86_64 box using a cross-compiler: FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is not a modulo of the size of section __mod_ssb_device_table=64. Fix definition of struct ssb_device_id in mod_devicetable.h Why does ARM have this special requirement and what is it about? Because ARM is a 32 bit architecture. Ehm, I didn't see this warning on any other architecture nor did we have _any_ problem with it on any other architecture. This code runs fine on x86_32, x86_64, powerpc and mips, at least. -- 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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:53:54 Russell King wrote:
I get extremely pissed off everytime I have to try to explain random
alignment issues to people. It doesn't work like i386 so it must be
broken is a rediculous position to take.
I did _not_ ask for a general description of alignment. I did
_just_ ask why ARM is special and why the compiler didn't handle
it there. I do develop code for MIPS, so I do know what alignment is about.
Can you _please_ explain what makes ARM so special here?
No because I don't really know.
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
2 bytes
__u16 coreid;
2 bytes
__u8revision;
1 byte
};
and therefore sizeof this structure will be 5 bytes, but because of the
ABI rules (which are _explicitly_ allowed by the C standard), it'll
become 8 bytes due to padding afterwards.
So that would be fine. I don't see what would be unaligned then.
Even if it would pad only one byte after the revision it would all
be aligned in a natural way.
At a _guess_ and its only a guess, the linker will enforce this rule
between compilation units, otherwise the implications are disgusting
(would probably result in all loads having to be individual byte loads
and instructions to combine the result - since ARM has strict alignment
requirements.)
Yeah. As I said. The code does work on MIPS, which has strict alignment
requirements as well.
What I can say is that the ABI will not be changed because someone in the
kernel decides they don't like it. So the options are: either fix it so
it works, or accept that the code is broken and will never work on ARM.
I did never ask to change some ABI, sorry.
Still I can't see why this structure will cause alignment issues, as the
compiler will pad it up to the right boundary automagically, as you said
above. Why doesn't the ARM compiler do this?
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 00:00:58 Russell King wrote:
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
2 bytes
__u16 coreid;
2 bytes
__u8revision;
1 byte
};
and therefore sizeof this structure will be 5 bytes, but because of the
ABI rules (which are _explicitly_ allowed by the C standard), it'll
become 8 bytes due to padding afterwards.
Another guess might be that, if using AEABI, this structure might
be 6 bytes in size, but the linker will align structures to 4 bytes.
If the struct is padded to 6 bytes and the linker aligns it to 4 byte
everything will be naturally aligned, as far as I can see.
FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
not a modulo of the size of section __mod_ssb_device_table=64.
Fix definition of struct ssb_device_id in mod_devicetable.h
So this message tells me the table size is 64 bytes. There are 8 entries,
so it seems the structure is padded to 8 bytes.
But above that it says that sizeof(struct ssb_device_id)=6
IMO this sanity check is broken and not the code.
Where does this sanity check message come from? The linker?
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Monday 18 February 2008 23:50:30 Harvey Harrison wrote:
On Mon, 2008-02-18 at 23:43 +0100, Michael Buesch wrote:
On Monday 18 February 2008 23:34:10 Russell King wrote:
Well, don't expect this driver to work until you fix your broken
assumptions about alignment requirements.
Mr King, I'm not an idiot!
Can you _please_ explain what makes ARM so special here?
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
__u16 coreid;
__u8revision;
};
I will not apply any patches that I don't understand.
Why doesn't the compiler handle this? What's special? Can you please
explain?
I believe this is a good place to start (although I could be totally
off-base)
http://lkml.org/lkml/2007/11/22/120
I know very well what unaligned access is. As I said the code
works on MIPS, which can't do unaligned accesses.
The _real_ question is, why doesn't align the compiler the stuff properly
on ARM? It does the right thing on x86_32/64, powerpc and MIPS. Why doesn't
it do the right thing on ARM and we have to manually align stuff?
See section Code that doesn't cause unaligned access
--
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: [RFC] [PATCH] Fix b43 driver build for arm
On Tuesday 19 February 2008 00:42:12 Sam Ravnborg wrote:
On Tue, Feb 19, 2008 at 12:17:04AM +0100, Michael Buesch wrote:
On Tuesday 19 February 2008 00:00:58 Russell King wrote:
Why can't we have an array of this structure on ARM?
struct ssb_device_id {
__u16 vendor;
2 bytes
__u16 coreid;
2 bytes
__u8revision;
1 byte
};
and therefore sizeof this structure will be 5 bytes, but because of the
ABI rules (which are _explicitly_ allowed by the C standard), it'll
become 8 bytes due to padding afterwards.
Another guess might be that, if using AEABI, this structure might
be 6 bytes in size, but the linker will align structures to 4 bytes.
If the struct is padded to 6 bytes and the linker aligns it to 4 byte
everything will be naturally aligned, as far as I can see.
FATAL: drivers/net/wireless/b43/b43: sizeof(struct ssb_device_id)=6 is
not a modulo of the size of section __mod_ssb_device_table=64.
Fix definition of struct ssb_device_id in mod_devicetable.h
So this message tells me the table size is 64 bytes. There are 8 entries,
so it seems the structure is padded to 8 bytes.
But above that it says that sizeof(struct ssb_device_id)=6
IMO this sanity check is broken and not the code.
Where does this sanity check message come from? The linker?
$ git grep 'not a modulo'
scripts/mod/file2alias.c: fatal(%s: sizeof(struct
%s_device_id)=%lu is not a modulo
It is a consistencycheck between host and target
layout of data.
You need to pad the structure so it becomes 8 byte in size.
Ok, I looked at the code and it is hightly questionable to me that this
check does work in a crosscompile environment (which the ARM build
most likely is).
It seems to check the size of the structure in the .o file against
the size of the structure on the _host_ where it is compiled.
I can't see why we would want to check _anything_ of the target stuff
to the host this stuff is compiled on.
I can compile an ARM kernel on any machine I want.
There actually is a comment:
* Check that sizeof(device_id type) are consistent with size of section
* in .o file. If in-consistent then userspace and kernel does not agree
* on actual size which is a bug.
So it seems what this check _wants_ to compare the sizeof the structure
in the kernel to the size of the stucture in the userland of the target system.
But it does _not_ do that.
It does compare the size of the structure in the kernel against the size of
the stucture in userland on the machine it is _compiled_ on.
That is wrong.
--
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: [2.6 patch] make b43_mac_{enable,suspend}() static
On Wednesday 30 January 2008 21:02:47 Adrian Bunk wrote:
> b43_mac_{enable,suspend}() can now become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
> ---
>
> drivers/net/wireless/b43/main.c |4 ++--
> drivers/net/wireless/b43/main.h |3 ---
> 2 files changed, 2 insertions(+), 5 deletions(-)
>
> e2a91b00d125ed4b60bdf9e37f550aed23d84747
> diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
> index 88d2c15..360515c 100644
> --- a/drivers/net/wireless/b43/main.c
> +++ b/drivers/net/wireless/b43/main.c
> @@ -2042,7 +2042,7 @@ static void b43_gpio_cleanup(struct b43_wldev *dev)
> }
>
> /* http://bcm-specs.sipsolutions.net/EnableMac */
> -void b43_mac_enable(struct b43_wldev *dev)
> +static void b43_mac_enable(struct b43_wldev *dev)
> {
> dev->mac_suspended--;
> B43_WARN_ON(dev->mac_suspended < 0);
> @@ -2066,7 +2066,7 @@ void b43_mac_enable(struct b43_wldev *dev)
> }
>
> /* http://bcm-specs.sipsolutions.net/SuspendMAC */
> -void b43_mac_suspend(struct b43_wldev *dev)
> +static void b43_mac_suspend(struct b43_wldev *dev)
> {
> int i;
> u32 tmp;
> diff --git a/drivers/net/wireless/b43/main.h b/drivers/net/wireless/b43/main.h
> index 2d52d9d..4397f49 100644
> --- a/drivers/net/wireless/b43/main.h
> +++ b/drivers/net/wireless/b43/main.h
> @@ -102,9 +102,6 @@ void b43_dummy_transmission(struct b43_wldev *dev);
>
> void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags);
>
> -void b43_mac_suspend(struct b43_wldev *dev);
> -void b43_mac_enable(struct b43_wldev *dev);
> -
> void b43_controller_restart(struct b43_wldev *dev, const char *reason);
>
> #define B43_PS_ENABLED (1 << 0)/* Force enable hardware power
> saving */
>
>
>
--
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: [2.6 patch] make b43_mac_{enable,suspend}() static
On Wednesday 30 January 2008 21:02:47 Adrian Bunk wrote:
b43_mac_{enable,suspend}() can now become static.
Signed-off-by: Adrian Bunk [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
---
drivers/net/wireless/b43/main.c |4 ++--
drivers/net/wireless/b43/main.h |3 ---
2 files changed, 2 insertions(+), 5 deletions(-)
e2a91b00d125ed4b60bdf9e37f550aed23d84747
diff --git a/drivers/net/wireless/b43/main.c b/drivers/net/wireless/b43/main.c
index 88d2c15..360515c 100644
--- a/drivers/net/wireless/b43/main.c
+++ b/drivers/net/wireless/b43/main.c
@@ -2042,7 +2042,7 @@ static void b43_gpio_cleanup(struct b43_wldev *dev)
}
/* http://bcm-specs.sipsolutions.net/EnableMac */
-void b43_mac_enable(struct b43_wldev *dev)
+static void b43_mac_enable(struct b43_wldev *dev)
{
dev-mac_suspended--;
B43_WARN_ON(dev-mac_suspended 0);
@@ -2066,7 +2066,7 @@ void b43_mac_enable(struct b43_wldev *dev)
}
/* http://bcm-specs.sipsolutions.net/SuspendMAC */
-void b43_mac_suspend(struct b43_wldev *dev)
+static void b43_mac_suspend(struct b43_wldev *dev)
{
int i;
u32 tmp;
diff --git a/drivers/net/wireless/b43/main.h b/drivers/net/wireless/b43/main.h
index 2d52d9d..4397f49 100644
--- a/drivers/net/wireless/b43/main.h
+++ b/drivers/net/wireless/b43/main.h
@@ -102,9 +102,6 @@ void b43_dummy_transmission(struct b43_wldev *dev);
void b43_wireless_core_reset(struct b43_wldev *dev, u32 flags);
-void b43_mac_suspend(struct b43_wldev *dev);
-void b43_mac_enable(struct b43_wldev *dev);
-
void b43_controller_restart(struct b43_wldev *dev, const char *reason);
#define B43_PS_ENABLED (1 0)/* Force enable hardware power
saving */
--
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: [PATCH -mm 5/5] b43: Avoid unregistering device objects during suspend
On Friday 25 January 2008 08:47:46 Pavel Machek wrote: > On Fri 2008-01-25 01:37:33, Rafael J. Wysocki wrote: > > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > > > Modify the b43 driver to avoid deadlocking suspend and resume, > > which happens as a result of attempting to unregister device objects > > locked by the PM core during suspend/resume cycles. Also, make it > > use a suspend-safe method of unregistering device object in the > > resume error path. > > > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Acked-by: Michael Buesch <[EMAIL PROTECTED]> > > Maybe we should have global suspend_in_progress (or maybe system_state > == suspending?) and automatically switch to schedule_removal() while > it is set? > That would be great, from my perspective :) -- 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: [PATCH -mm 5/5] b43: Avoid unregistering device objects during suspend
On Friday 25 January 2008 08:47:46 Pavel Machek wrote: On Fri 2008-01-25 01:37:33, Rafael J. Wysocki wrote: From: Rafael J. Wysocki [EMAIL PROTECTED] Modify the b43 driver to avoid deadlocking suspend and resume, which happens as a result of attempting to unregister device objects locked by the PM core during suspend/resume cycles. Also, make it use a suspend-safe method of unregistering device object in the resume error path. Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED] Acked-by: Michael Buesch [EMAIL PROTECTED] Maybe we should have global suspend_in_progress (or maybe system_state == suspending?) and automatically switch to schedule_removal() while it is set? That would be great, from my perspective :) -- 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: Linux 2.6.24-rc7
On Monday 07 January 2008 21:23:44 Alejandro Riveira Fernández wrote: > > > [ 37.043990] WARNING: at > > > /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx() > > > [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 > > > > > > [ 37.043998] > > > > > > [ 37.043999] Call Trace: > > > > > > [ 37.044001][] enqueue_task+0x13/0x30 > > > > > > [ 37.044040] [] :mac80211:__ieee80211_rx+0xc7e/0xd30 > > > > > > [ 37.044044] [] activate_task+0x32/0x50 > > > > > > [ 37.044073] [] > > > :mac80211:ieee80211_tasklet_handler+0xbb/0x120 > > > > > > [ 37.044086] [] tasklet_action+0x48/0xb0 > > > > > > [ 37.044091] [] __do_softirq+0x69/0xe0 > > > > > > [ 37.044097] [] call_softirq+0x1c/0x30 > > > > > > [ 37.044101] [] do_softirq+0x35/0x90 > > > > > > [ 37.044105] [] irq_exit+0x95/0xa0 > > > > > > [ 37.044108] [] do_IRQ+0x80/0x100 > > > > > > [ 37.044111] [] default_idle+0x0/0x40 > > > > > > [ 37.044115] [] ret_from_intr+0x0/0xa > > > > > > [ 37.044117][] default_idle+0x29/0x40 > > > > > > [ 37.044130] [] cpu_idle+0x75/0xc0 > > > > > > [ 37.044146] > > > > > > > > > Can you check if that is the > > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3); > > in rx.c line 1486? > > How can I check? The source code I build does indeed have the line > you quoted on net/mac80211/rx.c:1486 Is that what you are asking for? > > WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3); Yes fine. Patches are on their way. Ignore the warning for now. It is harmless. -- 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: Linux 2.6.24-rc7
On Monday 07 January 2008 21:23:44 Alejandro Riveira Fernández wrote: [ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx() [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 [ 37.043998] [ 37.043999] Call Trace: [ 37.044001] IRQ [80227fe3] enqueue_task+0x13/0x30 [ 37.044040] [88178cbe] :mac80211:__ieee80211_rx+0xc7e/0xd30 [ 37.044044] [80228062] activate_task+0x32/0x50 [ 37.044073] [8816a28b] :mac80211:ieee80211_tasklet_handler+0xbb/0x120 [ 37.044086] [80238d08] tasklet_action+0x48/0xb0 [ 37.044091] [80238c09] __do_softirq+0x69/0xe0 [ 37.044097] [8020ce2c] call_softirq+0x1c/0x30 [ 37.044101] [8020efe5] do_softirq+0x35/0x90 [ 37.044105] [80238aa5] irq_exit+0x95/0xa0 [ 37.044108] [8020f0c0] do_IRQ+0x80/0x100 [ 37.044111] [8020a840] default_idle+0x0/0x40 [ 37.044115] [8020c181] ret_from_intr+0x0/0xa [ 37.044117] EOI [8020a869] default_idle+0x29/0x40 [ 37.044130] [8020a8f5] cpu_idle+0x75/0xc0 [ 37.044146] Can you check if that is the WARN_ON_ONCE(((unsigned long)(skb-data + hdrlen)) 3); in rx.c line 1486? How can I check? The source code I build does indeed have the line you quoted on net/mac80211/rx.c:1486 Is that what you are asking for? WARN_ON_ONCE(((unsigned long)(skb-data + hdrlen)) 3); Yes fine. Patches are on their way. Ignore the warning for now. It is harmless. -- 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: Linux 2.6.24-rc7
On Monday 07 January 2008 17:52:48 Alejandro Riveira Fernández wrote: > El Mon, 7 Jan 2008 17:24:03 +0100 > Michael Buesch <[EMAIL PROTECTED]> escribió: > > > > > > > Can you post the lines above this? > > This might be a WARN_ON_ONCE() triggering, for which fixes are on their way > > into > > the wireless-2.6 tree. > > This? > > > [ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 > __ieee80211_rx() > [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 > > [ 37.043998] > > [ 37.043999] Call Trace: > > [ 37.044001][] enqueue_task+0x13/0x30 > > [ 37.044040] [] :mac80211:__ieee80211_rx+0xc7e/0xd30 > > [ 37.044044] [] activate_task+0x32/0x50 > > [ 37.044073] [] > :mac80211:ieee80211_tasklet_handler+0xbb/0x120 > > [ 37.044086] [] tasklet_action+0x48/0xb0 > > [ 37.044091] [] __do_softirq+0x69/0xe0 > > [ 37.044097] [] call_softirq+0x1c/0x30 > > [ 37.044101] [] do_softirq+0x35/0x90 > > [ 37.044105] [] irq_exit+0x95/0xa0 > > [ 37.044108] [] do_IRQ+0x80/0x100 > > [ 37.044111] [] default_idle+0x0/0x40 > > [ 37.044115] [] ret_from_intr+0x0/0xa > > [ 37.044117][] default_idle+0x29/0x40 > > [ 37.044130] [] cpu_idle+0x75/0xc0 > > [ 37.044146] > Can you check if that is the WARN_ON_ONCE(((unsigned long)(skb->data + hdrlen)) & 3); in rx.c line 1486? If that is the one, then fixes are already on their way upstream. Ignore the harmless warning for now. -- 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: Linux 2.6.24-rc7
On Monday 07 January 2008 17:14:15 Alejandro Riveira Fernández wrote: > El Sun, 6 Jan 2008 14:19:16 -0800 (PST) > Linus Torvalds <[EMAIL PROTECTED]> escribió: > > > > > It's been two weeks since rc6, but let's face it, with xmas and new years > > (and birthdays) in between, there hasn't actually been a lot of working > > days, and the incremental patch from -rc6 is about half the size of the > > one from rc5->rc6. > > > > And I'll be charitable and claim it's because it's all stabilizing, and > > not because we've all been in a drunken stupor over the holidays. > > > > The shortlog (appended below) is short and fairly informative. It's all > > really just a lot of rather small changes. The diffstat shows a lot of > > one- and two-liners, with just a few drivers (and the Cell platform) > > getting a bit more attention, and the SLUB support of /proc/slabinfo > > showing up as a blip. > > > > Both git trees and tar-balls/patches pushed out, should be mirroring out > > within minutes. So there are no excuses to not try it out, and see if your > > favorite regression has been fixed. > > > > Linus > > > Booted with it and I see > > [ 37.043998] > > [ 37.043999] Call Trace: > > [ 37.044001][] enqueue_task+0x13/0x30 > > [ 37.044040] [] :mac80211:__ieee80211_rx+0xc7e/0xd30 > > [ 37.044044] [] activate_task+0x32/0x50 > > [ 37.044073] [] > :mac80211:ieee80211_tasklet_handler+0xbb/0x120 > > [ 37.044086] [] tasklet_action+0x48/0xb0 > > [ 37.044091] [] __do_softirq+0x69/0xe0 > > [ 37.044097] [] call_softirq+0x1c/0x30 > > [ 37.044101] [] do_softirq+0x35/0x90 > > [ 37.044105] [] irq_exit+0x95/0xa0 > > [ 37.044108] [] do_IRQ+0x80/0x100 > > [ 37.044111] [] default_idle+0x0/0x40 > > [ 37.044115] [] ret_from_intr+0x0/0xa > > [ 37.044117][] default_idle+0x29/0x40 > > [ 37.044130] [] cpu_idle+0x75/0xc0 > > [ 37.044146] > Can you post the lines above this? This might be a WARN_ON_ONCE() triggering, for which fixes are on their way into the wireless-2.6 tree. -- 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: Linux 2.6.24-rc7
On Monday 07 January 2008 17:14:15 Alejandro Riveira Fernández wrote: El Sun, 6 Jan 2008 14:19:16 -0800 (PST) Linus Torvalds [EMAIL PROTECTED] escribió: It's been two weeks since rc6, but let's face it, with xmas and new years (and birthdays) in between, there hasn't actually been a lot of working days, and the incremental patch from -rc6 is about half the size of the one from rc5-rc6. And I'll be charitable and claim it's because it's all stabilizing, and not because we've all been in a drunken stupor over the holidays. The shortlog (appended below) is short and fairly informative. It's all really just a lot of rather small changes. The diffstat shows a lot of one- and two-liners, with just a few drivers (and the Cell platform) getting a bit more attention, and the SLUB support of /proc/slabinfo showing up as a blip. Both git trees and tar-balls/patches pushed out, should be mirroring out within minutes. So there are no excuses to not try it out, and see if your favorite regression has been fixed. Linus Booted with it and I see [ 37.043998] [ 37.043999] Call Trace: [ 37.044001] IRQ [80227fe3] enqueue_task+0x13/0x30 [ 37.044040] [88178cbe] :mac80211:__ieee80211_rx+0xc7e/0xd30 [ 37.044044] [80228062] activate_task+0x32/0x50 [ 37.044073] [8816a28b] :mac80211:ieee80211_tasklet_handler+0xbb/0x120 [ 37.044086] [80238d08] tasklet_action+0x48/0xb0 [ 37.044091] [80238c09] __do_softirq+0x69/0xe0 [ 37.044097] [8020ce2c] call_softirq+0x1c/0x30 [ 37.044101] [8020efe5] do_softirq+0x35/0x90 [ 37.044105] [80238aa5] irq_exit+0x95/0xa0 [ 37.044108] [8020f0c0] do_IRQ+0x80/0x100 [ 37.044111] [8020a840] default_idle+0x0/0x40 [ 37.044115] [8020c181] ret_from_intr+0x0/0xa [ 37.044117] EOI [8020a869] default_idle+0x29/0x40 [ 37.044130] [8020a8f5] cpu_idle+0x75/0xc0 [ 37.044146] Can you post the lines above this? This might be a WARN_ON_ONCE() triggering, for which fixes are on their way into the wireless-2.6 tree. -- 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: Linux 2.6.24-rc7
On Monday 07 January 2008 17:52:48 Alejandro Riveira Fernández wrote: El Mon, 7 Jan 2008 17:24:03 +0100 Michael Buesch [EMAIL PROTECTED] escribió: Can you post the lines above this? This might be a WARN_ON_ONCE() triggering, for which fixes are on their way into the wireless-2.6 tree. This? [ 37.043990] WARNING: at /home/alex/kernel/linux-2.6/net/mac80211/rx.c:1486 __ieee80211_rx() [ 37.043996] Pid: 0, comm: swapper Not tainted 2.6.24-rc7 #3 [ 37.043998] [ 37.043999] Call Trace: [ 37.044001] IRQ [80227fe3] enqueue_task+0x13/0x30 [ 37.044040] [88178cbe] :mac80211:__ieee80211_rx+0xc7e/0xd30 [ 37.044044] [80228062] activate_task+0x32/0x50 [ 37.044073] [8816a28b] :mac80211:ieee80211_tasklet_handler+0xbb/0x120 [ 37.044086] [80238d08] tasklet_action+0x48/0xb0 [ 37.044091] [80238c09] __do_softirq+0x69/0xe0 [ 37.044097] [8020ce2c] call_softirq+0x1c/0x30 [ 37.044101] [8020efe5] do_softirq+0x35/0x90 [ 37.044105] [80238aa5] irq_exit+0x95/0xa0 [ 37.044108] [8020f0c0] do_IRQ+0x80/0x100 [ 37.044111] [8020a840] default_idle+0x0/0x40 [ 37.044115] [8020c181] ret_from_intr+0x0/0xa [ 37.044117] EOI [8020a869] default_idle+0x29/0x40 [ 37.044130] [8020a8f5] cpu_idle+0x75/0xc0 [ 37.044146] Can you check if that is the WARN_ON_ONCE(((unsigned long)(skb-data + hdrlen)) 3); in rx.c line 1486? If that is the one, then fixes are already on their way upstream. Ignore the harmless warning for now. -- 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: [PATCH] iwlwifi: fix compilation warning in 'iwl-4965.c'
On Friday 04 January 2008 23:05:54 Miguel Botón wrote:
> This patch fixes a compilation warning in 'iwl-4965.c'.
>
> Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
>
> diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
> b/drivers/net/wireless/iwlwifi/iwl-4965.c
> index 74999af..92237cd 100644
> --- a/drivers/net/wireless/iwlwifi/iwl-4965.c
> +++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
> @@ -3616,7 +3616,7 @@ static void iwl4965_add_radiotap(struct iwl4965_priv
> *priv,
> if (skb_headroom(skb) < sizeof(*iwl4965_rt)) {
> if (net_ratelimit())
> printk(KERN_ERR "not enough headroom [%d] for "
> -"radiotap head [%d]\n",
> +"radiotap head [%ld]\n",
> skb_headroom(skb), sizeof(*iwl4965_rt));
I think %zu is the correct and portable integer conversion for a size_t type.
The kernel implementation seems to support 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: [PATCH] iwlwifi: fix compilation warning in 'iwl-4965.c'
On Friday 04 January 2008 23:05:54 Miguel Botón wrote:
This patch fixes a compilation warning in 'iwl-4965.c'.
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
diff --git a/drivers/net/wireless/iwlwifi/iwl-4965.c
b/drivers/net/wireless/iwlwifi/iwl-4965.c
index 74999af..92237cd 100644
--- a/drivers/net/wireless/iwlwifi/iwl-4965.c
+++ b/drivers/net/wireless/iwlwifi/iwl-4965.c
@@ -3616,7 +3616,7 @@ static void iwl4965_add_radiotap(struct iwl4965_priv
*priv,
if (skb_headroom(skb) sizeof(*iwl4965_rt)) {
if (net_ratelimit())
printk(KERN_ERR not enough headroom [%d] for
-radiotap head [%d]\n,
+radiotap head [%ld]\n,
skb_headroom(skb), sizeof(*iwl4965_rt));
I think %zu is the correct and portable integer conversion for a size_t type.
The kernel implementation seems to support 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: [PATCH 1/2] ssb: add 'ssb_pcihost_set_power_state' function
On Tuesday 01 January 2008 01:16:46 Miguel Botón wrote:
> This patch adds the 'ssb_pcihost_set_power_state' function.
>
> This function allows us to set the power state of a PCI device
> (for example b44 ethernet device).
>
> Signed-off-by: Miguel Botón <[EMAIL PROTECTED]>
Acked-by: Michael Buesch <[EMAIL PROTECTED]>
>
> diff --git a/include/linux/ssb/ssb.h b/include/linux/ssb/ssb.h
> index a21ab29..aa70fd0 100644
> --- a/include/linux/ssb/ssb.h
> +++ b/include/linux/ssb/ssb.h
> @@ -349,6 +349,13 @@ static inline void ssb_pcihost_unregister(struct
> pci_driver *driver)
> {
> pci_unregister_driver(driver);
> }
> +
> +static inline
> +void ssb_pcihost_set_power_state(struct ssb_device *sdev, pci_power_t state)
> +{
> + if (sdev->bus->bustype == SSB_BUSTYPE_PCI)
> + pci_set_power_state(sdev->bus->host_pci, state);
> +}
> #endif /* CONFIG_SSB_PCIHOST */
>
>
>
--
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: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 19:37:43 Torsten Kaiser wrote: > The base problem is that there already are many options to break > external modules. (CONFIG_MODULES=n ;) ) Exactly. There already are enough ways to break external modules. No need to introduce more. ;) > The question I can't answer in this context is: Do distributions want > to support external modules? > Only if yes, your argument is valid. But then they could just disable > this feature and prevent this kind of bugreports. That's my point. Nobody will risk bugs to save a few bytes of memory. -- 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: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 17:38:03 Alan Cox wrote: > On Mon, 31 Dec 2007 17:17:19 +0100 > "Torsten Kaiser" <[EMAIL PROTECTED]> wrote: > > > a) this could be disabled during development if you want this > > b) this would even only affect development if you add new code that > > now needs a EXPORT_SYMBOL that was removed on an earlier build. And > > right now this would also need to trigger a rerun of depmod. And the > > same trigger could redo this garbage collect. > > > > Or am I missing something obvious? > > Development is not a phase seperate from use or distribution. A lot of > module testers for distributions will not be compiling their own modules > but loading in ones to test provided by their vendor - which may of > course then need different ksyms As an example, the whole purpose wireless-compat package is to load latest bleeding edge wireless stuff into a distribution kernel. So people are not required to recompile their kernels for using drivers that support their hardware. And guess what, it is used a _lot_. And lots of bugs are found with it. It increases our testing community a lot. So, all this wouldn't work, if kernel symbols could randomly get nuked by some "garbage collector". In practice, no distribution would use symbol garbage collection, as the only benefit from it would be an increased level of bugreports. -- 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: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote: > On Dec 31, 2007 3:42 PM, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the > > theoretical possibility of CONIG_UNIX=m waste a few hundred bytes > > of memory. > > One thing I always wondered about in this discussion about wasted > EXPORT_SYMBOL's: > Shouldn't it be possible to garbage collect these? > > depmod already contains code to analyze all modules to create a > dependency tree. It should not be too difficult to extend it to create > a list of all symbols that really are used by the current modules. > Everything else could be stripped to save space. > > The problem with that: > * out-of-tree modules would break if they don't get lucky to only use > the remaining symbol. I would not see this as a problem, if the help > text of the garbage-collect-option would contain a note like "don't > enable this if you want out-of-tree modules". > * if you later change your .config to include additional modules you > might need to rebuild vmlinux and reboot into the new kernel. > Currently you can probably build and load new modules without a > reboot. (for example: usb drivers) I'd say the practical advantage to the user would be almost zero. Which distribution is going to enable this option and defacto banning external modules? -- 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: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 16:55:57 Torsten Kaiser wrote: On Dec 31, 2007 3:42 PM, Adrian Bunk [EMAIL PROTECTED] wrote: With CONFIG_MODULES=y the 13 EXPORT_SYMBOL's that only exist for the theoretical possibility of CONIG_UNIX=m waste a few hundred bytes of memory. One thing I always wondered about in this discussion about wasted EXPORT_SYMBOL's: Shouldn't it be possible to garbage collect these? depmod already contains code to analyze all modules to create a dependency tree. It should not be too difficult to extend it to create a list of all symbols that really are used by the current modules. Everything else could be stripped to save space. The problem with that: * out-of-tree modules would break if they don't get lucky to only use the remaining symbol. I would not see this as a problem, if the help text of the garbage-collect-option would contain a note like don't enable this if you want out-of-tree modules. * if you later change your .config to include additional modules you might need to rebuild vmlinux and reboot into the new kernel. Currently you can probably build and load new modules without a reboot. (for example: usb drivers) I'd say the practical advantage to the user would be almost zero. Which distribution is going to enable this option and defacto banning external modules? -- 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: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 17:38:03 Alan Cox wrote: On Mon, 31 Dec 2007 17:17:19 +0100 Torsten Kaiser [EMAIL PROTECTED] wrote: a) this could be disabled during development if you want this b) this would even only affect development if you add new code that now needs a EXPORT_SYMBOL that was removed on an earlier build. And right now this would also need to trigger a rerun of depmod. And the same trigger could redo this garbage collect. Or am I missing something obvious? Development is not a phase seperate from use or distribution. A lot of module testers for distributions will not be compiling their own modules but loading in ones to test provided by their vendor - which may of course then need different ksyms As an example, the whole purpose wireless-compat package is to load latest bleeding edge wireless stuff into a distribution kernel. So people are not required to recompile their kernels for using drivers that support their hardware. And guess what, it is used a _lot_. And lots of bugs are found with it. It increases our testing community a lot. So, all this wouldn't work, if kernel symbols could randomly get nuked by some garbage collector. In practice, no distribution would use symbol garbage collection, as the only benefit from it would be an increased level of bugreports. -- 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: [PATCH] Force UNIX domain sockets to be built in
On Monday 31 December 2007 19:37:43 Torsten Kaiser wrote: The base problem is that there already are many options to break external modules. (CONFIG_MODULES=n ;) ) Exactly. There already are enough ways to break external modules. No need to introduce more. ;) The question I can't answer in this context is: Do distributions want to support external modules? Only if yes, your argument is valid. But then they could just disable this feature and prevent this kind of bugreports. That's my point. Nobody will risk bugs to save a few bytes of memory. -- 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: [PATCH 1/2] ssb: add 'ssb_pcihost_set_power_state' function
On Tuesday 01 January 2008 01:16:46 Miguel Botón wrote:
This patch adds the 'ssb_pcihost_set_power_state' function.
This function allows us to set the power state of a PCI device
(for example b44 ethernet device).
Signed-off-by: Miguel Botón [EMAIL PROTECTED]
Acked-by: Michael Buesch [EMAIL PROTECTED]
diff --git a/include/linux/ssb/ssb.h b/include/linux/ssb/ssb.h
index a21ab29..aa70fd0 100644
--- a/include/linux/ssb/ssb.h
+++ b/include/linux/ssb/ssb.h
@@ -349,6 +349,13 @@ static inline void ssb_pcihost_unregister(struct
pci_driver *driver)
{
pci_unregister_driver(driver);
}
+
+static inline
+void ssb_pcihost_set_power_state(struct ssb_device *sdev, pci_power_t state)
+{
+ if (sdev-bus-bustype == SSB_BUSTYPE_PCI)
+ pci_set_power_state(sdev-bus-host_pci, state);
+}
#endif /* CONFIG_SSB_PCIHOST */
--
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: Boot time module loading problem
On Sunday 23 December 2007 20:39:18 Larry Finger wrote: > With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module, > which should be loaded by > the ssb module, fails with the following type of message: > > ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 > b43: disagrees about version of symbol ssb_device_is_enabled > b43: Unknown symbol ssb_device_is_enabled > b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable > b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable > b43: disagrees about version of symbol ssb_bus_may_powerdown > b43: Unknown symbol ssb_bus_may_powerdown This is a module versioning warning. I think it's caused by a b43 compiled against a different kernel tree than the currently running ssb module. Different may mean that only a tiny little thing was changed, which might not affect the API at all. modversion will complain then. I don't use module versioning, so I can't help you how to fix this. I'd simply suggest turning off module versioning. -- 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: Boot time module loading problem
On Sunday 23 December 2007 20:39:18 Larry Finger wrote: With 2.6.24-rc5, a b43 user reports a problem at bootup. The b43 module, which should be loaded by the ssb module, fails with the following type of message: ssb: Sonics Silicon Backplane found on PCI device :0c:00.0 b43: disagrees about version of symbol ssb_device_is_enabled b43: Unknown symbol ssb_device_is_enabled b43: disagrees about version of symbol ssb_pcicore_dev_irqvecs_enable b43: Unknown symbol ssb_pcicore_dev_irqvecs_enable b43: disagrees about version of symbol ssb_bus_may_powerdown b43: Unknown symbol ssb_bus_may_powerdown This is a module versioning warning. I think it's caused by a b43 compiled against a different kernel tree than the currently running ssb module. Different may mean that only a tiny little thing was changed, which might not affect the API at all. modversion will complain then. I don't use module versioning, so I can't help you how to fix this. I'd simply suggest turning off module versioning. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote: > On Dec 17, 2007 5:45 PM, Michael Buesch <[EMAIL PROTECTED]> wrote: > > > > Ehm, excuse me. > > What are you doing exactly? In this thread you told me you have > > a device which requires b43: > > > > Well, I'm not sure what you mean by "requires" b43, but I did say that > the device uses the b43 driver. Requires means requires. > Sorry, I should have been more specific. I figured since the device > could use bcm43xx, it could also use b43legacy, so I copied the > entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the > b43legacy driver. I removed the b43 and ssb modules, and inserted the > b43legacy module. Afterwards, I noticed b43 had still been autoloaded, > so I removed it (I checked dmesg and only b43legacy had initialized > anyway) , and proceeded to use the b43legacy driver with the version 3 > firmware. And like I said, it works exactly like the b43 driver with > the version 4 firmware. I'm not sure what you are trying to show with this hack. It's been said several times in this thread that the firmware has nothing to do with the device radio. So it won't affect the transmit rate or something like that. Note that the difference between b43 and b43legacy is NOT that the driver is "legacy". It is called legacy because it does _only_ support legacy _devices_. So if you hack it to drive a new card it will only work by luck (luck as in there might be some code left over which is able to initialize the device somehow.). My point being, we removed code for new devices from b43legacy and are probably going to remove even more stuff in the future. So there is simply no point in testing any new device with b43legacy. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote: > On Dec 17, 2007 5:35 AM, <[EMAIL PROTECTED]> wrote: > > If this is a mac80211 related problem, then other systems connecting > > to the same ap and using mac80211 would also be affected? Like I said > > earlier, there are five machines connecting to this ap, and I just > > realized one of them has a ralink card that uses the rt2x00 driver, > > which I believe is mac80211. That system doesn't have this problem, > > which leads me to believe it may not be mac80211 after all, although I > > wouldn't rule it out. > > > > This also doesn't seem to be related to firmware version. I forced my > device to use b43legacy, and the results were identical with the > version 3 firmware. Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: > I don't know what happened before, but after a reboot, I can't repeat > the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I > didn't move the laptop, or the ap, the only thing I can think of that > might have changed is the noise level. FWIW, link quality is > consistently the same or better with b43. How the hell can you now "force it to use b43legacy"?? -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote: > On Dec 17, 2007 1:52 AM, Larry Finger <[EMAIL PROTECTED]> wrote: > > > > One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the > > former always used a fixed > > rate; whereas mac80211 tries to adjust the bit rate according to the > > transmission conditions. > > Perhaps it isn't working quite right in your case because of some > > peculiarity of your AP. IIRC, you > > have an 802.11b AP. If so, you will get the same bit speed behavior for > > mac80211 as for bcdm43xx by > > issuing a 'sudo iwconfig eth1 rate 11M' command. > > I don't know what happened before, but after a reboot, I can't repeat > the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I > didn't move the laptop, or the ap, the only thing I can think of that > might have changed is the noise level. FWIW, link quality is > consistently the same or better with b43. > > Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and > quickly scales to 11 Mb/s, but I tried setting it manually anyway and > didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as > 1 Mb/s and the download speed was the same with all three (around > 30-40 kB/s). Are you working with wireless-2.6's #everything branch? -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Monday 17 December 2007 08:17:58 [EMAIL PROTECTED] wrote: On Dec 17, 2007 1:52 AM, Larry Finger [EMAIL PROTECTED] wrote: One major difference between bcm43xx-SoftMAC and b43-mac80211 is that the former always used a fixed rate; whereas mac80211 tries to adjust the bit rate according to the transmission conditions. Perhaps it isn't working quite right in your case because of some peculiarity of your AP. IIRC, you have an 802.11b AP. If so, you will get the same bit speed behavior for mac80211 as for bcdm43xx by issuing a 'sudo iwconfig eth1 rate 11M' command. I don't know what happened before, but after a reboot, I can't repeat the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I didn't move the laptop, or the ap, the only thing I can think of that might have changed is the noise level. FWIW, link quality is consistently the same or better with b43. Anyway, I'd noticed before that the bit rate starts at 1 Mb/s and quickly scales to 11 Mb/s, but I tried setting it manually anyway and didn't see any change. In fact, I set the rate to 5.5 Mb/s as well as 1 Mb/s and the download speed was the same with all three (around 30-40 kB/s). Are you working with wireless-2.6's #everything branch? -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Monday 17 December 2007 23:04:37 [EMAIL PROTECTED] wrote: On Dec 17, 2007 5:35 AM, [EMAIL PROTECTED] wrote: If this is a mac80211 related problem, then other systems connecting to the same ap and using mac80211 would also be affected? Like I said earlier, there are five machines connecting to this ap, and I just realized one of them has a ralink card that uses the rt2x00 driver, which I believe is mac80211. That system doesn't have this problem, which leads me to believe it may not be mac80211 after all, although I wouldn't rule it out. This also doesn't seem to be related to firmware version. I forced my device to use b43legacy, and the results were identical with the version 3 firmware. Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: I don't know what happened before, but after a reboot, I can't repeat the 200 kB/s speed. It's back down to 40 kB/s, just like originally. I didn't move the laptop, or the ap, the only thing I can think of that might have changed is the noise level. FWIW, link quality is consistently the same or better with b43. How the hell can you now force it to use b43legacy?? -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Tuesday 18 December 2007 00:12:30 [EMAIL PROTECTED] wrote: On Dec 17, 2007 5:45 PM, Michael Buesch [EMAIL PROTECTED] wrote: Ehm, excuse me. What are you doing exactly? In this thread you told me you have a device which requires b43: Well, I'm not sure what you mean by requires b43, but I did say that the device uses the b43 driver. Requires means requires. Sorry, I should have been more specific. I figured since the device could use bcm43xx, it could also use b43legacy, so I copied the entries in b43_ssb_tbl[] to b43legacy_ssb_tbl[] and rebuilt the b43legacy driver. I removed the b43 and ssb modules, and inserted the b43legacy module. Afterwards, I noticed b43 had still been autoloaded, so I removed it (I checked dmesg and only b43legacy had initialized anyway) , and proceeded to use the b43legacy driver with the version 3 firmware. And like I said, it works exactly like the b43 driver with the version 4 firmware. I'm not sure what you are trying to show with this hack. It's been said several times in this thread that the firmware has nothing to do with the device radio. So it won't affect the transmit rate or something like that. Note that the difference between b43 and b43legacy is NOT that the driver is legacy. It is called legacy because it does _only_ support legacy _devices_. So if you hack it to drive a new card it will only work by luck (luck as in there might be some code left over which is able to initialize the device somehow.). My point being, we removed code for new devices from b43legacy and are probably going to remove even more stuff in the future. So there is simply no point in testing any new device with b43legacy. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote: > > * John W. Linville <[EMAIL PROTECTED]> wrote: > > > > It's not that simple. For example, regression testing will be a > > > major PITA if one needs to switch back and forth from the new driver > > > to the old one in the process. > > > > Not really true -- a single system can easily have firmware installed > > for b43, b43legacy, and bcm43xx at the same time and switch back and > > forth between them. > > as long as the version 4 firmware blob is present in the system, will > testers have a fully fluid test- and work-flow when migrating across > from bcm43xx to b43, without any other changes to an existing Linux > installation? (i.e. no udev tweaks, no forced upgrades of components, > etc.) > > Will it Just Work in bisection as well, when a tester's kernel > flip/flops between bcm43xx and b43 - like it does for the other 3000+ > drivers in the kernel? > > Note that we are _NOT_ interested in "might" or "can" scenarios. We are > interested in preserving the _existing_ bcm43xx installed base and how > much of a seemless migration the b43 transition will be. _THAT_ is what > the "no regressions" upstream rule is about, not the "ideal distro" > scenario you outline above. It is YOUR total obligation as a kernel > maintainer to ensure that you dont break old installations. How hard is > that to understand? This is not rocket science. I see no reason for b43 to break, if the firmware is properly installed. In fact, almost all installation related bugreports we receive are caused by missing or incorrectly installed firmware. I would really _like_ to make installing firmware easier or make the whole need for it vanish, but I simply can not at this point. But anyway, installing it is not rocket science, either. The only thing you have to know is where your distribution stores the firmware image files. If you know that it's a matter of invoking one b43-fwcutter command to install it. This process can be automated in the distribution's rpm or deb package scripts. b43lagacy/ssb is completely featured with module autoload support. So if you have firmware installed it will automatically load all required modules and create the network device(s) for it without any user interaction. If that doesn't work, then stupid distributions are shipping braindamaged udev scripts that pin a mac address to a specific driver name (see another mail in this thread). I can _not_ fix this from within the kernel and I will absolutely shift all responsibility and blame for this to the maintainers of the distribution's udev scripts. That's not a b43 specific problem then. Other drivers do break with these scripts, too. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 03:30:16 Larry Finger wrote: > Michael Buesch wrote: > > On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > >> Well, the only problem with that is I suspect there are some "newer" cards > >> that > >> work better with v3 firmware, although they are supposed to support both. > > > > And I suspect that you are wrong until you show me one. :) > > The BCM4311/1 card used to work better with bcm43xx than it did with b43; > however, since the power > control problem was "solved" in b43, there is very little difference. When I > built my special system > to use the BCM4311 with b43legacy, there was no difference. > > I don't know of any cards that work better with bcm43xx than with b43. Of > course, that is comparing > SoftMAC with mac80211. There is, of course, no comparison. This was about version 3 firmware vs version 4 firmware. I doubt the firmware makes any difference at all. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 03:30:16 Larry Finger wrote: Michael Buesch wrote: On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) The BCM4311/1 card used to work better with bcm43xx than it did with b43; however, since the power control problem was solved in b43, there is very little difference. When I built my special system to use the BCM4311 with b43legacy, there was no difference. I don't know of any cards that work better with bcm43xx than with b43. Of course, that is comparing SoftMAC with mac80211. There is, of course, no comparison. This was about version 3 firmware vs version 4 firmware. I doubt the firmware makes any difference at all. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 10:22:43 Ingo Molnar wrote: * John W. Linville [EMAIL PROTECTED] wrote: It's not that simple. For example, regression testing will be a major PITA if one needs to switch back and forth from the new driver to the old one in the process. Not really true -- a single system can easily have firmware installed for b43, b43legacy, and bcm43xx at the same time and switch back and forth between them. as long as the version 4 firmware blob is present in the system, will testers have a fully fluid test- and work-flow when migrating across from bcm43xx to b43, without any other changes to an existing Linux installation? (i.e. no udev tweaks, no forced upgrades of components, etc.) Will it Just Work in bisection as well, when a tester's kernel flip/flops between bcm43xx and b43 - like it does for the other 3000+ drivers in the kernel? Note that we are _NOT_ interested in might or can scenarios. We are interested in preserving the _existing_ bcm43xx installed base and how much of a seemless migration the b43 transition will be. _THAT_ is what the no regressions upstream rule is about, not the ideal distro scenario you outline above. It is YOUR total obligation as a kernel maintainer to ensure that you dont break old installations. How hard is that to understand? This is not rocket science. I see no reason for b43 to break, if the firmware is properly installed. In fact, almost all installation related bugreports we receive are caused by missing or incorrectly installed firmware. I would really _like_ to make installing firmware easier or make the whole need for it vanish, but I simply can not at this point. But anyway, installing it is not rocket science, either. The only thing you have to know is where your distribution stores the firmware image files. If you know that it's a matter of invoking one b43-fwcutter command to install it. This process can be automated in the distribution's rpm or deb package scripts. b43lagacy/ssb is completely featured with module autoload support. So if you have firmware installed it will automatically load all required modules and create the network device(s) for it without any user interaction. If that doesn't work, then stupid distributions are shipping braindamaged udev scripts that pin a mac address to a specific driver name (see another mail in this thread). I can _not_ fix this from within the kernel and I will absolutely shift all responsibility and blame for this to the maintainers of the distribution's udev scripts. That's not a b43 specific problem then. Other drivers do break with these scripts, too. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: > Well, the only problem with that is I suspect there are some "newer" cards > that > work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: > On Friday, 14 of December 2007, Michael Buesch wrote: > > On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: > > > > This user did get the following messages in dmesg: > > > > > > > > b43err(dev->wl, "Firmware file \"%s\" not found " > > > >"or load failed.\n", path); > > > > > > So the question seems to be why b43 needs version 4, when b43legacy and > > > bcm43x uses version 3? > > > > That's really a question, right? > > > > Well. linux-2.4 doesn't work with the linux-2.6 modutils. > > Windows Vista doesn't work with Windows 98 device drivers. > > That leads to this assumption: > > b43 doesn't work with version 3 firmware but needs version 4. > > > > Newer drivers supporting newer hardware need newer firmware. > > Actually, can you explain why, from the technical point of view, the version 4 > firware is better than version 3, please? version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. We have to live with that crap until someone comes up with an opensource firmware. :) -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Saturday 15 December 2007 01:51:47 Rafael J. Wysocki wrote: On Friday, 14 of December 2007, Michael Buesch wrote: On Friday 14 December 2007 13:59:54 Simon Holm Thøgersen wrote: This user did get the following messages in dmesg: b43err(dev-wl, Firmware file \%s\ not found or load failed.\n, path); So the question seems to be why b43 needs version 4, when b43legacy and bcm43x uses version 3? That's really a question, right? Well. linux-2.4 doesn't work with the linux-2.6 modutils. Windows Vista doesn't work with Windows 98 device drivers. That leads to this assumption: b43 doesn't work with version 3 firmware but needs version 4. Newer drivers supporting newer hardware need newer firmware. Actually, can you explain why, from the technical point of view, the version 4 firware is better than version 3, please? version 4 is the new firmware released by broadcom. They obviously won't support and write any version 3 firmware anymore. So we are forced to switch to version 4 firmware to support the newest hardware (like N-PHY in the future). It's really as simple as that. The difference between v3 and v4 is basically the driver API. It changed a lot and it is nontrivial to support both v3 and v4 in one driver. So we decided to stay with v3 for legacy devices and take v4 for any newer devices. We have to live with that crap until someone comes up with an opensource firmware. :) -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Sunday 16 December 2007 00:18:43 Rafael J. Wysocki wrote: Well, the only problem with that is I suspect there are some newer cards that work better with v3 firmware, although they are supposed to support both. And I suspect that you are wrong until you show me one. :) -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 20:55:43 Ray Lee wrote: > Oh. My. God. > > Michael. I have a degree in Physics. I placed sixth in the world > finals of the ACM Collegiate programming contest in 1999, Cal Poly > Team Gold. ( http://icpc.baylor.edu/past/icpc99/Finals/Tour/Win/Win.html > , I'm the guy all the way to the right. ) I ported the 2.4 kernel to a > custom ppc platform, including writing drivers for various hardware on > it ( http://patinc.com ). I'm the guy who did all the software for a > linux-based Voice over IP call center ( > http://broncocommunications.com/ ). Nice. I am one of the main b43 developers and I wrote most of the code. I know most of the code from the top of my head. Besides that my weiner is bigger than yours. :P > To answer your question, it requests the rfkill-input module. But > under the version I'm trying, rfkill-input is not automatically > loaded. It is not an issue. You can even rmmod rfkill-input in FULL operation. It will not disturb the operation, except that an LED stops working. Try it! (I _did_ try it). > I've pointed to the mailing list URL that proves that. So, I > loaded rfkill and rfkill-input by hand. Perhaps rfkill wasn't > necessary, I don't know, and I don't care. But once I did that, *then > and only then* did your damn b43 driver start printing out any > messages to dmesg at all, which then let me download the latest > firmware, and continue moving forward. The b43 does print _nothing_ on modprobe. That is _correct_ behaviour. b43 does print the firmware message after "ifconfig up". Might it be possible that this was coincidence and you messed with modprobe rfkill and ifconfig up and finally saw the message? > > You are telling me that I don't understand patches that I sign off > > and I should not take this personally? > > That is challenging. > > I'm saying the patch you signed off on has a side-effect that will fix > my issue. And even if I *were* saying that, the most you should take Ok. So please revert that patch and try to reproduce the breakage. Does that work? > from it is that you are human and sometimes may make mistakes, just I am inhuman. We all know that. (That was a joke that you probably don't understand. But you can google for "bcw vs. bcm43xx" :) ) Ray, I _do_ want to understand what is going on in your machine. I _have_ to understand it. But I currently do not understand how the quoted patch could fix modprobe of b43 or rfkill. I'd simply call that impossible. Impossible because the patch does change a few function called _inside_ of the b43 module. How could that fix load of the b43 module? (Note that we are not changing some modprobe magic like the ID table). So could you please try to reproduce the breakage by reverting that patch again? Just to make really sure it is this patch fixing the issue and not just some coincidence. Thanks for your help. -- 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: [PATCH 3/3] net: wireless: bcm43xx: big_buffer_sem semaphore to mutex
On Friday 14 December 2007 20:25:39 Ray Lee wrote:
> > I'm sorry. The patch that _you_ quoted fixes a blinking LED
> > and nothing else.
>
> Well, you're wrong. Sorry, but that's just the way it is. See below.
>
> > It does _not_ fix loading of rfkill or b43 in any way.
> > It does, however, fix loading of rfkill-input. But the b43 module
> > operation does _not_ depend in any way on the rfkill-input module, except
> > the tiny LED that doesn't blink if it's not loaded.
> > I hope you understood now that the thread on bcm43xx-dev was NOT about
> > your requirement to load rfkill before b43.
>
> *AGAIN*, please read your message here, in particular item number
> seven on Larry's list:
>
> https://lists.berlios.de/pipermail/bcm43xx-dev/2007-December/006472.html
>
> For the last fscking time, if rfkill and rfkill-input are not loaded,
> not one line comes out in dmesg when b43 and ssb are loaded. In
> particular, your pretty little message about needing newer firmware
> also does not print. So, yeah, not loading rfkill{,-input} *does*
> cause issues with b43 working, as there's no damn way to find out
> what's broken!
Guy... .
I KNOW what the patch above does.
What do you think does the following line?
err = request_module("rfkill-input");
Does it load the "rfkill-input" or the "rfkill" module.
That's the million dollar question. You only have one try.
This patch is NOT about the "rfkill" module. I don't know how
often I have to say that. It is _obvious_.
Let's also quote Larry's sevenths point here, that you referred to
now for the second time:
" (7) If rfkill-input is built as a module, it is not automatically loaded."
I am not sure how I can make this any more clear.
It does load the "rfkill-input" module from within b43.
It does NOT load "rfkill"
It does NOT load "rfkill-input" BEFORE b43 was loaded.
This patch does exactly ONE thing. It does make sure a LED does blink.
Nothing more.
I signed this patch off. So you can be 100% sure I know what it does.
I do NOT sign off patches for which I don't know what they do.
> > > I have complete current userspace as of yesterday's Ubuntu Hardy Heron
> > > development archives.
> >
> > Ok. I will install a copy of Ubuntu Hardy Heron and check if I can
> > reproduce this.
>
> I'm not asking you to do that, this particular bug will be fixed by
> Larry's patch, whether you believe that or not.
Did you try that?
How can b43 load get fixed by a patch that adds a request_module()
to the b43 module? That is a chicken and egg problem!
> > However the fact that this does not happen on older Ubuntu platforms
> > and does not happen on Fedora leads to the conclusion that it
> > is a bug in Hardy Heron that I am not responsible for.
>
> The kernel does not exist in a vacuum. It's the kernel's job to make
> sure it works with properly written userspace. Broken userspace, sure,
> then we can talk about breaking it.
yes properly written userspace.
> > And you also do realise that Hardy Heron is the current development
> > version of Ubuntu? Development versions have bugs.
>
> Oy vay. I'm not an idiot. Yes, it's the current develoment version.
> But tracking the latest kernel.org kernel has in the past required the
> latest develoment version of the distribution, so I upgrade it as
> well.
I am running wireless-2.6 on feisty. So the kernel does _not_ require
an update of the distribution.
q.e.d.
> I'm not blaming it on you. I'm merely reporting a fucking
> incompatibility. Read my messages again from the top, and stop taking
> this all so damn personally, will you?
You are telling me that I don't understand patches that I sign off
and I should not take this personally?
That is challenging.
--
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/
