This may count as one of the biggest -rc releases ever. It's humongous.

Usually the compressed -rc1 diffs are in the 3-5MB range, with occasional

smaller ones, and the occasional ones that top 6M, but this one is

*eleven* megs.
I'd blame the x86 renames (and the watchdog ones), but the thing is, it's

absolutely huge even when I generate the diff with git turning all those

renames into relatively small rename diffs (which I don't do for the

public diffs, since I expect that git people use git to get the changes,

and non-git people won't have tools that understand a diff that involves

renames).
In short, we just had an unusually large amount of not just x86 merges,

but also tons of new drivers (wireless networking stands out, but is by no

means the only thing - we've got dvb, regular wired network, mmc etc all

joining in), and a fair amount or architecture stuff, filesystems,

networking etc too.
So there's just lots of new stuff. The diffstat is ten thousand lines

long, and weighing in at comfortably over half a megabyte it is way over

the limits of this - or any sane - mailing list. The shortlog is barely

shorter, weighing in at "just" 8461 lines and almost 400k. The full

changelog (which I'm still producing for y'all, since people told me they

actually care last time I asked) is 4 megs.
In other words, I don't even know where to start. The big noticeable thing

is the x86 merge, and I think we all fervently hope that it won't cause

any issues. So far it's been pretty smooth sailing. Knock wood.
Less smooth has the scatter-gather changes to the block layer been, but

they are hopefully all in reasonable shape by now too. And the VM changes?

I honestly hope nobody even notices. Same goes for some of the VFS layer

changes that affected basically every filesystem (although in mostly very

straightforward ways).
Just for fun, I'd really encourage git users to just try the
	git shortlog v2.6.23..
thing, it really is quite impressive. 
			Linus

-

...
[ message continues ]

Hi,
This patch adds the symbol "init_level4_pgt" to the vmcoreinfo data so

that makedumpfile (dump filtering command) supports x86_64 sparsemem

kernel of linux-2.6.24.
makedumpfile creates a small dumpfile by excluding unnecessary pages for

the analysis. It checks attributes in page structures and distinguishes

necessary pages and unnecessary ones. To check them, makedumpfile gets

the vmcoreinfo data which has the minimum debugging information only for

dump filtering.
For older x86_64 kernel (linux-2.6.23 or before), makedumpfile translates

the virtual address of page structure into physical address by subtracting

PAGE_OFFSET from virtual address, but this translation isn't effective for

linux-2.6.24 sparsemem kernel, because its page structures are in virtual

memmap area. makedumpfile should translate their virtual address by 4-levels

paging and it needs the symbol "init_level4_pgt".
Thanks

Ken'ichi Ohmichi 
---

Signed-off-by: Ken'ichi Ohmichi <oomichi@mxs.nes.nec.co.jp>
---

diff -rpuN a/arch/x86/kernel/machine_kexec_64.c b/arch/x86/kernel/machine_kexec_64.c

--- a/arch/x86/kernel/machine_kexec_64.c	2007-10-26 11:05:34.000000000 +0900

+++ b/arch/x86/kernel/machine_kexec_64.c	2007-10-26 11:16:24.000000000 +0900

@@ -233,6 +233,8 @@ NORET_TYPE void machine_kexec(struct kim
 void arch_crash_save_vmcoreinfo(void)

 {

+	VMCOREINFO_SYMBOL(init_level4_pgt);

+

 #ifdef CONFIG_ARCH_DISCONTIGMEM_ENABLE

 	VMCOREINFO_SYMBOL(node_data);

 	VMCOREINFO_LENGTH(node_data, MAX_NUMNODES);

_
-

-- Linus Torvalds wrote : 
This may count as one of the biggest -rc releases ever. It's humongous.

Usually the compressed -rc1 diffs are in the 3-5MB range, with occasional

smaller ones, and the occasional ones that top 6M, but this one is

*eleven* megs.
I'd blame the x86 renames (and the watchdog ones), but the thing is, it's

absolutely huge even when I generate the diff with git turning all those

renames into relatively small rename diffs (which I don't do for the

public diffs, since I expect that git people use git to get the changes,

and non-git people won't have tools that understand a diff that involves

renames).
In short, we just had an unusually large amount of not just x86 merges,

but also tons of new drivers (wireless networking stands out, but is by no

means the only thing - we've got dvb, regular wired network, mmc etc all

joining in), and a fair amount or architecture stuff, filesystems,

networking etc too.
So there's just lots of new stuff. The diffstat is ten thousand lines

long, and weighing in at comfortably over half a megabyte it is way over

the limits of this - or any sane - mailing list. The shortlog is barely

shorter, weighing in at "just" 8461 lines and almost 400k. The full

changelog (which I'm still producing for y'all, since people told me they

actually care last time I asked) is 4 megs.
In other words, I don't even know where to start. The big noticeable thing

is the x86 merge, and I think we all fervently hope that it won't cause

any issues. So far it's been pretty smooth sailing. Knock wood.
Less smooth has the scatter-gather changes to the block layer been, but

they are hopefully all in reasonable shape by now too. And the VM changes?

I honestly hope nobody even notices. Same goes for some of the VFS layer

changes that affected basically every filesystem (although in mostly very

straightforward ways).
Just for fun, I'd really encourage git users to just try the
	git shortlog v2.6.23..
thing, it really is quite i...
[ message continues ]

I can't seem to get 2.6.24-rc1 to build:
  ...

  LD      .tmp_vmlinux1

arch/x86/kernel/built-in.o: In function `smp_send_nmi_allbutself':

/usr/projects/linux/linux-2.6/arch/x86/kernel/crash.c:85: undefined reference to `genapic'

make: *** [.tmp_vmlinux1] Error 1
Has anyone else seen this?
						- Ted

Hi Ted,
The patch for this build issue is available at http://lkml.org/lkml/2007/10/24/128.

--

Thanks & Regards,

Kamalesh Babulal,

Linux Technology Center,

IBM, ISTL.

-

Subject: portman2x4.c: fix boot hang

From: Ingo Molnar <mingo@elte.hu>
when booting an allyesconfig bzImage kernel the bootup hangs in the

portman2x4 driver (on a box that does not have this hardware), at:
 Pid: 1, comm:              swapper

 EIP: 0060:[<c02f763c>] CPU: 0

 EIP is at parport_pc_read_status+0x4/0x8

  EFLAGS: 00000202    Not tainted  (2.6.23-rc9 #904)

 EAX: f7e57a7f EBX: 00000010 ECX: c2b808c0 EDX: 00000379

 ESI: f7cb8230 EDI: 00000010 EBP: f7cb8230 DS: 007b ES: 007b FS: 0000

 CR0: 8005003b CR2: fff9c000 CR3: 007ec000 CR4: 00000690

 DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000

 DR6: ffff0ff0 DR7: 00000400

  [<c04613de>] portman_flush_input+0xde/0x12c

  [<c0461a24>] snd_portman_probe+0x368/0x484

  [<c02fbb8c>] __device_attach+0x0/0x8

  [<c02fce68>] platform_drv_probe+0xc/0x10

  [<c02fba6c>] driver_probe_device+0x74/0x194

  [<c0587174>] klist_next+0x38/0x70

  [<c02fbb8c>] __device_attach+0x0/0x8

  [<c02faea1>] bus_for_each_drv+0x35/0x68

  [<c02fbc22>] device_attach+0x72/0x78
the reason is due to an inconsistent error return code of 1 or 2, while

snd_portman_probe only realizes negative error codes.
with this fixed the probe fails as it should and the bootup continues.
Signed-off-by: Ingo Molnar <mingo@elte.hu>

---

 sound/drivers/portman2x4.c |    6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux/sound/drivers/portman2x4.c

===================================================================

--- linux.orig/sound/drivers/portman2x4.c

+++ linux/sound/drivers/portman2x4.c

@@ -467,7 +467,7 @@ static int portman_probe(struct parport

 	/* Check for ESTB to be clear */

 	/* 4 */

 	if ((parport_read_status(p) & ESTB) == ESTB)

-		return 1;	/* CODE 1 - Strobe Failure. */

+		return -EIO;	/* CODE 1 - Strobe Failure. */
 	/* Set for RXDATA0 where no damage will be done. */

 	/* 5 */

@@ -475,7 +475,7 @@ static int portman_probe(struct parport 
 	/* 6...
[ message continues ]

At Wed, 24 Oct 2007 21:44:17 +0200,
Thanks.  But isn't the patch below easier?
Takashi
diff -r 09088524dd7f drivers/portman2x4.c

--- a/drivers/portman2x4.c	Thu Oct 25 11:46:24 2007 +0200

+++ b/drivers/portman2x4.c	Thu Oct 25 11:49:17 2007 +0200

@@ -668,7 +668,7 @@ static int __devinit snd_portman_probe_p

 	parport_release(pardev);

 	parport_unregister_device(pardev);
-	return res;

+	return res ? -EIO : 0;

 }
 static void __devinit snd_portman_attach(struct parport *p)

-

Why are you keeping the "CODE 1" comment? Just "Strobe Failure" as comment

would seem more consistent with the change.

-

looking at other uses of 'CODE' suggested that 'CODE 1' is not the

return code - so i left it alone.
	Ingo

-

On 2.6.24-rc1-gc9927c2b BUG: unable to handle kernel paging request at virtual address 3d15b925
In last git, I see the following BUGs in various programs.  It seems

reproducible, but sometime I've hard lookup on poweroff.
ciao

        cate
vivi: open called (minor=0)

vivi: close called (minor=0, users=0)

BUG: unable to handle kernel paging request at virtual address 3d15b925

printing eip: 3d15b925 *pde = 00000000

Oops: 0000 [#1] SMP

Modules linked in: fuse tuner tea5767 tda8290 tuner_simple mt20xx bttv ir_common videobuf_dma_sg btcx_risc tveeprom floppy
Pid: 3389, comm: icedove-bin Not tainted (2.6.24-rc1-gc9927c2b #17)

EIP: 0060:[<3d15b925>] EFLAGS: 00210206 CPU: 0

EIP is at 0x3d15b925

EAX: c4c7a2bc EBX: c4c7a36c ECX: 00000000 EDX: 00000000

ESI: c4c7a2bc EDI: 00000000 EBP: 00000000 ESP: c495ee00

 DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0068

Process icedove-bin (pid: 3389, ti=c495e000 task=c4876570 task.ti=c495e000)

Stack: 00000001 0000002e 00000000 00006c01 b1171795 00000000 c4c7a2bc 00008068

       c495ee78 c017c362 00000000 00000000 c495ee78 00008068 00000000 c4c7a2bc

       c017c53a c24058c0 00000001 c4c79f14 00000008 222281a4 22222222 22222222

Call Trace:

 [<c017c362>] inode_setattr+0x53/0x152

 [<c017c53a>] notify_change+0xd9/0x2a3

 [<c0169b51>] do_truncate+0x5e/0x75

 [<c0169130>] get_unused_fd_flags+0x52/0xc1

 [<c0170d4b>] permission+0xc5/0xde

 [<c0171e07>] may_open+0x155/0x1b3

 [<c0173ba4>] open_namei+0x6b/0x5f9

 [<c01693e3>] do_filp_open+0x25/0x40

 [<c0169130>] get_unused_fd_flags+0x52/0xc1

 [<c016943e>] do_sys_open+0x40/0xc5

 [<c01694fe>] sys_open+0x1c/0x20

 [<c0103fde>] sysenter_past_esp+0x5f/0x85

 =======================

Code:  Bad EIP value.

EIP: [<3d15b925>] 0x3d15b925 SS:ESP 0068:c495ee00

BUG: unable to handle kernel paging request at virtual address 3d15b925

printing eip: 3d15b925 *pde = 00000000

Oops: 0000 [#2] SMP

Modules linked in: fuse tuner tea5767 tda8290 t...
[ message continues ]

hi,
do you still get this with more recent kernels? We had a number of fixes

for memory corruptors since -rc1 - perhaps one of them took care of your

problem as well.
	Ingo

--

No, the problem was solved few days after the report.
Thanks,

	cate
--

Can you point me to the fix, please?
Rafael

--

Unfortunately no. To much chaos in that period:

I think I incurred into two or three different kernel bugs

(and a Debian keyboard bug) in one or two days. Usually

I find such important bugs only few times per year,

and never together).
I tried also git-bisect, but too much runs, to many non-compiling

commits, bad environment (the Debian bug) and the quick fix of the

kernel bug ;-) stopped me in further searching.
ciao

	cate

--

Hi,
2.6.23-rc1 fails for me. I have the sensation it is network-related, but

I am not sure, so I send this message just to the list.

This same failure was present in git-5734-gd85714d, I sent

a message to the list but it seems it never arrived. I hope this will

pass through. My system is a toshiba satellite A305-S5077, dual core pentium.
The symptoms are quite strange. At boot, NetworkManager fails to activate

my eth0 (r8169). Just stopping/restarting NM will make it works.
Then, after one or two or maximum three suspend to ram and resume that

works, all go awry. Notice that I do not know if the s2ram is the cause, or

simply the way to accelerate the bug.
The suspend-to-ram will fail with a messages: 
"gnome-power-manager: (romano) DBUS timed out, but recovering"
and a number of processes go into D state (please find their sysrq-t traces

few lines down). Now I cannot create new windows, nor doing sudo (sudo

anything will go into D limbo), and not even a clean shutdown. Trying that

the system loops forever saying: 
BUG: soft lockup - CPU#0 stuck for 11s! [ifconfig: 7481]
and sysrq-b is the only option. 
Complete dmesg, config, etc at:

http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_1/
Thanks, 
	Romano 
PS sorry for the disclaimer, I cannot stop it (¡!) 
nmbd          D ca9cbea4     0  5464      1

       c256eaa0 00000086 00000002 ca9cbea4 ca9cbe9c 00000000 c256ebdc c17fba80

       c250e900 c0426080 c0426080 c22f67d0 c01773a3 00000010 c0426080 00013bab

       00000000 000000ff 00000000 00000000 00000000 c03bc514 c03bc51c c03bc518

Call Trace:

 [cache_alloc_refill+115/1280] cache_alloc_refill+0x73/0x500

 [__mutex_lock_slowpath+85/144] __mutex_lock_slowpath+0x55/0x90

 [mutex_lock+20/32] mutex_lock+0x14/0x20

 [sock_ioctl+0/560] sock_ioctl+0x0/0x230

 [dev_ioctl+200/1312] dev_ioctl+0xc8/0x520

 [sock_init_data+108/384] sock_init_data+0x6c/0x180

 [inet_create+413/832] inet_create+0x19d/0x340

 [inotify_d_instantiate+24/128] inotify_d_instantiat...
[ message continues ]

Denis V. Lunev wrote a patch for the NetworkManager thing a day or two

ago (which DaveM has queued).
Since netlink is involved in the traces you sent, this might do something

for the other too.
diff --git a/net/netlink/af_netlink.c b/net/netlink/af_netlink.c

index 98e313e..44a8b41 100644

--- a/net/netlink/af_netlink.c

+++ b/net/netlink/af_netlink.c

@@ -1565,7 +1565,10 @@ int netlink_dump_start(struct sock *ssk, struct sk_buff *skb,
 	netlink_dump(sk);

 	sock_put(sk);

-	return 0;

+

+	/* We successfully started a dump, by returning -EINTR we

+	 * signal not to send ACK even if it was requested */

+	return -EINTR;

 }
 void netlink_ack(struct sk_buff *in_skb, struct nlmsghdr *nlh, int err)

@@ -1619,17 +1622,21 @@ int netlink_rcv_skb(struct sk_buff *skb, int (*cb)(struct sk_buff *,
 		/* Only requests are handled by the kernel */

 		if (!(nlh->nlmsg_flags & NLM_F_REQUEST))

-			goto skip;

+			goto ack;
 		/* Skip control messages */

 		if (nlh->nlmsg_type < NLMSG_MIN_TYPE)

-			goto skip;

+			goto ack;
 		err = cb(skb, nlh);

-skip:

+		if (err == -EINTR)

+			goto skip;

+

+ack:

 		if (nlh->nlmsg_flags & NLM_F_ACK || err)

 			netlink_ack(skb, nlh, err);
+skip:

 	        msglen = NLMSG_ALIGN(nlh->nlmsg_len);

 		if (msglen > skb->len)

 			msglen = skb->len;
--

Joseph Fannin

jfannin@gmail.com

-

This *do* fix the "network manager needs to be restarted at boot" part

of the problem, but leave as is the worst one (the failed suspend to ram

and following bugs). 
	Romano 
--

Sorry for the disclaimer --- ¡I cannot stop it!
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

-

could you turn on these in your .config:
  CONFIG_PROVE_LOCKING=y

  CONFIG_DEBUG_LIST=y

  CONFIG_FRAME_POINTER=y

  CONFIG_DEBUG_SLAB=y
and please post the resulting dmesg output - does lockdep notice any

lockup reason? (your backtrace suggests some mutex stuff so it might as

well detect it)
	Ingo

-

Done. The results are at: 
http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_2/
in the  syslog-after-failed-suspend.txt file. After the failed suspend

(at line 15766) there where the bunch of things in D-state. I have left

the file intact.
At line 17646 there  is:
WARNING: at kernel/lockdep.c:2033 trace_hardirqs_on() 
I waited a bit and then, on an already-opened root shell, did

s2ram -f -p -m  (line 17811)
and then a lot more things happened, and I am somewhat lost.
Hope this could be useful to you.
Romano 
--

Sorry for the disclaimer --- ¡I cannot stop it!
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

-

hm, this lockdep warning caused lockdep to turn itself off - hence we

wont get to the really interesting warnings. We'll try to come up with a

solution for this.
	Ingo

-

Does this help?
---

Subject: lockdep: invalid irq usage
this function can be called from hardirq context.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>

---
Index: linux-2.6-2/kernel/sched_debug.c

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

--- linux-2.6-2.orig/kernel/sched_debug.c

+++ linux-2.6-2/kernel/sched_debug.c

@@ -80,6 +80,7 @@ print_task(struct seq_file *m, struct rq

 static void print_rq(struct seq_file *m, struct rq *rq, int rq_cpu)

 {

 	struct task_struct *g, *p;

+	unsigned long flags;

=20

 	SEQ_printf(m,

 	"\nrunnable tasks:\n"

@@ -88,7 +89,7 @@ static void print_rq(struct seq_file *m,

 	"------------------------------------------------------"

 	"----------------------------------------------------\n");

=20

-	read_lock_irq(&tasklist_lock);

+	read_lock_irqsave(&tasklist_lock, flags);

=20

 	do_each_thread(g, p) {

 		if (!p->se.on_rq || task_cpu(p) !=3D rq_cpu)

@@ -97,7 +98,7 @@ static void print_rq(struct seq_file *m,

 		print_task(m, rq, p);

 	} while_each_thread(g, p);

=20

-	read_unlock_irq(&tasklist_lock);

+	read_unlock_irqrestore(&tasklist_lock, flags);

 }

=20

 void print_cfs_rq(struct seq_file *m, int cpu, struct cfs_rq *cfs_rq)

I tried this, but although I have the D-state processes, I cannot see

any debug trace now. Results are at:
http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_3/
Can I try anything more? This is quite a show-stopper for me... and

before trying to bisect 11Mbyte of patches...
Romano 
--

Sorry for the disclaimer --- ¡I cannot stop it!
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

-

hm, from your log it appears that lockdep did not find anything, still

the hang does trigger.
it's /sbin/ifconfig and inet_ioctl() / dev_close() / rtl8169_down() that

seems to be hanging. I've extracted the relevant backtrace below. I've

Cc:-ed people who might have a better idea about what's going on.
	Ingo
 ------------------>

 ifconfig      S c0476f80     0  7226   7166

        cbb67df0 00000046 c02f3f97 c0476f80 cbb67dc0 c01489d5 c2b81550 c2b8168c

        c1cf7b80 00000000 c30bd250 00000000 cbb67dd0 00000282 cbb67e00 c0476f80

        cbb67df0 c0132618 00004232 00000000 00000282 cbb67e00 00004232 f884e000

 Call Trace:

  [schedule_timeout+72/192] schedule_timeout+0x48/0xc0

  [schedule_timeout_interruptible+21/32] schedule_timeout_interruptible+0x15/0x20

  [msleep_interruptible+39/64] msleep_interruptible+0x27/0x40

  [<f88422f0>] rtl8169_down+0xb0/0xd0 [r8169]

  [<f88424cf>] rtl8169_close+0x1f/0xb0 [r8169]

  [dev_close+71/96] dev_close+0x47/0x60

  [dev_change_flags+125/384] dev_change_flags+0x7d/0x180

  [devinet_ioctl+1225/1632] devinet_ioctl+0x4c9/0x660

  [inet_ioctl+107/144] inet_ioctl+0x6b/0x90

  [sock_ioctl+208/544] sock_ioctl+0xd0/0x220

  [do_ioctl+40/128] do_ioctl+0x28/0x80

  [vfs_ioctl+87/640] vfs_ioctl+0x57/0x280

  [sys_ioctl+57/96] sys_ioctl+0x39/0x60

  [sysenter_past_esp+95/165] sysenter_past_esp+0x5f/0xa5

  =======================

-

On Fri, 26 Oct 2007 08:37:33 +0200
Are you building with NAPI enabled or not. Looks like the following

might help the non-napi case.
--- a/drivers/net/r8169.c	2007-10-24 21:38:43.000000000 -0700

+++ b/drivers/net/r8169.c	2007-10-26 09:46:07.000000000 -0700

@@ -2989,13 +2989,16 @@ static void rtl8169_down(struct net_devi

 {

 	struct rtl8169_private *tp = netdev_priv(dev);

 	void __iomem *ioaddr = tp->mmio_addr;

-	unsigned int poll_locked = 0;

 	unsigned int intrmask;
 	rtl8169_delete_timer(dev);
 	netif_stop_queue(dev);
+#ifdef CONFIG_R8169_NAPI

+	napi_disable(&tp->napi);

+#endif

+

 core_down:

 	spin_lock_irq(&tp->lock);
@@ -3009,11 +3012,6 @@ core_down:
 	synchronize_irq(dev->irq);
-	if (!poll_locked) {

-		napi_disable(&tp->napi);

-		poll_locked++;

-	}

-

 	/* Give a racing hard_start_xmit a few cycles to complete. */

 	synchronize_sched();  /* FIXME: should this be synchronize_irq()? */
--

Stephen Hemminger <shemminger@linux-foundation.org>

-

the config from:
  http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_1/
suggests that NAPI was disabled:
  CONFIG_R8169=m

  # CONFIG_R8169_NAPI is not set

  CONFIG_R8169_VLAN=y
	Ingo

-

Don't call napi_disable if not configured.

And make sure that any misuse of napi_xxx in future fails

with a compile error.
Signed-off-by: Stephen Hemminger <shemminger@linux-foundation.org>
--- a/drivers/net/r8169.c	2007-10-24 21:38:43.000000000 -0700

+++ b/drivers/net/r8169.c	2007-10-26 11:27:02.000000000 -0700

@@ -392,7 +392,9 @@ struct rtl8169_private {

 	void __iomem *mmio_addr;	/* memory map physical address */

 	struct pci_dev *pci_dev;	/* Index of PCI device */

 	struct net_device *dev;

+#ifdef CONFIG_R8169_NAPI

 	struct napi_struct napi;

+#endif

 	spinlock_t lock;		/* spin lock flag */

 	u32 msg_enable;

 	int chipset;

@@ -2989,13 +2991,16 @@ static void rtl8169_down(struct net_devi

 {

 	struct rtl8169_private *tp = netdev_priv(dev);

 	void __iomem *ioaddr = tp->mmio_addr;

-	unsigned int poll_locked = 0;

 	unsigned int intrmask;
 	rtl8169_delete_timer(dev);
 	netif_stop_queue(dev);
+#ifdef CONFIG_R8169_NAPI

+	napi_disable(&tp->napi);

+#endif

+

 core_down:

 	spin_lock_irq(&tp->lock);
@@ -3009,11 +3014,6 @@ core_down:
 	synchronize_irq(dev->irq);
-	if (!poll_locked) {

-		napi_disable(&tp->napi);

-		poll_locked++;

-	}

-

 	/* Give a racing hard_start_xmit a few cycles to complete. */

 	synchronize_sched();  /* FIXME: should this be synchronize_irq()? */
-

This fix the problem for me (at least, after 8 suspend/resume cycles).

Thanks.
Tested-by: Romano Giannetti <romano.giannetti@gmail.com>
--

Sorry for the disclaimer --- ¡I cannot stop it!
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

-

Will test as soon as possible (been without internet in the week end).

Thanks.
As a bonus, I tried more thing, and I had a signal form lockdep. You can

find it here:
http://www.dea.icai.upcomillas.es/romano/linux/info/2624rc1_5/
patching and compiling now.
Romano 
--

Sorry for the disclaimer --- ¡I cannot stop it!
--

La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido esta comunicación por error, por favor, notifíquelo inmediatamente al remitente contestando a este mensaje y proceda a continuación a destruirlo. Gracias por su colaboración.
This communication contains confidential information. It is for the exclusive use of the intended addressee. If you are not the intended addressee, please note that any form of distribution, copying or use of this communication or the information in it is strictly prohibited by law. If you have received this communication in error, please immediately notify the sender by reply e-mail and destroy this message. Thank you for your cooperation.

-

Acked-off-by: Francois Romieu <romieu@fr.zoreil.com>
--

Ueimor

-

Linus, please pull the latest x86 git tree from:
   git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
it contains two build fixes and an oops-printout-ugliness fix.
Thanks!
	Ingo
------------------>

Alexey Dobriyan (1):

      x86: fix bogus KERN_ALERT on oops
Jeff Garzik (1):

      x86: lguest build fix
Mike Galbraith (1):

      x86: fix CONFIG_KEXEC build breakage
 kernel/crash.c |    6 +++---

 lguest/boot.c  |    1 +

 mm/fault_32.c  |    2 +-

 3 files changed, 5 insertions(+), 4 deletions(-)

-

Any chance you can kill the warnings that appear on !CONFIG_SMP,

!LOCAL_APIC ?  :)
http://marc.info/?l=linux-kernel&m=119317911305274&w=2

http://marc.info/?l=linux-kernel&m=119317911105258&w=2
It is /likely/ that my fixes are not upstream-worthy, these patches

mainly illustrate the problem, not necessarily the best solution.
	Jeff
-

thx, i have picked them up. Please keep the warnings fixes coming, they

are much appreciated! I've missed real kernel bugs due to compiler noise

way too many times.
	Ingo

-

Fix this uml building error:

arch/um/drivers/ubd_kern.c: In function 'do_ubd_request':

arch/um/drivers/ubd_kern.c:1118: error: implicit declaration of function 'sg_page'

arch/um/drivers/ubd_kern.c:1118: warning: passing argument 6 of 'prepare_request' makes pointer from integer without a cast

make[1]: *** [arch/um/drivers/ubd_kern.o] Error 1

make: *** [arch/um/drivers] Error 2
Signed-off-by: WANG Cong <xiyou.wangcong@gmail.com>
---

 arch/um/drivers/ubd_kern.c |    1 +

 1 file changed, 1 insertion(+)
diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c

index 3a8cd3d..440ed25 100644

--- a/arch/um/drivers/ubd_kern.c

+++ b/arch/um/drivers/ubd_kern.c

@@ -35,6 +35,7 @@

 #include "linux/genhd.h"

 #include "linux/spinlock.h"

 #include "linux/platform_device.h"

+#include "linux/scatterlist.h"

 #include "asm/segment.h"

 #include "asm/uaccess.h"

 #include "asm/irq.h"

-

Thanks, applied!
--

Jens Axboe
-

Btw, can we please finis up this merge a little more before we freeze

2.6.24?  The way we currently have leftovers of arch/i386/ and arch/x86_64/

is quite a nightmare and not how the other architectures were merged.
Thomas, what again prevents us from just killing these leftovers?
-

If these 10 files gives you nightmares then poor soul ;-)
Anyway - the primary issue is the two defconfig files and the Kconfig stuff.

For defconfig we can inheritate the solution from powerpc where

the defconfig file is selected based on architecture.

Something like a

DEFCONFIG := defconfig_$(ARCH)
and then stuff them in configs/ directory.
The Kconfig stuff could be handled by special casing in scripts/kconfig.

We cannot just do the more obvious which is source the files since

they have conflicting choice symbols.

That could be fixed but requires a bit more work to do so - since we need

to track all relevant usages of the choice symbols and rename these.

We could also teach kconfig to allow duplicate symbols names in two choices

but Roman Zippel has not done that yet.
The Makefile stuff is trivial to merge.
The above is not preventing us - more what needs to be done.
	Sam

-

yes. But even Makefile merging can be surprisingly nontrivial at times:

we had bugs in earlier versions of the unification due to link ordering

and silent init section dependencies in the code. When we unified the

makefiles certain init code broke because the initcall ordering changed.

That's why we went for the "stupid, mechanic unification" approach first

- to always have a 100% correct fallback position that people can bisect

to.
	Ingo

-

Hi Ingo.
This is first step in getting rid of the two directories.

I had to do some very minor modifications in common files

to let it work out - but nothing really hackish.
If you & Thomas + hpa are OK with the changes they can be

pulled from:
	git://git.kernel.org/pub/scm/linux/kernel/git/sam/x86.git
As this is mostly renames I have attached a git -M diff only.
The remaining stuff is Kconfig files.
Before looking into these I am hoping someone could

step in and make the two Kconfig.debug

files 100% equal - because then I can fix the kconfig

stuff and finally kill the two directories.
	Sam
commit 4aaac9bda3be500750347129ee13d63e80bf4b9f

Author: Sam Ravnborg <sam@ravnborg.org>

Date:   Wed Oct 24 23:00:06 2007 +0200
    x86: move defconfig files for i386 and x86_64 to x86
    With some small changes to kconfig makefile we can now

    locate the defconfig files for i386 and x86_64 in

    the configs/ subdirectory under x86.
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
commit f745ab20e4697829100edfe29035d491f7efdc42

Author: Sam Ravnborg <sam@ravnborg.org>

Date:   Wed Oct 24 22:44:11 2007 +0200
    x86: move i386 and x86_64 Makefiles to arch/x86
    Moving the ARCH specific MAkefiles for i386 and x86_64

    required a litle bit tweaking in the top-lvel Makefile.

    But this is one of the final steps to get rid of the

    x86_64 and i386 directories.
    Signed-off-by: Sam Ravnborg <sam@ravnborg.org>
git diff -M --stat:
 Makefile                                           |    7 +++++--

 arch/{i386/Makefile => x86/Makefile_32}            |    4 ++--

 arch/{i386/Makefile.cpu => x86/Makefile_32.cpu}    |    0

 arch/{x86_64/Makefile => x86/Makefile_64}          |    2 +-

 .../{i386/defconfig => x86/configs/i386_defconfig} |    0

 .../defconfig => x86/configs/x86_64_defconfig}     |    0

 scripts/kconfig/Makefile                           |    6 +++---

 7 files changed, 11 insert...
[ message continues ]

How about mechanically unifying them by adding:
	depends on X86_32
and:
	depends on X86_64
lines? Can you see any problem with such an approach?
	Ingo

-

Not really.

But when we touch Kconfig.debug we should check up on that it reflect

reality. I would be suprised if we do not miss an option or two.

I am tempted to just go forward with the version Randy made where

he merged the two.

If I get time I will look at it tonight and send out a series of patches

for review.
We have to get rid of the directories - just consider the poor victim

that has her/his code reviewed by hch after he have had his nightmare ;-)
	Sam

-

Uh, maybe I jumped too far.  I merged the 2 x86 Kconfig.debug files

into arch/x86/Kconfig.debug....
---
From: Randy Dunlap <randy.dunlap@oracle.com>
Merge i386/Kconfig.debug and x86_64/Kconfig.debug into x86/Kconfig.debug,

using "depends on X86_32" or X86_64 when needed.
Signed-off-by: Randy Dunlap <randy.dunlap@oracle.com>

---

 arch/i386/Kconfig.debug   |   88 ----------------------------------

 arch/x86/Kconfig.debug    |  119 ++++++++++++++++++++++++++++++++++++++++++++++

 arch/x86_64/Kconfig.debug |   61 -----------------------

 3 files changed, 119 insertions(+), 149 deletions(-)
--- linux-2.6.24-rc1.orig/arch/i386/Kconfig.debug

+++ /dev/null

@@ -1,88 +0,0 @@

-menu "Kernel hacking"

-

-config TRACE_IRQFLAGS_SUPPORT

-	bool

-	default y

-

-source "lib/Kconfig.debug"

-

-config EARLY_PRINTK

-	bool "Early printk" if EMBEDDED && DEBUG_KERNEL

-	default y

-	help

-	  Write kernel log output directly into the VGA buffer or to a serial

-	  port.

-

-	  This is useful for kernel debugging when your machine crashes very

-	  early before the console code is initialized. For normal operation

-	  it is not recommended because it looks ugly and doesn't cooperate

-	  with klogd/syslogd or the X server. You should normally N here,

-	  unless you want to debug such a crash.

-

-config DEBUG_STACKOVERFLOW

-	bool "Check for stack overflows"

-	depends on DEBUG_KERNEL

-	help

-	  This option will cause messages to be printed if free stack space

-	  drops below a certain limit.

-

-config DEBUG_STACK_USAGE

-	bool "Stack utilization instrumentation"

-	depends on DEBUG_KERNEL

-	help

-	  Enables the display of the minimum amount of free stack which each

-	  task has ever had available in the sysrq-T and sysrq-P debug output.

-

-	  This option will slow down process creation somewhat.

-

-comment "Page alloc debug is incompatible with Software Suspend on i386"

-	depends on DEBUG_KERNEL && HIBERNATION

-

-config DEBUG_PAGEALLOC

-	bool "Debug page memo...
[ message continues ]

...

in x86_64/Kconfig has EARLY_PRINTK too
config EARLY_PRINTK

        bool

        default y
YH

-

I noticed this too. So on x86_64 it was unconditionally enabled

whereas with i386 (and the merged files) if it an option that

can be turned off.
Randy - did you realise this when you did the merge?
	Sam

-

No, I missed that.
---

~Randy

-

With trivial I thought of:

ifeq ($(ARCH),x86_64)

include arch/x86/Makefile_64

else

include arch/x86/Makefile_32

endif
And common stuff could be put before/after the include.
	Sam

-

to answer that question one should first be aware of the fundamental

code quality problems that the unified x86 architecture has inherited

from the split i386 and x86_64 architectures.
To get objective and automated metrics about code quality, i've

constructed a table of "coding style errors per one thousand lines of

source code" numbers with the help of the latest checkpatch.pl. The

codebases i measured are the pre-merge i386 and x86_64 tree, the

post-merge arch/x86 unified architecture, and i've also added a handful

of other architectures and selected core subsystems, as comparison:
               -------------------------------------------------------

               |    errors  | lines of code  |    errors/KLOC

               |            |                |    (smaller is better)

 --------------|------------|----------------|------------------------

  arch/i386/          5717            73865         77.3

  arch/x86_64/        2993            31155         96.0

  arch/x86/           8504           114654         74.1

 ..............|............|................|........................

  arch/ia64/          1779            64022         27.7

  arch/mips/          2110            94692         22.2

  arch/sparc64/       1387            49253         28.1

 ..............|............|................|........................

  kernel/              762            83540          9.1

  kernel/time/          15             4191          3.5

  kernel/irq/            1             2317          0.4

  mm/                  464            46324         10.0

  net/core             176            24413          7.2

 ..............|............|................|........................
a couple of observations. Firstly, it is plainly obvious that the x86_64

and i386 architectures were in a dreadful state of code quality before

the unification. Their code quality was almost an order of magnitude

worse than that of the core kernel (!) - and their code quality was

significa...
[ message continues ]

what is also impressive is:
   $ git shortlog v2.6.23.. | grep \):$ | wc -l

   756
756 individual contributors. Wow!
	Ingo

-

Yep, posted a build fix for this the other day...
	Jeff
-

Hi,

build failed on my pc:
arch/x86/kernel/built-in.o(.text+0x1b192): In function
Regards

dave

-

please send us the .config you are using. Chances are that the patch

below will fix the build breakage for you.
	Ingo
--------------------->

Subject: x86: fix CONFIG_KEXEC build breakage

From: Mike Galbraith <efault@gmx.de>
X86_32 build fix to commit 62a31a03b3d2a9d20e7a073e2cd9b27bfb7d6a3f
Signed-off-by: Mike Galbraith <efault@gmx.de>

Signed-off-by: Ingo Molnar <mingo@elte.hu>

Signed-off-by: Thomas Gleixner <tglx@linutronix.de>

---

 arch/x86/kernel/crash.c |    6 +++---

 1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux/arch/x86/kernel/crash.c

===================================================================

--- linux.orig/arch/x86/kernel/crash.c

+++ linux/arch/x86/kernel/crash.c

@@ -25,7 +25,7 @@

 #include <linux/kdebug.h>

 #include <asm/smp.h>
-#ifdef X86_32

+#ifdef CONFIG_X86_32

 #include <mach_ipi.h>

 #else

 #include <asm/mach_apic.h>

@@ -41,7 +41,7 @@ static int crash_nmi_callback(struct not

 			unsigned long val, void *data)

 {

 	struct pt_regs *regs;

-#ifdef X86_32

+#ifdef CONFIG_X86_32

 	struct pt_regs fixed_regs;

 #endif

 	int cpu;

@@ -60,7 +60,7 @@ static int crash_nmi_callback(struct not

 		return NOTIFY_STOP;

 	local_irq_disable();
-#ifdef X86_32

+#ifdef CONFIG_X86_32

 	if (!user_mode_vm(regs)) {

 		crash_fixup_ss_esp(&fixed_regs, regs);

 		regs = &fixed_regs;

-

Hi,

Yes, I have tried it, works fine.
Part of my .config:

#

# Automatically generated make config: don't edit

# Linux kernel version: 2.6.24-rc1

# Wed Oct 24 13:02:24 2007

#

CONFIG_X86_32=y

CONFIG_GENERIC_TIME=y

CONFIG_GENERIC_CMOS_UPDATE=y

CONFIG_CLOCKSOURCE_WATCHDOG=y

CONFIG_GENERIC_CLOCKEVENTS=y

CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

CONFIG_LOCKDEP_SUPPORT=y

CONFIG_STACKTRACE_SUPPORT=y

CONFIG_SEMAPHORE_SLEEPERS=y

CONFIG_X86=y

CONFIG_MMU=y

CONFIG_ZONE_DMA=y

CONFIG_QUICKLIST=y

CONFIG_GENERIC_ISA_DMA=y

CONFIG_GENERIC_IOMAP=y

CONFIG_GENERIC_BUG=y

CONFIG_GENERIC_HWEIGHT=y

CONFIG_ARCH_MAY_HAVE_PC_FDC=y

CONFIG_DMI=y

CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

-

Hi Ingo,
I had the same issue, which is now fixed with your patch.
Thanks,

Ohad.
(.config attached)

Impressive, indeed! At least it's a great testimonial for GIT and the

workflow it permits, but from a user's perspective, so many changes at

once may look frightening!
Regards,

Willy
-