* Re: Trying again with cross compile
From: Takashi Iwai @ 2006-04-07 18:22 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144433926.9653.53.camel@localhost.localdomain>
At Fri, 07 Apr 2006 19:18:45 +0100,
Adrian McMenamin wrote:
>
> On Fri, 2006-04-07 at 20:10 +0200, Takashi Iwai wrote:
> > At Fri, 07 Apr 2006 19:07:01 +0100,
> > Adrian McMenamin wrote:
> > >
> > > On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> > >
> > > > Maybe not yet? The fix is simple as below.
> > > >
> > > >
> > > > Takashi
> > > >
> > > >
> > > > diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> > > > --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> > > > +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> > > > @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
> > > >
> > > > #define snd_power_lock(card) do { (void)(card); } while (0)
> > > > #define snd_power_unlock(card) do { (void)(card); } while (0)
> > > > -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> > > > +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> > > > #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> > > > #define snd_power_change_state(card, state) do { (void)(card); } while (0)
> > > >
> > > >
> > >
> > > I've patched and everything seems to be fine expect that the build gets
> > > wedged on hpi6000
> > >
> > > I've even tried leaving if for over an hour - to no avail
> > >
> > > Here's what make reports with debugging on if that helps anyone...
> >
> > Above all, why do you compile that driver??
> > You'd better to use --with-cards option.
>
> Because I still haven't worked out how to get it to build the sh drivers
> and I was just testing it building 'all'
Then better to fix that first. Why don't you post the patch you're
trying?
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [ALSA - driver 0002004]: Via say unknown codec on FSC Amilo 1667G
From: bugtrack @ 2006-04-07 18:21 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=2004>
======================================================================
Reported By: deathlove23
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 2004
Category: PCI - via82xx
Reproducibility: always
Severity: feature
Priority: normal
Status: new
Distribution: Gentoo
Kernel Version: 2.6.16
======================================================================
Date Submitted: 04-05-2006 18:40 CEST
Last Modified: 04-07-2006 20:21 CEST
======================================================================
Summary: Via say unknown codec on FSC Amilo 1667G
Description:
Hello,
I have a Notebook from FSC: Amilo 1667G
and is get thes messages in boot bzw. on dmesg:
---
ALSA device list:
#0: VIA 8237 with unknown codec at 0xc800, irq 50
---
my Alsa Kernel config is:
---
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_RAWMIDI=y
CONFIG_SND_RTCTIMER=y
CONFIG_SND_MPU401_UART=y
CONFIG_SND_AC97_CODEC=y
CONFIG_SND_AC97_BUS=y
CONFIG_SND_VIA82XX=y
---
and my lspci -vv is:
---
00:11.5 Multimedia audio controller: VIA Technologies, Inc.
VT8233/A/8235/8237 AC97 Audio Controller (rev 60)
Subsystem: Fujitsu Siemens Computer GmbH Unknown device 1093
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
Interrupt: pin C routed to IRQ 50
Region 0: I/O ports at c800 [size=256]
Capabilities: [c0] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
---
can you my soundcard to the ID lists eg. another Amilio's?
Thanks
Alex - Deathlove23
======================================================================
----------------------------------------------------------------------
tiwai - 04-07-06 19:21
----------------------------------------------------------------------
Please upload the contents of /proc/asound/card0/codec97#0/* files.
----------------------------------------------------------------------
deathlove23 - 04-07-06 20:21
----------------------------------------------------------------------
thanks for you replay, i upload the Files.
Issue History
Date Modified Username Field Change
======================================================================
04-05-06 18:40 deathlove23 New Issue
04-05-06 18:40 deathlove23 Distribution => Gentoo
04-05-06 18:40 deathlove23 Kernel Version => 2.6.16
04-07-06 19:21 tiwai Note Added: 0009145
04-07-06 20:17 deathlove23 Issue Monitored: deathlove23
04-07-06 20:19 deathlove23 File Added: ac97#0-0
04-07-06 20:19 deathlove23 File Added: ac97#0-0+regs
04-07-06 20:19 deathlove23 Issue End Monitor: deathlove23
04-07-06 20:21 deathlove23 Note Added: 0009155
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: wierd failures from -mm1
From: Martin Bligh @ 2006-04-07 18:20 UTC (permalink / raw)
To: Dave Hansen; +Cc: Andrew Morton, linux-kernel, Andy Whitcroft
In-Reply-To: <1144433309.24221.7.camel@localhost.localdomain>
Dave Hansen wrote:
> On Fri, 2006-04-07 at 11:05 -0700, Martin Bligh wrote:
>
>>http://test.kernel.org/abat/27596/debug/console.log
>>Hangs after bringing up cpus.
>
>
> See attached patch. It fixes curly.
Splendid -thanks. This may well fix the first two ... I think the reiser
thing is likely still borked though.
M.
> -- Dave
>
>
> ------------------------------------------------------------------------
>
> Subject:
> [PATCH 2.6.17-rc1-mm1] sched_domain-handle-kmalloc-failure-fix
> From:
> Lee Schermerhorn <Lee.Schermerhorn@hp.com>
> Date:
> Thu, 06 Apr 2006 15:58:47 -0400
> To:
> linux-kernel <linux-kernel@vger.kernel.org>
>
> To:
> linux-kernel <linux-kernel@vger.kernel.org>
> CC:
> Andrew Morton <akpm@osdl.org>, Eric Whitney <eric.whitney@hp.com>
>
>
> [PATCH] sched_domain-handle-kmalloc-failure-fix
>
> 2.6.17-rc1-mm1 hangs during boot on HP rx8620 and dl585 -- both 4 node
> NUMA platforms. Problem is in build_sched_domains() setting up the
> sched_group_nodes[] lists, resulting from patch:
> sched_domain-handle-kmalloc-failure.patch
>
> The referenced patch does not propagate the "next" pointer from the head
> of the list, resulting in a loop between the last 2 groups in the list.
> This causes a tight loop/hang in init_numa_sched_groups_power() because
> 'sg->next' never == 'group_head' when you have > 2 nodes.
>
> This patch seems to fix the problem.
>
> Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com>
>
> Index: linux-2.6.17-rc1-mm1/kernel/sched.c
> ===================================================================
> --- linux-2.6.17-rc1-mm1.orig/kernel/sched.c 2006-04-06 15:18:32.000000000 -0400
> +++ linux-2.6.17-rc1-mm1/kernel/sched.c 2006-04-06 15:20:49.000000000 -0400
> @@ -6360,7 +6360,7 @@ static int build_sched_domains(const cpu
> }
> sg->cpu_power = 0;
> sg->cpumask = tmp;
> - sg->next = prev;
> + sg->next = prev->next;
> cpus_or(covered, covered, tmp);
> prev->next = sg;
> prev = sg;
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* Re: Trying again with cross compile
From: Adrian McMenamin @ 2006-04-07 18:18 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5h4q151ckb.wl%tiwai@suse.de>
On Fri, 2006-04-07 at 20:10 +0200, Takashi Iwai wrote:
> At Fri, 07 Apr 2006 19:07:01 +0100,
> Adrian McMenamin wrote:
> >
> > On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> >
> > > Maybe not yet? The fix is simple as below.
> > >
> > >
> > > Takashi
> > >
> > >
> > > diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> > > --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> > > +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> > > @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
> > >
> > > #define snd_power_lock(card) do { (void)(card); } while (0)
> > > #define snd_power_unlock(card) do { (void)(card); } while (0)
> > > -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> > > +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> > > #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> > > #define snd_power_change_state(card, state) do { (void)(card); } while (0)
> > >
> > >
> >
> > I've patched and everything seems to be fine expect that the build gets
> > wedged on hpi6000
> >
> > I've even tried leaving if for over an hour - to no avail
> >
> > Here's what make reports with debugging on if that helps anyone...
>
> Above all, why do you compile that driver??
> You'd better to use --with-cards option.
Because I still haven't worked out how to get it to build the sh drivers
and I was just testing it building 'all'
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: Trying again with cross compile
From: Takashi Iwai @ 2006-04-07 18:10 UTC (permalink / raw)
To: Adrian McMenamin; +Cc: alsa-devel
In-Reply-To: <1144433221.9653.51.camel@localhost.localdomain>
At Fri, 07 Apr 2006 19:07:01 +0100,
Adrian McMenamin wrote:
>
> On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
>
> > Maybe not yet? The fix is simple as below.
> >
> >
> > Takashi
> >
> >
> > diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> > --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> > +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> > @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
> >
> > #define snd_power_lock(card) do { (void)(card); } while (0)
> > #define snd_power_unlock(card) do { (void)(card); } while (0)
> > -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> > +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> > #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> > #define snd_power_change_state(card, state) do { (void)(card); } while (0)
> >
> >
>
> I've patched and everything seems to be fine expect that the build gets
> wedged on hpi6000
>
> I've even tried leaving if for over an hour - to no avail
>
> Here's what make reports with debugging on if that helps anyone...
Above all, why do you compile that driver??
You'd better to use --with-cards option.
Takashi
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* [linux-lvm] logical extent (630) already mapped
From: Oliver Hörold @ 2006-04-07 18:09 UTC (permalink / raw)
To: lvm mailinglist
hi,
after using for some time lvm without any problems, my lvm system
generates after rebooting some strang errors.
the problems look like these:
http://www.copilotconsulting.com/mail-archives/linux-lvm.2005/msg00025.html
but the solution doesnt work for me.
summery:
system suse 10.1, boot drive sata /dev/sda (no lvm)
lvm composed of 8 ide drives (/dev/hda to /dev/hdh)
worked for some time, but i think the auto-update of suse screwed the
lvm.
pvscan, pvdisplay, lvsvan and vgscan all generate errors. i have no idea
where the "logic extend" is already mapped. i cant diagnose the error.
i think the pv are still intact, but i dont knwo how to put em back
together.
here are some of the errors:
tokyoo:/tmp # pvscan
/dev/sdb: open failed: Kein Medium gefunden (No Media found)
/dev/sdc: open failed: Kein Medium gefunden
/dev/sdd: open failed: Kein Medium gefunden
/dev/sde: open failed: Kein Medium gefunden
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
No matching physical volumes found
tokyoo:/tmp # pvdisplay
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
remark: with every commad that generates an error i get the "No Media
found" error block f�r the /dev/sdx devices. i removed them to save
space.
but strangely the single drives are recognised as proper PV:
tokyoo:/tmp # pvdisplay /dev/hda1
--- Physical volume ---
PV Name /dev/hda1
VG Name system
PV Size 111,78 GB / not usable 0
Allocatable yes
PE Size (KByte) 16384
Total PE 7154
Free PE 7154
Allocated PE 0
PV UUID afdGTQ-95Qv-f3oL-anWh-V2LO-PKIf-eXTbRb
[...]
some other things i tried:
tokyoo:/tmp # lvscan
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # lvdisplay
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # lvdisplay system
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # vgscan
Reading all physical volumes. This may take a while...
logical extent (630) already mapped.
Couldn't fill logical volume maps.
logical extent (630) already mapped.
Couldn't fill logical volume maps.
Volume group "system" not found
tokyoo:/tmp # vgcreate
erwin /dev/hda1 /dev/hdc1 /dev/hdd1 /dev/hde1 /dev/hdf1 /dev/hdg1 /dev/hdh1
Physical volume '/dev/hda1' is already in volume group 'system'
Unable to add physical volume '/dev/hda1' to volume group 'erwin'.
^ permalink raw reply
* [Qemu-devel] Patch for minor qemu heap corruption bug when the console is zero width
From: Kenneth Duda @ 2006-04-07 18:08 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <6fe044190604060153i6b43333dlec41c663f2229cd3@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 522 bytes --]
Hi everyone, here is another patch for a much less significant bug. If
your "vc" console width is 0, qemu corrupts the heap (because it
writes one character into a screen buffer that's been malloc'ed as
size 0). I don't know if this bug ever causes problems in practice
--- I picked it up using mcheck() when debugging heap corruption due
to various slirp bugs. Anyway, this trivial patch fixes the trivial
bug. Feedback on what I can do to get patches like this applied most
appreciated!
Thanks,
-Ken
[-- Attachment #2: qemu-zero-width-console.patch --]
[-- Type: text/plain, Size: 664 bytes --]
diff -burN qemu-snapshot-2006-03-27_23.orig/console.c qemu-snapshot-2006-03-27_23/console.c
--- qemu-snapshot-2006-03-27_23.orig/console.c 2006-03-11 07:35:30.000000000 -0800
+++ qemu-snapshot-2006-03-27_23/console.c 2006-04-06 00:25:41.000000000 -0700
@@ -407,7 +407,8 @@
if (s->width < w1)
w1 = s->width;
- cells = qemu_malloc(s->width * s->total_height * sizeof(TextCell));
+ cells = qemu_malloc((s->width * s->total_height + 1) * sizeof(TextCell));
+ /* Add one extra in case s->width is 0, so we can still store one character. */
for(y = 0; y < s->total_height; y++) {
c = &cells[y * s->width];
if (w1 > 0) {
^ permalink raw reply
* [Bluez-devel] Discoverabe Mode - GIAC or LIAC
From: Renan @ 2006-04-07 18:07 UTC (permalink / raw)
To: bluez-devel
[-- Attachment #1: Type: text/plain, Size: 212 bytes --]
Hello everyone!!!
Does anybody know how to set the discoverable mode for a device under
Linux?
How to set the LIAC/GIAC mode for a device?
Thanks in advance.
Renan Martins
renan@atlantico.com.br
[-- Attachment #2: Type: text/html, Size: 5366 bytes --]
^ permalink raw reply
* Re: Trying again with cross compile
From: Adrian McMenamin @ 2006-04-07 18:07 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hmzextpl7.wl%tiwai@suse.de>
On Fri, 2006-04-07 at 16:41 +0200, Takashi Iwai wrote:
> Maybe not yet? The fix is simple as below.
>
>
> Takashi
>
>
> diff -r fd751f7a6395 -r 6cddb34dad21 include/core.h
> --- a/include/core.h Thu Apr 6 15:23:55 2006 +0200
> +++ b/include/core.h Thu Apr 6 15:26:05 2006 +0200
> @@ -176,7 +176,7 @@ int snd_power_wait(struct snd_card *card
>
> #define snd_power_lock(card) do { (void)(card); } while (0)
> #define snd_power_unlock(card) do { (void)(card); } while (0)
> -static inline int snd_power_wait(struct snd_card *card, unsigned int state, struct file *file) { return 0; }
> +static inline int snd_power_wait(struct snd_card *card, unsigned int state) { return 0; }
> #define snd_power_get_state(card) SNDRV_CTL_POWER_D0
> #define snd_power_change_state(card, state) do { (void)(card); } while (0)
>
>
I've patched and everything seems to be fine expect that the build gets
wedged on hpi6000
I've even tried leaving if for over an hour - to no avail
Here's what make reports with debugging on if that helps anyone...
Successfully remade target file
`/home/adrian/alsa-driver/pci/asihpi/hpi4000.o'.
Considering target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
File `/home/adrian/alsa-driver/pci/asihpi/hpi6000.o' does not
exist.
Looking for an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Trying pattern rule with stem `hpi6000.o'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o_shipped'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Trying rule prerequisite `FORCE'.
Found an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Considering target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Looking for an implicit rule for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c_shipped'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c,v'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.c,v'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.c'.
Trying pattern rule with stem `hpi6000.c'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.c'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y_shipped'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.y,v'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.y,v'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.y'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.y'.
Trying pattern rule with stem `hpi6000.y'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.y'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l_shipped'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.l,v'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.l,v'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.l'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.l'.
Trying pattern rule with stem `hpi6000.l'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.l'.
Trying pattern rule with stem `hpi6000'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Looking for a rule with intermediate file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
Avoiding implicit rule recursion.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w_shipped'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w,v'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.w,v'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/RCS/hpi6000.w'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/s.hpi6000.w'.
Trying pattern rule with stem `hpi6000.w'.
Trying implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/SCCS/s.hpi6000.w'.
Trying pattern rule with stem `hpi6000'.
Rejecting impossible implicit prerequisite
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.w'.
No implicit rule found for
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Finished prerequisites of target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
No need to remake target
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.c'.
Pruning file `FORCE'.
Finished prerequisites of target file
`/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Must remake target `/home/adrian/alsa-driver/pci/asihpi/hpi6000.o'.
Putting child 0x080e9bd8 (/home/adrian/alsa-driver/pci/asihpi/hpi6000.o)
PID 19527 on the chain.
Live child 0x080e9bd8 (/home/adrian/alsa-driver/pci/asihpi/hpi6000.o)
PID 19527
CC [M] /home/adrian/alsa-driver/pci/asihpi/hpi6000.o
It sticks here for ever - though top reports cc1 is still active
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
* Re: chmod u+s confusion
From: Chris Largret @ 2006-04-07 18:06 UTC (permalink / raw)
To: David Fierbaugh; +Cc: linux-newbie
In-Reply-To: <200604070842.19837.david@fierbaugh.org>
On Fri, 2006-04-07 at 08:42 +0000, David Fierbaugh wrote:
> I'd have to actually do a little playing around to make sure, but I believe
> that whoami is specifically written to NOT take SUID into account. It figures
> out exactly who ran the process which called it.
>
> This prevents faking out whoami into saying everyone is root.
I probably should have mentioned that this was just a PoC for what I was
trying to do. I'm actually trying to have the script create a file
someplace like /etc/cron.hourly. It has limited uses (and only my user
and root will be able to run it -- root group), but the script is
refusing to create the file.
> Why?
> Let's say you have a script that runs whoami to determine what
> access/control/etc a user should be given. If an attacker could manage to
> fake whoami into always saying the user was root by using suid, then they now
> have administrative access to whatever that script does.
>
> This would be a bad thing.
>
> You might also want to take a look at /bin/id
/usr/bin/id (where my id program is placed) still returns my username.
Thanks for the reply, but I'm still stumped :)
> > $ echo -e '#!/bin/sh\n\nwhoami'>whoami.sh
> > # chown root:root whoami.sh
> > # chmod 4755 whoami.sh
> > $ ./whoami.sh
> > chris
> > # chmod u+s `which whoami`
> > $ whoami
> > root
--
Chris Largret <http://daga.dyndns.org>
-
To unsubscribe from this list: send the line "unsubscribe linux-newbie" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.linux-learn.org/faqs
^ permalink raw reply
* wierd failures from -mm1
From: Martin Bligh @ 2006-04-07 18:05 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, Andy Whitcroft
I hadn't mailed this out for a while, cause we weren't sure if it was
-mm or a testing glitch, but there's been no -git releases, so Andy
reran -mm to double check, and it still seems to be there. a subsequent
test of rc1 + cons patches didn't hit this ... I think -mm has issues ;-)
Look at the 2.6.17-rc1-mm1 column from: http://test.kernel.org/
Drilling down into the console logs:
http://test.kernel.org/abat/27597/debug/console.log
Hangs after testing NMI watchdog.
http://test.kernel.org/abat/27596/debug/console.log
Hangs after bringing up cpus.
http://test.kernel.org/abat/27598/debug/console.log
http://test.kernel.org/abat/27593/debug/console.log
Both fail with reiserfs fsck errors; at first sight look like just dirty
root partitions, but I don't think they are.
Filesystem is clean
Failed to lock the process to fsck the mounted ro partition. Bad address.
fsck.reiserfs /dev/sda3 failed (status 0x8). Run manually!
Note that it's actually saying it's clean.
^ permalink raw reply
* [Qemu-devel] Patch for sending large (>4k) packets through qemu/slirp
From: Kenneth Duda @ 2006-04-07 18:05 UTC (permalink / raw)
To: qemu-devel
In-Reply-To: <6fe044190604060153g1e642409p9682c21a774a21df@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 846 bytes --]
Hi everyone,
I have patches for a few bugs in qemu, and am new to the list --- if
anyone could clue me in on the best way to get patches applied to the
qemu mainline, that would be great.
This patch fixes three problems (actually all in slirp) with sending
large packets from guest to host in qemu-0.8.0.20060327:
(1) the code in slirp's ip_reass() reads a next pointer out an mbuf
after freeing it via m_cat().
(2) the code in slirp's m_inc() calls realloc() on a large mbuf, but
fails to adjust m_data to point to the new allocation (see
http://lists.gnu.org/archive/html/qemu-devel/2005-05/msg00228.html).
(3) there are many places within ip_input(), ip_reass(), udp_input(),
etc., that treat ip_len and ip_off as though they were declared
unsigned, when in fact they have been declared signed.
Thanks,
-Ken
[-- Attachment #2: qemu-slirp-reassembly-bug.patch --]
[-- Type: text/plain, Size: 466 bytes --]
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 06:02:52.000000000 +0000
@@ -344,8 +344,8 @@
while (q != (struct ipasfrag *)fp) {
struct mbuf *t;
t = dtom(q);
- m_cat(m, t);
q = (struct ipasfrag *) q->ipf_next;
+ m_cat(m, t);
}
/*
[-- Attachment #3: qemu-slirp-mbuf-bug.patch --]
[-- Type: text/plain, Size: 887 bytes --]
diff -BurN qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c qemu-snapshot-2006-03-27_23/slirp/mbuf.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/mbuf.c 2004-04-22 00:10:47.000000000 +0000
+++ qemu-snapshot-2006-03-27_23/slirp/mbuf.c 2006-04-05 13:03:03.000000000 +0000
@@ -146,18 +146,19 @@
struct mbuf *m;
int size;
{
+ int datasize;
+
/* some compiles throw up on gotos. This one we can fake. */
if(m->m_size>size) return;
if (m->m_flags & M_EXT) {
- /* datasize = m->m_data - m->m_ext; */
+ datasize = m->m_data - m->m_ext;
m->m_ext = (char *)realloc(m->m_ext,size);
/* if (m->m_ext == NULL)
* return (struct mbuf *)NULL;
*/
- /* m->m_data = m->m_ext + datasize; */
+ m->m_data = m->m_ext + datasize;
} else {
- int datasize;
char *dat;
datasize = m->m_data - m->m_dat;
dat = (char *)malloc(size);
[-- Attachment #4: qemu-slirp-32k-packets.patch --]
[-- Type: text/plain, Size: 4433 bytes --]
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip.h qemu-snapshot-2006-03-27_23/slirp/ip.h
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip.h 2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip.h 2006-04-06 00:28:49.000000000 -0700
@@ -79,6 +79,11 @@
* We declare ip_len and ip_off to be short, rather than u_short
* pragmatically since otherwise unsigned comparisons can result
* against negative integers quite easily, and fail in subtle ways.
+ *
+ * The only problem with the above theory is that these quantities
+ * are in fact unsigned, and sorting fragments by a signed version
+ * of ip_off doesn't work very well, nor does length checks on
+ * ip packets with a signed version of their length!
*/
struct ip {
#ifdef WORDS_BIGENDIAN
@@ -101,6 +106,9 @@
struct in_addr ip_src,ip_dst; /* source and dest address */
};
+#define IP_OFF(ip) (*(u_int16_t *)&((ip)->ip_off))
+#define IP_LEN(ip) (*(u_int16_t *)&((ip)->ip_len))
+
#define IP_MAXPACKET 65535 /* maximum packet size */
/*
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c qemu-snapshot-2006-03-27_23/slirp/ip_input.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/ip_input.c 2004-04-21 17:10:47.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/ip_input.c 2006-04-06 00:32:19.000000000 -0700
@@ -111,7 +111,7 @@
* Convert fields to host representation.
*/
NTOHS(ip->ip_len);
- if (ip->ip_len < hlen) {
+ if (IP_LEN(ip) < hlen) {
ipstat.ips_badlen++;
goto bad;
}
@@ -124,13 +124,13 @@
* Trim mbufs if longer than we expect.
* Drop packet if shorter than we expect.
*/
- if (m->m_len < ip->ip_len) {
+ if (m->m_len < IP_LEN(ip)) {
ipstat.ips_tooshort++;
goto bad;
}
/* Should drop packet if mbuf too long? hmmm... */
- if (m->m_len > ip->ip_len)
- m_adj(m, ip->ip_len - m->m_len);
+ if (m->m_len > IP_LEN(ip))
+ m_adj(m, IP_LEN(ip) - m->m_len);
/* check ip_ttl for a correct ICMP reply */
if(ip->ip_ttl==0 || ip->ip_ttl==1) {
@@ -191,7 +191,7 @@
* or if this is not the first fragment,
* attempt reassembly; if it succeeds, proceed.
*/
- if (((struct ipasfrag *)ip)->ipf_mff & 1 || ip->ip_off) {
+ if (((struct ipasfrag *)ip)->ipf_mff & 1 || IP_OFF(ip)) {
ipstat.ips_fragments++;
ip = ip_reass((struct ipasfrag *)ip, fp);
if (ip == 0)
@@ -281,7 +281,7 @@
*/
for (q = (struct ipasfrag *)fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *)q->ipf_next)
- if (q->ip_off > ip->ip_off)
+ if (IP_OFF(q) > IP_OFF(ip))
break;
/*
@@ -290,10 +290,10 @@
* segment. If it provides all of our data, drop us.
*/
if (q->ipf_prev != (ipasfragp_32)fp) {
- i = ((struct ipasfrag *)(q->ipf_prev))->ip_off +
- ((struct ipasfrag *)(q->ipf_prev))->ip_len - ip->ip_off;
+ i = IP_OFF((struct ipasfrag *)(q->ipf_prev)) +
+ IP_LEN((struct ipasfrag *)(q->ipf_prev)) - IP_OFF(ip);
if (i > 0) {
- if (i >= ip->ip_len)
+ if (i >= IP_LEN(ip))
goto dropfrag;
m_adj(dtom(ip), i);
ip->ip_off += i;
@@ -305,9 +305,9 @@
* While we overlap succeeding segments trim them or,
* if they are completely covered, dequeue them.
*/
- while (q != (struct ipasfrag *)fp && ip->ip_off + ip->ip_len > q->ip_off) {
- i = (ip->ip_off + ip->ip_len) - q->ip_off;
- if (i < q->ip_len) {
+ while (q != (struct ipasfrag *)fp && IP_OFF(ip) + IP_LEN(ip) > IP_OFF(q)) {
+ i = (IP_OFF(ip) + IP_LEN(ip)) - IP_OFF(q);
+ if (i < IP_LEN(q)) {
q->ip_len -= i;
q->ip_off += i;
m_adj(dtom(q), i);
@@ -327,9 +327,9 @@
next = 0;
for (q = (struct ipasfrag *) fp->ipq_next; q != (struct ipasfrag *)fp;
q = (struct ipasfrag *) q->ipf_next) {
- if (q->ip_off != next)
+ if (IP_OFF(q) != next)
return (0);
- next += q->ip_len;
+ next += IP_LEN(q);
}
if (((struct ipasfrag *)(q->ipf_prev))->ipf_mff & 1)
return (0);
diff -burN qemu-snapshot-2006-03-27_23.orig/slirp/udp.c qemu-snapshot-2006-03-27_23/slirp/udp.c
--- qemu-snapshot-2006-03-27_23.orig/slirp/udp.c 2006-04-06 00:24:30.000000000 -0700
+++ qemu-snapshot-2006-03-27_23/slirp/udp.c 2006-04-06 00:32:55.000000000 -0700
@@ -111,12 +111,12 @@
*/
len = ntohs((u_int16_t)uh->uh_ulen);
- if (ip->ip_len != len) {
- if (len > ip->ip_len) {
+ if (IP_LEN(ip) != len) {
+ if (len > IP_LEN(ip)) {
udpstat.udps_badlen++;
goto bad;
}
- m_adj(m, len - ip->ip_len);
+ m_adj(m, len - IP_LEN(ip));
ip->ip_len = len;
}
^ permalink raw reply
* Re: fs/binfmt_elf.c:maydump()
From: Daniel Jacobowitz @ 2006-04-07 18:02 UTC (permalink / raw)
To: David S. Miller; +Cc: linux-kernel
In-Reply-To: <20060406.221807.114721185.davem@davemloft.net>
On Thu, Apr 06, 2006 at 10:18:07PM -0700, David S. Miller wrote:
> How about something like the following patch? If it's executable
> and not written to, skip it. This would skip the main executable
> image and all text segments of the shared libraries mapped in.
Will this dump text segments that have been COW'd for the purposes of
inserting a breakpoint?
It's just a question of goals, I guess. We could dump code, but it's
rarely useful, so historically we didn't. Similarly, we could dump
mapped data from shared memory, but it can be huge and is rarely
useful, so generally we don't.
--
Daniel Jacobowitz
CodeSourcery
^ permalink raw reply
* Re: [PATCH 2.6.17-rc1-mm1] sched_domain-handle-kmalloc-failure-fix
From: Dave Hansen @ 2006-04-07 18:01 UTC (permalink / raw)
To: Lee Schermerhorn; +Cc: linux-kernel, Andrew Morton, Eric Whitney
In-Reply-To: <1144353528.5162.190.camel@localhost.localdomain>
On Thu, 2006-04-06 at 15:58 -0400, Lee Schermerhorn wrote:
> 2.6.17-rc1-mm1 hangs during boot on HP rx8620 and dl585 -- both 4 node
> NUMA platforms. Problem is in build_sched_domains() setting up the
> sched_group_nodes[] lists, resulting from patch:
> sched_domain-handle-kmalloc-failure.patch
>
> The referenced patch does not propagate the "next" pointer from the head
> of the list, resulting in a loop between the last 2 groups in the list.
> This causes a tight loop/hang in init_numa_sched_groups_power() because
> 'sg->next' never == 'group_head' when you have > 2 nodes.
Wow. I'm incredibly impressed that you tracked that down. I can't
believe how horribly unintelligible that code is.
I ran into the same freeze on a 4-node NUMA-Q. Your patch fixed it.
Is there any good reason that sched domains has to roll its own linked
lists? Why not use list_heads? Seems like it would avoid crappy
problems like this.
-- Dave
^ permalink raw reply
* Re: [Xenomai-core] Frozen timer IRQ - now traced with kgdb :)
From: Jan Kiszka @ 2006-04-07 18:00 UTC (permalink / raw)
To: Philippe Gerum; +Cc: xenomai-core
In-Reply-To: <443695BB.6030502@domain.hid>
[-- Attachment #1.1: Type: text/plain, Size: 2000 bytes --]
Philippe Gerum wrote:
> Philippe Gerum wrote:
>> Jan Kiszka wrote:
>>
>>>
>>> BTW, that trace hacking reminds me that we should really think about
>>> making a kernel debugger run. I recently noticed that latest kgdb
>>> applied with a single failing hunk on top of ipipe (2.6.15, x86). Maybe
>>> it is just about making kgdb's irq-locks ipipe-aware and bypassing the
>>> ipipe for int3 and the serial IRQ (so that ipipe can be debugged as
>>> well) and catching the relevant exceptions. Hmm, the debugger seems to
>>> get initialised in the "early" stage. Is this before or after ipipe
>>> setup?
>>>
>>
>> It depends. If "kgdbwait" is set in the bootargs to halt the kernel
>> waiting for the remote GDB to connect to the target, kgdb starts
>> before the ipipe. Otherwise, it's a late init, and kgdb starts after
>> the ipipe is fully initialized.
>>
>
> Basically, kgdb could start before the i-pipe as soon as a breakpoint is
> hit before the latter is enabled in init/main.c.
>
Yep, I dug deeper meanwhile and also came across this.
I already have a trivial hack running here. The most tricky part for me
was to learn quilt, but now I start to love it :). Here is a snapshot
series for 2.6.15.5:
<kgdb series from CVS>
prepare-ipipe-x86.patch
adeos-ipipe-2.6.15-i386-1.2-01.patch
kgdb-ipipe-x86.patch
I'm currently wondering if it makes sense to register a kgdb domain and
"officially" capture all involved IRQs and events. So far the serial
line IRQ is hard-coded (should be retrieved from some internal kgdb
structure later). Anyway, it seems to work quite well, I'm currently
stepping through a network IRQ at ipipe-level.
While playing with this tool a bit, displaying the the ipipe structures,
and thinking about the original problem again, I wondered what could
cause a temporary (as I think to found out now) stalled xeno domain
without locking up the system? Some irq-lock leaks at driver level (i.e.
inside our own code)?
Jan
[-- Attachment #1.2: kgdb-ipipe-x86.patch --]
[-- Type: text/plain, Size: 3997 bytes --]
Index: linux-2.6.15.5/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/entry.S 2006-04-07 16:53:39.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/entry.S 2006-04-07 16:53:40.000000000 +0200
@@ -194,7 +194,7 @@
.previous
-ENTRY(ret_from_fork)
+KPROBE_ENTRY(ret_from_fork)
STI_COND_HW
pushl %eax
call schedule_tail
@@ -582,7 +582,7 @@
PUSH_XCODE(do_simd_coprocessor_error)
jmp error_code
-ENTRY(device_not_available)
+KPROBE_ENTRY(device_not_available)
pushl $-1 # mark this as an int
SAVE_ALL
DIVERT_EXCEPTION(device_not_available)
@@ -767,7 +767,7 @@
jmp error_code
#endif
-ENTRY(spurious_interrupt_bug)
+KPROBE_ENTRY(spurious_interrupt_bug)
pushl $0
PUSH_XCODE(do_spurious_interrupt_bug)
jmp error_code
Index: linux-2.6.15.5/kernel/kgdb.c
===================================================================
--- linux-2.6.15.5.orig/kernel/kgdb.c 2006-04-07 16:30:51.000000000 +0200
+++ linux-2.6.15.5/kernel/kgdb.c 2006-04-07 16:57:35.000000000 +0200
@@ -740,7 +740,7 @@
unsigned long flags;
int processor;
- local_irq_save(flags);
+ local_irq_save_hw(flags);
processor = smp_processor_id();
kgdb_info[processor].debuggerinfo = regs;
kgdb_info[processor].task = current;
@@ -770,7 +770,7 @@
/* Signal the master processor that we are done */
atomic_set(&procindebug[processor], 0);
spin_unlock(&slavecpulocks[processor]);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
#endif
@@ -1033,7 +1033,7 @@
* Interrupts will be restored by the 'trap return' code, except when
* single stepping.
*/
- local_irq_save(flags);
+ local_irq_save_hw(flags);
/* Hold debugger_active */
procid = smp_processor_id();
@@ -1056,7 +1056,7 @@
if (atomic_read(&cpu_doing_single_step) != -1 &&
atomic_read(&cpu_doing_single_step) != procid) {
atomic_set(&debugger_active, 0);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
goto acquirelock;
}
@@ -1556,7 +1556,7 @@
kgdb_restore:
/* Free debugger_active */
atomic_set(&debugger_active, 0);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
return error;
}
@@ -1925,9 +1925,9 @@
if (!kgdb_connected || atomic_read(&debugger_active) != 0)
return 0;
if ((code == SYS_RESTART) || (code == SYS_HALT) || (code == SYS_POWER_OFF)){
- local_irq_save(flags);
+ local_irq_save_hw(flags);
put_packet("X00");
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
return NOTIFY_DONE;
}
@@ -1942,9 +1942,9 @@
if (!kgdb_connected || atomic_read(&debugger_active) != 0)
return;
- local_irq_save(flags);
+ local_irq_save_hw(flags);
kgdb_msg_write(s, count);
- local_irq_restore(flags);
+ local_irq_restore_hw(flags);
}
static struct console kgdbcons = {
Index: linux-2.6.15.5/arch/i386/kernel/ipipe-root.c
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/ipipe-root.c 2006-04-07 16:53:39.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/ipipe-root.c 2006-04-07 17:48:00.000000000 +0200
@@ -111,6 +111,15 @@
#endif /* CONFIG_X86_LOCAL_APIC */
+#ifdef CONFIG_KGDB
+static struct ipipe_domain kgdb_domain;
+
+static void kgdb_domain_entry(void)
+{
+
+}
+#endif /* CONFIG_KGDB */
+
/* __ipipe_enable_pipeline() -- We are running on the boot CPU, hw
interrupts are off, and secondary CPUs are still lost in space. */
@@ -248,6 +257,10 @@
ipipe_root_domain->irqs[IPIPE_SERVICE_IPI2].control &= ~IPIPE_SYSTEM_MASK;
ipipe_root_domain->irqs[IPIPE_SERVICE_IPI3].control &= ~IPIPE_SYSTEM_MASK;
#endif /* CONFIG_X86_LOCAL_APIC */
+
+#ifdef CONFIG_KGDB
+ ipipe_control_irq(4, 0, IPIPE_HANDLE_MASK|IPIPE_STICKY_MASK|IPIPE_SYSTEM_MASK);
+#endif /* CONFIG_KGDB */
}
static inline void __fixup_if(struct pt_regs *regs)
[-- Attachment #1.3: prepare-ipipe-x86.patch --]
[-- Type: text/plain, Size: 838 bytes --]
Index: linux-2.6.15.5/arch/i386/kernel/entry.S
===================================================================
--- linux-2.6.15.5.orig/arch/i386/kernel/entry.S 2006-04-07 16:42:54.000000000 +0200
+++ linux-2.6.15.5/arch/i386/kernel/entry.S 2006-04-07 16:47:23.000000000 +0200
@@ -123,7 +123,7 @@
.previous
-KPROBE_ENTRY(ret_from_fork)
+ENTRY(ret_from_fork)
pushl %eax
call schedule_tail
GET_THREAD_INFO(%ebp)
@@ -470,7 +470,7 @@
pushl $do_simd_coprocessor_error
jmp error_code
-KPROBE_ENTRY(device_not_available)
+ENTRY(device_not_available)
pushl $-1 # mark this as an int
SAVE_ALL
movl %cr0, %eax
@@ -652,7 +652,7 @@
jmp error_code
#endif
-KPROBE_ENTRY(spurious_interrupt_bug)
+ENTRY(spurious_interrupt_bug)
pushl $0
pushl $do_spurious_interrupt_bug
jmp error_code
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply
* checking write_cached_data return status inside _release and _flush?
From: Massimiliano Galanti @ 2006-04-07 18:03 UTC (permalink / raw)
To: linux-mtd
hi!
i experienced some corruption of data on flash memories i am using, and
discovered that this is related to these functions in mtdblock.c:
static int mtdblock_release(struct mtd_blktrans_dev *mbd)
static int mtdblock_flush(struct mtd_blktrans_dev *dev)
not checking the return value of the function:
write_cached_data(mtdblk)
i fixed that by checking the return value inside a while cycle but is
there any particular reason the original code is written that way?
Thank you.
--
Massimiliano Galanti
-IM-----------------------
MSN: viperzed@hotmail.com
Yahoo: massimilianogalanti
ICQ: 227544335
Skype: massimilianogalanti
--------------------------
^ permalink raw reply
* Re: [PATCH 0/5] clocksource patches
From: john stultz @ 2006-04-07 17:57 UTC (permalink / raw)
To: Roman Zippel; +Cc: linux-kernel, Andrew Morton
In-Reply-To: <Pine.LNX.4.64.0604031431220.25825@scrub.home>
On Mon, 2006-04-03 at 21:54 +0200, Roman Zippel wrote:
> Some more notes about the patches:
Hey Roman,
I'll reply to more specifics to the patches themselves, but I'll try to
get some general clarifications here.
> 1. generic clocksource updates:
> The most important change is probably clocksource_get_nsec_offset(), it
> returns the nsec part of the realtime clock and is adjusted once a second.
> Other time services can be built on top of this and also only have to be
> updated once a second via second_overflow(). I changed the return value to
> an unsigned long which gives us a 3 second window, which should be more
> than enough (anyone not allowing the timer interrupt for that long gets
> what he is asking for). This function should become clocksource specific
> so arch/clocks can optimize this function themselves (e.g. changing
> resolution, making some parameters constant). The generic clocksource
> currently still deals a bit too much with cycles, more of this should be
> moved into the clocksource drivers (using library functions).
I'm still not convinced for the need of clocksource specific
get_nsec_offset() functions. I really want to limit the clocksource
structure to be as stateless as possible and to only provide an
abstraction to the hardware counter below.
But clearly you are pretty concerned about it, so maybe could you share
the case you have in mind where it would be necessary?
> I'm also still interested in opinions about different possibilities to
> organize the clocksource infrastructure (although I'd more appreciate
> pro/con arguments than outright rejections). One possibility here would be
> to also shorten the function names a bit (clocksource_ is a lot to type :)
> ), cs_... or clock_... would IMO work too.
I *much* prefer the clarity of clocksource over the wear and tear typing
it might take on my fingers.
> 2. periodic clocksource update
> I updated the error adjustment algorithm to be more robust and optimized
> it a bit for the more common cases. It does everything in 64bit right now,
> which is fine for 64bit archs and it allows resolutions of less then
> 1nsec, but as long as e.g. gettimeofday() takes longer than 1nsec that's
> a little wasteful and nobody will see a difference if we "restrict" the
> resolution to 1nsec, which would allow to keep parts of it in 32bit.
>
> I also kept it separate from the do_timer() callback and simply created a
> new callback function, which archs can use. This makes it less likely to
> break any existing setup and even allows to coexists both methods until
> archs have been completely converted.
One of the reasons I did the significant rework of the TOD patches was
so that we could generically introduce the clocksource abstraction first
(using jiffies) for all arches. I feel this provides a much smoother
transition to the generic timekeeping code (and greatly reduces the
amount of CONFIG_GENERIC_TIME specific code), so I'm not sure I
understand why you want to go back to separate do_timer() functions.
I guess what I'm asking for is what was wrong with the way my code did
it? What breakage are you concerned about?
> Another general comment from an arch/driver specific perspective: right
> now everything is rather concentrated on getting the time, but AFAICT it's
> more common that the subsystem which is used to read the time is also used
> as timer (i.e. for the scheduler tick), this means the clocksource driver
> should also include the interrupt setup. Consequently this means the
> update callback isn't sufficient anymore and we need at least something
> like start/stop callbacks. This also means the jiffie clocksource becomes
> basically obsolete, since every arch already needs at least a basic
> clocksource to provide the scheduler tick (which is setup via
> time_init()).
> i386 is currently rather hardcoded to use the i8253 timer, but AFAIK it
> would be desirable to e.g. use HPET for that (especially for hrtimer).
> Something like TSC should internally use another clocksource to provide
> the timer interrupt. Anyway, i386 is quite a mess here right now and I can
> understand that you wanted to stay away from it with the generic
> gettimeofday infrastructure. :-)
> This is not important right now, but I wanted to mention it, it's IMO
> something to keep in mind for the next steps and what at least I'll
> look out for.
Thomas has already commented on this, and maybe we both misunderstand
what your suggesting here, but I am pretty hesitant to bind the clock
source / hardware interrupt timer code together. The reason for that is
in my experience w/ i386 (and I'll take my lumps for my part in the i386
timekeeping mess) the number of combinations of clock/timers is
something like: PIT/PIT, TSC/PIT, CYCLONE/PIT, ACPIPM/PIT, HPET/PIT,
TSC/HPET, HPET/HPET. And with some of Andi's patches x86-64 patches you
can do them all over /APIC.
My goal with the clocksources is to take just the counter aspect of any
hardware and export it generically so we can use that inside generic
code. I also would support a similar timer interrupt source abstraction,
like what Thomas has started in his clockevent patches in his hrt
patchset. The hope being we can later freely mix and match
clocksources/clockevents, allowing for some of the features needed for
dynamic ticks and virtualization.
Do these concerns make sense to you? Or was it something else you were
suggesting?
thanks
-john
^ permalink raw reply
* [PATCH] kdump: enable CONFIG_PROC_VMCORE by default
From: Vivek Goyal @ 2006-04-07 17:59 UTC (permalink / raw)
To: linux kernel mailing list, Fastboot mailing list
Cc: Morton Andrew Morton, Theodore Y Tso
o Everybody seems to be using /proc/vmcore as a method to access the kernel
crash dump. Hence probably it makes sense to enable CONFIG_PROC_VMCORE by
default if CONFIG_CRASH_DUMP is selected. This makes kdump configuration
further easier for a user.
Signed-off-by: Vivek Goyal <vgoyal@in.ibm.com>
---
fs/Kconfig | 1 +
1 files changed, 1 insertion(+)
diff -puN fs/Kconfig~kdump-enable-config-proc-vmcore-by-default fs/Kconfig
--- linux-2.6.17-rc1-1M/fs/Kconfig~kdump-enable-config-proc-vmcore-by-default 2006-04-07 12:44:29.000000000 -0400
+++ linux-2.6.17-rc1-1M-root/fs/Kconfig 2006-04-07 12:44:29.000000000 -0400
@@ -799,6 +799,7 @@ config PROC_KCORE
config PROC_VMCORE
bool "/proc/vmcore support (EXPERIMENTAL)"
depends on PROC_FS && EXPERIMENTAL && CRASH_DUMP
+ default y
help
Exports the dump image of crashed kernel in ELF format.
_
^ permalink raw reply
* RE: [RFC] Hypercalls from HVM guests
From: Petersson, Mats @ 2006-04-07 17:56 UTC (permalink / raw)
To: Keir Fraser; +Cc: Steve Ofsthun, xen-devel
> -----Original Message-----
> From: Keir Fraser [mailto:Keir.Fraser@cl.cam.ac.uk]
> Sent: 07 April 2006 18:40
> To: Petersson, Mats
> Cc: Steve Ofsthun; xen-devel@lists.xensource.com
> Subject: Re: [Xen-devel] [RFC] Hypercalls from HVM guests
>
>
> On 7 Apr 2006, at 18:24, Petersson, Mats wrote:
>
> > Good question - the way I'd say is to look at CPUID to see if it's
> > "GeunineIntel" or "AuthenticAMD", but I'm not sure if
> that's the BEST.
> > Of course, this assumes the code is already aware that it's
> in a HVM
> > environment, which I'm not sure if you know that or not at
> the point
> > you need to know if it's AMD or Intel... Of course, if CPUID is
> > intercepted, it may return other things (but it's against
> the "rules"
> > to lie about the brand of the CPU!)
>
> I like the idea of stealing some MSR space for this, and
> doing some initial interaction with the underlying hypervisor
> platform via RDMSR/WRMSR to known MSRs. We could 'read' an
> 'MSR' that would tell us the correct instruction sequence to
> do a hypercall (either directly, or maybe tell us a 'physical
> address' to read the hypercall transport information from --
> then we could have a hypercall transfer page just as we
> already do for paravirtualised guests).
>
> We just need to pick some MSRs that won't get used by Intel
> or AMD in the future. There's quite a lot of addressing space
> to carve up though.
> :-)
I like this idea, it's quirky and neat at the same time...
But isn't this going to be a catch-22 situation? We don't know if we're
virtualized or not, so we can't make hypercalls, and to find out, we
read an unimplemented MSR, which on REAL hardware causes a GP fault (and
probably also in SVM, since the map for SVM capturing MSR read/write
operations is very specific - at least if we use a MSR like 0xb0000000
or such).
Actually, maybe using an unused index for CPUID (e.g. 0xb0000000) would
be better? As that's defined to return all zero's, and not cause any
traps whatever value you use (unless the CPU is so old that it doesn't
support CPUID, of course).
--
Mats
>
> -- Keir
>
>
>
^ permalink raw reply
* Re: How to know when file data has been flushed into disk?
From: Zach Brown @ 2006-04-07 17:54 UTC (permalink / raw)
To: Xin Zhao; +Cc: linux-kernel, linux-fsdevel
In-Reply-To: <4ae3c140604070842x537353c4s9a60706c2a2d25d9@mail.gmail.com>
> If a program access data like this:
>
> 1. open the file
> 2. write a lot of data into this file
You don't say if this is an extending write or overwriting existing file
data. I'm going to assume extending writes so that data=ordered kicks in.
> 3. close the file
> So my questions are:
> 1. How will the file system be notified after all data has been
> flushed into disk?
Look at phase 2 in journal_commit_transaction(). The kjournald thread
issues the writeback of the file data by walking t_sync_datalist and
then waits for the writeback to complete by using wait_on_buffer()
before committing the transaction.
> 2. Unlike data=journal mode, in data=order mode, the data could be
> lost if system crashes when data is being flushed to disk. When system
> reboots, does journal contains the old meta data for undo?
No, ext3 isn't roll-backward. It doesn't store the *old* data in the
journal and undo the change if it fails halfway through. It's
roll-forward. It stores the *new* data in the journal and replays
complete transactions in the journal that weren't moved out to their
final place on disk at the time of the crash.
So if the machine reboots during the writeback phase then the
transaction won't be committed yet and recovery won't replay that
transaction from the journal. From the metadata's point of view the
file extension will never have happened.
> 3. Does sys_close() have to be blocked until all data and metadata
> are committed?
No, and neither does sys_getpid() :)
> to take subsequent operation. However, data flush could be failed. In
> this case, file system seems to mislead the application. Is this true?
No. The application has no grounds for assuming that a successful
close() has synced previous operations to disk. It's simply not part of
the API.
> If so, any solutions?
The application should rely on tools like fsync(), fdatasync(), O_SYNC,
mount -o sync, etc. Whatever suits it best.
- z
^ permalink raw reply
* Re: [PATCH/RFC] libata: turn on the ATAPI DMADIR support per word 62 (revised)
From: Jeff Garzik @ 2006-04-07 17:54 UTC (permalink / raw)
To: albertl; +Cc: linux-ide, Jonathan Benson, Tejun Heo, Carlos Pardo, Doug Maxey
In-Reply-To: <4436431C.8070800@tw.ibm.com>
Albert Lee wrote:
> Turn on the ATAPI DMADIR support if word 62 indicates it.
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
> (Revised to add mwdma/udma mask of word 62 per Jeff's comments.
> Need more testing once I get the SiI 3811, etc.)
>
> ATAPI DMADIR follow-up patch to turn on the DMADIR support automatically
> by checking identify device word 62. (Thanks for Jeff and Tejun's pointer.)
>
> According to Jonathan's test result, SiI 3611 (the current known bridge that
> requires the ATAPI DMADIR support) doesn't implement word 62. So, the
> atapi_dmadir parameter is preserved to enable the DMA DIR support manually as
> work around.
>
> Patch against upstream (c2a6585296009379e0f4eff39cdcb108b457ebf2).
> For your review, thanks.
I ACK the patch, though like I said, I would like to see this tested
first with some compliant devices.
Jeff
^ permalink raw reply
* Re: Serial console problem with Xen 3.0
From: Stephen C. Tweedie @ 2006-04-07 17:54 UTC (permalink / raw)
To: Michael Paesold; +Cc: Amitayu Das, xen-devel
In-Reply-To: <02de01c65a4b$6d03a400$d801a8c0@zaphod>
Hi,
On Fri, 2006-04-07 at 15:59 +0200, Michael Paesold wrote:
> Me too. Adding "sync_console" at least repaired the console *output*. I
> still have the problem that keyboard input does not reach linux
Serial input seems to have a bad interaction with ACPI plug-n-play.
Appending "pnpacpi=off" to the "module vmlinuz..." grub.conf line should
turn that off, and restore serial input.
--Stephen
^ permalink raw reply
* nice device running linux
From: Harald Dunkel @ 2006-04-07 17:52 UTC (permalink / raw)
To: linux-kernel
[-- Attachment #1: Type: text/plain, Size: 223 bytes --]
Hi folks,
Have you seen this one?
http://www.iamm.co.kr/eng/product/ntd25/ntd25.php
It seems to be Linux-powered (derived from 2.4.17). ESR is
explicitly mentioned in the firmware :-).
Regards
Harri
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply
* DRM via bugs?
From: John Richard Moser @ 2006-04-07 17:49 UTC (permalink / raw)
To: linux-kernel
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
I'm not sure if this is mainline or ubuntu kernel and can't seem to find
any info on this (i.e. if it's known, fixed in 2.6.16, etc), so here's
some massive oopsen from my Athlon 64..
Feb 23 07:52:06 localhost kernel: [33790.181014] Oops: 0000 [1] PREEMPT SMP
Feb 23 07:52:06 localhost kernel: [33790.181017] CPU 0
Feb 23 07:52:06 localhost kernel: [33790.181020] Modules linked in:
af_packet nls_utf8 usb_storage rfcomm l2cap bluetooth powernow_k8
cpufreq_userspace cpufreq_stats freq_table cpufreq_powersave
cpufreq_ondemand cpufreq_conservative via drm video tc1100_wmi sony_acpi
pcc_acpi hotkey dev_acpi container button acpi_sbs battery i2c_acpi_ec
ac nls_iso8859_1 nls_cp437 vfat fat ext2 dm_mod md_mod sr_mod sbp2
parport_pc lp parport ipv6 psmouse serio_raw snd_emu10k1_synth
snd_emux_synth snd_seq_virmidi snd_seq_midi_emul tsdev snd_seq_dummy
snd_seq_oss snd_seq_midi snd_seq_midi_event snd_seq i2c_viapro
snd_emu10k1 snd_rawmidi snd_ac97_codec
snd_ac97_bus usblp snd_pcm_oss snd_mixer_oss i2c_core pcspkr rtc
ohci1394 ieee1394 snd_pcm snd_seq_device snd_timer snd_page_alloc
snd_util_mem snd_hwdep snd 8139cp 8139too mii soundcore shpchp usbhid
pci_hotplug sg evdev xfs exportfs ehci_hcd uhci_hcd usbcore ide_generic
ide_cd cdrom generic via82cxxx sd_mod sata_via
libata scsi_mod thermal processor fan capability commoncap vga16fb cf
Feb 23 07:52:06 localhost kernel: copyarea vgastate cfbimgblt
cfbfillrect fbcon
tileblit font bitblit softcursor
Feb 23 07:52:06 localhost kernel: [33790.181069] Pid: 4204, comm: Xorg
Not tainted 2.6.15-15-amd64-k8 #1
Feb 23 07:52:06 localhost kernel: [33790.181072] RIP:
0010:[_end+134037098/2132357120] <ffffffff88440e6a>{:via:via_mmFreeMem+10}
Feb 23 07:52:06 localhost kernel: [33790.181081] RSP:
0018:ffff8100348fddf8 EFLAGS: 00010202
Feb 23 07:52:06 localhost kernel: [33790.181085] RAX: 0000000000000001
RBX: ffff8100382e0000 RCX: 0000000000000000
Feb 23 07:52:06 localhost kernel: [33790.181088] RDX: 0000000000000001
RSI: ffff8100348fde18 RDI: 0000000005fdc280
Feb 23 07:52:06 localhost kernel: [33790.181091] RBP: 0000000000000002
R08: 0000000000000001 R09: 0000000000000001
Feb 23 07:52:06 localhost kernel: [33790.181094] R10: 0000000000000000
R11: 0000000000000000 R12: 0000000000000001
Feb 23 07:52:06 localhost kernel: [33790.181099] R13: ffff8100348fde18
R14: ffff810035238800 R15: ffff810031bc0000
Feb 23 07:52:06 localhost kernel: [33790.181103] FS:
00002aaaab7acce0(0000) GS:ffffffff80426800(0000) knlGS:0000000000000000
Feb 23 07:52:06 localhost kernel: [33790.181107] CS: 0010 DS: 0000 ES:
0000 CR0: 000000008005003b
Feb 23 07:52:06 localhost kernel: [33790.181110] CR2: 0000000005fdc288
CR3: 0000000035625000 CR4: 00000000000006e0
Feb 23 07:52:06 localhost kernel: [33790.181115] Process Xorg (pid:
4204, threadinfo ffff8100348fc000, task ffff81003ab688e0)
Feb 23 07:52:06 localhost kernel: [33790.181117] Stack: ffff8100382e0000
ffffffff8844151a 0000000100000000 ffff81002b346688
Feb 23 07:52:06 localhost kernel: [33790.181126] 0000000005fdc280
ffff81003bcdb4c0 ffff810035238800 0000000000000021
Feb 23 07:52:06 localhost kernel: [33790.181132] ffff81003bcdb4c0
ffff81003523884c
Feb 23 07:52:06 localhost kernel: [33790.181136] Call
Trace:<ffffffff8844151a>{:via:via_final_context+202}
<ffffffff8842a5a0>{:drm:drm_rmctx+128}
Feb 23 07:52:06 localhost kernel: [33790.181191]
<ffffffff801ab64c>{mntput_no_expire+28} <ffffffff8842a520>{:drm:drm_rmctx+0}
Feb 23 07:52:06 localhost kernel: [33790.181215]
<ffffffff8842b365>{:drm:drm_ioctl+405} <ffffffff801a1a09>{do_ioctl+105}
Feb 23 07:52:06 localhost kernel: [33790.181240]
<ffffffff801a1ceb>{vfs_ioctl+683} <ffffffff801ab64c>{mntput_no_expire+28}
Feb 23 07:52:06 localhost kernel: [33790.181251]
<ffffffff801a1d8c>{sys_ioctl+108} <ffffffff8010fede>{system_call+126}
Feb 23 07:52:06 localhost kernel: [33790.181268]
Feb 23 07:52:06 localhost kernel: [33790.181281]
Feb 23 07:52:06 localhost kernel: [33790.181282] Code: 48 8b 4f 08 48 85
c9 0f 84 99 00 00 00 e9 9b 00 00 00 66 66
Feb 23 07:52:06 localhost kernel: [33790.181291] RIP
<ffffffff88440e6a>{:via:via_mmFreeMem+10} RSP <ffff8100348fddf8>
Feb 23 07:52:06 localhost kernel: [33790.181300] CR2: 0000000005fdc288
Feb 23 07:52:06 localhost kernel: [33790.181303] <1>Unable to handle
kernel paging request at 0000000005fdc288 RIP:
Feb 23 07:52:06 localhost kernel: [33790.187430]
<ffffffff88440e6a>{:via:via_mmFreeMem+10}
Feb 23 07:52:06 localhost kernel: [33790.187444] PGD 39181067 PUD
39182067 PMD 0
Something else that happened as well:
[ 1378.035582] agpgart: Found an AGP 3.0 compliant device at 0000:00:00.0.
[ 1378.035596] agpgart: Xorg tried to set rate=x12. Setting to AGP3 x8 mode.
[ 1378.035601] agpgart: Putting AGP V3 device at 0000:00:00.0 into 8x mode
[ 1378.035640] agpgart: Putting AGP V3 device at 0000:01:00.0 into 8x mode
[ 1378.252992] irq 201: nobody cared (try booting with the "irqpoll" option)
[ 1378.252998]
[ 1378.252999] Call Trace: <IRQ> <ffffffff80165aa5>{__report_bad_irq+53}
<ffffffff80165d1a>{note_interrupt+538}
[ 1378.253030] <ffffffff80165407>{__do_IRQ+215}
<ffffffff8011300f>{do_IRQ+47}
[ 1378.253052] <ffffffff80142af0>{ksoftirqd+0}
<ffffffff80110480>{ret_from_intr+0}
[ 1378.253061] <EOI> <ffffffff8030fd62>{thread_return+82}
<ffffffff8010e720>{default_idle+0}
[ 1378.253078] <ffffffff8010e758>{default_idle+56}
<ffffffff8010e846>{cpu_idle+150}
[ 1378.253090] <ffffffff80439895>{start_kernel+485}
<ffffffff80439286>{_sinittext+646}
[ 1378.253102]
[ 1378.253107] handlers:
[ 1378.253109] [<ffffffff8846c430>] (via_driver_irq_handler+0x0/0x170 [via])
[ 1378.253120] Disabling IRQ #201
- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.
Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
-- Eric Steven Raymond
We will enslave their women, eat their children and rape their
cattle!
-- Evil alien overlord from Blasto
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iQIVAwUBRDamCws1xW0HCTEFAQJI4BAAk8TcxM0WDcT0MD/tcz5X9mH/dRIYykeA
tu/fM4dHFVKE+URLw5kjlokP7B7GRK7qvvmmJhV0EbbBSU2eEMIxbEpbaqmuQOa0
fRMOdegc+uWmUDxqOBLp7Iz4G9rC/PxkEoo2uwBiEUEw3aq/nNylHx4kDANkmTQj
0nDUWXgwefmippnsoUiRXpAP/3ttaRSpnaxfdKi0VAeXRw4t632EP6RI2RV57d4Y
CobyujHzMtaZfO5S3WtnAJzCH9UWR+YJ1VUgjG01ndzy3KYC82irvXDQ2R9bnue6
LNwAxJH3Nm1SMdO8d21muo8P3ND6DlCtZiHe0YQzMTxaRjAvhJKDXePdJa8XQT73
ogyJ2cZhnJGLvWlNc/zvqnk/3KwH+6GIv15TmDHyEIounYRXDoYiutxBFWqVfUE7
MJ3oIVUbyZTNaSvYaw9ailewMBQS44bP8j5e53Ulh6a3TLKIcmpmLSfTG2oKSILd
T6KzGP3RDPd69vYZk9Jzyt4KWHaI786edDaNva0FrzxBQ53+a6atyEgdugP3zZEn
3Uq9eFPReDrslawODOJRgDr/9IKSNxLebRcPExxrS/PZPIDmVDVcfk9sUeSmHfq7
JqDi6tHyhw1ULh902sW86783sl/migRbxYc/qi1l7RKJ7hdtAtxfT7aS2d8dKIaJ
YJptBx7ONJM=
=cC5h
-----END PGP SIGNATURE-----
^ permalink raw reply
* [ALSA - driver 0001995]: Master and PCM control missing
From: bugtrack @ 2006-04-07 17:47 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1995>
======================================================================
Reported By: baja
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1995
Category: CORE - control
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution:
Kernel Version:
======================================================================
Date Submitted: 04-03-2006 06:13 CEST
Last Modified: 04-07-2006 19:47 CEST
======================================================================
Summary: Master and PCM control missing
Description:
1.0.11rc3 had the PCM control but the Master control was missing. rc4 now
has both the PCM and the Master volume control missing.
Drivers loaded:
$ lsmod | grep snd
snd_seq_dummy 3396 0
snd_seq_oss 34240 0
snd_seq_midi_event 7232 1 snd_seq_oss
snd_seq 54528 5
snd_seq_dummy,snd_seq_oss,snd_seq_midi_event
snd_seq_device 7952 3 snd_seq_dummy,snd_seq_oss,snd_seq
snd_pcm_oss 42016 0
snd_mixer_oss 16320 1 snd_pcm_oss
snd_hda_intel 16028 1
snd_hda_codec 166536 1 snd_hda_intel
snd_pcm 88396 3 snd_pcm_oss,snd_hda_intel,snd_hda_codec
snd_timer 22600 2 snd_seq,snd_pcm
snd 59072 12
snd_seq_dummy,snd_seq_oss,snd_seq,snd_seq_device,snd_pcm_oss,snd_mixer_oss,snd_hda_intel,snd_hda_codec,snd_pcm,snd_timer
snd_page_alloc 9360 2 snd_hda_intel,snd_pcm
Controls reported by alsa
$ amixer controls
numid=11,iface=MIXER,name='Headphone Playback Switch'
numid=4,iface=MIXER,name='Surround Playback Switch'
numid=3,iface=MIXER,name='Surround Playback Volume'
numid=7,iface=MIXER,name='Center Playback Switch'
numid=5,iface=MIXER,name='Center Playback Volume'
numid=8,iface=MIXER,name='LFE Playback Switch'
numid=6,iface=MIXER,name='LFE Playback Volume'
numid=17,iface=MIXER,name='Line Playback Switch'
numid=16,iface=MIXER,name='Line Playback Volume'
numid=19,iface=MIXER,name='CD Playback Switch'
numid=18,iface=MIXER,name='CD Playback Volume'
numid=13,iface=MIXER,name='Mic Playback Switch'
numid=12,iface=MIXER,name='Mic Playback Volume'
numid=21,iface=MIXER,name='Capture Switch'
numid=23,iface=MIXER,name='Capture Switch',index=1
numid=25,iface=MIXER,name='Capture Switch',index=2
numid=20,iface=MIXER,name='Capture Volume'
numid=22,iface=MIXER,name='Capture Volume',index=1
numid=24,iface=MIXER,name='Capture Volume',index=2
numid=29,iface=MIXER,name='IEC958 Playback Con Mask'
numid=30,iface=MIXER,name='IEC958 Playback Pro Mask'
numid=31,iface=MIXER,name='IEC958 Playback Default'
numid=32,iface=MIXER,name='IEC958 Playback Switch'
numid=34,iface=MIXER,name='IEC958 Capture Default'
numid=33,iface=MIXER,name='IEC958 Capture Switch'
numid=15,iface=MIXER,name='Front Mic Playback Switch'
numid=14,iface=MIXER,name='Front Mic Playback Volume'
numid=2,iface=MIXER,name='Front Playback Switch'
numid=1,iface=MIXER,name='Front Playback Volume'
numid=26,iface=MIXER,name='Input Source'
numid=27,iface=MIXER,name='Input Source',index=1
numid=28,iface=MIXER,name='Input Source',index=2
numid=10,iface=MIXER,name='Side Playback Switch'
numid=9,iface=MIXER,name='Side Playback Volume'
Assuming that that this is an issue since applications look for this
"generic" volume controls.
Thanks
Baja
======================================================================
----------------------------------------------------------------------
baja - 04-03-06 06:17
----------------------------------------------------------------------
By the way... I am using a MSi mother board:
MSI K8NGM2-FID Socket 939 NVIDIA GeForce 6150
ls pci reports:
00:10.1 Audio device: nVidia Corporation MCP51 High Definition Audio (rev
a2)
with snd_hda_intel...
----------------------------------------------------------------------
tiwai - 04-07-06 19:47
----------------------------------------------------------------------
The most important information is missing: Please upload
/proc/asound/card0/codec#* files.
Possibly there is no master volume or PCM control on your chip indeed, but
only volume for each output jack, Front, Surround, CLFE.
Issue History
Date Modified Username Field Change
======================================================================
04-03-06 06:13 baja New Issue
04-03-06 06:17 baja Note Added: 0009084
04-07-06 19:47 tiwai Note Added: 0009154
======================================================================
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.