Hello,

On Sun, 2 Sep 2007 13:25:57 +0200
Adrian Bunk <[email protected]> wrote:

> On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.23-rc3-mm1:
> >...
> > git-net.patch
> >...
> > git trees
> >...
>
> This patch fixes the following compile error:
>
> <-- snip -->
>
> ...
> LD .tmp_vmlinux1
> net/built-in.o: In function `inet6_csk_xmit':
> (.text+0x72b0f): undefined reference to `flow_cache_genid'
> net/built-in.o: In function `inet6_csk_xmit':
> (.text+0x72be5): undefined reference to `flow_cache_genid'
> make[1]: *** [.tmp_vmlinux1] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <[email protected]>
>
> ---
> --- a/net/ipv6/Kconfig
> +++ b/net/ipv6/Kconfig
> @@ -5,6 +5,7 @@
> # IPv6 as module will cause a CRASH if you try to unload it
> config IPV6
> tristate "The IPv6 protocol"
> + select XFRM
> default m
> ---help---
> This is complemental support for the IP version 6.
>
> -

Thank you for catching this. the issue is caused with patch
"[IPV6] XFRM: Fix connected socket to use transformation."
which I sent to netdev.
(a85d5450ddeb959bdf9e4603f9c06e9d79217cfa on net-2.6.24).

I'd prefer to modify the original patch to use "ifdef CONFIG_XFRM"
than changing kernel config depends. Does it make sense?

Please review the attached patch.

--
Masahide NAKAMURA

Attachments:

0001-PATCH-IPV6-XFRM-Fix-dependency-issue-at-inet6_csk_xmit.txt (2.06 kB)

2007-09-03 16:36:37

On Tue, 4 Sep 2007 10:54:32 -0700
Zach Carter <[email protected]> wrote:

>
> > +ioc3-program-uart-predividers.patch
> > +sky2-fe-chip-support.patch
> > +sky2-use-debugfs-rename.patch
> > +sky2-document-gphy_ctrl-bits.patch
> > +sky2-dont-restrict-config-space-access.patch
> > +sky2-advanced-error-reporting.patch
> > +sky2-use-pci_config-access-functions.patch
> > +sky2-use-net_device-internal-stats.patch
> > +ktime_sub_ns-analog-of-ktime_add_ns.patch
> > +export-reciprocal_value-for-modules.patch
> > +sky2-hardware-receive-timestamp-counter.patch

I already told Andrew to please drop this last patch, because
it causes interrupt messages. It seems masking off the IRQ
in hardware doesn't prevent that interrupt!

2007-09-05 14:37:56

On Wed, 05 Sep 2007 08:12:07 PDT, Andrew Morton said:

> Seems to me that there's a missing pte_unmap_lock() in insert_page().
>
> Also, a hunk in do_anonymous_page() is indented one tabstop too far, which
> makes me suspect that patch(1) might have put it in the wrong place.
> Balbir, can you please check that?
>
> diff -puN mm/memory.c~memory-controller-memory-accounting-v7-fix mm/memory.c
> --- a/mm/memory.c~memory-controller-memory-accounting-v7-fix
> +++ a/mm/memory.c
> @@ -1135,7 +1135,7 @@ static int insert_page(struct mm_struct

Confirming that this patch fixes things.

Tested-by: Valdis Kletnieks <[email protected]>

Attachments:

(No filename) (226.00 B)

2007-09-05 19:46:56

by Valdis Klētnieks

[permalink] [raw]

Subject: 2.6.23-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820

On Fri, 31 Aug 2007 21:58:22 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc4/2.6.23-rc4-mm1/

git-alsa.patch breaks audio on my laptop, worked fine in -rc3-mm1. Almost
certainly bustification in the Intel HDA rewrite.

Symptoms: alsamixer finds the chipset, can adjust the volumes and mute/unmute,
and /usr/bin/play is able to write a .wav to the ALSA device without complaint.
However, no sound actually comes out. Very "lights are on but nobody is home".

Dell Latitude D820, lspci reports:

00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 01)
and alsamixer reports finding a "SigmaTel STAC9200"

% grep HDA_ .config
CONFIG_SND_HDA_INTEL=y
# CONFIG_SND_HDA_HWDEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
# CONFIG_SND_HDA_CODEC_VIA is not set
# CONFIG_SND_HDA_CODEC_ATIHDMI is not set
# CONFIG_SND_HDA_CODEC_CONEXANT is not set
# CONFIG_SND_HDA_CODEC_CMEDIA is not set
# CONFIG_SND_HDA_CODEC_SI3054 is not set
CONFIG_SND_HDA_GENERIC=y
# CONFIG_SND_HDA_POWER_SAVE is not set

dmesg under -rc4-mm1:
Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC).
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21
hda_intel: position_fix set to 1 for device 1028:01cc
ALSA device list:
#0: HDA Intel at 0xefffc000 irq 506

dmesg under -rc3-mm1:

Advanced Linux Sound Architecture Driver Version 1.0.14 (Fri Jul 20 09:12:58 2007 UTC).
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21
hda_intel: position_fix set to 1 for device 1028:01cc
ALSA device list:
#0: HDA Intel at 0xefffc000 irq 506

(Yes, they look the same to me, too...)

I'd provide more info, if I had a clue what else to add...

Attachments:

(No filename) (226.00 B)

2007-09-05 19:55:13

On Wed, 05 Sep 2007 22:27:35 +0200, Takashi Iwai said:

> BTW, there are 10 different models to test for Dell with STAC9200
> (dell-d2[1-3] and dell-m2[1-7], see

modprobe snd_hda_intel model=dell-m23

was the magic incantation. I'm sure that every user who trips over this
is going to call it a regression, since the -rc3-mm1 module was able to
get it right without hints. ;)

Attachments:

(No filename) (226.00 B)

2007-09-05 21:39:59

by Takashi Iwai

[permalink] [raw]

Subject: Re: 2.6.23-rc4-mm1 - git-alsa.patch breaks audio on Dell Latitude D820

At Wed, 05 Sep 2007 17:16:49 -0400,
[email protected] wrote:
>
> On Wed, 05 Sep 2007 22:27:35 +0200, Takashi Iwai said:
>
> > BTW, there are 10 different models to test for Dell with STAC9200
> > (dell-d2[1-3] and dell-m2[1-7], see
>
> modprobe snd_hda_intel model=dell-m23
>
> was the magic incantation. I'm sure that every user who trips over this
> is going to call it a regression, since the -rc3-mm1 module was able to
> get it right without hints. ;)

Well, it's indeed a regression. There seems to be mistakes in the pin
configuration orders.

Could you try the patch below (without model option)?

thanks,

Takashi

diff -r 3a300e020eca pci/hda/patch_sigmatel.c
--- a/pci/hda/patch_sigmatel.c Wed Sep 05 19:14:38 2007 +0200
+++ b/pci/hda/patch_sigmatel.c Wed Sep 05 23:37:25 2007 +0200
@@ -563,8 +563,8 @@ static unsigned int ref9200_pin_configs[
102801E8
*/
static unsigned int dell9200_d21_pin_configs[8] = {
- 0x400001f0, 0x400001f1, 0x01a19021, 0x90100140,
- 0x01813122, 0x02214030, 0x01014010, 0x02a19020,
+ 0x400001f0, 0x400001f1, 0x02214030, 0x01014010,
+ 0x02a19020, 0x01a19021, 0x90100140, 0x01813122,
};

/*
@@ -573,8 +573,8 @@ static unsigned int dell9200_d21_pin_con
102801C1
*/
static unsigned int dell9200_d22_pin_configs[8] = {
- 0x400001f0, 0x400001f1, 0x02a19021, 0x90100140,
- 0x400001f2, 0x0221401f, 0x01014010, 0x01813020,
+ 0x400001f0, 0x400001f1, 0x0221401f, 0x01014010,
+ 0x01813020, 0x02a19021, 0x90100140, 0x400001f2,
};

/*
@@ -587,8 +587,8 @@ static unsigned int dell9200_d22_pin_con
102801E3
*/
static unsigned int dell9200_d23_pin_configs[8] = {
- 0x400001f0, 0x400001f1, 0x01a19021, 0x90100140,
- 0x400001f2, 0x0221401f, 0x01014010, 0x01813020,
+ 0x400001f0, 0x400001f1, 0x0221401f, 0x01014010,
+ 0x01813020, 0x01a19021, 0x90100140, 0x400001f2,
};

@@ -598,8 +598,8 @@ static unsigned int dell9200_d23_pin_con
102801D8 (Dell Inspiron 640m)
*/
static unsigned int dell9200_m21_pin_configs[8] = {
- 0x40c003fa, 0x03441340, 0x03a11020, 0x401003fc,
- 0x403003fd, 0x0321121f, 0x0321121f, 0x408003fb,
+ 0x40c003fa, 0x03441340, 0x0321121f, 0x90170310,
+ 0x408003fb, 0x03a11020, 0x401003fc, 0x403003fd,
};

/*
@@ -611,8 +611,8 @@ static unsigned int dell9200_m21_pin_con
102801D6
*/
static unsigned int dell9200_m22_pin_configs[8] = {
- 0x40c003fa, 0x0144131f, 0x03A11020, 0x401003fb,
- 0x40f000fc, 0x0321121f, 0x90170310, 0x90a70321,
+ 0x40c003fa, 0x0144131f, 0x0321121f, 0x90170310,
+ 0x90a70321, 0x03a11020, 0x401003fb, 0x40f000fc,
};

/*
@@ -633,8 +633,8 @@ static unsigned int dell9200_m23_pin_con
102801D3
*/
static unsigned int dell9200_m24_pin_configs[8] = {
- 0x40c003fa, 0x404003fb, 0x03a11020, 0x401003fd,
- 0x403003fe, 0x0321121f, 0x90170310, 0x408003fc,
+ 0x40c003fa, 0x404003fb, 0x0321121f, 0x90170310,
+ 0x408003fc, 0x03a11020, 0x401003fd, 0x403003fe,
};

/*
@@ -644,8 +644,8 @@ static unsigned int dell9200_m24_pin_con
102801EF
*/
static unsigned int dell9200_m25_pin_configs[8] = {
- 0x40c003fa, 0x01441340, 0x04a11020, 0x401003fc,
- 0x403003fd, 0x0421121f, 0x90170310, 0x408003fb,
+ 0x40c003fa, 0x01441340, 0x0421121f, 0x90170310,
+ 0x408003fb, 0x04a11020, 0x401003fc, 0x403003fd,
};

/*
@@ -654,8 +654,8 @@ static unsigned int dell9200_m25_pin_con
102801F6
*/
static unsigned int dell9200_m26_pin_configs[8] = {
- 0x40c003fa, 0x404003fb, 0x04a11020, 0x401003fd,
- 0x403003fe, 0x0421121f, 0x90170310, 0x408003fc,
+ 0x40c003fa, 0x404003fb, 0x0421121f, 0x90170310,
+ 0x408003fc, 0x04a11020, 0x401003fd, 0x403003fe,
};

/*
@@ -663,8 +663,8 @@ static unsigned int dell9200_m26_pin_con
102801CD (Dell Inspiron E1705/9400)
*/
static unsigned int dell9200_m27_pin_configs[8] = {
- 0x40c003fa, 0x01441340, 0x04a11020, 0x90170310,
- 0x40f003fc, 0x0421121f, 0x90170310, 0x408003fb,
+ 0x40c003fa, 0x01441340, 0x0421121f, 0x90170310,
+ 0x90170310, 0x04a11020, 0x90170310, 0x40f003fc,
};

2007-09-06 06:39:30

by Satyam Sharma

[permalink] [raw]

Subject: [PATCH] sched: Use show_regs() to improve __schedule_bug() output

Hi Ingo,

On Sun, 2 Sep 2007, Ingo Molnar wrote:
>
> Thanks! Not sure how that bug slipped in, in my tree it does this:
>
> + struct pt_regs *regs;
> ...
> + regs = get_irq_regs();

You're very right indeed -- this bit was absent from -rc4-mm1's
softlockup-improve-debug-output.patch but now that I looked at your
original patch at http://lkml.org/lkml/2007/7/17/180, it becomes
obvious this was simply a mismerge issue after all :-)

[ Andrew, feel free to ignore my patch in case you just resolve
the mismerge by yourself. ]

BTW would something similar would be useful in __schedule_bug() too?
I sure think so -- I'm not sure if EIP holds anything useful there,
but CPU#, EFLAGS and the init_utsname() stuff would be definitely
helpful ...

[PATCH] sched: Use show_regs() to improve __schedule_bug() output

A full register dump along with stack backtrace would make the "scheduling
while atomic" message more helpful. Use show_regs() instead of dump_stack()
for this. We already know we're atomic in here (that is why this function
was called) so show_regs()'s atomicity expectations are guaranteed.

Also, modify the output of the "BUG: scheduling while atomic:" header a bit
to keep task->comm and task->pid together and preempt_count() after them.

Signed-off-by: Satyam Sharma <[email protected]>

---

kernel/sched.c | 14 +++++++++++---
1 files changed, 11 insertions(+), 3 deletions(-)

diff --git a/kernel/sched.c b/kernel/sched.c
index b533d6d..4fb07c1 100644
--- a/kernel/sched.c
+++ b/kernel/sched.c
@@ -63,6 +63,7 @@
#include <linux/unistd.h>

#include <asm/tlb.h>
+#include <asm/irq_regs.h>

/*
* Scheduler clock - returns current time in nanosec units.
@@ -3404,12 +3405,19 @@ EXPORT_SYMBOL(sub_preempt_count);
*/
static noinline void __schedule_bug(struct task_struct *prev)
{
- printk(KERN_ERR "BUG: scheduling while atomic: %s/0x%08x/%d\n",
- prev->comm, preempt_count(), prev->pid);
+ struct pt_regs *regs = get_irq_regs();
+
+ printk(KERN_ERR "BUG: scheduling while atomic: %s/%d/0x%08x\n",
+ prev->comm, prev->pid, preempt_count());
+
debug_show_held_locks(prev);
if (irqs_disabled())
print_irqtrace_events(prev);
- dump_stack();
+
+ if (regs)
+ show_regs(regs);
+ else
+ dump_stack();
}

/*

2007-09-06 14:11:17

2007-09-10 20:19:06

* Satyam Sharma <[email protected]> wrote:

> BTW would something similar would be useful in __schedule_bug() too? I
> sure think so -- I'm not sure if EIP holds anything useful there, but
> CPU#, EFLAGS and the init_utsname() stuff would be definitely helpful
> ...
>
> [PATCH] sched: Use show_regs() to improve __schedule_bug() output
>
> A full register dump along with stack backtrace would make the
> "scheduling while atomic" message more helpful. Use show_regs()
> instead of dump_stack() for this. We already know we're atomic in here
> (that is why this function was called) so show_regs()'s atomicity
> expectations are guaranteed.
>
> Also, modify the output of the "BUG: scheduling while atomic:" header
> a bit to keep task->comm and task->pid together and preempt_count()
> after them.

thanks, applied.

Ingo