please build F-10 and F-11 for back-port ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

2009-05-06 Thread John W. Linville
SSIA -- requesting here rather than building myself to assuage concerns
of overloading Koji...

John
-- 
John W. LinvilleLinux should be at the core
linvi...@redhat.com of your literate lifestyle.

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: please build F-10 and F-11 for back-port ath9k: Fix FIF_BCN_PRBRESP_PROMISC handling

2009-05-06 Thread John W. Linville
On Wed, May 06, 2009 at 10:48:27AM -0400, John W. Linville wrote:
 SSIA -- requesting here rather than building myself to assuage concerns
 of overloading Koji...

Sorry, got impatient...

-- 
John W. LinvilleLinux should be at the core
linvi...@redhat.com of your literate lifestyle.

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: crash with iwl3945/iwlagn; fix is in 2.6.28, can it be provided to 2.6.27?

2009-01-28 Thread John W. Linville
On Wed, Jan 28, 2009 at 10:20:03AM -0500, Bill Nottingham wrote:
 Pete Zaitcev (zait...@redhat.com) said: 
   Intel has produced a patch, and John Linville has applied this to the 
   2.6.28
   kernel (available from koji), but it now sounds like 2.6.28 might not make
   it out soon, or ever. Can this fix be applied to the 2.6.27 branch?
  
  Maybe the -stable team will pick it, so we'd get it automatically?
 
 We should still add it in the meantime (there are other dups in bugzilla,
 such as #480701) - it's very common hardware, and at least when I was seeing
 it I was repeatedly getting hard panics requiring reboot within 1-2 minutes
 of the wireless interface being enabled.

IIRC, it will take some porting for 2.6.27.  Is there an F-10-2_6_27
fork somewhere?

John
-- 
John W. LinvilleLinux should be at the core
linvi...@redhat.com of your literate lifestyle.

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: de-modularising for the win!

2008-09-19 Thread John W. Linville
On Thu, Sep 18, 2008 at 12:13:55PM -0700, Bill Nottingham wrote:
 See various and sundry plumber's conf discussions.
 
 Comments? (The netfilter stuff needs further investigation.)

 @@ -1284,7 +1284,7 @@
  CONFIG_WLAN_80211=y
  # CONFIG_PCMCIA_RAYCS is not set
  
 -CONFIG_MAC80211=m
 +CONFIG_MAC80211=y
  CONFIG_MAC80211_QOS=y
  CONFIG_MAC80211_RC_DEFAULT_PID=y
  # CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set

This helps a lot of drivers, but I have no idea what percentage
of Fedora users that represents.  Do we know what percentage that
_should_ be?  Do we have smolt data to support meeting that percentage?
I suspect that this is just a waste of memory for most desktop (as
opposed to laptop) users.

Also, as someone pointed out it is still common practice for people
to run the compat-wireless package of back-ported drivers (and the
matching mac80211 components).  This might make life more difficult
for those users.  (NOTE: these are not the typical out of tree
drivers -- they are in-tree, just a different, later tree.)

Finally, _if_ we build these in then we should probable build-in the
crypto modules that mac80211 requests...

 @@ -1299,7 +1299,7 @@
  # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set
  # CONFIG_MAC80211_DEBUG is not set
  
 -CONFIG_IEEE80211=m
 +CONFIG_IEEE80211=y
  CONFIG_IEEE80211_DEBUG=y
  CONFIG_IEEE80211_CRYPT_WEP=m
  CONFIG_IEEE80211_CRYPT_CCMP=m

This only helps two drivers, ipw2100 and ipw2200.  I don't think this
is worthwhile.

And FWIW, I ACK all the non-wireless bits! :-)

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: RFC: split changelog out of spec

2008-08-18 Thread John W. Linville
On Mon, Aug 18, 2008 at 07:43:49PM +0200, drago01 wrote:
 On Mon, Aug 18, 2008 at 7:41 PM, Jarod Wilson [EMAIL PROTECTED] wrote:
  We could also, if so desired, install the split-out changelog as a %doc
  file, the thought being that not everyone knows to look at 'rpm -q
  --changelog' output or look in the srpm/cvs/etc to see what's changed.
 
 This would just confuse user and is inconsistent with the rest of the 
 distro...

I presume the rpm command would still work, so I would see no harm
in adding the changelog as a %doc (if/when it is broken-out from the
spec file).

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?

2008-08-06 Thread John W. Linville
On Tue, Aug 05, 2008 at 05:05:33PM -0400, Chuck Ebbert wrote:
 John W. Linville wrote:
 
 I still think that for continuity's sake f8 and f9 should continue
 to get wireless fixes from 2.6.27.  Those should only be specific
 bug fixes (although I suppose there is still time for a new driver),
 so hopefully the nattering nabobs won't be opposed to continuing with
 that part of the original plan.
 

 If you push wireless fixes to -stable Fedora would then get them for free.
 I don't see many wireless patches in there generally, though the ath5k
 memory corruption fix just went in.

Well I see where you had to revert a few in the F-9 changelogs as
you rebased on later -stable kernels, so there must be a few getting
through. :-)

If you would like to nominate more wireless fixes for -stable, feel
free to do so.  As it is, I mostly rely on my driver/stack maintainers
to identify appropriate patches for stable -- they are aware of the
process, including the Cc: [EMAIL PROTECTED] trick.

Even so, that only works for those problems which date back to 2.6.26.
Since Fedora kernels already have 2.6.27 code, then the 2.6.27 patches
would seem appropriate for Fedora too.  Of course you could elide the
2.6.27 code from the Fedora kernels as you have suggested elsewhere,
but then you will reintroduce other problems.

 And new drivers would be great. Lots of people seem to want ath9k, for
 example.

We'll see.  Honestly I've been dropping other things in favor of
keeping Fedora up-to-date for the last year or more.  Rather than find
ways to spend just as much time on Fedora while getting less bang for
my buck, I'll probably find something else to occupy more of my time.
In particular, I think ath9k will make it into the 2.6.27 queue.

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?

2008-07-31 Thread John W. Linville
On Mon, Jul 07, 2008 at 11:37:10AM -0400, John W. Linville wrote:

 So, here is what I propose:
 
 -- continue the current practice until 2.6.26 is released and the
 2.6.27 merge window closes;
 
 -- after that, continue the current practice for updating rawhide; but,
 
 -- once F9 (and presumably F8) move to 2.6.26, move the -pending bits
 to the -wireless.patch and do _not_ create a new -pending.patch for
 2.6.28 bits;
 
 -- once 2.6.27 is released, drop the -wireless patch and F9/F8 will
 get no more wireless updates at all;
 
 -- F10 will release with -wireless and -pending patches inherited from
 rawhide, but they will age out following the process described for
 F9/F8 above.

Sorry to revive an old thread, but I'd like to amend the plan.

I'm going to decline to add any post-2.6.27 wireless bits to rawhide.
I think continuing that practice only complicates things for when
rawhide becomes f10, and in the meantime just adds to my personal pain.
Besides, I'm quite tired of...well, I'm just tired.

I'm prepared to consider adding specific items as requested
(e.g. ath9k), but for now let's just presume that rawhide will mostly
just get its wireless bits through Linus.

I still think that for continuity's sake f8 and f9 should continue
to get wireless fixes from 2.6.27.  Those should only be specific
bug fixes (although I suppose there is still time for a new driver),
so hopefully the nattering nabobs won't be opposed to continuing with
that part of the original plan.

Thanks,

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: iwl4965 ht/802.11n

2008-07-08 Thread John W. Linville
On Tue, Jul 08, 2008 at 06:48:11AM -0700, Jason Newton wrote:
 Hi all,
 I'm new to this list and sort of to fedora so be gentle :-).
 I bought myself a new 802.11n router since 2.6.25 and up now boast 
 802.11n functionality with iwl4965, a card I have in my t61p thinkpad, 
 but it seems CONFIG_IWL4965_HT and CONFIG_NETDEVICES_MULTIQUEUE are not 
 set in either 2.6.25.9-76.fc9 or rawhide's 2.6.26-0.107.rc8.git2 and are 
 required for 802.11n functionality.  Is there a chance they might be 
 enabled in current or future builds for fedora 9/rawhide?  How soon 
 could I expect such  builds to be released?

CONFIG_IWL4965_HT has been removed upstream and in the code in the
Fedora kernels.  It is no longer necessary.

CONFIG_NETDEVICES_MULTIQUEUE is necessary and I feel a bit silly
that I didn't realize it was not on at least in rawhide.  Is there
any reason we don't have it on already?

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: iwl4965 ht/802.11n

2008-07-08 Thread John W. Linville
On Tue, Jul 08, 2008 at 07:04:45AM -0700, Jason Newton wrote:

 Again, I'm a newbie but it seems that CONFIG_IWL4965_HT  is present in 
 both compat-wireless-2008-07-08 and vanilla 2.6.26-rc9 or am I not 
 looking upstream enough

You are not.

-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: When will we stop shipping WLAN improvements ahead of upstream in released Fedora version?

2008-07-07 Thread John W. Linville
. the current contents
of the -pending patch) when F9 picks-up 2.6.26, you would be going
backwards in your wireless support.

FWIW, this practice started in Rawhide ages ago.  Then it continued
into F7 or so because wireless continued to lag expectations.
But at some point things got enough better for enough people that
now my judgment is widely questioned.  So I've been thinking for
some time that the process should change, but I was looking for a
graceful transition.

So, here is what I propose:

-- continue the current practice until 2.6.26 is released and the
2.6.27 merge window closes;

-- after that, continue the current practice for updating rawhide; but,

-- once F9 (and presumably F8) move to 2.6.26, move the -pending bits
to the -wireless.patch and do _not_ create a new -pending.patch for
2.6.28 bits;

-- once 2.6.27 is released, drop the -wireless patch and F9/F8 will
get no more wireless updates at all;

-- F10 will release with -wireless and -pending patches inherited from
rawhide, but they will age out following the process described for
F9/F8 above.

The alternative would be to simply remove the -pending (and possibly
-wireless) patches from F10 early after it is cut, but that seems
jittery to me.

I will defer to the judgment of the group -- as I've said I spend
a lot more time keeping Fedora up-to-date than I would like to
be doing.  Just don't expect me to transfer that effort over to
tireless cherry-picking of fixes, for I just do not have the time.

Thanks,

John

P.S.  This quote is based on ignorance by the person being quoted:

On Sat, Jul 05, 2008 at 05:50:52PM +0200, Thorsten Leemhuis wrote:

 Or, to abuse some words from someone else in the discussions around 
 separately packaged kernel modules for Fedora: If they [the patches in 
 this case] are not good enough to get applied upstream why should they 
 be good enough for us? There is a reason for the short merge window and 
 the longer stabilization phase upstream.

None of the patches in question meet this definition.  They are all
queued for upstream.  Some of them are queued for the next upstream
release rather than the current one due mostly to the upstream release
process's scheduling requirements.  But they are all upstream material.
The only patch I've added to Fedora that does not meet this definition
is the one for the at76_usb driver, which is a special case.  I'm happy
to discuss at76_usb separately if someone so wishes.

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list


Re: kernel renames wlan to eth

2008-02-27 Thread John W. Linville
On Wed, Feb 27, 2008 at 11:18:17AM +0100, Adam Pribyl wrote:
 I am just wondering what is going on with all this device names renaming.
 
 hostap always used to use wlanX device names.. but well in F8 this is some 
 kind of different - at least on SMP system, the kernel asks for device 
 wlan0 to be renamed to eth1. I thought it is udev magic, so I played with 
 70-persistent-net.rules, but it has no efect. Then I tried the udevmonitor 
 and I see:
 
 UEVENT[1203878535.039740] add /module/hostap (module)
 UDEV [1203878535.042915] add /module/hostap (module)
 UEVENT[1203878535.057209] add /module/hostap_pci (module)
 UEVENT[1203878535.057845] add /bus/pci/drivers/hostap_pci (drivers)
 UEVENT[1203878535.058343] add /class/net/wifi1 (net)
 UDEV [1203878535.066578] add /bus/pci/drivers/hostap_pci (drivers)
 UDEV [1203878535.069191] add /module/hostap_pci (module)
 UDEV [1203878535.212557] add /class/net/wifi1 (net)
 UEVENT[1203878535.269178] add /class/net/wlan0 (net)
 UEVENT[1203878535.278823] move /class/net/eth1 (net)
 UDEV [1203878539.946245] add /class/net/eth1 (net)
 UDEV [1203878539.994233] move /class/net/eth1 (net)
 
 So this has nothing to do with udev, it's kernel who is asking for device 
 to be renamed. But why?
 
 Some details: http://forums.fedoraforum.org/showthread.php?p=968699

In that thread you indicated that you had previously used orinoco,
which would have given you an ethX name for that same MAC address.
So somewhere that association has stuck.  Perhaps you are using an
HWADDR line in /etc/sysconfig/network-scripts/ifcfg-eth1?

John
-- 
John W. Linville
[EMAIL PROTECTED]

___
Fedora-kernel-list mailing list
Fedora-kernel-list@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-kernel-list