On Sun, Apr 10, 2005 at 11:51:24PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
> Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> >
> > On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
> > > I based my listen program on the fclisten.c posted by Kaigai Kohei
> > > with
Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
>
> On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
> > I based my listen program on the fclisten.c posted by Kaigai Kohei
> > with my own modification. Unfortunately i lost my test machine in the
> > lab. I will recreate the
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
> I based my listen program on the fclisten.c posted by Kaigai Kohei
> with my own modification. Unfortunately i lost my test machine in the
> lab. I will recreate the listen program Monday. The original listener
> did
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen program Monday. The original listener
did not
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen
On Sun, Apr 10, 2005 at 11:51:24PM -0700, Andrew Morton ([EMAIL PROTECTED])
wrote:
Evgeniy Polyakov [EMAIL PROTECTED] wrote:
On Sun, Apr 10, 2005 at 10:43:24PM -0700, Jay Lan ([EMAIL PROTECTED]) wrote:
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen program Monday. The original listener
did not validate sequence number. It also prints length of data and
sequence number of
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen program Monday. The original listener
did not validate sequence number. It also prints length of data and
sequence number of
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
> With the patch you provide to me, i did not see the bugcheck
> at cn_queue_wrapper() at the console.
>
> Unmatched sequence number messages still happened. We expect
> to lose packets under system stressed situation, but i
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan [EMAIL PROTECTED] wrote:
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
e:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Po
bre/archive/connector
> - jay
>
> Jay Lan wrote:
> > My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
> >
> > Your patch caused 5 out of 8 hunks failure at connector.c
> > and one failure at connector.h.
> >
> > Could you generate
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will
On Thu, 2005-04-07 at 15:47 -0700, Jay Lan wrote:
> BTW, when it happened last time, my program listening to the socket
> complained about duplicate messages received.
>
> Unmatched seq. Rcvd=1824062, expected=1824061 <===
> Unmatched seq. Rcvd=1824062, expected=1824063 <===
>
On Thu, 2005-04-07 at 15:47 -0700, Jay Lan wrote:
BTW, when it happened last time, my program listening to the socket
complained about duplicate messages received.
Unmatched seq. Rcvd=1824062, expected=1824061 ===
Unmatched seq. Rcvd=1824062, expected=1824063 ===
Unmatched
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask,
I will send updated sources with Andrew's comments resolved too.
I do not know exactly your connector version,
so patch will
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would
Lan [EMAIL PROTECTED] wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1
BTW, when it happened last time, my program listening to the socket
complained about duplicate messages received.
Unmatched seq. Rcvd=1824062, expected=1824061 <===
Unmatched seq. Rcvd=1824062, expected=1824063 <===
Unmatched seq. Rcvd=1824348, expected=1824307
When my program
Hi Evgeniy,
Should i be concerned about this bugcheck?
I have seen this happening a number of times, all with the same signature
in my testing. I ran a mix of AIM7, ubench, fork-test (continuously
fork new
processes), and another program reading from the fork connector socket.
Thanks,
- jay
Hi Evgeniy,
Should i be concerned about this bugcheck?
I have seen this happening a number of times, all with the same signature
in my testing. I ran a mix of AIM7, ubench, fork-test (continuously
fork new
processes), and another program reading from the fork connector socket.
Thanks,
- jay
BTW, when it happened last time, my program listening to the socket
complained about duplicate messages received.
Unmatched seq. Rcvd=1824062, expected=1824061 ===
Unmatched seq. Rcvd=1824062, expected=1824063 ===
Unmatched seq. Rcvd=1824348, expected=1824307
When my program received
Bartlomiej Zolnierkiewicz a écrit :
On Apr 3, 2005 11:56 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
Mathieu Bérard <[EMAIL PROTECTED]> wrote:
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related w
On Fri, Apr 01, 2005 at 12:37:27PM -0500, Jason Davis wrote:
> Hello,
>
> x86_64 genapic mechanism should be aware of machines that use physical APIC
> mode regardless of how many clusters/processors are detected. ACPI 3.0 FADT
> makes this determination very simple by providing a feature flag
On Sunday 03 April 2005 01:38, Jesper Juhl wrote:
> On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
>
> > Hi,
> >
> > out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
> > I found one:
> >
> > # grep -nr "memset.*\,\(\ \|\)0\(\
Hi,
On Tuesday, 5 of April 2005 17:01, Romano Giannetti wrote:
> >
> > Same way to debug it, then try minimal drivers.
>
> Yes, the lifer of a kernel debugger is hard...
>
> Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be
> possible to add a printk when invoking
>
> Same way to debug it, then try minimal drivers.
Yes, the lifer of a kernel debugger is hard...
Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be
possible to add a printk when invoking and returning from suspend/resume
methods of drivers, telling if they are
Hi!
> Same issue here.
>
> Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in
> mm2,3 and mm4 it is broken.
>
> It suspends properly but does not resume. Just a blackscreen and no
> reaction on keypress/usb plug-in/network/power button.
>
Same way to debug it, then try
On Die, 05 Apr 2005, Pavel Machek wrote:
> > It's b44. It *was* working with b44 insmod-ed and up and running, but
> > now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes.
> > If I do a ifdown eth0 before suspending, it works.
>
> Does this one hel
compiled it into 2.6.12-rc2-mm1, and first wanted to try it with
module removed etc, but 2.6.12-rc2-mm1 not even freezes after resuming,
but immediately reboots!
So, more to track down. I will recreate my 2.6.12-rc1-mm4 tree, and try
your fix. Then I will try to find out *why* the hell 2.6.12
On Apr 3, 2005 11:56 PM, Andrew Morton <[EMAIL PROTECTED]> wrote:
> Mathieu Bérard <[EMAIL PROTECTED]> wrote:
> >
> > Hi,
> > I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
> > (Everyting run smoothly using 2.6.11-mm1)
> > It
On Fri, Apr 01, 2005 at 12:37:27PM -0500, Jason Davis wrote:
Hello,
x86_64 genapic mechanism should be aware of machines that use physical APIC
mode regardless of how many clusters/processors are detected. ACPI 3.0 FADT
makes this determination very simple by providing a feature flag
Bartlomiej Zolnierkiewicz a écrit :
On Apr 3, 2005 11:56 PM, Andrew Morton [EMAIL PROTECTED] wrote:
Mathieu Bérard [EMAIL PROTECTED] wrote:
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related with mounting
On Apr 3, 2005 11:56 PM, Andrew Morton [EMAIL PROTECTED] wrote:
Mathieu Bérard [EMAIL PROTECTED] wrote:
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related with mounting a reiserfs3 filesystem
, and first wanted to try it with
module removed etc, but 2.6.12-rc2-mm1 not even freezes after resuming,
but immediately reboots!
So, more to track down. I will recreate my 2.6.12-rc1-mm4 tree, and try
your fix. Then I will try to find out *why* the hell 2.6.12-rc2-mm1 is
not resuming at all. Any
On Die, 05 Apr 2005, Pavel Machek wrote:
It's b44. It *was* working with b44 insmod-ed and up and running, but
now as soon as b44-eth0 is ifup-ed while suspending, the resume freezes.
If I do a ifdown eth0 before suspending, it works.
Does this one help?
With 2.6.12-rc1-mm4 it did help
Hi!
Same issue here.
Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in
mm2,3 and mm4 it is broken.
It suspends properly but does not resume. Just a blackscreen and no
reaction on keypress/usb plug-in/network/power button.
Same way to debug it, then try minimal
Same way to debug it, then try minimal drivers.
Yes, the lifer of a kernel debugger is hard...
Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be
possible to add a printk when invoking and returning from suspend/resume
methods of drivers, telling if they are
Hi,
On Tuesday, 5 of April 2005 17:01, Romano Giannetti wrote:
Same way to debug it, then try minimal drivers.
Yes, the lifer of a kernel debugger is hard...
Pavel, one question (maybe stupid, I am not at all an expert). Wouldn't be
possible to add a printk when invoking and
On Sunday 03 April 2005 01:38, Jesper Juhl wrote:
On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
Hi,
out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
I found one:
# grep -nr memset.*\,\(\ \|\)0\(\ \|\)); *
net/ieee80211/ieee80211_tx.c:226: memset(txb
Hello Andrew,
I received a comment from Mita-san.
On Tue, 5 Apr 2005 00:45:24 +0900
Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
> This patch updates NEC VR4100 series CPU-PCI bridge support.
> This patch already had applied to Ralf's cvs.
>
> + if (request_mem_region(PCIU_BASE, PCIU_SIZE,
This release also fixes a small bug in the coalescing code, which could
> of mistakenly dropped a move event. We now verify that the cookies
> match before coalescing.
And a patch for 2.6.12-rc1-mm4.
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, p
On Mon, 2005-04-04 at 19:40 +0200, Ingo Molnar wrote:
> * Peter Zijlstra <[EMAIL PROTECTED]> wrote:
>
> > Hi Ingo,
> >
> > I need the following two patches to keep my system alive and avoid
> > the BUGs in the log send to you earlier (private mail).
>
> hm, the second patch does not apply (and
pcmcia_core 8250_pci 8250 serial_core
snd_ali5451 snd_ac97_codec snd_pcm snd_timer snd soundcore
snd_page_alloc ext3 jbd mbcache
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010202 (2.6.12-rc1-mm4)
EIP is at sysfs_create_link+0x5f/0x69
eax: e8babf01 ebx: c710cbb4 ecx: edx: c8322600
* Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> Hi Ingo,
>
> I need the following two patches to keep my system alive and avoid
> the BUGs in the log send to you earlier (private mail).
hm, the second patch does not apply (and the merge didnt look trivial) -
maybe it depends on some patch in
This patch updates NEC VR4100 series CPU-PCI bridge support.
This patch already had applied to Ralf's cvs.
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c
rc1-mm4/arch/mips/pci/ops-vr41xx.c
---
db_console_write (co=0xc03c8000, s=0x603d1c "k", count=6307100) at
arch/i386/kernel/kgdb_stub.c:2230
2230kgdb_gdb_message(s, count);
(gdb) s
kgdb_gdb_message (
s=0xc04e07c3 "[4294667.296000] Linux version 2.6.12-rc1-mm4 ([EMAIL
PROTECTED])
(gcc version 3.3.5 (Debian
Hi Pavel!
On Mon, 04 Apr 2005, Pavel Machek wrote:
> I'd like to fix the problem, but first I need to know where the
> problem is. If it works with minimal config, I know that it is one of
> drivers you deselected.
It's b44. It *was* working with b44 insmod-ed and up and running, but
now as
Hi Pavel!
On Mon, 04 Apr 2005, Pavel Machek wrote:
I'd like to fix the problem, but first I need to know where the
problem is. If it works with minimal config, I know that it is one of
drivers you deselected.
It's b44. It *was* working with b44 insmod-ed and up and running, but
now as soon
k, count=6307100) at
arch/i386/kernel/kgdb_stub.c:2230
2230kgdb_gdb_message(s, count);
(gdb) s
kgdb_gdb_message (
s=0xc04e07c3 [4294667.296000] Linux version 2.6.12-rc1-mm4 ([EMAIL
PROTECTED])
(gcc version 3.3.5 (Debian 1:3.3.5-12)) #1 SMP PREEMPT Mon Apr 4 12:07:40
CEST 2005\n6
This patch updates NEC VR4100 series CPU-PCI bridge support.
This patch already had applied to Ralf's cvs.
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/pci/ops-vr41xx.c
rc1-mm4/arch/mips/pci/ops-vr41xx.c
---
* Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
hm, the second patch does not apply (and the merge didnt look trivial) -
maybe it depends on some patch in -mm that
On Mon, 2005-04-04 at 19:40 +0200, Ingo Molnar wrote:
* Peter Zijlstra [EMAIL PROTECTED] wrote:
Hi Ingo,
I need the following two patches to keep my system alive and avoid
the BUGs in the log send to you earlier (private mail).
hm, the second patch does not apply (and the merge
in the coalescing code, which could
of mistakenly dropped a move event. We now verify that the cookies
match before coalescing.
And a patch for 2.6.12-rc1-mm4.
Robert Love
inotify!
inotify is intended to correct the deficiencies of dnotify, particularly
its inability to scale and its terrible user
Hello Andrew,
I received a comment from Mita-san.
On Tue, 5 Apr 2005 00:45:24 +0900
Yoichi Yuasa [EMAIL PROTECTED] wrote:
This patch updates NEC VR4100 series CPU-PCI bridge support.
This patch already had applied to Ralf's cvs.
snip
+ if (request_mem_region(PCIU_BASE, PCIU_SIZE,
Andrew Morton a écrit :
It appears that we might have jumped from flagged_taskfile into something
at 0xdf6d1211, which is rather odd.
You have two different low-level IDE drivers configured. Which one is
driving that filesystem? VIA or Promise?
hdg is connected to my Promise PDC20268 (Ultra100
Hi!
> it is only suspend2ram which stopped working after 2.6.11-mm4 (at least
> in 2.6.12-rc1-mm3,4).
>
> Concerning tests with minimal kernel config: I guess since it *was*
> working there should not be a change necessary -- but well, from
> 2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to
On Fre, 01 Apr 2005, Pavel Machek wrote:
> > I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
> > working. Nothing in the log files. Is there anything which may cause
> > these troubles when compiled into the kernel and not loaded as module?
> > (as it was with my usb stuff
Mathieu Bérard <[EMAIL PROTECTED]> wrote:
>
> Hi,
> I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
> (Everyting run smoothly using 2.6.11-mm1)
> It seems to be related with mounting a reiserfs3 filesystem.
It looks more like an IDE bug.
> ReiserFS: hd
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related with mounting a reiserfs3 filesystem.
Please also note that this kernel was compiled using gcc-4.0-0pre9
(from Debian)
I'm using mount 2.12p
Please CC: me.
Here
This patch had removed obsolete VR41xx RTC function from vr41xx.h .
I forgot to put this change in "update VR41xx RTC support".
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h
rc1-mm4/include/asm-mips/vr41xx/vr41xx.h
This patch had removed obsolete VR41xx RTC function from vr41xx.h .
I forgot to put this change in update VR41xx RTC support.
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/include/asm-mips/vr41xx/vr41xx.h
rc1-mm4/include/asm-mips/vr41xx/vr41xx.h
---
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related with mounting a reiserfs3 filesystem.
Please also note that this kernel was compiled using gcc-4.0-0pre9
(from Debian)
I'm using mount 2.12p
Please CC: me.
Here
Mathieu Bérard [EMAIL PROTECTED] wrote:
Hi,
I get a 100% reproductible oops while booting linux 2.6.12-rc1-mm4.
(Everyting run smoothly using 2.6.11-mm1)
It seems to be related with mounting a reiserfs3 filesystem.
It looks more like an IDE bug.
ReiserFS: hdg1: checking transaction log
On Fre, 01 Apr 2005, Pavel Machek wrote:
I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
working. Nothing in the log files. Is there anything which may cause
these troubles when compiled into the kernel and not loaded as module?
(as it was with my usb stuff until
Hi!
it is only suspend2ram which stopped working after 2.6.11-mm4 (at least
in 2.6.12-rc1-mm3,4).
Concerning tests with minimal kernel config: I guess since it *was*
working there should not be a change necessary -- but well, from
2.6.11-mm2 to 2.6.11-mm4 I had to stop hotplug/usb to get
Andrew Morton a écrit :
It appears that we might have jumped from flagged_taskfile into something
at 0xdf6d1211, which is rather odd.
You have two different low-level IDE drivers configured. Which one is
driving that filesystem? VIA or Promise?
hdg is connected to my Promise PDC20268 (Ultra100
rd results.
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c~ 2005-03-25 10:14:32.0 +0100
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-02 18:58:19.0 +0200
@@ -376,8 +376,8 @@
static v
On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
> Hi,
>
> out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
> I found one:
>
> # grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" *
> net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
> i
Hi,
out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
I found one:
# grep -nr "memset.*\,\(\ \|\)0\(\ \|\));" *
net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
ieee80211_txb), 0);
I found none in Linus' bk.
Regards,
Maciej
-
To unsubs
(2.6.12-rc1-mm4)
EIP is at sysfs_create_link+0x60/0x70
eax: d5fdba01 ebx: d78182ac ecx: edx: d5b8b201
esi: edi: d5b8b274 ebp: d65003e0 esp: d7e9adb8
ds: 007b es: 007b ss: 0068
Process khubd (pid: 23, threadinfo=d7e9a000 task=d7e99a50)
Stack: d5b8b214 d5b8b274
: 00010202 (2.6.12-rc1-mm4)
EIP is at sysfs_create_link+0x60/0x70
eax: d5fdba01 ebx: d78182ac ecx: edx: d5b8b201
esi: edi: d5b8b274 ebp: d65003e0 esp: d7e9adb8
ds: 007b es: 007b ss: 0068
Process khubd (pid: 23, threadinfo=d7e9a000 task=d7e99a50)
Stack: d5b8b214
Hi,
out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
I found one:
# grep -nr memset.*\,\(\ \|\)0\(\ \|\)); *
net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
ieee80211_txb), 0);
I found none in Linus' bk.
Regards,
Maciej
-
To unsubscribe from
On Sat, 2 Apr 2005, Maciej Soltysiak wrote:
Hi,
out of boredom I grepped 2.6.12-rc1-mm4 for swapped memset arguments.
I found one:
# grep -nr memset.*\,\(\ \|\)0\(\ \|\)); *
net/ieee80211/ieee80211_tx.c:226: memset(txb, sizeof(struct
ieee80211_txb), 0);
And here's a patch
.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
--- /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c~ 2005-03-25 10:14:32.0 +0100
+++ /usr/src/linux-2.6.12-rc1-mm4-RT-V0.7.42-08/net/ipv4/icmp.c 2005-04-02 18:58:19.0 +0200
@@ -376,8 +376,8 @@
static void icmp_reply(struct
This patch had fixed the following warning about audit_arch().
ptrace.o
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype
Yoichi
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/kernel/ptrace.c
Same issue here.
Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in
mm2,3 and mm4 it is broken.
It suspends properly but does not resume. Just a blackscreen and no
reaction on keypress/usb plug-in/network/power button.
regards,
Stefan
-
To unsubscribe from this list: send the
AIL PROTECTED]>
diff -Naurp linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c
linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c
--- linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c 2005-03-02
02:38:25.0 -0500
+++ linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c 2
Hi!
> Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was
> with 2.6.11-mm4 with the same .config.
>
> I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
> working. Nothing in the log files. Is there anything which may cause
> these troubles when compiled
This patch applies to 2.6.12-rc1-mm4
Many thanks to Andrew for the great help,
Best regards,
Guillaume
Signed-off-by: Guillaume Thouvenin <[EMAIL PROTECTED]>
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c
This patch applies to 2.6.12-rc1-mm4
Many thanks to Andrew for the great help,
Best regards,
Guillaume
Signed-off-by: Guillaume Thouvenin [EMAIL PROTECTED]
---
drivers/connector/Kconfig | 11
drivers/connector/Makefile |1
drivers/connector/cn_fork.c | 113
Hi!
Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was
with 2.6.11-mm4 with the same .config.
I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
working. Nothing in the log files. Is there anything which may cause
these troubles when compiled into
]
diff -Naurp linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c
linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c
--- linux-2.6.12-rc1-mm4/arch/i386/kernel/acpi/boot.c 2005-03-02
02:38:25.0 -0500
+++ linux-2.6.12-rc1-mm4-genapic/arch/i386/kernel/acpi/boot.c 2005-03-31
18:15
Same issue here.
Suspend-to-ram works perfectly fine with kernel 2.6.12-rc1-mm1, in
mm2,3 and mm4 it is broken.
It suspends properly but does not resume. Just a blackscreen and no
reaction on keypress/usb plug-in/network/power button.
regards,
Stefan
-
To unsubscribe from this list: send the
This patch had fixed the following warning about audit_arch().
ptrace.o
arch/mips/kernel/ptrace.c:305: warning: function declaration isn't a prototype
Yoichi
Signed-off-by: Yoichi Yuasa [EMAIL PROTECTED]
diff -urN -X dontdiff rc1-mm4-orig/arch/mips/kernel/ptrace.c
On Thu, 2005-03-31 at 16:10 -0800, Jay Lan wrote:
> Andrew Morton wrote:
>
> >Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
> >
> >
> >> This patch adds a fork connector in the do_fork() routine.
> >>...
> >>
> >> The fork connector is used by the Enhanced Linux System Accounting
> >>project
Andrew Morton wrote:
> bk-audit.patch
This seems to have broken compile for uml:
CC arch/um/kernel/ptrace.o
arch/um/kernel/ptrace.c:345:74: macro "audit_syscall_entry" requires 7
arguments, but only 6 given
arch/um/kernel/ptrace.c: In function `syscall_trace':
Andrew Morton wrote:
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
This patch adds a fork connector in the do_fork() routine.
...
The fork connector is used by the Enhanced Linux System Accounting
project http://elsa.sourceforge.net
Does it also meet all the in-kernel requirements for
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> This patch adds a fork connector in the do_fork() routine.
>
> +config FORK_CONNECTOR
> + bool "Enable fork connector"
> + depends on CONNECTOR=y
This kind of defeats connector's ability to be built as a module. Doing
Guillaume Thouvenin <[EMAIL PROTECTED]> wrote:
>
> This patch adds a fork connector in the do_fork() routine.
> ...
>
> The fork connector is used by the Enhanced Linux System Accounting
> project http://elsa.sourceforge.net
Does it also meet all the in-kernel requirements for other
Dear Andrew, dear developers!
Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was
with 2.6.11-mm4 with the same .config.
I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
working. Nothing in the log files. Is there anything which may cause
these troubles
g of the message) is
around 2%. If we use the CBUS patch http://lkml.org/lkml/2005/3/20/14
instead of cn_netlink_send() routine we can reduce this overhead near to
0%. We're waiting for the inclusion of the CBUS in the -mm tree.
This patch applies to 2.6.12-rc1-mm4.
Signed-off-by: Guillaume T
Andrew Morton wrote:
...
make-sysrq-f-call-oom_kill.patch
make sysrq-F call oom_kill()
Glad to see it fixed. :)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Andrew Morton wrote:
...
make-sysrq-f-call-oom_kill.patch
make sysrq-F call oom_kill()
Glad to see it fixed. :)
-
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
) is
around 2%. If we use the CBUS patch http://lkml.org/lkml/2005/3/20/14
instead of cn_netlink_send() routine we can reduce this overhead near to
0%. We're waiting for the inclusion of the CBUS in the -mm tree.
This patch applies to 2.6.12-rc1-mm4.
Signed-off-by: Guillaume Thouvenin [EMAIL
Dear Andrew, dear developers!
Since 2.6.12-rc1-mmX I cannot get suspend2ram working again as it was
with 2.6.11-mm4 with the same .config.
I suspends fine, but never resumes. No CapsLock, no sysrq, no network is
working. Nothing in the log files. Is there anything which may cause
these troubles
1 - 100 of 105 matches
Mail list logo
