kernel January 2011

kernel@lists.fedoraproject.org

19 participants
19 discussions

[PATCH] disable CONFIG_SERIAL_8250_DETECT_IRQ
by Michal Schmidt 31 Jan '11

31 Jan '11

The autodetection of IRQ on standard serial ports perhaps made sense on old hardware, but not anymore. These days we know the IRQ from PnP info or simply assume the standard IRQ setting (IRQ4 for 0x3F8, IRQ3 for 0x2F8). The autodetection takes 240 ms of everyone's boot time: autoconfig_irq() probe_irq_off(probe_irq_on()); msleep(20); msleep(100); probe_irq_on(); msleep(20); msleep(100); Just boot with "initcall_debug" to see how long serial8250_init takes. I checked Debian, OpenSuse, Ubuntu, ArchLinux - none of them have this option enabled. --- config-generic | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/config-generic b/config-generic index 7e50163..d179334 100644 --- a/config-generic +++ b/config-generic @@ -2017,7 +2017,7 @@ CONFIG_SERIAL_8250_RUNTIME_UARTS=4 CONFIG_SERIAL_8250_EXTENDED=y CONFIG_SERIAL_8250_MANY_PORTS=y CONFIG_SERIAL_8250_SHARE_IRQ=y -CONFIG_SERIAL_8250_DETECT_IRQ=y +# CONFIG_SERIAL_8250_DETECT_IRQ is not set CONFIG_SERIAL_8250_RSA=y # CONFIG_COMPUTONE is not set CONFIG_CYCLADES=m

3 2

linux-2.6-enable-more-pci-autosuspend.patch
by Kyle McMartin 25 Jan '11

25 Jan '11

Hi Matthew, This patch needs rebasing by you for 2.6.38, since it appears to have been fairly heavily broken by the addition of implicit notify support between .37 and .38-rc1, and by the rebase of ACPICA. I took a quick look at its upstream-edness, and it would be good if you could poke that too. Thanks, Kyle.

2 2

runtime_pm_fixups.patch
by Kyle McMartin 25 Jan '11

25 Jan '11

Am I just being an idiot? It looks to me like this patch was bugged? (I only noticed because the acpi_power_get_inferred_state prototype was changed to return the state in a pointer.) We've been using it in pci_bind.c like this, acpi_power_transition(device, acpi_power_get_inferred_state(device)); But it seems acpi_power_get_inferred_state only returns exit status, and not the ACPI_STATE_D0...ACPI_STATE_D3 values which acpi_power_transition expects. This may have been accidentally working since the common return value from acpi_power_get_inferred_state is 0. I changed pci_bind as such to, acpi_power_get_inferred_state(device, &state); acpi_power_transition(device, state); And am testing now... Change to acpi_power_get_inferred_state was in, commit 32a00d274e877eab3ea7ab196b75c9be5170d25e Author: Rafael J. Wysocki <rjw(a)sisk.pl> Date: Thu Nov 25 00:05:17 2010 +0100 ACPI / PM: Prevent acpi_power_get_inferred_state() from making changes acpi_power_get_inferred_state() should not update device->power.state behind the back of its caller, so make it return the state via a pointer instead. Signed-off-by: Rafael J. Wysocki <rjw(a)sisk.pl> Signed-off-by: Len Brown <len.brown(a)intel.com> --Kyle

1 0

[PATCH 2.6.34.y] hostap_cs: fix sleeping function called from invalid context
by Stanislaw Gruszka 17 Jan '11

17 Jan '11

commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream. pcmcia_request_irq() and pcmcia_enable_device() are intended to be called from process context (first function allocate memory with GFP_KERNEL, second take a mutex). We can not take spin lock and call them. It's safe to move spin lock after pcmcia_enable_device() as we still hold off IRQ until dev->base_addr is 0 and driver will not proceed with interrupts when is not ready. Patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=643758 Reported-and-tested-by: rbugz(a)biobind.com Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> --- drivers/net/wireless/hostap/hostap_cs.c | 14 +++----------- 1 files changed, 3 insertions(+), 11 deletions(-) diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c index f33e18e..116b5c6 100644 --- a/drivers/net/wireless/hostap/hostap_cs.c +++ b/drivers/net/wireless/hostap/hostap_cs.c @@ -638,12 +638,6 @@ static int prism2_config(struct pcmcia_device *link) link->dev_node = &hw_priv->node; /* - * Make sure the IRQ handler cannot proceed until at least - * dev->base_addr is initialized. - */ - spin_lock_irqsave(&local->irq_init_lock, flags); - - /* * Allocate an interrupt line. Note that this does not assign a * handler to the interrupt, unless the 'Handler' member of the * irq structure is initialized. @@ -653,7 +647,7 @@ static int prism2_config(struct pcmcia_device *link) link->irq.Handler = prism2_interrupt; ret = pcmcia_request_irq(link, &link->irq); if (ret) - goto failed_unlock; + goto failed; } /* @@ -663,11 +657,11 @@ static int prism2_config(struct pcmcia_device *link) */ ret = pcmcia_request_configuration(link, &link->conf); if (ret) - goto failed_unlock; + goto failed; + spin_lock_irqsave(&local->irq_init_lock, flags); dev->irq = link->irq.AssignedIRQ; dev->base_addr = link->io.BasePort1; - spin_unlock_irqrestore(&local->irq_init_lock, flags); /* Finally, report what we've done */ @@ -698,8 +692,6 @@ static int prism2_config(struct pcmcia_device *link) } return ret; - failed_unlock: - spin_unlock_irqrestore(&local->irq_init_lock, flags); failed: kfree(hw_priv); prism2_release((u_long)link); -- 1.7.1

1 0

[PATCH 2.6.35.y] hostap_cs: fix sleeping function called from invalid context
by Stanislaw Gruszka 17 Jan '11

17 Jan '11

commit 4e5518ca53be29c1ec3c00089c97bef36bfed515 upstream. pcmcia_request_irq() and pcmcia_enable_device() are intended to be called from process context (first function allocate memory with GFP_KERNEL, second take a mutex). We can not take spin lock and call them. It's safe to move spin lock after pcmcia_enable_device() as we still hold off IRQ until dev->base_addr is 0 and driver will not proceed with interrupts when is not ready. Patch resolves: https://bugzilla.redhat.com/show_bug.cgi?id=643758 Reported-and-tested-by: rbugz(a)biobind.com Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> --- drivers/net/wireless/hostap/hostap_cs.c | 15 ++++++--------- 1 files changed, 6 insertions(+), 9 deletions(-) diff --git a/drivers/net/wireless/hostap/hostap_cs.c b/drivers/net/wireless/hostap/hostap_cs.c index 29b31a6..4ebf63d 100644 --- a/drivers/net/wireless/hostap/hostap_cs.c +++ b/drivers/net/wireless/hostap/hostap_cs.c @@ -627,14 +627,13 @@ static int prism2_config(struct pcmcia_device *link) hw_priv->link = link; /* - * Make sure the IRQ handler cannot proceed until at least - * dev->base_addr is initialized. + * We enable IRQ here, but IRQ handler will not proceed + * until dev->base_addr is set below. This protect us from + * receive interrupts when driver is not initialized. */ - spin_lock_irqsave(&local->irq_init_lock, flags); - ret = pcmcia_request_irq(link, prism2_interrupt); if (ret) - goto failed_unlock; + goto failed; /* * This actually configures the PCMCIA socket -- setting up @@ -643,11 +642,11 @@ static int prism2_config(struct pcmcia_device *link) */ ret = pcmcia_request_configuration(link, &link->conf); if (ret) - goto failed_unlock; + goto failed; + spin_lock_irqsave(&local->irq_init_lock, flags); dev->irq = link->irq; dev->base_addr = link->io.BasePort1; - spin_unlock_irqrestore(&local->irq_init_lock, flags); /* Finally, report what we've done */ @@ -676,8 +675,6 @@ static int prism2_config(struct pcmcia_device *link) return ret; - failed_unlock: - spin_unlock_irqrestore(&local->irq_init_lock, flags); failed: kfree(hw_priv); prism2_release((u_long)link); -- 1.7.1

1 0

Re: 2.6.35.10-74 compilation (and build) problems
by Mr Dash Four 13 Jan '11

13 Jan '11

> Aha!!! I do see the cause of your problem!! > > From YOUR email below, you say: > > cd ~/rpmbuild/BUILD/kernel-2.6.35.fc13/linux-2.6.25.x86_64 > > So, why are you dickering with linux-2.6.25.x86_64 ??? > > I thought you wanted to build 2.6.35.10-74 !!! Sorry, it was a typo - it should read "linux-2.6.35.x86_64". Everything else is the same as I wrote previously (I think ;-) ) >> cd ~/rpmbuild/BUILD/kernel-2.6.35.fc13/linux-2.6.25.x86_64 >> cp ~/kernel/solar-34-options.config .config >> make oldconfig >> make menuconfig (I do NOT make any changes!!!) > > If you do not make any changes, why do it? It is completely unnecessary! So the logic says and, in principle, I agree with you. As I pointed out earlier - I used to get errors when I do not run "make menuconfig" and then proceed with the next step. This was the case with .34, though I did not test this with .35 yet. >> diff -NurBb ~/kernel/solar-34-options.config .config (this is to see >> what has been changed - I ONLY execute this during minor revisions, >> that's all) > > So, what do you do with the resulting diff? I check for two things - 1) if any of the options I have previously saved (e.g. "solar-34-config") are not present; or 2) there are new options that were set in the 'new' kernel version than after building the kernel (and making sure it works as expected) I copy this new config as my new 'saved' config so that I could use it the next time. That basically is it. >> vi .config (this is to add the magic "# x86_64" at the top) > I don't understand why you need a commented line??? > What's the magic about it? A comment is ignored. See the "Fedora Wiki" ( :-D ) for building the kernel - the target arch needs to be added as a comment on the first line of that .config file (that is particularly important if I do cross-compilation of the kernel - I add "# i386" for i686 targets for example). If that is not present all hell breaks loose! >> cp .config ~/rpmbuild/SOURCES/config-x86_64-generic > > This will not guarantee that the config file will not be modified. > I have done this numerous times, and I can tell you unequivocally, > it will not keep all the options you want, nor will it exclude all the > options you do NOT want. > What it will give you is a beast that is niether what you want nor > what you do not want. > This is the wierdness of the .spec file operations and the Makefile > script in ...SOURCES/Makefile.config What would you advice me to do then?! I need to end up with 3 kernel-*.rpm files plus one perf*.rpm, which I can distribute to all my machines. The above set of instructions is what "Fedora Wiki" ( :-D ) advices on building the kernel... > The fedora release people have not provided us with a mechanism > that will let us build a kernel EXACTLY as the config file we save in > the SOURCES directory. What do they actually change - after I build and install the kernel and then check the corresponding .config file in the /boot partition/directory it is the same as the one I have copied as config-x86_64-generic, so, naturally, I assume that nothing has been modified/changed. Is that not the case? What also puzzles me in is that after running the oldconfig target not all options are transferred to the .config file? Do you think this is normal or a bug? Do I have to go through the motions and transfer each kernel value manually when I am dealing with major kernel revisions? This can't be right!

5 57

[PATCH 2.6.35] mac80211: fix hard lockup in sta_addba_resp_timer_expired
by Stanislaw Gruszka 12 Jan '11

12 Jan '11

Problem is 2.6.35 specific, bug was introduced in backport of upstream 44271488b91c9eecf249e075a1805dd887e222d2 commit. We can not call del_timer_sync(addba_resp_timer) from ___ieee80211_stop_tx_ba_session(), as this function can be called from that timer callback. To fix, simply use not synchronous del_timer(). Resolve https://bugzilla.redhat.com/show_bug.cgi?id=667459 Reported-and-tested-by: Mathieu Chouquet-Stringer <mathieu-acct(a)csetco.com> Signed-off-by: Stanislaw Gruszka <sgruszka(a)redhat.com> --- net/mac80211/agg-tx.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/net/mac80211/agg-tx.c b/net/mac80211/agg-tx.c index f935490..72ab63d 100644 --- a/net/mac80211/agg-tx.c +++ b/net/mac80211/agg-tx.c @@ -138,7 +138,7 @@ int ___ieee80211_stop_tx_ba_session(struct sta_info *sta, u16 tid, sta->sta.addr, tid); #endif /* CONFIG_MAC80211_HT_DEBUG */ - del_timer_sync(&tid_tx->addba_resp_timer); + del_timer(&tid_tx->addba_resp_timer); state = &sta->ampdu_mlme.tid_state_tx[tid]; -- 1.7.3.4

3 2

Ath9k driver
by JD 11 Jan '11

11 Jan '11

Dear All, I installed a new wifi mini-pci card in my notebook. It has the Atheros AR9220/AR9223 chipset. When I boot into level 5 and su to root, I run modprobe ath9k and I get error messages from multiple components of ath9k Here is some info: # ifconfig lo Link encap:Local Loopback inet addr:127.0.0.1 Mask:255.0.0.0 UP LOOPBACK RUNNING MTU:16436 Metric:1 RX packets:14 errors:0 dropped:0 overruns:0 frame:0 TX packets:14 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:0 RX bytes:814 (814.0 b) TX bytes:814 (814.0 b) # ifconfig ath0 ath0: error fetching interface information: Device not found # modprobe ath9k WARNING: Error inserting ath9k_hw (/lib/modules/2.6.37-1.fc13.i686/kernel/drivers/net/wireless/ath/ath9k/ath9k_hw.ko): Invalid argument WARNING: Error inserting ath9k_common (/lib/modules/2.6.37-1.fc13.i686/kernel/drivers/net/wireless/ath/ath9k/ath9k_common.ko): Invalid argument WARNING: Error inserting compat (/lib/modules/2.6.37-1.fc13.i686/updates/compat/compat.ko): Invalid argument WARNING: Error inserting mac80211 (/lib/modules/2.6.37-1.fc13.i686/updates/net/mac80211/mac80211.ko): Invalid argument FATAL: Error inserting ath9k (/lib/modules/2.6.37-1.fc13.i686/kernel/drivers/net/wireless/ath/ath9k/ath9k.ko): Invalid argument

3 3

Compilation error in kernel-2.6.35.10-74
by JD 11 Jan '11

11 Jan '11

The last few lines of the build output: vour=PAE + InstallName=vmlinuz + Config=kernel-2.6.35.10-i686-PAE.config + DevelDir=/usr/src/kernels/2.6.35.10-74.i686.PAE + '[' arch/x86/boot/bzImage = vmlinux ']' + CopyKernel=cp + KernelVer=2.6.35.10-74.i686.PAE + echo BUILDING A KERNEL FOR PAE i686... BUILDING A KERNEL FOR PAE i686... + perl -p -i -e 's/^EXTRAVERSION.*/EXTRAVERSION = .10-74.i686.PAE/' Makefile + make -s mrproper + cp configs/kernel-2.6.35.10-i686-PAE.config .config ++ cut -b 3- ++ head -1 .config + Arch=i386 + echo USING ARCH=i386 USING ARCH=i386 + make -s ARCH=i386 nonint_oldconfig + make -s ARCH=i386 V=1 bzImage kernel/sched.c: In function 'init_idle': kernel/sched.c:5397: error: implicit declaration of function 'double_rq_lock' kernel/sched.c:5422: error: implicit declaration of function 'double_rq_unlock' make[1]: *** [kernel/sched.o] Error 1 make: *** [kernel] Error 2 error: Bad exit status from /var/tmp/rpm-tmp.quW5nA (%build) The build command: rpmbuild -vvv -bb --with up --without debug --without smp --without pae --without pae_debug kernel.spec So, why is it building for PAE when the rpmbuild arg expplicitly states --without pae? I have saved the .config file. Are there kernel devs on this list who could advise me on the next step to take? Thanx, JD

4 8

linux-2.6-debug-nmi-timeout.patch
by Kyle McMartin 10 Jan '11

10 Jan '11

arch/x86/kernel/apic/nmi.c has been removed upstream, so I'm wondering how to merge this patch... The most appropriate place to change the sample period appears to be kernel/watchdog.c::get_sample_period and making the '5' configurable, but obviously that isn't quite the same as what the original patch intended. Or, should I drop the patch since it seems to be generally unnecessary... --Kyle

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

kernel January 2011