[PATCH] disable CONFIG_SERIAL_8250_DETECT_IRQ
by Michal Schmidt
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
12 years, 4 months
linux-2.6-enable-more-pci-autosuspend.patch
by Kyle McMartin
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.
12 years, 4 months
runtime_pm_fixups.patch
by Kyle McMartin
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
12 years, 4 months
[PATCH 2.6.34.y] hostap_cs: fix sleeping function called from invalid context
by Stanislaw Gruszka
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
12 years, 4 months
[PATCH 2.6.35.y] hostap_cs: fix sleeping function called from invalid context
by Stanislaw Gruszka
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
12 years, 4 months
Re: 2.6.35.10-74 compilation (and build) problems
by Mr Dash Four
> 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!
12 years, 4 months
[PATCH 2.6.35] mac80211: fix hard lockup in sta_addba_resp_timer_expired
by Stanislaw Gruszka
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
12 years, 4 months
Ath9k driver
by JD
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
12 years, 4 months
Compilation error in kernel-2.6.35.10-74
by JD
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
12 years, 4 months
linux-2.6-debug-nmi-timeout.patch
by Kyle McMartin
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
12 years, 4 months
