Re: 2.6.13-rc4-mm1: Divide by zero in find_idlest_group
On Fri, 2005-08-12 at 01:27 +1000, Con Kolivas wrote: > On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote: > > Should there be any locking around this? Or should the value of > > rq->nr_running be saved to a local variable as in this untested patch? > > Very sneaky.. > > On initial inspection your patch makes complete sense. I see no point in > adding locking to this function as the accuracy is not critical. Want to give > your patch a run and then push it to akpm? Thanks! Okay, I'm testing it now. It took running overnight to hit the problem before, so I'll let it run until tomorrow before I push it. > Cheers, > Con -- David Kleikamp IBM Linux Technology Center - 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.13-rc4-mm1: Divide by zero in find_idlest_group
On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
> I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
>
> [70347.743727] divide error: [#2]
> [70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
> [70347.773060] last sysfs file: /devices/pnp0/00:11/id
>
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0xc0119556 in find_idlest_group (sd=0xc1084dc0, p=0xc3b96030, this_cpu=0)
> at sched.c:1033
> 1033target_load = target_load * rq->prio_bias /
> rq->nr_running;
>
> (gdb) where
> #0 0xc0119556 in find_idlest_group (sd=0xc1084dc0, p=0xc3b96030,
> this_cpu=0) at sched.c:1033
> #1 0xc0119744 in sched_balance_self (cpu=0, flag=4) at sched.c:1151
> #2 0xc011a63f in sched_exec () at sched.c:1840
> #3 0xc016cacb in do_execve (filename=0xc3e35000 "/bin/sh",
> argv=0xbfff512c, envp=0xbfff6010, regs=0xa00) at exec.c:1162
> #4 0xc0101b5a in sys_execve (regs=
> {ebx = -1208173323, ecx = -1073786580, edx = -1073782768, esi =
> -1073782768, edi = -1208107392, ebp = -1073786620, eax = 11, xds = 123, xes
> = -1072693125, orig_eax = 11, eip = -1208664822, xcs = 115, eflags = 658,
> esp = -1073786628, xss = 123}) at process.c:787 #5 0xc0102fdd in
> syscall_call () at current.h:9
> #6 0xb7fcbcf5 in ?? ()
>
> print *(struct runqueue *)0xc108c400
> $1 = {lock = {raw_lock = {slock = 1}, break_lock = 0}, nr_running = 0,
> prio_bias = 0, cpu_load = {0, 0, 0}, nr_switches = 8877527,
> nr_uninterruptible = 132930, expired_timestamp = 0,
> timestamp_last_tick = 70347783539837, curr = 0xc1103550, idle =
> 0xc1103550, prev_mm = 0x0, active = 0xc108c8c0, expired = 0xc108c448,
> arrays = {{ nr_active = 0, bitmap = {0, 0, 0, 0, 4096}, queue = {{next =
> 0xc108c460, prev = 0xc108c460}, {next = 0xc108c468, prev = 0xc108c468}, {
> next = 0xc108c470, prev = 0xc108c470}, {next = 0xc108c478, prev =
> 0xc108c478}, {next = 0xc108c480, prev = 0xc108c480}, { next = 0xc108c488,
> prev = 0xc108c488}, {next = 0xc108c490,
>
> in __source_load, it looks like rq_nr_running must have changed between
> the if statement and the divide:
>
> if (rq->nr_running > 1 || (idle == NOT_IDLE && rq->nr_running))
> /*
> * If we are busy rebalancing the load is biased by
> * priority to create 'nice' support across cpus. When
> * idle rebalancing we should only bias the source_load if
> * there is more than one task running on that queue to
> * prevent idle rebalance from trying to pull tasks from a
> * queue with only one running task.
> */
> source_load = source_load * rq->prio_bias / rq->nr_running;
>
> Should there be any locking around this? Or should the value of
> rq->nr_running be saved to a local variable as in this untested patch?
Very sneaky..
On initial inspection your patch makes complete sense. I see no point in
adding locking to this function as the accuracy is not critical. Want to give
your patch a run and then push it to akpm? Thanks!
Cheers,
Con
-
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.13-rc4-mm1: Divide by zero in find_idlest_group
On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote:
I encounted this trap on a 2-way i386 box running 2.6.13-rc4-mm1:
[70347.743727] divide error: [#2]
[70347.752979] PREEMPT SMP DEBUG_PAGEALLOC
[70347.773060] last sysfs file: /devices/pnp0/00:11/id
Program received signal SIGTRAP, Trace/breakpoint trap.
0xc0119556 in find_idlest_group (sd=0xc1084dc0, p=0xc3b96030, this_cpu=0)
at sched.c:1033
1033target_load = target_load * rq-prio_bias /
rq-nr_running;
(gdb) where
#0 0xc0119556 in find_idlest_group (sd=0xc1084dc0, p=0xc3b96030,
this_cpu=0) at sched.c:1033
#1 0xc0119744 in sched_balance_self (cpu=0, flag=4) at sched.c:1151
#2 0xc011a63f in sched_exec () at sched.c:1840
#3 0xc016cacb in do_execve (filename=0xc3e35000 /bin/sh,
argv=0xbfff512c, envp=0xbfff6010, regs=0xa00) at exec.c:1162
#4 0xc0101b5a in sys_execve (regs=
{ebx = -1208173323, ecx = -1073786580, edx = -1073782768, esi =
-1073782768, edi = -1208107392, ebp = -1073786620, eax = 11, xds = 123, xes
= -1072693125, orig_eax = 11, eip = -1208664822, xcs = 115, eflags = 658,
esp = -1073786628, xss = 123}) at process.c:787 #5 0xc0102fdd in
syscall_call () at current.h:9
#6 0xb7fcbcf5 in ?? ()
print *(struct runqueue *)0xc108c400
$1 = {lock = {raw_lock = {slock = 1}, break_lock = 0}, nr_running = 0,
prio_bias = 0, cpu_load = {0, 0, 0}, nr_switches = 8877527,
nr_uninterruptible = 132930, expired_timestamp = 0,
timestamp_last_tick = 70347783539837, curr = 0xc1103550, idle =
0xc1103550, prev_mm = 0x0, active = 0xc108c8c0, expired = 0xc108c448,
arrays = {{ nr_active = 0, bitmap = {0, 0, 0, 0, 4096}, queue = {{next =
0xc108c460, prev = 0xc108c460}, {next = 0xc108c468, prev = 0xc108c468}, {
next = 0xc108c470, prev = 0xc108c470}, {next = 0xc108c478, prev =
0xc108c478}, {next = 0xc108c480, prev = 0xc108c480}, { next = 0xc108c488,
prev = 0xc108c488}, {next = 0xc108c490,
in __source_load, it looks like rq_nr_running must have changed between
the if statement and the divide:
if (rq-nr_running 1 || (idle == NOT_IDLE rq-nr_running))
/*
* If we are busy rebalancing the load is biased by
* priority to create 'nice' support across cpus. When
* idle rebalancing we should only bias the source_load if
* there is more than one task running on that queue to
* prevent idle rebalance from trying to pull tasks from a
* queue with only one running task.
*/
source_load = source_load * rq-prio_bias / rq-nr_running;
Should there be any locking around this? Or should the value of
rq-nr_running be saved to a local variable as in this untested patch?
Very sneaky..
On initial inspection your patch makes complete sense. I see no point in
adding locking to this function as the accuracy is not critical. Want to give
your patch a run and then push it to akpm? Thanks!
Cheers,
Con
-
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.13-rc4-mm1: Divide by zero in find_idlest_group
On Fri, 2005-08-12 at 01:27 +1000, Con Kolivas wrote: On Fri, 12 Aug 2005 01:21 am, Dave Kleikamp wrote: Should there be any locking around this? Or should the value of rq-nr_running be saved to a local variable as in this untested patch? Very sneaky.. On initial inspection your patch makes complete sense. I see no point in adding locking to this function as the accuracy is not critical. Want to give your patch a run and then push it to akpm? Thanks! Okay, I'm testing it now. It took running overnight to hit the problem before, so I'll let it run until tomorrow before I push it. Cheers, Con -- David Kleikamp IBM Linux Technology Center - 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.13-rc4-mm1: iptables DROP crashes the computer
On 07/08/05, Patrick McHardy <[EMAIL PROTECTED]> wrote: > Could be related to the refcnt underflow with conntrack event > notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS > enabled please try this patch. > I can confirm that that patch solved my problems, thank you :) -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway - 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.13-rc4-mm1: iptables DROP crashes the computer
Adrian Bunk wrote:
> On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote:
>
>
>>After execing "iptables -A INPUT -j DROP" my computer crashes hard. It
>>dosent hang immediately, but after a couple of seconds.
>>The machine is an amd64, running a clean x86_64 environment.
>>uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
>>CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
>>...
Could be related to the refcnt underflow with conntrack event
notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS
enabled please try this patch.
[NETFILTER]: Fix multiple problems with the conntrack event cache
refcnt underflow: the reference count is decremented when a conntrack
entry is removed from the hash but it is not incremented when entering
new entries.
missing protection of process context against softirq context: all
cache operations need to locally disable softirqs to avoid races.
Additionally the event cache can't be initialized when a packet enteres
the conntrack code but needs to be initialized whenever we cache an event
and the stored conntrack entry doesn't match the current one.
incorrect flushing of the event cache in ip_ct_iterate_cleanup: without
real locking we can't flush the cache for different CPUs without incurring
races. The cache for different CPUs can only be flushed when no packets
are going through the code. ip_ct_iterate_cleanup doesn't need to drop
all references, so flushing is moved to the cleanup path.
Signed-off-by: Patrick McHardy <[EMAIL PROTECTED]>
---
commit d20d18715b8425060334e879ebb4835202457b3e
tree 3279243f59162c14f8ac145473e1c3f4c586b2fa
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patrick McHardy <[EMAIL PROTECTED]> Wed, 03 Aug 2005 20:33:25 +0200
committer Patrick McHardy <[EMAIL PROTECTED]> Wed, 03 Aug 2005 20:33:25 +0200
include/linux/netfilter_ipv4/ip_conntrack.h | 29 +++---
include/linux/netfilter_ipv4/ip_conntrack_core.h | 14 +--
net/ipv4/netfilter/ip_conntrack_core.c | 107 --
net/ipv4/netfilter/ip_conntrack_standalone.c |3 -
4 files changed, 58 insertions(+), 95 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ip_conntrack.h
b/include/linux/netfilter_ipv4/ip_conntrack.h
--- a/include/linux/netfilter_ipv4/ip_conntrack.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -411,6 +411,7 @@ struct ip_conntrack_stat
#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
#include
+#include
struct ip_conntrack_ecache {
struct ip_conntrack *ct;
@@ -445,26 +446,24 @@ ip_conntrack_expect_unregister_notifier(
return notifier_chain_unregister(_conntrack_expect_chain, nb);
}
+extern void ip_ct_deliver_cached_events(const struct ip_conntrack *ct);
+extern void __ip_ct_event_cache_init(struct ip_conntrack *ct);
+
static inline void
ip_conntrack_event_cache(enum ip_conntrack_events event,
const struct sk_buff *skb)
{
- struct ip_conntrack_ecache *ecache =
- &__get_cpu_var(ip_conntrack_ecache);
-
- if (unlikely((struct ip_conntrack *) skb->nfct != ecache->ct)) {
- if (net_ratelimit()) {
- printk(KERN_ERR "ctevent: skb->ct != ecache->ct !!!\n");
- dump_stack();
- }
- }
+ struct ip_conntrack *ct = (struct ip_conntrack *)skb->nfct;
+ struct ip_conntrack_ecache *ecache;
+
+ local_bh_disable();
+ ecache = &__get_cpu_var(ip_conntrack_ecache);
+ if (ct != ecache->ct)
+ __ip_ct_event_cache_init(ct);
ecache->events |= event;
+ local_bh_enable();
}
-extern void
-ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct);
-extern void ip_conntrack_event_cache_init(const struct sk_buff *skb);
-
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct)
{
@@ -483,9 +482,7 @@ static inline void ip_conntrack_event_ca
const struct sk_buff *skb) {}
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct) {}
-static inline void ip_conntrack_deliver_cached_events_for(
- struct ip_conntrack *ct) {}
-static inline void ip_conntrack_event_cache_init(const struct sk_buff *skb) {}
+static inline void ip_ct_deliver_cached_events(const struct ip_conntrack *ct)
{}
static inline void
ip_conntrack_expect_event(enum ip_conntrack_expect_events event,
struct ip_conntrack_expect *exp) {}
diff --git a/include/linux/netfilter_ipv4/ip_conntrack_core.h
b/include/linux/netfilter_ipv4/ip_conntrack_core.h
--- a/include/linux/netfilter_ipv4/ip_conntrack_core.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack_core.h
@@ -44,18 +44,14 @@ static inline int ip_conntrack_confirm(s
Re: 2.6.13-rc4-mm1: iptables DROP crashes the computer
On 07/08/05, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote: > > > After execing "iptables -A INPUT -j DROP" my computer crashes hard. It > > dosent hang immediately, but after a couple of seconds. > > The machine is an amd64, running a clean x86_64 environment. > > uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 > > CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD > >... > > Is this reproducible or did it happen only once? It is reproducible, happens each time when running "iptables -A INPUT -j DROP", other rules like "iptables -A INPUT -m --state ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT" works well tho. > Are there any messages that might give a hint where to search for the > problem? The kernel log dont give any messages before the crash, and since the computer crash hard i cant check for relevant messages after the crash ;) > You are reporting this against 2.6.13-rc4-mm1, but are attaching a > .config of 2.6.13-rc5-mm1. Which kernels are affected, and which are > not? Im sorry about that glitch, recently compiled 2.6.13-rc5-mm1, but i got a kernel panic at boot, havent looked into that yet, but it might be related to ACPI. The config for rc4-mm1 and rc5-mm1 is similar. > Does it still happen if you compile your kernel with preemption > disabled? Havent tried this yet, but ill do it right away. > Please send the output of ./scripts/ver_linux . If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 3.4.4 Gnu make 3.80 binutils 2.16.1 util-linux 2.12q mount 2.12q module-init-tools 3.2-pre7 e2fsprogs 1.38 reiserfsprogs line reiser4progs line xfsprogs 2.6.25 Linux C Library2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 065 Modules Loaded iptable_filter ip_tables snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_pcm_oss snd_mixer_oss rtc ntfs snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore usb_storage uhci_hcd usbcore -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway - 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.13-rc4-mm1: iptables DROP crashes the computer
On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote: > After execing "iptables -A INPUT -j DROP" my computer crashes hard. It > dosent hang immediately, but after a couple of seconds. > The machine is an amd64, running a clean x86_64 environment. > uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 > CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD >... Is this reproducible or did it happen only once? Are there any messages that might give a hint where to search for the problem? You are reporting this against 2.6.13-rc4-mm1, but are attaching a .config of 2.6.13-rc5-mm1. Which kernels are affected, and which are not? Does it still happen if you compile your kernel with preemption disabled? Please send the output of ./scripts/ver_linux . > Mvh / Best regards > Espen Fjellvær Olsen cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc4-mm1: iptables DROP crashes the computer
On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote: After execing iptables -A INPUT -j DROP my computer crashes hard. It dosent hang immediately, but after a couple of seconds. The machine is an amd64, running a clean x86_64 environment. uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD ... Is this reproducible or did it happen only once? Are there any messages that might give a hint where to search for the problem? You are reporting this against 2.6.13-rc4-mm1, but are attaching a .config of 2.6.13-rc5-mm1. Which kernels are affected, and which are not? Does it still happen if you compile your kernel with preemption disabled? Please send the output of ./scripts/ver_linux . Mvh / Best regards Espen Fjellvær Olsen cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc4-mm1: iptables DROP crashes the computer
On 07/08/05, Adrian Bunk [EMAIL PROTECTED] wrote: On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote: After execing iptables -A INPUT -j DROP my computer crashes hard. It dosent hang immediately, but after a couple of seconds. The machine is an amd64, running a clean x86_64 environment. uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD ... Is this reproducible or did it happen only once? It is reproducible, happens each time when running iptables -A INPUT -j DROP, other rules like iptables -A INPUT -m --state ESTABLISHED,RELATED -p tcp --dport 22 -j ACCEPT works well tho. Are there any messages that might give a hint where to search for the problem? The kernel log dont give any messages before the crash, and since the computer crash hard i cant check for relevant messages after the crash ;) You are reporting this against 2.6.13-rc4-mm1, but are attaching a .config of 2.6.13-rc5-mm1. Which kernels are affected, and which are not? Im sorry about that glitch, recently compiled 2.6.13-rc5-mm1, but i got a kernel panic at boot, havent looked into that yet, but it might be related to ACPI. The config for rc4-mm1 and rc5-mm1 is similar. Does it still happen if you compile your kernel with preemption disabled? Havent tried this yet, but ill do it right away. Please send the output of ./scripts/ver_linux . If some fields are empty or look unusual you may have an old version. Compare to the current minimal requirements in Documentation/Changes. Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44 CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD GNU/Linux Gnu C 3.4.4 Gnu make 3.80 binutils 2.16.1 util-linux 2.12q mount 2.12q module-init-tools 3.2-pre7 e2fsprogs 1.38 reiserfsprogs line reiser4progs line xfsprogs 2.6.25 Linux C Library2.3.5 Dynamic linker (ldd) 2.3.5 Procps 3.2.5 Net-tools 1.60 Kbd1.12 Sh-utils 5.2.1 udev 065 Modules Loaded iptable_filter ip_tables snd_seq_midi snd_emu10k1_synth snd_emux_synth snd_seq_virmidi snd_seq_midi_event snd_seq_midi_emul snd_seq snd_pcm_oss snd_mixer_oss rtc ntfs snd_emu10k1 snd_rawmidi snd_seq_device snd_ac97_codec snd_pcm snd_timer snd_page_alloc snd_util_mem snd_hwdep snd soundcore usb_storage uhci_hcd usbcore -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway - 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.13-rc4-mm1: iptables DROP crashes the computer
Adrian Bunk wrote:
On Sun, Aug 07, 2005 at 07:12:00PM +0200, Espen Fjellvær Olsen wrote:
After execing iptables -A INPUT -j DROP my computer crashes hard. It
dosent hang immediately, but after a couple of seconds.
The machine is an amd64, running a clean x86_64 environment.
uname -a: Linux gentoo 2.6.13-rc4-mm1 #1 PREEMPT Thu Aug 4 01:01:44
CEST 2005 x86_64 AMD Athlon(tm) 64 Processor 3400+ AuthenticAMD
...
Could be related to the refcnt underflow with conntrack event
notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS
enabled please try this patch.
[NETFILTER]: Fix multiple problems with the conntrack event cache
refcnt underflow: the reference count is decremented when a conntrack
entry is removed from the hash but it is not incremented when entering
new entries.
missing protection of process context against softirq context: all
cache operations need to locally disable softirqs to avoid races.
Additionally the event cache can't be initialized when a packet enteres
the conntrack code but needs to be initialized whenever we cache an event
and the stored conntrack entry doesn't match the current one.
incorrect flushing of the event cache in ip_ct_iterate_cleanup: without
real locking we can't flush the cache for different CPUs without incurring
races. The cache for different CPUs can only be flushed when no packets
are going through the code. ip_ct_iterate_cleanup doesn't need to drop
all references, so flushing is moved to the cleanup path.
Signed-off-by: Patrick McHardy [EMAIL PROTECTED]
---
commit d20d18715b8425060334e879ebb4835202457b3e
tree 3279243f59162c14f8ac145473e1c3f4c586b2fa
parent df2e0392536ecdd6385f4319f746045fd6fae38f
author Patrick McHardy [EMAIL PROTECTED] Wed, 03 Aug 2005 20:33:25 +0200
committer Patrick McHardy [EMAIL PROTECTED] Wed, 03 Aug 2005 20:33:25 +0200
include/linux/netfilter_ipv4/ip_conntrack.h | 29 +++---
include/linux/netfilter_ipv4/ip_conntrack_core.h | 14 +--
net/ipv4/netfilter/ip_conntrack_core.c | 107 --
net/ipv4/netfilter/ip_conntrack_standalone.c |3 -
4 files changed, 58 insertions(+), 95 deletions(-)
diff --git a/include/linux/netfilter_ipv4/ip_conntrack.h
b/include/linux/netfilter_ipv4/ip_conntrack.h
--- a/include/linux/netfilter_ipv4/ip_conntrack.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack.h
@@ -411,6 +411,7 @@ struct ip_conntrack_stat
#ifdef CONFIG_IP_NF_CONNTRACK_EVENTS
#include linux/notifier.h
+#include linux/interrupt.h
struct ip_conntrack_ecache {
struct ip_conntrack *ct;
@@ -445,26 +446,24 @@ ip_conntrack_expect_unregister_notifier(
return notifier_chain_unregister(ip_conntrack_expect_chain, nb);
}
+extern void ip_ct_deliver_cached_events(const struct ip_conntrack *ct);
+extern void __ip_ct_event_cache_init(struct ip_conntrack *ct);
+
static inline void
ip_conntrack_event_cache(enum ip_conntrack_events event,
const struct sk_buff *skb)
{
- struct ip_conntrack_ecache *ecache =
- __get_cpu_var(ip_conntrack_ecache);
-
- if (unlikely((struct ip_conntrack *) skb-nfct != ecache-ct)) {
- if (net_ratelimit()) {
- printk(KERN_ERR ctevent: skb-ct != ecache-ct !!!\n);
- dump_stack();
- }
- }
+ struct ip_conntrack *ct = (struct ip_conntrack *)skb-nfct;
+ struct ip_conntrack_ecache *ecache;
+
+ local_bh_disable();
+ ecache = __get_cpu_var(ip_conntrack_ecache);
+ if (ct != ecache-ct)
+ __ip_ct_event_cache_init(ct);
ecache-events |= event;
+ local_bh_enable();
}
-extern void
-ip_conntrack_deliver_cached_events_for(const struct ip_conntrack *ct);
-extern void ip_conntrack_event_cache_init(const struct sk_buff *skb);
-
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct)
{
@@ -483,9 +482,7 @@ static inline void ip_conntrack_event_ca
const struct sk_buff *skb) {}
static inline void ip_conntrack_event(enum ip_conntrack_events event,
struct ip_conntrack *ct) {}
-static inline void ip_conntrack_deliver_cached_events_for(
- struct ip_conntrack *ct) {}
-static inline void ip_conntrack_event_cache_init(const struct sk_buff *skb) {}
+static inline void ip_ct_deliver_cached_events(const struct ip_conntrack *ct)
{}
static inline void
ip_conntrack_expect_event(enum ip_conntrack_expect_events event,
struct ip_conntrack_expect *exp) {}
diff --git a/include/linux/netfilter_ipv4/ip_conntrack_core.h
b/include/linux/netfilter_ipv4/ip_conntrack_core.h
--- a/include/linux/netfilter_ipv4/ip_conntrack_core.h
+++ b/include/linux/netfilter_ipv4/ip_conntrack_core.h
@@ -44,18 +44,14 @@ static inline int ip_conntrack_confirm(s
Re: 2.6.13-rc4-mm1: iptables DROP crashes the computer
On 07/08/05, Patrick McHardy [EMAIL PROTECTED] wrote: Could be related to the refcnt underflow with conntrack event notifications enabled. If you have CONFIG_IP_NF_CONNTRACK_EVENTS enabled please try this patch. I can confirm that that patch solved my problems, thank you :) -- Mvh / Best regards Espen Fjellvær Olsen [EMAIL PROTECTED] Norway - 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-usb-devel] Re: 2.6.13-rc4-mm1
> Date: Sun, 31 Jul 2005 19:02:09 -0700 > From: [EMAIL PROTECTED] > > > Date: Sun, 31 Jul 2005 16:02:44 -0700 > > From: Greg KH <[EMAIL PROTECTED]> > > > > On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: > > > I think that "continuing" codepath came from someone at Phoenix, FWIW; > > > the problem is that I see the PCI quirks code has evolved even farther > > > from the main copy of the init code in the USB tree. Sigh. > > > > I don't like that either, but can't think of a way to make it easier to > > keep them in sync. Can you? > > Sure. The problem as I see it is that there are two copies, and one > of them isn't in the USB part of the tree. So just move it, and cope > with the consequences during the 2.6.14 cycle: > > (a) Move the USB quirks out of the generic PCI drivers directory > into the USB HCD directory (see the attached patch); > > (b) foreach HCD in (ehci ohci uhci) do: > > (1) Merge the two different routines: HCD internal init/reset > and the PCI quirk code are identical in intent, but they > each address different sets of quirks. > > (2) Then the HCD reset() and PCI quirk() code will call those > single shared routine. Attached, find a patch addressing the additional Makefile issue ... > At OLS, Vojtech mentioned wanting to make "usb-handoff" be the default. > That's seem plausible (USB has more than its fair share of BIOS issues!) > but should only kick in sometime after we merge the two different sets > of quirk handling logic. ... but conflicting with a patch Vojtech just submitted for "-mm"; which, as I said, should IMO kick in only after we merge the two different sets of quirk logic. - Dave This moves the PCI quirk handling for USB host controllers from the PCI directory to the USB directory. Follow-on patches will need to: - Merge the two copies that exist ... so EHCI, OHCI, and UHCI each have only one copy of this PCI-specific init logic, and it agrees with more recent code that's aware of _different_ sets of quirks. - We should probably make "usb-handoff" be the default. The late handoff seems to confuse some BIOS versions, and then the input subsystem. Signed-off-by: David Brownell <[EMAIL PROTECTED]> Index: g26/drivers/usb/host/Makefile === --- g26.orig/drivers/usb/host/Makefile 2005-08-02 06:59:22.0 -0700 +++ g26/drivers/usb/host/Makefile 2005-08-02 07:58:44.0 -0700 @@ -1,8 +1,9 @@ # -# Makefile for USB Host Controller Driver -# framework and drivers +# Makefile for USB Host Controller Drivers # +obj-$(CONFIG_PCI) += pci-quirks.o + obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o Index: g26/drivers/usb/Makefile === --- g26.orig/drivers/usb/Makefile 2005-08-02 06:59:22.0 -0700 +++ g26/drivers/usb/Makefile2005-08-02 07:58:44.0 -0700 @@ -8,6 +8,7 @@ obj-$(CONFIG_USB) += core/ obj-$(CONFIG_USB_MON) += mon/ +obj-$(CONFIG_PCI) += host/ obj-$(CONFIG_USB_EHCI_HCD) += host/ obj-$(CONFIG_USB_ISP116X_HCD) += host/ obj-$(CONFIG_USB_OHCI_HCD) += host/ Index: g26/drivers/Makefile === --- g26.orig/drivers/Makefile 2005-08-02 06:59:22.0 -0700 +++ g26/drivers/Makefile2005-08-02 07:58:44.0 -0700 @@ -5,7 +5,7 @@ # Rewritten to use lists instead of if-statements. # -obj-$(CONFIG_PCI) += pci/ +obj-$(CONFIG_PCI) += pci/ usb/host/ obj-$(CONFIG_PARISC) += parisc/ obj-y += video/ obj-$(CONFIG_ACPI_BOOT)+= acpi/ Index: g26/drivers/usb/host/pci-quirks.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ g26/drivers/usb/host/pci-quirks.c 2005-08-02 07:58:44.0 -0700 @@ -0,0 +1,279 @@ +/* + * This file contains work-arounds for many known PCI hardware and BIOS + * quirks relating to USB host controllers. + * + * There are a lot of those, especially on hardware that needs to work + * with USB mice and keyboard for booting. And this code needs to fire + * early; before the input subsystem gets initialized, and while BIOS + * (or SMI) code has few problems running. + * + * They're collected here since USB host controller drivers need to use + * the same code as part of hardware initialization. + * + * Copyright (c) 1999 Martin Mares <[EMAIL PROTECTED]> + * (and others) + */ + +#include +#include +#include +#include +#include +#include +#include + +// #include "pci.h" + +/* + * PIIX3 USB: We have to disable USB interrupts that are + * hardwired to PIRQD# and may be shared with an + * external device. + * + *
Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
Date: Sun, 31 Jul 2005 19:02:09 -0700 From: [EMAIL PROTECTED] Date: Sun, 31 Jul 2005 16:02:44 -0700 From: Greg KH [EMAIL PROTECTED] On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: I think that continuing codepath came from someone at Phoenix, FWIW; the problem is that I see the PCI quirks code has evolved even farther from the main copy of the init code in the USB tree. Sigh. I don't like that either, but can't think of a way to make it easier to keep them in sync. Can you? Sure. The problem as I see it is that there are two copies, and one of them isn't in the USB part of the tree. So just move it, and cope with the consequences during the 2.6.14 cycle: (a) Move the USB quirks out of the generic PCI drivers directory into the USB HCD directory (see the attached patch); (b) foreach HCD in (ehci ohci uhci) do: (1) Merge the two different routines: HCD internal init/reset and the PCI quirk code are identical in intent, but they each address different sets of quirks. (2) Then the HCD reset() and PCI quirk() code will call those single shared routine. Attached, find a patch addressing the additional Makefile issue ... At OLS, Vojtech mentioned wanting to make usb-handoff be the default. That's seem plausible (USB has more than its fair share of BIOS issues!) but should only kick in sometime after we merge the two different sets of quirk handling logic. ... but conflicting with a patch Vojtech just submitted for -mm; which, as I said, should IMO kick in only after we merge the two different sets of quirk logic. - Dave This moves the PCI quirk handling for USB host controllers from the PCI directory to the USB directory. Follow-on patches will need to: - Merge the two copies that exist ... so EHCI, OHCI, and UHCI each have only one copy of this PCI-specific init logic, and it agrees with more recent code that's aware of _different_ sets of quirks. - We should probably make usb-handoff be the default. The late handoff seems to confuse some BIOS versions, and then the input subsystem. Signed-off-by: David Brownell [EMAIL PROTECTED] Index: g26/drivers/usb/host/Makefile === --- g26.orig/drivers/usb/host/Makefile 2005-08-02 06:59:22.0 -0700 +++ g26/drivers/usb/host/Makefile 2005-08-02 07:58:44.0 -0700 @@ -1,8 +1,9 @@ # -# Makefile for USB Host Controller Driver -# framework and drivers +# Makefile for USB Host Controller Drivers # +obj-$(CONFIG_PCI) += pci-quirks.o + obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o Index: g26/drivers/usb/Makefile === --- g26.orig/drivers/usb/Makefile 2005-08-02 06:59:22.0 -0700 +++ g26/drivers/usb/Makefile2005-08-02 07:58:44.0 -0700 @@ -8,6 +8,7 @@ obj-$(CONFIG_USB) += core/ obj-$(CONFIG_USB_MON) += mon/ +obj-$(CONFIG_PCI) += host/ obj-$(CONFIG_USB_EHCI_HCD) += host/ obj-$(CONFIG_USB_ISP116X_HCD) += host/ obj-$(CONFIG_USB_OHCI_HCD) += host/ Index: g26/drivers/Makefile === --- g26.orig/drivers/Makefile 2005-08-02 06:59:22.0 -0700 +++ g26/drivers/Makefile2005-08-02 07:58:44.0 -0700 @@ -5,7 +5,7 @@ # Rewritten to use lists instead of if-statements. # -obj-$(CONFIG_PCI) += pci/ +obj-$(CONFIG_PCI) += pci/ usb/host/ obj-$(CONFIG_PARISC) += parisc/ obj-y += video/ obj-$(CONFIG_ACPI_BOOT)+= acpi/ Index: g26/drivers/usb/host/pci-quirks.c === --- /dev/null 1970-01-01 00:00:00.0 + +++ g26/drivers/usb/host/pci-quirks.c 2005-08-02 07:58:44.0 -0700 @@ -0,0 +1,279 @@ +/* + * This file contains work-arounds for many known PCI hardware and BIOS + * quirks relating to USB host controllers. + * + * There are a lot of those, especially on hardware that needs to work + * with USB mice and keyboard for booting. And this code needs to fire + * early; before the input subsystem gets initialized, and while BIOS + * (or SMI) code has few problems running. + * + * They're collected here since USB host controller drivers need to use + * the same code as part of hardware initialization. + * + * Copyright (c) 1999 Martin Mares [EMAIL PROTECTED] + * (and others) + */ + +#include linux/config.h +#include linux/types.h +#include linux/kernel.h +#include linux/pci.h +#include linux/init.h +#include linux/delay.h +#include linux/acpi.h + +// #include pci.h + +/* + * PIIX3 USB: We have to disable USB interrupts that are + * hardwired to PIRQD# and may be shared with an + *
Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
> >> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: > >> > I think that "continuing" codepath came from someone at > >> > Phoenix, FWIW; > > That was me. Thanks. It's good to have BIOS experts involved too. :) > >> > the problem is that I see the PCI quirks code has evolved > >even farther > >> > from the main copy of the init code in the USB tree. Sigh. > >> > >> I don't like that either, but can't think of a way to make > >it easier to > >> keep them in sync. Can you? > > Major problem here is that handoff may be necessary even if whole > USB support is disabled in config. I was thinking of integrating them > into USB code somehow, but did not have enough time for it, sorry :( So now would seem to be the time to start ... > >Sure. The problem as I see it is that there are two copies, and one > >of them isn't in the USB part of the tree. So just move it, and cope > >with the consequences during the 2.6.14 cycle: > > > > (a) Move the USB quirks out of the generic PCI drivers directory > > into the USB HCD directory (see the attached patch); > > > > (b) foreach HCD in (ehci ohci uhci) do: > > > > (1) Merge the two different routines: HCD internal init/reset > > and the PCI quirk code are identical in intent, but they > > each address different sets of quirks. > > > > (2) Then the HCD reset() and PCI quirk() code will call those > > single shared routine. > > > > Agree, but at least: > - drivers/Makefile & drivers/usb/Makefile have to be modified as well >to include quirks on CONFIG_PCI I was more thinking that when CONFIG_PCI it should just always descend into the relevant USB dirs; right now it only does it when CONFIG_USB, and that shouldn't matter. This is a reason to update that (a) patch before merging. > - Constants like EHCI_USBCMD_RUN should probably be replaced with > 'native' usb code ones. Yes. That would be part of (b.1) patches above. Ditto for UHCI, OHCI; the resulting routine would be exported to HCDs given CONFIG_USB. It's probably too early to talk about whether the driver model should include platform-specific device reset() methods, though that could be handy in some other board customization cases. :) - Dave > Thanks, > Aleks. > > > > >At OLS, Vojtech mentioned wanting to make "usb-handoff" be the default. > >That's seem plausible (USB has more than its fair share of > >BIOS issues!) > >but should only kick in sometime after we merge the two different sets > >of quirk handling logic. > > > >- Dave > > - 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-usb-devel] Re: 2.6.13-rc4-mm1
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>[EMAIL PROTECTED]
>Sent: Sunday, July 31, 2005 7:02 PM
>To: [EMAIL PROTECTED]
>Cc: linux-usb-devel@lists.sourceforge.net;
>linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
>Subject: Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
>
>> Date: Sun, 31 Jul 2005 16:02:44 -0700
>> From: Greg KH <[EMAIL PROTECTED]>
>>
>> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
>> > I think that "continuing" codepath came from someone at
>Phoenix, FWIW;
That was me.
>> > the problem is that I see the PCI quirks code has evolved
>even farther
>> > from the main copy of the init code in the USB tree. Sigh.
>>
>> I don't like that either, but can't think of a way to make
>it easier to
>> keep them in sync. Can you?
Major problem here is that handoff may be necessary even if whole
USB support is disabled in config. I was thinking of integrating them
into
USB code somehow, but did not have enough time for it, sorry :(
>
>Sure. The problem as I see it is that there are two copies, and one
>of them isn't in the USB part of the tree. So just move it, and cope
>with the consequences during the 2.6.14 cycle:
>
> (a) Move the USB quirks out of the generic PCI drivers directory
> into the USB HCD directory (see the attached patch);
>
> (b) foreach HCD in (ehci ohci uhci) do:
>
> (1) Merge the two different routines: HCD internal init/reset
> and the PCI quirk code are identical in intent, but they
> each address different sets of quirks.
>
> (2) Then the HCD reset() and PCI quirk() code will call those
> single shared routine.
>
Agree, but at least:
- drivers/Makefile & drivers/usb/Makefile have to be modified as well
to include
quirks on CONFIG_PCI
- Constants like EHCI_USBCMD_RUN should probably be replaced with
'native' usb code ones.
Thanks,
Aleks.
>
>At OLS, Vojtech mentioned wanting to make "usb-handoff" be the default.
>That's seem plausible (USB has more than its fair share of
>BIOS issues!)
>but should only kick in sometime after we merge the two different sets
>of quirk handling logic.
>
>- Dave
>
>
>
>This moves the PCI quirk handling for USB host controllers from the
>PCI directory to the USB directory.
>
>Follow-on patches will need to remove code duplication, and probably
>make "usb-handoff" be the system default.
>
>Compile-tested only so far.
>
>Signed-off-by: David Brownell <[EMAIL PROTECTED]>
>
>--- g26.orig/drivers/usb/host/Makefile 2005-06-28
>19:23:13.0 -0700
>+++ g26/drivers/usb/host/Makefile 2005-07-31
>18:41:35.0 -0700
>@@ -1,8 +1,9 @@
> #
>-# Makefile for USB Host Controller Driver
>-# framework and drivers
>+# Makefile for USB Host Controller Drivers
> #
>
>+obj-$(CONFIG_PCI) += pci-quirks.o
>+
> obj-$(CONFIG_USB_EHCI_HCD)+= ehci-hcd.o
> obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
> obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
>--- /dev/null 1970-01-01 00:00:00.0 +
>+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31
>17:33:38.0 -0700
>@@ -0,0 +1,279 @@
>+/*
>+ * This file contains work-arounds for many known PCI
>hardware and BIOS
>+ * quirks relating to USB host controllers.
>+ *
>+ * There are a lot of those, especially on hardware that needs to work
>+ * with USB mice and keyboard for booting. And this code
>needs to fire
>+ * early; before the input subsystem gets initialized, and while BIOS
>+ * (or SMI) code has few problems running.
>+ *
>+ * They're collected here since USB host controller drivers
>need to use
>+ * the same code as part of hardware initialization.
>+ *
>+ * Copyright (c) 1999 Martin Mares <[EMAIL PROTECTED]>
>+ * (and others)
>+ */
>+
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+#include
>+
>+// #include "pci.h"
>+
>+/*
>+ * PIIX3 USB: We have to disable USB interrupts that are
>+ * hardwired to PIRQD# and may be shared with an
>+ * external device.
>+ *
>+ * Legacy Support Register (LEGSUP):
>+ * bit13: USB PIRQ Enable (USBPIRQDEN),
>+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
>+ *
>+ * We mask out all r/wc bits, too.
>+ */
>+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
>+{
>+ u16 legsup;
>+
>+ pci_read_config_word(dev, 0xc0, );
>+ legsup &= 0x50ef;
>+ pci_write_config_word(dev, 0xc0, legsup);
>+}
>+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
>PCI_D
RE: 2.6.13-rc4-mm1
>-Original Message- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Michael Thonke >Sent: Sunday, July 31, 2005 8:12 AM >To: Andrew Morton >Cc: linux-kernel@vger.kernel.org >Subject: Re: 2.6.13-rc4-mm1 > >Hello Andrew, > >the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. >The system boots now noiseless, except on problem with USB. > >If my Prolific USB-Serialadapter plugged in on reboot >the ehci_hcd driver complains about a Hand-off bug in Bios. > >-> snip > >ehci_hcd :00:1d.7: EHCI Host Controller > >ehci_hcd :00:1d.7: debug port 1 > >ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) > >ehci_hcd :00:1d.7: continuing after BIOS bug... > >ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 > >ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 > >-> snip > > >I wonder about this because all other USB devices working without this >message on boot. > >USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. > >When I rebooted without plugged Prolific Adapter and plug them in the >same port >the kernel prints this message. > >->snip > >usb 4-1: new full speed USB device using uhci_hcd and address 2 > >pl2303 4-1:1.0: PL-2303 converter detected > >usb 4-1: PL-2303 converter now attached to ttyUSB0 > >-> snip > > >Any Ideas what could be wrong here? > Could you try 'usb-handoff' as a kernel parameter. Is it any better ? Aleks. - 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.13-rc4-mm1
From: Alexandre Buisse <[EMAIL PROTECTED]> Date: Mon, 01 Aug 2005 07:52:29 +0200 > I have this when I enable nfnetlink as a module : > > net/built-in.o: In function `ip_ct_port_tuple_to_nfattr': > : undefined reference to `__nfa_fill' This got fixed in -mm2 and later methinks. - 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.13-rc4-mm1
Hi Andrew, I have this when I enable nfnetlink as a module : net/built-in.o: In function `ip_ct_port_tuple_to_nfattr': : undefined reference to `__nfa_fill' net/built-in.o: In function `ip_ct_port_tuple_to_nfattr': : undefined reference to `__nfa_fill' net/built-in.o: In function `tcp_to_nfattr': ip_conntrack_proto_tcp.c:(.text+0x5c557): undefined reference to `__nfa_fill' net/built-in.o: In function `icmp_tuple_to_nfattr': ip_conntrack_proto_icmp.c:(.text+0x5e1e2): undefined reference to `__nfa_fill' ip_conntrack_proto_icmp.c:(.text+0x5e221): undefined reference to `__nfa_fill' net/built-in.o:ip_conntrack_proto_icmp.c:(.text+0x5e25c): more undefined references to `__nfa_fill' follow Relevant part of my .config : CONFIG_IP_NF_CONNTRACK_NETLINK=m CONFIG_NETFILTER_NETLINK=m # CONFIG_NETFILTER_NETLINK_QUEUE is not set I am sorry, but I don't have time to investigate it further. Regards, Alexandre - 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.13-rc4-mm1
Hi Andrew, I have this when I enable nfnetlink as a module : net/built-in.o: In function `ip_ct_port_tuple_to_nfattr': : undefined reference to `__nfa_fill' net/built-in.o: In function `ip_ct_port_tuple_to_nfattr': : undefined reference to `__nfa_fill' net/built-in.o: In function `tcp_to_nfattr': ip_conntrack_proto_tcp.c:(.text+0x5c557): undefined reference to `__nfa_fill' net/built-in.o: In function `icmp_tuple_to_nfattr': ip_conntrack_proto_icmp.c:(.text+0x5e1e2): undefined reference to `__nfa_fill' ip_conntrack_proto_icmp.c:(.text+0x5e221): undefined reference to `__nfa_fill' net/built-in.o:ip_conntrack_proto_icmp.c:(.text+0x5e25c): more undefined references to `__nfa_fill' follow Relevant part of my .config : CONFIG_IP_NF_CONNTRACK_NETLINK=m CONFIG_NETFILTER_NETLINK=m # CONFIG_NETFILTER_NETLINK_QUEUE is not set I am sorry, but I don't have time to investigate it further. Regards, Alexandre - 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.13-rc4-mm1
From: Alexandre Buisse [EMAIL PROTECTED] Date: Mon, 01 Aug 2005 07:52:29 +0200 I have this when I enable nfnetlink as a module : net/built-in.o: In function `ip_ct_port_tuple_to_nfattr': : undefined reference to `__nfa_fill' This got fixed in -mm2 and later methinks. - 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.13-rc4-mm1
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Michael Thonke Sent: Sunday, July 31, 2005 8:12 AM To: Andrew Morton Cc: linux-kernel@vger.kernel.org Subject: Re: 2.6.13-rc4-mm1 Hello Andrew, the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. The system boots now noiseless, except on problem with USB. If my Prolific USB-Serialadapter plugged in on reboot the ehci_hcd driver complains about a Hand-off bug in Bios. - snip ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: debug port 1 ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) ehci_hcd :00:1d.7: continuing after BIOS bug... ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 - snip I wonder about this because all other USB devices working without this message on boot. USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. When I rebooted without plugged Prolific Adapter and plug them in the same port the kernel prints this message. -snip usb 4-1: new full speed USB device using uhci_hcd and address 2 pl2303 4-1:1.0: PL-2303 converter detected usb 4-1: PL-2303 converter now attached to ttyUSB0 - snip Any Ideas what could be wrong here? Could you try 'usb-handoff' as a kernel parameter. Is it any better ? Aleks. - 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-usb-devel] Re: 2.6.13-rc4-mm1
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of
[EMAIL PROTECTED]
Sent: Sunday, July 31, 2005 7:02 PM
To: [EMAIL PROTECTED]
Cc: linux-usb-devel@lists.sourceforge.net;
linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at
Phoenix, FWIW;
That was me.
the problem is that I see the PCI quirks code has evolved
even farther
from the main copy of the init code in the USB tree. Sigh.
I don't like that either, but can't think of a way to make
it easier to
keep them in sync. Can you?
Major problem here is that handoff may be necessary even if whole
USB support is disabled in config. I was thinking of integrating them
into
USB code somehow, but did not have enough time for it, sorry :(
Sure. The problem as I see it is that there are two copies, and one
of them isn't in the USB part of the tree. So just move it, and cope
with the consequences during the 2.6.14 cycle:
(a) Move the USB quirks out of the generic PCI drivers directory
into the USB HCD directory (see the attached patch);
(b) foreach HCD in (ehci ohci uhci) do:
(1) Merge the two different routines: HCD internal init/reset
and the PCI quirk code are identical in intent, but they
each address different sets of quirks.
(2) Then the HCD reset() and PCI quirk() code will call those
single shared routine.
Agree, but at least:
- drivers/Makefile drivers/usb/Makefile have to be modified as well
to include
quirks on CONFIG_PCI
- Constants like EHCI_USBCMD_RUN should probably be replaced with
'native' usb code ones.
Thanks,
Aleks.
At OLS, Vojtech mentioned wanting to make usb-handoff be the default.
That's seem plausible (USB has more than its fair share of
BIOS issues!)
but should only kick in sometime after we merge the two different sets
of quirk handling logic.
- Dave
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory.
Follow-on patches will need to remove code duplication, and probably
make usb-handoff be the system default.
Compile-tested only so far.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/host/Makefile 2005-06-28
19:23:13.0 -0700
+++ g26/drivers/usb/host/Makefile 2005-07-31
18:41:35.0 -0700
@@ -1,8 +1,9 @@
#
-# Makefile for USB Host Controller Driver
-# framework and drivers
+# Makefile for USB Host Controller Drivers
#
+obj-$(CONFIG_PCI) += pci-quirks.o
+
obj-$(CONFIG_USB_EHCI_HCD)+= ehci-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_OHCI_HCD)+= ohci-hcd.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31
17:33:38.0 -0700
@@ -0,0 +1,279 @@
+/*
+ * This file contains work-arounds for many known PCI
hardware and BIOS
+ * quirks relating to USB host controllers.
+ *
+ * There are a lot of those, especially on hardware that needs to work
+ * with USB mice and keyboard for booting. And this code
needs to fire
+ * early; before the input subsystem gets initialized, and while BIOS
+ * (or SMI) code has few problems running.
+ *
+ * They're collected here since USB host controller drivers
need to use
+ * the same code as part of hardware initialization.
+ *
+ * Copyright (c) 1999 Martin Mares [EMAIL PROTECTED]
+ * (and others)
+ */
+
+#include linux/config.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/acpi.h
+
+// #include pci.h
+
+/*
+ * PIIX3 USB: We have to disable USB interrupts that are
+ * hardwired to PIRQD# and may be shared with an
+ * external device.
+ *
+ * Legacy Support Register (LEGSUP):
+ * bit13: USB PIRQ Enable (USBPIRQDEN),
+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
+ *
+ * We mask out all r/wc bits, too.
+ */
+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
+{
+ u16 legsup;
+
+ pci_read_config_word(dev, 0xc0, legsup);
+ legsup = 0x50ef;
+ pci_write_config_word(dev, 0xc0, legsup);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82371SB_2, quirk_piix3_usb );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL,
PCI_DEVICE_ID_INTEL_82371AB_2, quirk_piix3_usb );
+
+
+/* FIXME this should be the same code that the USB controllers use...
+ * the hcd-reset() method basically does this.
+ */
+
+#define UHCI_USBLEGSUP0xc0/*
legacy support */
+#define UHCI_USBCMD 0 /* command register */
+#define UHCI_USBSTS 2 /* status register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define
Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: I think that continuing codepath came from someone at Phoenix, FWIW; That was me. Thanks. It's good to have BIOS experts involved too. :) the problem is that I see the PCI quirks code has evolved even farther from the main copy of the init code in the USB tree. Sigh. I don't like that either, but can't think of a way to make it easier to keep them in sync. Can you? Major problem here is that handoff may be necessary even if whole USB support is disabled in config. I was thinking of integrating them into USB code somehow, but did not have enough time for it, sorry :( So now would seem to be the time to start ... Sure. The problem as I see it is that there are two copies, and one of them isn't in the USB part of the tree. So just move it, and cope with the consequences during the 2.6.14 cycle: (a) Move the USB quirks out of the generic PCI drivers directory into the USB HCD directory (see the attached patch); (b) foreach HCD in (ehci ohci uhci) do: (1) Merge the two different routines: HCD internal init/reset and the PCI quirk code are identical in intent, but they each address different sets of quirks. (2) Then the HCD reset() and PCI quirk() code will call those single shared routine. Agree, but at least: - drivers/Makefile drivers/usb/Makefile have to be modified as well to include quirks on CONFIG_PCI I was more thinking that when CONFIG_PCI it should just always descend into the relevant USB dirs; right now it only does it when CONFIG_USB, and that shouldn't matter. This is a reason to update that (a) patch before merging. - Constants like EHCI_USBCMD_RUN should probably be replaced with 'native' usb code ones. Yes. That would be part of (b.1) patches above. Ditto for UHCI, OHCI; the resulting routine would be exported to HCDs given CONFIG_USB. It's probably too early to talk about whether the driver model should include platform-specific device reset() methods, though that could be handy in some other board customization cases. :) - Dave Thanks, Aleks. At OLS, Vojtech mentioned wanting to make usb-handoff be the default. That's seem plausible (USB has more than its fair share of BIOS issues!) but should only kick in sometime after we merge the two different sets of quirk handling logic. - Dave - 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-usb-devel] Re: 2.6.13-rc4-mm1
> Date: Sun, 31 Jul 2005 16:02:44 -0700
> From: Greg KH <[EMAIL PROTECTED]>
>
> On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
> > I think that "continuing" codepath came from someone at Phoenix, FWIW;
> > the problem is that I see the PCI quirks code has evolved even farther
> > from the main copy of the init code in the USB tree. Sigh.
>
> I don't like that either, but can't think of a way to make it easier to
> keep them in sync. Can you?
Sure. The problem as I see it is that there are two copies, and one
of them isn't in the USB part of the tree. So just move it, and cope
with the consequences during the 2.6.14 cycle:
(a) Move the USB quirks out of the generic PCI drivers directory
into the USB HCD directory (see the attached patch);
(b) foreach HCD in (ehci ohci uhci) do:
(1) Merge the two different routines: HCD internal init/reset
and the PCI quirk code are identical in intent, but they
each address different sets of quirks.
(2) Then the HCD reset() and PCI quirk() code will call those
single shared routine.
At OLS, Vojtech mentioned wanting to make "usb-handoff" be the default.
That's seem plausible (USB has more than its fair share of BIOS issues!)
but should only kick in sometime after we merge the two different sets
of quirk handling logic.
- Dave
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory.
Follow-on patches will need to remove code duplication, and probably
make "usb-handoff" be the system default.
Compile-tested only so far.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
--- g26.orig/drivers/usb/host/Makefile 2005-06-28 19:23:13.0 -0700
+++ g26/drivers/usb/host/Makefile 2005-07-31 18:41:35.0 -0700
@@ -1,8 +1,9 @@
#
-# Makefile for USB Host Controller Driver
-# framework and drivers
+# Makefile for USB Host Controller Drivers
#
+obj-$(CONFIG_PCI) += pci-quirks.o
+
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31 17:33:38.0 -0700
@@ -0,0 +1,279 @@
+/*
+ * This file contains work-arounds for many known PCI hardware and BIOS
+ * quirks relating to USB host controllers.
+ *
+ * There are a lot of those, especially on hardware that needs to work
+ * with USB mice and keyboard for booting. And this code needs to fire
+ * early; before the input subsystem gets initialized, and while BIOS
+ * (or SMI) code has few problems running.
+ *
+ * They're collected here since USB host controller drivers need to use
+ * the same code as part of hardware initialization.
+ *
+ * Copyright (c) 1999 Martin Mares <[EMAIL PROTECTED]>
+ * (and others)
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+// #include "pci.h"
+
+/*
+ * PIIX3 USB: We have to disable USB interrupts that are
+ * hardwired to PIRQD# and may be shared with an
+ * external device.
+ *
+ * Legacy Support Register (LEGSUP):
+ * bit13: USB PIRQ Enable (USBPIRQDEN),
+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
+ *
+ * We mask out all r/wc bits, too.
+ */
+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
+{
+ u16 legsup;
+
+ pci_read_config_word(dev, 0xc0, );
+ legsup &= 0x50ef;
+ pci_write_config_word(dev, 0xc0, legsup);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_2,
quirk_piix3_usb );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_2,
quirk_piix3_usb );
+
+
+/* FIXME this should be the same code that the USB controllers use...
+ * the hcd->reset() method basically does this.
+ */
+
+#define UHCI_USBLEGSUP 0xc0/* legacy support */
+#define UHCI_USBCMD0 /* command register */
+#define UHCI_USBSTS2 /* status register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define UHCI_USBLEGSUP_DEFAULT 0x2000 /* only PIRQ enable set */
+#define UHCI_USBCMD_RUN(1 << 0)/* RUN/STOP bit */
+#define UHCI_USBCMD_GRESET (1 << 2)/* Global reset */
+#define UHCI_USBCMD_CONFIGURE (1 << 6)/* config semaphore */
+#define UHCI_USBSTS_HALTED (1 << 5)/* HCHalted bit */
+
+#define OHCI_CONTROL 0x04
+#define OHCI_CMDSTATUS 0x08
+#define OHCI_INTRSTATUS0x0c
+#define OHCI_INTRENABLE0x10
+#define OHCI_INTRDISABLE 0x14
+#define OHCI_OCR (1 << 3)/* ownership change request */
+#define OHCI_CTRL_IR (1 << 8)/* interrupt routing */
+#define OHCI_INTR_OC (1 << 30) /* ownership change */
+
+#define EHCI_HCC_PARAMS0x08/* extended
capabilities
Re: 2.6.13-rc4-mm1
Jesus Delgado <[EMAIL PROTECTED]> wrote: > > Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems > is the boot hang: >my test is different combinations the acpi=off , noacpi, pci=noirq, > etc.etc both have is the same error not boot. > > The only information is simple: > > .. > > Uncompressiong Linux... Ok. booting the kernel. > _ > > Not more information. You should check basic .config things such as the CPU type. Also ensure that you have `earlyprintk=vga' on the kernel boot command line. The only thing I can think of which would cause such an early failure is the kexec changes. Does 2.6.13-rc1 work OK? It had kexec. If 2.6.13-rc1 fails then please try these patches, against 2.6.12: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.12-git7.gz ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.12-git8.gz If 2.6.12-git7 works and 2.6.12-git8 fails then we'll know where to start looking, thanks. - 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.13-rc4-mm1
Hi all: Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems is the boot hang: my test is different combinations the acpi=off , noacpi, pci=noirq, etc.etc both have is the same error not boot. The only information is simple: .. Uncompressiong Linux... Ok. booting the kernel. _ Not more information. anex dmesg the kernel 2.6.12-ck3. Linux version 2.6.12-ck3 ([EMAIL PROTECTED] (gcc version 4.0.1 20050720 (Red Hat 4.0.1-4)) #1 Mon Jul 25 00:14:40 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 4fef (usable) BIOS-e820: 4fef - 4fefb000 (ACPI data) BIOS-e820: 4fefb000 - 4ff0 (ACPI NVS) BIOS-e820: 4ff0 - 5000 (reserved) BIOS-e820: fffe - 0001 (reserved) 382MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 327408 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 98032 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f8410 ACPI: RSDT (v001 Arima 161Fh0x0604 LTP 0x) @ 0x4fef6b5d ACPI: FADT (v001 Arima 161Fh0x0604 PTL_ 0x000f4240) @ 0x4fefae66 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x4fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x4fefafb0 ACPI: DSDT (v001 Arima 161Fh0x0604 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x4008 Allocating PCI resources starting at 5000 (gap: 5000:affe) Built 1 zonelists Kernel command line: ro root=LABEL=/ early-login quiet vga=788 Initializing CPU#0 CPU 0 irqstacks, hard=c047 soft=c046f000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1804.747 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1292408k/1309632k available (2620k kernel code, 16076k reserved, 680k data, 188k init, 392128k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3571.71 BogoMIPS (lpj=1785856) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff e1d3fbff CPU: After vendor identify, caps: 078bfbff e1d3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: After all inits, caps: 078bfbff e1d3fbff 0010 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Mobile AMD Athlon(tm) 64 Processor 3000+ stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0400 (from 0e00) checking if image is initramfs... it is Freeing initrd memory: 1086k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd8cc, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *9, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 23) *11, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *10, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *10, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *9 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 11 12 14 15) *10 ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: Embedded Controller [EC] (gpe 1) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 8 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report pnp: 00:05: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:05: ioport range 0xf510-0xf511 could not be reserved pnp: 00:05: ioport range 0xf500-0xf500 has been reserved pnp: 00:05: ioport range 0x4000-0x407f could not be reserved pnp: 00:05: ioport range 0x8100-0x811f has been reserved apm: BIOS
Re: [linux-usb-devel] Re: 2.6.13-rc4-mm1
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: > I think that "continuing" codepath came from someone at Phoenix, FWIW; > the problem is that I see the PCI quirks code has evolved even farther > from the main copy of the init code in the USB tree. Sigh. I don't like that either, but can't think of a way to make it easier to keep them in sync. Can you? thanks, greg k-h - 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.13-rc4-mm1
Andrew Morton wrote: > Andreas Steinmetz <[EMAIL PROTECTED]> wrote: > >>Andrew Morton wrote: >> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ >> >> Andrew, >> the good news is I can access pcmcia devices with rc4-mm1 which I >> couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least >> one more problem with yenta_socket. Please see the attached dmesg output >> and look for: >> >> Badness in __release_resource at kernel/resource.c:184 >> >> This happens when accessing pcmcia from an initrd to read keys from a >> pcmcia flash disk and removing the pcmcia modules afterwards. > > > hm, OK. That's brought to us by the below -mm-only debugging patch. Maybe > we should add more stuff to it to idenfify the child resources? > Well, could be. Unfortunately I have zero knowledge in this area of the kernel. Maybe Dominik can help? -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - 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-usb-devel] Re: 2.6.13-rc4-mm1
> > If my Prolific USB-Serialadapter plugged in on reboot > > the ehci_hcd driver complains about a Hand-off bug in Bios. > > > > -> snip > > > > ehci_hcd :00:1d.7: EHCI Host Controller > > ehci_hcd :00:1d.7: debug port 1 > > > > ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) > > ehci_hcd :00:1d.7: continuing after BIOS bug... This is a warning, not an error, but it's one of two symptoms of BIOS level problems on your board. - Try booting with the "usb-handoff" kernel parameter, to kick in more specialized PCI quirk handling. - See if there's a BIOS setting related to USB that you can change. Sometimes they use quirky modes. - See if there's a BIOS update for your motherboard. I think that "continuing" codepath came from someone at Phoenix, FWIW; the problem is that I see the PCI quirks code has evolved even farther from the main copy of the init code in the USB tree. Sigh. > > When I rebooted without plugged Prolific Adapter and plug them in the > > same port the kernel prints this message. > > > > ->snip > > > > usb 4-1: new full speed USB device using uhci_hcd and address 2 > > pl2303 4-1:1.0: PL-2303 converter detected > > usb 4-1: PL-2303 converter now attached to ttyUSB0 > > > > > > Any Ideas what could be wrong here? That is, you think it should always see the adapter, not just when it's not plugged in at boot time? Sure sounds like BIOS problems to me. - Dave - 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.13-rc4-mm1
Andreas Steinmetz <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> >
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
>
> Andrew,
> the good news is I can access pcmcia devices with rc4-mm1 which I
> couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
> one more problem with yenta_socket. Please see the attached dmesg output
> and look for:
>
> Badness in __release_resource at kernel/resource.c:184
>
> This happens when accessing pcmcia from an initrd to read keys from a
> pcmcia flash disk and removing the pcmcia modules afterwards.
hm, OK. That's brought to us by the below -mm-only debugging patch. Maybe
we should add more stuff to it to idenfify the child resources?
From: [EMAIL PROTECTED] (Matthew Wilcox)
What does it mean to release a resource with children? Should the children
become children of the released resource's parent? Should they be released
too? Should we fail the release?
I bet we have no callers who expect this right now, but with
insert_resource() we may get some. At the point where someone hits this
BUG we can figure out what semantics we want.
Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
---
25-akpm/kernel/resource.c |2 ++
1 files changed, 2 insertions(+)
diff -puN kernel/resource.c~releasing-resources-with-children kernel/resource.c
--- 25/kernel/resource.c~releasing-resources-with-children 2005-04-02
00:21:52.0 -0800
+++ 25-akpm/kernel/resource.c 2005-04-02 00:22:22.0 -0800
@@ -181,6 +181,8 @@ static int __release_resource(struct res
{
struct resource *tmp, **p;
+ WARN_ON(old->child);
+
p = >parent->child;
for (;;) {
tmp = *p;
_
-
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.13-rc4-mm1
(cc linux-usb-devel) Michael Thonke <[EMAIL PROTECTED]> wrote: > > Hello Andrew, > > the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. > The system boots now noiseless, except on problem with USB. > > If my Prolific USB-Serialadapter plugged in on reboot > the ehci_hcd driver complains about a Hand-off bug in Bios. > > -> snip > > ehci_hcd :00:1d.7: EHCI Host Controller > > ehci_hcd :00:1d.7: debug port 1 > > ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) > > ehci_hcd :00:1d.7: continuing after BIOS bug... > > ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 > > ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 > > -> snip > > > I wonder about this because all other USB devices working without this > message on boot. > > USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. > > When I rebooted without plugged Prolific Adapter and plug them in the > same port > the kernel prints this message. > > ->snip > > usb 4-1: new full speed USB device using uhci_hcd and address 2 > > pl2303 4-1:1.0: PL-2303 converter detected > > usb 4-1: PL-2303 converter now attached to ttyUSB0 > > -> snip > > > Any Ideas what could be wrong here? Nope. Can you identify the most recent kernel which didn't have these problems? - 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.13-rc4-mm1
On Sun, 31 Jul 2005 02:05:52 -0700 Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ > > - Dropped the connector patches: turns out that we no longer have a netlink > slot available for them anyway. I don't feel strongly pro or con about the connector patches, but DaveM suggested using a netlink multiplexer for iscsi (which also needs a netlink slot), so presumably that could work for the connector patches also...? --- ~Randy - 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.13-rc4-mm1
> >Why was the KERNEL_VERSION(a,b,c) macro removed from > >include/linux/version.h? The removal breaks external drivers like > >NDISWRAPPER or nVidia propietary. > > > Hello Felipe, > > I could not regonize a breakage of NVidia (Version 1.0-7667) propietary > drivers. > They work just perfect. Indeed they do work perfectly, but I can't compile them (from the nVidia package) without adding back the KERNEL_VERSION macro in file include/linux/version.h. - 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.13-rc4-mm1
Andrew Morton wrote: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Andrew, the good news is I can access pcmcia devices with rc4-mm1 which I couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least one more problem with yenta_socket. Please see the attached dmesg output and look for: Badness in __release_resource at kernel/resource.c:184 This happens when accessing pcmcia from an initrd to read keys from a pcmcia flash disk and removing the pcmcia modules afterwards. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] Bootdata ok (command line is BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 init=/linuxrc rw) Linux version 2.6.13-rc4-mm1-gringo ([EMAIL PROTECTED]) (gcc version 3.4.4) #1 PREEMPT Sun Jul 31 15:11:12 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7a000 (ACPI data) BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fffe - 0001 (reserved) ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x3ff73fde ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x3ff79e56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x3ff79eda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x3ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x On node 0 totalpages: 262000 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257904 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bffe) Built 1 zonelists Initializing CPU#0 Kernel command line: BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 init=/linuxrc rw ide_setup: hdb=none ide_setup: hdc=cdrom ide_setup: hdd=none PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 3.579545 MHz PM timer. time.c: Detected 1801.073 MHz processor. time.c: Using PIT/TSC based timekeeping. Console: colour VGA+ 80x50 time.c: Lost 3 timer tick(s)! rip start_kernel+0xfd/0x1f0) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1023708k/1048000k available (3160k kernel code, 23596k reserved, 1340k data, 176k init) Calibrating delay using timer specific routine.. 3606.48 BogoMIPS (lpj=1803241) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) mtrr: v2.0 (20020519) CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a time.c: Lost 85 timer tick(s)! rip acpi_os_write_port+0x1a/0x38) Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. time.c: Lost 56 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120) testing NMI watchdog ... OK. checking if image is initramfs...it isn't (no cpio magic); looks like an initrd softlockup thread 0 started up. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI Interrupt Link
Re: 2.6.13-rc4-mm1
Hello Andrew, the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. The system boots now noiseless, except on problem with USB. If my Prolific USB-Serialadapter plugged in on reboot the ehci_hcd driver complains about a Hand-off bug in Bios. -> snip ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: debug port 1 ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) ehci_hcd :00:1d.7: continuing after BIOS bug... ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 -> snip I wonder about this because all other USB devices working without this message on boot. USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. When I rebooted without plugged Prolific Adapter and plug them in the same port the kernel prints this message. ->snip usb 4-1: new full speed USB device using uhci_hcd and address 2 pl2303 4-1:1.0: PL-2303 converter detected usb 4-1: PL-2303 converter now attached to ttyUSB0 -> snip Any Ideas what could be wrong here? Greets Best regards 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.13-rc4-mm1
On Sun, Jul 31, 2005 at 01:37:21PM +0100, James Courtier-Dutton wrote: > Adrian Bunk wrote: > >On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote: > > > > > >>>ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ > >> > >>Why was the KERNEL_VERSION(a,b,c) macro removed from > >>include/linux/version.h? The removal breaks external drivers like > > > > > >It moved to a different header file. > > > > > >>NDISWRAPPER or nVidia propietary. > > > > > >That's their problem. > > > >cu > >Adrian > > > > Where have they moved to? >... utsname.h cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc4-mm1
Adrian Bunk wrote: On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like It moved to a different header file. NDISWRAPPER or nVidia propietary. That's their problem. cu Adrian Where have they moved to? This will break ALSA as well. - 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.13-rc4-mm1
Felipe Alfaro Solana schrieb: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. - 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/ Hello Felipe, I could not regonize a breakage of NVidia (Version 1.0-7667) propietary drivers. They work just perfect. Greets 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.13-rc4-mm1
Hi, On Sunday, 31 of July 2005 11:05, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ > > > - Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who > need these can get them from 2.6.13-rc3-mm3. > > - Dropped the CKRM patches. I don't think they were doing much in -mm and > we didn't find many problems with them anyway. > > - Dropped the connector patches: turns out that we no longer have a netlink > slot available for them anyway. It looks like 2.6.13-rc4-mm1 is fine and dandy on two of AMD64 boxes I have access to. In particular, all of the problems that I've had recently with Asus L5D seem to be gone now. :-)) I only had a problem with this kernel on a NUMA-enabled dual-Opteron box, which hanged solid when I started to copy huge amounts of data from it over the network. If I'm able to reproduce it, I'll investigate it a bit more and let you know. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll "Alice's Adventures in Wonderland" - 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.13-rc4-mm1
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ > > Why was the KERNEL_VERSION(a,b,c) macro removed from > include/linux/version.h? The removal breaks external drivers like It moved to a different header file. > NDISWRAPPER or nVidia propietary. That's their problem. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc4-mm1
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. - 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.13-rc4-mm1
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. - 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.13-rc4-mm1
On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like It moved to a different header file. NDISWRAPPER or nVidia propietary. That's their problem. cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc4-mm1
Hi, On Sunday, 31 of July 2005 11:05, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ - Dropped areca-raid-linux-scsi-driver.patch and iteraid.patch. People who need these can get them from 2.6.13-rc3-mm3. - Dropped the CKRM patches. I don't think they were doing much in -mm and we didn't find many problems with them anyway. - Dropped the connector patches: turns out that we no longer have a netlink slot available for them anyway. It looks like 2.6.13-rc4-mm1 is fine and dandy on two of AMD64 boxes I have access to. In particular, all of the problems that I've had recently with Asus L5D seem to be gone now. :-)) I only had a problem with this kernel on a NUMA-enabled dual-Opteron box, which hanged solid when I started to copy huge amounts of data from it over the network. If I'm able to reproduce it, I'll investigate it a bit more and let you know. Greets, Rafael -- - Would you tell me, please, which way I ought to go from here? - That depends a good deal on where you want to get to. -- Lewis Carroll Alice's Adventures in Wonderland - 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.13-rc4-mm1
Adrian Bunk wrote: On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like It moved to a different header file. NDISWRAPPER or nVidia propietary. That's their problem. cu Adrian Where have they moved to? This will break ALSA as well. - 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.13-rc4-mm1
Felipe Alfaro Solana schrieb: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. - 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/ Hello Felipe, I could not regonize a breakage of NVidia (Version 1.0-7667) propietary drivers. They work just perfect. Greets 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.13-rc4-mm1
On Sun, Jul 31, 2005 at 01:37:21PM +0100, James Courtier-Dutton wrote: Adrian Bunk wrote: On Sun, Jul 31, 2005 at 12:04:59PM +0200, Felipe Alfaro Solana wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like It moved to a different header file. NDISWRAPPER or nVidia propietary. That's their problem. cu Adrian Where have they moved to? ... utsname.h cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed - 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.13-rc4-mm1
Hello Andrew, the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. The system boots now noiseless, except on problem with USB. If my Prolific USB-Serialadapter plugged in on reboot the ehci_hcd driver complains about a Hand-off bug in Bios. - snip ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: debug port 1 ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) ehci_hcd :00:1d.7: continuing after BIOS bug... ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 - snip I wonder about this because all other USB devices working without this message on boot. USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. When I rebooted without plugged Prolific Adapter and plug them in the same port the kernel prints this message. -snip usb 4-1: new full speed USB device using uhci_hcd and address 2 pl2303 4-1:1.0: PL-2303 converter detected usb 4-1: PL-2303 converter now attached to ttyUSB0 - snip Any Ideas what could be wrong here? Greets Best regards 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.13-rc4-mm1
Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Andrew, the good news is I can access pcmcia devices with rc4-mm1 which I couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least one more problem with yenta_socket. Please see the attached dmesg output and look for: Badness in __release_resource at kernel/resource.c:184 This happens when accessing pcmcia from an initrd to read keys from a pcmcia flash disk and removing the pcmcia modules afterwards. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] Bootdata ok (command line is BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 init=/linuxrc rw) Linux version 2.6.13-rc4-mm1-gringo ([EMAIL PROTECTED]) (gcc version 3.4.4) #1 PREEMPT Sun Jul 31 15:11:12 CEST 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 3ff7 (usable) BIOS-e820: 3ff7 - 3ff7a000 (ACPI data) BIOS-e820: 3ff7a000 - 3ff8 (ACPI NVS) BIOS-e820: 3ff8 - 4000 (reserved) BIOS-e820: fffe - 0001 (reserved) ACPI: RSDP (v000 PTLTD ) @ 0x000f6a60 ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x3ff73fde ACPI: FADT (v002 AMDK8 PTLTW0x0604 PTL_ 0x000f4240) @ 0x3ff79e56 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x3ff79eda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x3ff79fb0 ACPI: DSDT (v001 VIA PTL_ACPI 0x0604 MSFT 0x010e) @ 0x On node 0 totalpages: 262000 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 257904 pages, LIFO batch:31 HighMem zone: 0 pages, LIFO batch:1 ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee0 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 15:4 APIC version 16 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: IOAPIC (id[0x01] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 1, version 3, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 high edge) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. ACPI: IRQ9 used by override. Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at 4000 (gap: 4000:bffe) Built 1 zonelists Initializing CPU#0 Kernel command line: BOOT_IMAGE=2.6.13rc4mm hdb=none hdc=cdrom hdd=none elevator=cfq psmouse.rate=20 report_lost_ticks iommu=off root=/dev/ram0 init=/linuxrc rw ide_setup: hdb=none ide_setup: hdc=cdrom ide_setup: hdd=none PID hash table entries: 4096 (order: 12, 131072 bytes) time.c: Using 3.579545 MHz PM timer. time.c: Detected 1801.073 MHz processor. time.c: Using PIT/TSC based timekeeping. Console: colour VGA+ 80x50 time.c: Lost 3 timer tick(s)! rip start_kernel+0xfd/0x1f0) Dentry cache hash table entries: 262144 (order: 9, 2097152 bytes) Inode-cache hash table entries: 131072 (order: 8, 1048576 bytes) Memory: 1023708k/1048000k available (3160k kernel code, 23596k reserved, 1340k data, 176k init) Calibrating delay using timer specific routine.. 3606.48 BogoMIPS (lpj=1803241) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) mtrr: v2.0 (20020519) CPU: AMD Athlon(tm) 64 Processor 3000+ stepping 0a time.c: Lost 85 timer tick(s)! rip acpi_os_write_port+0x1a/0x38) Using local APIC timer interrupts. Detected 12.507 MHz APIC timer. time.c: Lost 56 timer tick(s)! rip setup_boot_APIC_clock+0x112/0x120) testing NMI watchdog ... OK. checking if image is initramfs...it isn't (no cpio magic); looks like an initrd softlockup thread 0 started up. NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Subsystem revision 20050408 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] segment is 0 Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 16 17 18 19 20 21 22 23) *10, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *11, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *11, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 12 14 15) *10 ACPI: PCI Interrupt Link
Re: 2.6.13-rc4-mm1
Why was the KERNEL_VERSION(a,b,c) macro removed from include/linux/version.h? The removal breaks external drivers like NDISWRAPPER or nVidia propietary. Hello Felipe, I could not regonize a breakage of NVidia (Version 1.0-7667) propietary drivers. They work just perfect. Indeed they do work perfectly, but I can't compile them (from the nVidia package) without adding back the KERNEL_VERSION macro in file include/linux/version.h. - 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.13-rc4-mm1
On Sun, 31 Jul 2005 02:05:52 -0700 Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ - Dropped the connector patches: turns out that we no longer have a netlink slot available for them anyway. I don't feel strongly pro or con about the connector patches, but DaveM suggested using a netlink multiplexer for iscsi (which also needs a netlink slot), so presumably that could work for the connector patches also...? --- ~Randy - 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.13-rc4-mm1
Andreas Steinmetz [EMAIL PROTECTED] wrote:
Andrew Morton wrote:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/
Andrew,
the good news is I can access pcmcia devices with rc4-mm1 which I
couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least
one more problem with yenta_socket. Please see the attached dmesg output
and look for:
Badness in __release_resource at kernel/resource.c:184
This happens when accessing pcmcia from an initrd to read keys from a
pcmcia flash disk and removing the pcmcia modules afterwards.
hm, OK. That's brought to us by the below -mm-only debugging patch. Maybe
we should add more stuff to it to idenfify the child resources?
From: [EMAIL PROTECTED] (Matthew Wilcox)
What does it mean to release a resource with children? Should the children
become children of the released resource's parent? Should they be released
too? Should we fail the release?
I bet we have no callers who expect this right now, but with
insert_resource() we may get some. At the point where someone hits this
BUG we can figure out what semantics we want.
Signed-off-by: Matthew Wilcox [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---
25-akpm/kernel/resource.c |2 ++
1 files changed, 2 insertions(+)
diff -puN kernel/resource.c~releasing-resources-with-children kernel/resource.c
--- 25/kernel/resource.c~releasing-resources-with-children 2005-04-02
00:21:52.0 -0800
+++ 25-akpm/kernel/resource.c 2005-04-02 00:22:22.0 -0800
@@ -181,6 +181,8 @@ static int __release_resource(struct res
{
struct resource *tmp, **p;
+ WARN_ON(old-child);
+
p = old-parent-child;
for (;;) {
tmp = *p;
_
-
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.13-rc4-mm1
(cc linux-usb-devel) Michael Thonke [EMAIL PROTECTED] wrote: Hello Andrew, the ACPI bug or the problems with 2.6.13-rc3-mm[2,3] gone. The system boots now noiseless, except on problem with USB. If my Prolific USB-Serialadapter plugged in on reboot the ehci_hcd driver complains about a Hand-off bug in Bios. - snip ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: debug port 1 ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) ehci_hcd :00:1d.7: continuing after BIOS bug... ehci_hcd :00:1d.7: new USB bus registered, assigned bus number 1 ehci_hcd :00:1d.7: irq 161, io mem 0xd2dffc00 - snip I wonder about this because all other USB devices working without this message on boot. USB Mouse,Keyboard and USB Storage and all mixed from USB 1.1 and 2. When I rebooted without plugged Prolific Adapter and plug them in the same port the kernel prints this message. -snip usb 4-1: new full speed USB device using uhci_hcd and address 2 pl2303 4-1:1.0: PL-2303 converter detected usb 4-1: PL-2303 converter now attached to ttyUSB0 - snip Any Ideas what could be wrong here? Nope. Can you identify the most recent kernel which didn't have these problems? - 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.13-rc4-mm1
Andrew Morton wrote: Andreas Steinmetz [EMAIL PROTECTED] wrote: Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc4/2.6.13-rc4-mm1/ Andrew, the good news is I can access pcmcia devices with rc4-mm1 which I couldn't with at least rc3-mm1 on my x86_64 laptop. There is at least one more problem with yenta_socket. Please see the attached dmesg output and look for: Badness in __release_resource at kernel/resource.c:184 This happens when accessing pcmcia from an initrd to read keys from a pcmcia flash disk and removing the pcmcia modules afterwards. hm, OK. That's brought to us by the below -mm-only debugging patch. Maybe we should add more stuff to it to idenfify the child resources? Well, could be. Unfortunately I have zero knowledge in this area of the kernel. Maybe Dominik can help? -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - 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-usb-devel] Re: 2.6.13-rc4-mm1
If my Prolific USB-Serialadapter plugged in on reboot the ehci_hcd driver complains about a Hand-off bug in Bios. - snip ehci_hcd :00:1d.7: EHCI Host Controller ehci_hcd :00:1d.7: debug port 1 ehci_hcd :00:1d.7: BIOS handoff failed (104, 01010001) ehci_hcd :00:1d.7: continuing after BIOS bug... This is a warning, not an error, but it's one of two symptoms of BIOS level problems on your board. - Try booting with the usb-handoff kernel parameter, to kick in more specialized PCI quirk handling. - See if there's a BIOS setting related to USB that you can change. Sometimes they use quirky modes. - See if there's a BIOS update for your motherboard. I think that continuing codepath came from someone at Phoenix, FWIW; the problem is that I see the PCI quirks code has evolved even farther from the main copy of the init code in the USB tree. Sigh. When I rebooted without plugged Prolific Adapter and plug them in the same port the kernel prints this message. -snip usb 4-1: new full speed USB device using uhci_hcd and address 2 pl2303 4-1:1.0: PL-2303 converter detected usb 4-1: PL-2303 converter now attached to ttyUSB0 Any Ideas what could be wrong here? That is, you think it should always see the adapter, not just when it's not plugged in at boot time? Sure sounds like BIOS problems to me. - Dave - 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-usb-devel] Re: 2.6.13-rc4-mm1
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote: I think that continuing codepath came from someone at Phoenix, FWIW; the problem is that I see the PCI quirks code has evolved even farther from the main copy of the init code in the USB tree. Sigh. I don't like that either, but can't think of a way to make it easier to keep them in sync. Can you? thanks, greg k-h - 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.13-rc4-mm1
Hi all: Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems is the boot hang: my test is different combinations the acpi=off , noacpi, pci=noirq, etc.etc both have is the same error not boot. The only information is simple: .. Uncompressiong Linux... Ok. booting the kernel. _ Not more information. anex dmesg the kernel 2.6.12-ck3. Linux version 2.6.12-ck3 ([EMAIL PROTECTED] (gcc version 4.0.1 20050720 (Red Hat 4.0.1-4)) #1 Mon Jul 25 00:14:40 CDT 2005 BIOS-provided physical RAM map: BIOS-e820: - 0009f800 (usable) BIOS-e820: 0009f800 - 000a (reserved) BIOS-e820: 000d8000 - 0010 (reserved) BIOS-e820: 0010 - 4fef (usable) BIOS-e820: 4fef - 4fefb000 (ACPI data) BIOS-e820: 4fefb000 - 4ff0 (ACPI NVS) BIOS-e820: 4ff0 - 5000 (reserved) BIOS-e820: fffe - 0001 (reserved) 382MB HIGHMEM available. 896MB LOWMEM available. On node 0 totalpages: 327408 DMA zone: 4096 pages, LIFO batch:1 Normal zone: 225280 pages, LIFO batch:31 HighMem zone: 98032 pages, LIFO batch:31 DMI 2.3 present. ACPI: RSDP (v000 PTLTD ) @ 0x000f8410 ACPI: RSDT (v001 Arima 161Fh0x0604 LTP 0x) @ 0x4fef6b5d ACPI: FADT (v001 Arima 161Fh0x0604 PTL_ 0x000f4240) @ 0x4fefae66 ACPI: SSDT (v001 PTLTD POWERNOW 0x0604 LTP 0x0001) @ 0x4fefaeda ACPI: MADT (v001 PTLTD APIC 0x0604 LTP 0x) @ 0x4fefafb0 ACPI: DSDT (v001 Arima 161Fh0x0604 MSFT 0x010e) @ 0x ACPI: PM-Timer IO Port: 0x4008 Allocating PCI resources starting at 5000 (gap: 5000:affe) Built 1 zonelists Kernel command line: ro root=LABEL=/ early-login quiet vga=788 Initializing CPU#0 CPU 0 irqstacks, hard=c047 soft=c046f000 PID hash table entries: 4096 (order: 12, 65536 bytes) Detected 1804.747 MHz processor. Using pmtmr for high-res timesource Console: colour dummy device 80x25 Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) Memory: 1292408k/1309632k available (2620k kernel code, 16076k reserved, 680k data, 188k init, 392128k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay loop... 3571.71 BogoMIPS (lpj=1785856) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 512 CPU: After generic identify, caps: 078bfbff e1d3fbff CPU: After vendor identify, caps: 078bfbff e1d3fbff CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 1024K (64 bytes/line) CPU: After all inits, caps: 078bfbff e1d3fbff 0010 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. CPU: AMD Mobile AMD Athlon(tm) 64 Processor 3000+ stepping 08 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK. ACPI: setting ELCR to 0400 (from 0e00) checking if image is initramfs... it is Freeing initrd memory: 1086k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfd8cc, last bus=1 PCI: Using configuration type 1 mtrr: v2.0 (20020519) ACPI: Subsystem revision 20050309 ACPI: Interpreter enabled ACPI: Using PIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (:00) PCI: Probing PCI hardware (bus 00) Boot video device is :01:00.0 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [ALKA] (IRQs 16 17 18 19 20 21 22 23) *9, disabled. ACPI: PCI Interrupt Link [ALKB] (IRQs 23) *11, disabled. ACPI: PCI Interrupt Link [ALKC] (IRQs 22) *10, disabled. ACPI: PCI Interrupt Link [ALKD] (IRQs 21) *10, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 *9 12 14 15) ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 *11 12 14 15) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 11 12 14 15) *10 ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 *10 11 12 14 15) ACPI: Embedded Controller [EC] (gpe 1) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 8 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try pci=routeirq. If it helps, post a report pnp: 00:05: ioport range 0x4d0-0x4d1 has been reserved pnp: 00:05: ioport range 0xf510-0xf511 could not be reserved pnp: 00:05: ioport range 0xf500-0xf500 has been reserved pnp: 00:05: ioport range 0x4000-0x407f could not be reserved pnp: 00:05: ioport range 0x8100-0x811f has been reserved apm: BIOS
Re: 2.6.13-rc4-mm1
Jesus Delgado [EMAIL PROTECTED] wrote: Im try test with kernels 2.6.13-rc4 and 2.6.13-rc4-mm1, the problems is the boot hang: my test is different combinations the acpi=off , noacpi, pci=noirq, etc.etc both have is the same error not boot. The only information is simple: .. Uncompressiong Linux... Ok. booting the kernel. _ Not more information. You should check basic .config things such as the CPU type. Also ensure that you have `earlyprintk=vga' on the kernel boot command line. The only thing I can think of which would cause such an early failure is the kexec changes. Does 2.6.13-rc1 work OK? It had kexec. If 2.6.13-rc1 fails then please try these patches, against 2.6.12: ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.12-git7.gz ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/patch-2.6.12-git8.gz If 2.6.12-git7 works and 2.6.12-git8 fails then we'll know where to start looking, thanks. - 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-usb-devel] Re: 2.6.13-rc4-mm1
Date: Sun, 31 Jul 2005 16:02:44 -0700
From: Greg KH [EMAIL PROTECTED]
On Sun, Jul 31, 2005 at 11:25:10AM -0700, [EMAIL PROTECTED] wrote:
I think that continuing codepath came from someone at Phoenix, FWIW;
the problem is that I see the PCI quirks code has evolved even farther
from the main copy of the init code in the USB tree. Sigh.
I don't like that either, but can't think of a way to make it easier to
keep them in sync. Can you?
Sure. The problem as I see it is that there are two copies, and one
of them isn't in the USB part of the tree. So just move it, and cope
with the consequences during the 2.6.14 cycle:
(a) Move the USB quirks out of the generic PCI drivers directory
into the USB HCD directory (see the attached patch);
(b) foreach HCD in (ehci ohci uhci) do:
(1) Merge the two different routines: HCD internal init/reset
and the PCI quirk code are identical in intent, but they
each address different sets of quirks.
(2) Then the HCD reset() and PCI quirk() code will call those
single shared routine.
At OLS, Vojtech mentioned wanting to make usb-handoff be the default.
That's seem plausible (USB has more than its fair share of BIOS issues!)
but should only kick in sometime after we merge the two different sets
of quirk handling logic.
- Dave
This moves the PCI quirk handling for USB host controllers from the
PCI directory to the USB directory.
Follow-on patches will need to remove code duplication, and probably
make usb-handoff be the system default.
Compile-tested only so far.
Signed-off-by: David Brownell [EMAIL PROTECTED]
--- g26.orig/drivers/usb/host/Makefile 2005-06-28 19:23:13.0 -0700
+++ g26/drivers/usb/host/Makefile 2005-07-31 18:41:35.0 -0700
@@ -1,8 +1,9 @@
#
-# Makefile for USB Host Controller Driver
-# framework and drivers
+# Makefile for USB Host Controller Drivers
#
+obj-$(CONFIG_PCI) += pci-quirks.o
+
obj-$(CONFIG_USB_EHCI_HCD) += ehci-hcd.o
obj-$(CONFIG_USB_ISP116X_HCD) += isp116x-hcd.o
obj-$(CONFIG_USB_OHCI_HCD) += ohci-hcd.o
--- /dev/null 1970-01-01 00:00:00.0 +
+++ g26/drivers/usb/host/pci-quirks.c 2005-07-31 17:33:38.0 -0700
@@ -0,0 +1,279 @@
+/*
+ * This file contains work-arounds for many known PCI hardware and BIOS
+ * quirks relating to USB host controllers.
+ *
+ * There are a lot of those, especially on hardware that needs to work
+ * with USB mice and keyboard for booting. And this code needs to fire
+ * early; before the input subsystem gets initialized, and while BIOS
+ * (or SMI) code has few problems running.
+ *
+ * They're collected here since USB host controller drivers need to use
+ * the same code as part of hardware initialization.
+ *
+ * Copyright (c) 1999 Martin Mares [EMAIL PROTECTED]
+ * (and others)
+ */
+
+#include linux/config.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/pci.h
+#include linux/init.h
+#include linux/delay.h
+#include linux/acpi.h
+
+// #include pci.h
+
+/*
+ * PIIX3 USB: We have to disable USB interrupts that are
+ * hardwired to PIRQD# and may be shared with an
+ * external device.
+ *
+ * Legacy Support Register (LEGSUP):
+ * bit13: USB PIRQ Enable (USBPIRQDEN),
+ * bit4: Trap/SMI On IRQ Enable (USBSMIEN).
+ *
+ * We mask out all r/wc bits, too.
+ */
+static void __devinit quirk_piix3_usb(struct pci_dev *dev)
+{
+ u16 legsup;
+
+ pci_read_config_word(dev, 0xc0, legsup);
+ legsup = 0x50ef;
+ pci_write_config_word(dev, 0xc0, legsup);
+}
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371SB_2,
quirk_piix3_usb );
+DECLARE_PCI_FIXUP_HEADER(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_82371AB_2,
quirk_piix3_usb );
+
+
+/* FIXME this should be the same code that the USB controllers use...
+ * the hcd-reset() method basically does this.
+ */
+
+#define UHCI_USBLEGSUP 0xc0/* legacy support */
+#define UHCI_USBCMD0 /* command register */
+#define UHCI_USBSTS2 /* status register */
+#define UHCI_USBINTR 4 /* interrupt register */
+#define UHCI_USBLEGSUP_DEFAULT 0x2000 /* only PIRQ enable set */
+#define UHCI_USBCMD_RUN(1 0)/* RUN/STOP bit */
+#define UHCI_USBCMD_GRESET (1 2)/* Global reset */
+#define UHCI_USBCMD_CONFIGURE (1 6)/* config semaphore */
+#define UHCI_USBSTS_HALTED (1 5)/* HCHalted bit */
+
+#define OHCI_CONTROL 0x04
+#define OHCI_CMDSTATUS 0x08
+#define OHCI_INTRSTATUS0x0c
+#define OHCI_INTRENABLE0x10
+#define OHCI_INTRDISABLE 0x14
+#define OHCI_OCR (1 3)/* ownership change request */
+#define OHCI_CTRL_IR (1 8)/* interrupt routing */
+#define OHCI_INTR_OC (1 30) /* ownership change */
+
+#define EHCI_HCC_PARAMS
