Failed Build of modules for 2.6.27.9-159

Failed Build of modules for 2.6.27.9-159

[Paul Hickey]

Ath9k is part of (my) Fedora 10 and loaded in kernel
2.6.27-9.159.fc10.x86_64. mac80211 is loaded when Ath9k is loaded and
loads cfg80211. mac80211 can be loaded without loading Ath9k (you still
get cfg80211) but one of them gives a never ending log entry of
=46orceXPAon:0

I have a valid .config file
I have the kernel headers and development files as well.

[root@panda4 compat-wireless-2009-01-18]# make
make -C /lib/modules/2.6.27.9-159.fc10.x86_64/build
M=3D/home/paul/Download/compat-wireless-2009-01-18 modules
make[1]: Entering directory `/usr/src/kernels/2.6.27.9-159.fc10.x86_64'

Message from syslogd@panda4 at Jan 18 15:50:48 ...
kernel:Disabling IRQ #16
  CC
[M]  /home/paul/Download/compat-wireless-2009-01-18/net/wireless/compat=
=2Eo
/home/paul/Download/compat-wireless-2009-01-18/net/wireless/compat.c:18=
:
error: redefinition of =E2=80=98pci_ioremap_bar=E2=80=99
include/linux/pci.h:1127: error: previous definition of
=E2=80=98pci_ioremap_bar=E2=80=99 was here
make[3]: ***
[/home/paul/Download/compat-wireless-2009-01-18/net/wireless/compat.o]
Error 1
make[2]: ***
[/home/paul/Download/compat-wireless-2009-01-18/net/wireless] Error 2
make[1]: *** [_module_/home/paul/Download/compat-wireless-2009-01-18]
Error 2
make[1]: Leaving directory `/usr/src/kernels/2.6.27.9-159.fc10.x86_64'
make: *** [modules] Error 2

I tried both the wireless-testing download and the compat-wireless with
the same results.

Any suggestions?

Thanks


Paul Hickey
Christian Patriot

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Sun, Jan 18, 2009 at 03:04:14PM -0800, Paul Hickey wrote:
> Ath9k is part of (my) Fedora 10 and loaded in kernel
> 2.6.27-9.159.fc10.x86_64. mac80211 is loaded when Ath9k is loaded and
> loads cfg80211. mac80211 can be loaded without loading Ath9k (you sti=
ll
> get cfg80211) but one of them gives a never ending log entry of
> ForceXPAon:0

You can ignore this ForceXPAon message, it was supposed to be a debug m=
essage
but was left with a normal print.

> I have a valid .config file
> I have the kernel headers and development files as well.
>=20
> [root@panda4 compat-wireless-2009-01-18]# make
> make -C /lib/modules/2.6.27.9-159.fc10.x86_64/build
> M=3D/home/paul/Download/compat-wireless-2009-01-18 modules
> make[1]: Entering directory `/usr/src/kernels/2.6.27.9-159.fc10.x86_6=
4'
>=20
> Message from syslogd@panda4 at Jan 18 15:50:48 ...
> kernel:Disabling IRQ #16
>   CC
> [M]  /home/paul/Download/compat-wireless-2009-01-18/net/wireless/comp=
at.o
> /home/paul/Download/compat-wireless-2009-01-18/net/wireless/compat.c:=
18:
> error: redefinition of =E2=80=98pci_ioremap_bar=E2=80=99
> include/linux/pci.h:1127: error: previous definition of
> =E2=80=98pci_ioremap_bar=E2=80=99 was here

The 2.6.27 kernel does not have pci_ioremap_bar(), and compat.c defined=
 it
for older kernels as a couple of drivers (ipw, and some ralink driver)
make use of it. Can you try downloading today's version of compat-wirel=
ess and
then try to compile?

If you still see the complaint above then please ensure your kernel
headers are installed properly. By default this is the directory used:

/lib/modules/`uname -r`/build

So check:

ls -ld /lib/modules/`uname -r`/build

And ensure that's pointing to a 2.6.27 directory. Then check the includ=
e/linux/pci.h
file there and look for pci_ioremap_bar. If its there then I am surpris=
ed. Please report
back. I just tested a compile test against 2.6.27 on Ubuntu.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Mon, Jan 19, 2009 at 10:42:18PM -0800, Paul Hickey wrote:
> Hi Luis,
>=20
> 2.6.27.9-159.fc10.x86_64 is the kernel. I burned the distro right fro=
m
> Fedora.

I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
pci_ioremap_bar() in their kernel header include/linux/pci.h. I
have verified this by checking:

http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86_64/ke=
rnel-devel-2.6.27.9-159.fc10.x86_64.rpm

I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do not have=
 this. This breaks
compatibility projects like compat-wireless :(

Kyle?

> Also, the ForceXPA might not be a problem, but it makes and logs its
> attempts 4X per minute. It may not be much of an impact on the CPU, b=
ut
> is it necessary? Plus the message log gets really long really fast.

Good point, hopefully this is enough of an argument to make the patch
go into 2.6.27. The patch is already in for >=3D 2.6.28.

Greg -- there is an annoying message that gets printed very often
when new Atheros 11n cards are used, this is printed upon hw reset
which occurs on channel changes (scans) and as such happens quite
often. The message was moved to print only when "EEPROM debugging"
was enaabled through upstream commit f1dc56003b23d2d5bb5a756de6b1633a76=
c9e697.
Unfortunately this commit is pretty large as it refactored hw.c into
separate files. Below is a small one line patch that changes this. Plea=
se
let me know if this is OK for 2.6.27.x

  Luis

=46rom: Luis R. Rodriguez <lrodriguez@atheros.com>
Subject: [PATCH] ath9k: quiet harmless ForceXPAon messages

This is a port of one line of upstream patch
f1dc56003b23d2d5bb5a756de6b1633a76c9e697

The "ForceXPAon" messages on ath9k were not meant to be printed
regularly, lets quiet them as this can happen quite frequently
(scans) and will fill the logs with tons of these messages.

Signed-off-by: Sujith <Sujith.Manoharan@atheros.com>
Signed-off-by: Luis R. Rodriguez <lrodriguez@atheros.com>

--- drivers/net/wireless/ath9k/hw.c.orig	2009-01-20 11:33:44.000000000 =
-0800
+++ drivers/net/wireless/ath9k/hw.c	2009-01-20 11:34:10.000000000 -0800
@@ -729,7 +729,7 @@
 					  AR_AN_TOP2_LOCALBIAS,
 					  AR_AN_TOP2_LOCALBIAS_S,
 					  pModal->local_bias);
-		DPRINTF(ah->ah_sc, ATH_DBG_ANY, "ForceXPAon: %d\n",
+		DPRINTF(ah->ah_sc, ATH_DBG_EEPROM, "ForceXPAon: %d\n",
 			pModal->force_xpaon);
 		REG_RMW_FIELD(ah, AR_PHY_XPA_CFG, AR_PHY_FORCE_XPA_CFG,
 			      pModal->force_xpaon);

--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Greg KH]

On Tue, Jan 20, 2009 at 11:42:43AM -0800, Luis R. Rodriguez wrote:
> On Mon, Jan 19, 2009 at 10:42:18PM -0800, Paul Hickey wrote:
> > Hi Luis,
> >=20
> > 2.6.27.9-159.fc10.x86_64 is the kernel. I burned the distro right f=
rom
> > Fedora.
>=20
> I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
> pci_ioremap_bar() in their kernel header include/linux/pci.h. I
> have verified this by checking:
>=20
> http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86_64/=
kernel-devel-2.6.27.9-159.fc10.x86_64.rpm
>=20
> I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do not ha=
ve this. This breaks
> compatibility projects like compat-wireless :(

compatibility projects should be checking for the absense or presence o=
f
specific functions, not triggering off of kernel release numbers :)

> > Also, the ForceXPA might not be a problem, but it makes and logs it=
s
> > attempts 4X per minute. It may not be much of an impact on the CPU,=
 but
> > is it necessary? Plus the message log gets really long really fast.
>=20
> Good point, hopefully this is enough of an argument to make the patch
> go into 2.6.27. The patch is already in for >=3D 2.6.28.
>=20
> Greg -- there is an annoying message that gets printed very often
> when new Atheros 11n cards are used, this is printed upon hw reset
> which occurs on channel changes (scans) and as such happens quite
> often. The message was moved to print only when "EEPROM debugging"
> was enaabled through upstream commit f1dc56003b23d2d5bb5a756de6b1633a=
76c9e697.
> Unfortunately this commit is pretty large as it refactored hw.c into
> separate files. Below is a small one line patch that changes this. Pl=
ease
> let me know if this is OK for 2.6.27.x

Looks good to me, I'll queue it up for the next .27 release.

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Tue, Jan 20, 2009 at 12:05:15PM -0800, Greg KH wrote:
> On Tue, Jan 20, 2009 at 11:42:43AM -0800, Luis R. Rodriguez wrote:
> > On Mon, Jan 19, 2009 at 10:42:18PM -0800, Paul Hickey wrote:
> > > Hi Luis,
> > >
> > > 2.6.27.9-159.fc10.x86_64 is the kernel. I burned the distro right=
 from
> > > Fedora.
> >
> > I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
> > pci_ioremap_bar() in their kernel header include/linux/pci.h. I
> > have verified this by checking:
> >
> > http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86_6=
4/kernel-devel-2.6.27.9-159.fc10.x86_64.rpm
> >
> > I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do not =
have this. This breaks
> > compatibility projects like compat-wireless :(
>=20
> compatibility projects should be checking for the absense or presence=
 of
> specific functions, not triggering off of kernel release numbers :)

How can I do that? #ifdef no worky on static inlines, for example.

BTW are you saying the above practice of adding new stuff to headers
is OK too? I wish it wasn't...

> > > Also, the ForceXPA might not be a problem, but it makes and logs =
its
> > > attempts 4X per minute. It may not be much of an impact on the CP=
U, but
> > > is it necessary? Plus the message log gets really long really fas=
t.
> >
> > Good point, hopefully this is enough of an argument to make the pat=
ch
> > go into 2.6.27. The patch is already in for >=3D 2.6.28.
> >
> > Greg -- there is an annoying message that gets printed very often
> > when new Atheros 11n cards are used, this is printed upon hw reset
> > which occurs on channel changes (scans) and as such happens quite
> > often. The message was moved to print only when "EEPROM debugging"
> > was enaabled through upstream commit f1dc56003b23d2d5bb5a756de6b163=
3a76c9e697.
> > Unfortunately this commit is pretty large as it refactored hw.c int=
o
> > separate files. Below is a small one line patch that changes this. =
Please
> > let me know if this is OK for 2.6.27.x
>=20
> Looks good to me, I'll queue it up for the next .27 release.

Awesome thanks.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Greg KH]

On Tue, Jan 20, 2009 at 12:13:16PM -0800, Luis R. Rodriguez wrote:
> On Tue, Jan 20, 2009 at 12:05:15PM -0800, Greg KH wrote:
> > On Tue, Jan 20, 2009 at 11:42:43AM -0800, Luis R. Rodriguez wrote:
> > > On Mon, Jan 19, 2009 at 10:42:18PM -0800, Paul Hickey wrote:
> > > > Hi Luis,
> > > >
> > > > 2.6.27.9-159.fc10.x86_64 is the kernel. I burned the distro rig=
ht from
> > > > Fedora.
> > >
> > > I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
> > > pci_ioremap_bar() in their kernel header include/linux/pci.h. I
> > > have verified this by checking:
> > >
> > > http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86=
_64/kernel-devel-2.6.27.9-159.fc10.x86_64.rpm
> > >
> > > I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do no=
t have this. This breaks
> > > compatibility projects like compat-wireless :(
> >=20
> > compatibility projects should be checking for the absense or presen=
ce of
> > specific functions, not triggering off of kernel release numbers :)
>=20
> How can I do that? #ifdef no worky on static inlines, for example.

You can automatically test if the feature is there, right?  If so, then
set your own #define for your compatiblity wrappers.

> BTW are you saying the above practice of adding new stuff to headers
> is OK too? I wish it wasn't...

Sure it's ok, distros can do whatever they want in their kernels, are
you telling them that they are now not allowed to do that?  :)

thanks,

greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Kyle McMartin]

On Tue, Jan 20, 2009 at 01:16:30PM -0800, Luis R. Rodriguez wrote:
> As Michael pointed out -- its tough, in fact I am not sure how to do this with
> static inlines. Advice on how to do this is welcomed. I have no clue.
> 

In this case, where a header will be providing a static inline, and you
need to provide a stub function, and you're unable to test on a typedef,
you'll have to use a weak function.

kyle@phobos ~ $ cat foo.c
#include "bar.h"
#include "compat.h"

int main(void) {
	int a = 0;

	a = foo(a);

	return a;
}

kyle@phobos ~ $ cat compat.h
int __attribute__((weak)) foo(int x);

kyle@phobos ~ $ cat bar.h
static inline int foo(int a) {
	return a;
}

kyle@phobos ~ $ cat compat.c
int __attribute__((weak)) foo(int a)
{
	return a+1;
}

kyle@phobos ~ $ gcc -Wall -O2 -o foo foo.c compat.c
kyle@phobos ~ $ ./foo
kyle@phobos ~ $ echo $?
0

Seems to work ok and not whinge about the double definition.

> > > BTW are you saying the above practice of adding new stuff to headers
> > > is OK too? I wish it wasn't...
> > 
> > Sure it's ok, distros can do whatever they want in their kernels, are
> > you telling them that they are now not allowed to do that?  :)
> 
> Heh they can do what they want, but I think it can create issues and I personally
> frown upon it. So I will at least bitch about it and maybe I'll create a bug report
> to see if it gets washed away.
> 

*sigh* I don't know, and don't really want to argue about it. ;-) People
with backports are pretty much always going to get screwed. What's the
use case for wireless-testing backports? bugfixes or new features? Could
we improve the stable process to help wireless stuff get into 2.6.$(x-1)
more easily so this won't happen in the future?

regards, Kyle

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Greg KH]

On Tue, Jan 20, 2009 at 05:08:10PM -0500, Kyle McMartin wrote:
> 
> *sigh* I don't know, and don't really want to argue about it. ;-) People
> with backports are pretty much always going to get screwed. What's the
> use case for wireless-testing backports? bugfixes or new features? Could
> we improve the stable process to help wireless stuff get into 2.6.$(x-1)
> more easily so this won't happen in the future?

I don't think we want to start adding entire new drivers to the -stable
releases, which is what the wireless backport stuff is for, right?  That
would really be adding new features, which is not the goal.

thanks,

greg k-h

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Tue, Jan 20, 2009 at 2:37 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Jan 20, 2009 at 05:08:10PM -0500, Kyle McMartin wrote:
>>
>> *sigh* I don't know, and don't really want to argue about it. ;-) People
>> with backports are pretty much always going to get screwed. What's the
>> use case for wireless-testing backports? bugfixes or new features? Could
>> we improve the stable process to help wireless stuff get into 2.6.$(x-1)
>> more easily so this won't happen in the future?
>
> I don't think we want to start adding entire new drivers to the -stable
> releases, which is what the wireless backport stuff is for, right?

Amongst a good amount of other things, yes, getting new drivers is one
reason for it. compat-wireless allows users of stable series to get
bleeding edge updates on the wireless subsystem. Sometimes this may
mean even non-oops fixes to drivers or mac80211 which may be too big
to be merged into the stable release series. Basically anything that
John maintains on his wireless-testing tree get pulled into the
compat-crap except the ancient drivers. Another reason for it is that
if you want a bleeding edge mac80211 driver, say foo you will also
need bleeding edge mac80211 and cfg80211 and since iwlwifi and ath9k
drivers depend on mac80211 and cfg80211 as well for example, so we
just provide backport work for all mac80211 drivers. This should
prevent vendors from doing nutty things like pushing their own version
of mac80211, say foo_mac80211, for their own drivers which can cause
divergence and patch hogging through unintended forks.

>That
> would really be adding new features, which is not the goal.

Sure.

  Luis

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Kyle McMartin]

On Tue, Jan 20, 2009 at 02:37:07PM -0800, Greg KH wrote:
> On Tue, Jan 20, 2009 at 05:08:10PM -0500, Kyle McMartin wrote:
> > 
> > *sigh* I don't know, and don't really want to argue about it. ;-) People
> > with backports are pretty much always going to get screwed. What's the
> > use case for wireless-testing backports? bugfixes or new features? Could
> > we improve the stable process to help wireless stuff get into 2.6.$(x-1)
> > more easily so this won't happen in the future?
> 
> I don't think we want to start adding entire new drivers to the -stable
> releases, which is what the wireless backport stuff is for, right?  That
> would really be adding new features, which is not the goal.
> 

Sorry, I meant getting bugfixes in.

r, Kyle

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Tue, Jan 20, 2009 at 2:08 PM, Kyle McMartin <kyle@infradead.org> wrote:
> On Tue, Jan 20, 2009 at 01:16:30PM -0800, Luis R. Rodriguez wrote:
>> As Michael pointed out -- its tough, in fact I am not sure how to do this with
>> static inlines. Advice on how to do this is welcomed. I have no clue.
>>
>
> In this case, where a header will be providing a static inline, and you
> need to provide a stub function, and you're unable to test on a typedef,
> you'll have to use a weak function.
>
> kyle@phobos ~ $ cat foo.c
> #include "bar.h"
> #include "compat.h"
>
> int main(void) {
>        int a = 0;
>
>        a = foo(a);
>
>        return a;
> }
>
> kyle@phobos ~ $ cat compat.h
> int __attribute__((weak)) foo(int x);
>
> kyle@phobos ~ $ cat bar.h
> static inline int foo(int a) {
>        return a;
> }
>
> kyle@phobos ~ $ cat compat.c
> int __attribute__((weak)) foo(int a)
> {
>        return a+1;
> }
>
> kyle@phobos ~ $ gcc -Wall -O2 -o foo foo.c compat.c
> kyle@phobos ~ $ ./foo
> kyle@phobos ~ $ echo $?
> 0
>
> Seems to work ok and not whinge about the double definition.

Thanks Kyle, that's pretty neat, unfortunately my compat.c includes
compat.h and since compat.h includes pci.h the compiler nags about the
double header redefinition of foo() where pci.h already has that
present (on those systems only). Essentially I'd need a way for
systems without foo() to define the header line and for systems that
already have it to not add the line. Know any trick for that?

Any particular strong reason to add that pci inline onto FC10 headers?

  Luis

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Kyle McMartin]

On Tue, Jan 20, 2009 at 04:07:52PM -0800, Luis R. Rodriguez wrote:
> Thanks Kyle, that's pretty neat, unfortunately my compat.c includes
> compat.h and since compat.h includes pci.h the compiler nags about the
> double header redefinition of foo() where pci.h already has that
> present (on those systems only). Essentially I'd need a way for
> systems without foo() to define the header line and for systems that
> already have it to not add the line. Know any trick for that?
> 
> Any particular strong reason to add that pci inline onto FC10 headers?

Well, because it came with an ALSA update...

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Tue, Jan 20, 2009 at 4:12 PM, Kyle McMartin <kyle@infradead.org> wrote:
> On Tue, Jan 20, 2009 at 04:07:52PM -0800, Luis R. Rodriguez wrote:
>> Thanks Kyle, that's pretty neat, unfortunately my compat.c includes
>> compat.h and since compat.h includes pci.h the compiler nags about the
>> double header redefinition of foo() where pci.h already has that
>> present (on those systems only). Essentially I'd need a way for
>> systems without foo() to define the header line and for systems that
>> already have it to not add the line. Know any trick for that?
>>
>> Any particular strong reason to add that pci inline onto FC10 headers?
>
> Well, because it came with an ALSA update...

Any chance that can be moved to ALSA specific dirs for the alsa updates?

  Luis

Re: [stable] Failed Build of modules for 2.6.27.9-159

[Michael Buesch]

On Tuesday 20 January 2009 21:05:15 Greg KH wrote:
> > I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
> > pci_ioremap_bar() in their kernel header include/linux/pci.h. I
> > have verified this by checking:
> >=20
> > http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86_6=
4/kernel-devel-2.6.27.9-159.fc10.x86_64.rpm
> >=20
> > I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do not =
have this. This breaks
> > compatibility projects like compat-wireless :(
>=20
> compatibility projects should be checking for the absense or presence=
 of
> specific functions, not triggering off of kernel release numbers :)

Yeah, well. But it's hard to do, if you can't do it in the preprocessor=
=2E
So you can really only check for macros, not functions.

--=20
Greetings, Michael.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Failed Build of modules for 2.6.27.9-159

[Kyle McMartin]

On Tue, Jan 20, 2009 at 11:42:43AM -0800, Luis R. Rodriguez wrote:
> On Mon, Jan 19, 2009 at 10:42:18PM -0800, Paul Hickey wrote:
> > Hi Luis,
> >=20
> > 2.6.27.9-159.fc10.x86_64 is the kernel. I burned the distro right f=
rom
> > Fedora.
>=20
> I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
> pci_ioremap_bar() in their kernel header include/linux/pci.h. I
> have verified this by checking:
>=20
> http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86_64/=
kernel-devel-2.6.27.9-159.fc10.x86_64.rpm
>=20
> I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do not ha=
ve this. This breaks
> compatibility projects like compat-wireless :(
>=20
> Kyle?
>=20

=4610 will be going to 2.6.28 within a few days... but honestly, if peo=
ple
are going to using out of tree wireless (which is what they're doing,
even if it's going upstream, it's not there now) why can't they just
build their own kernel too?

cheers, Kyle
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Failed Build of modules for 2.6.27.9-159

[Luis R. Rodriguez]

On Tue, Jan 20, 2009 at 01:12:46PM -0800, Kyle McMartin wrote:
> On Tue, Jan 20, 2009 at 11:42:43AM -0800, Luis R. Rodriguez wrote:
> > On Mon, Jan 19, 2009 at 10:42:18PM -0800, Paul Hickey wrote:
> > > Hi Luis,
> > >
> > > 2.6.27.9-159.fc10.x86_64 is the kernel. I burned the distro right=
 from
> > > Fedora.
> >
> > I am =FCber-surprised to hear that FC10 2.6.27 kernels have added
> > pci_ioremap_bar() in their kernel header include/linux/pci.h. I
> > have verified this by checking:
> >
> > http://download.fedora.redhat.com/pub/fedora/linux/updates/10/x86_6=
4/kernel-devel-2.6.27.9-159.fc10.x86_64.rpm
> >
> > I have checked upstrea 2.6.27.9 and even 2.6.27.12 and they do not =
have this. This breaks
> > compatibility projects like compat-wireless :(
> >
> > Kyle?
> >
>=20
> F10 will be going to 2.6.28 within a few days... but honestly, if peo=
ple
> are going to using out of tree wireless (which is what they're doing,
> even if it's going upstream, it's not there now)=20

This stuff just pulls directly from wireless-testing BTW, the rest is j=
ust compat crap
to get it to work on older kernels.

> why can't they just
> build their own kernel too?

Because it involves a lot more work, just getting initrds to work prope=
rly these
days in distributions tends to be a real big pain in the ass for the no=
vice user.
Upgrading a user's wireless subsystem by simply typing in

make
sudo make install

Is a lot easier than trying to get them to wrap their brain around how =
to compile
and successfully install a new kernel. Additionally some project like o=
penwrt seem
to find it a lot more useful than bumping their entire kernel. 16 GB wo=
rth of
downloads of compat-wireless seems to indicate some people find it a re=
asonable
alternative. Its the only reason why I still maintain it.

  Luis
--
To unsubscribe from this list: send the line "unsubscribe linux-wireles=
s" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html