* [ALSA - driver 0000222]: Request for Microphone support.
From: bugtrack @ 2006-03-22 1:44 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=222>
======================================================================
Reported By: dolphy
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 222
Category: PPC - powermac
Reproducibility: always
Severity: feature
Priority: normal
Status: assigned
Distribution: Debian
Kernel Version: 2.6.5
======================================================================
Date Submitted: 04-19-2004 13:47 CEST
Last Modified: 03-22-2006 02:44 CET
======================================================================
Summary: Request for Microphone support.
Description:
I know my imac (ilamp model) has a microphone but no way to get it working
with alsa. Is it supported ? Is it just alsamixer not supporting it ?
======================================================================
----------------------------------------------------------------------
tiwai - 04-23-04 17:37
----------------------------------------------------------------------
the codec chip on snapper is different from the tumbler, so it's
not easy. looking at the source code of drawin would be the only
proper way.
----------------------------------------------------------------------
rlrevell - 03-22-06 02:44
----------------------------------------------------------------------
Is this fixed in recent ALSA versions?
Issue History
Date Modified Username Field Change
======================================================================
04-19-04 13:47 dolphy New Issue
04-19-04 13:47 dolphy Distribution => Debian
04-19-04 13:47 dolphy Kernel Version => 2.6.5
04-20-04 12:47 tiwai Note Added: 0000874
04-20-04 12:53 dolphy Note Added: 0000877
04-20-04 12:56 tiwai Note Added: 0000879
04-20-04 17:27 dolphy Note Added: 0000887
04-23-04 17:37 tiwai Note Added: 0000910
01-04-06 17:14 schwab Issue Monitored: schwab
03-22-06 02:44 rlrevell Note Added: 0008784
======================================================================
-------------------------------------------------------
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 0000623]: No volume control on SPDIF on cmedia CMI8738-MC6
From: bugtrack @ 2006-03-22 1:43 UTC (permalink / raw)
To: alsa-devel
The following issue has been CLOSED
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=623>
======================================================================
Reported By: mtempels
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 623
Category: PCI - cmipci
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Distribution: Ubuntu Linux 4.10
Kernel Version: Linux bubbles 2.6.8.1-3-386 #1 Tue Oct 12 12:41:57
BST 2004 i686 GNU/Linux
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 11-02-2004 11:24 CET
Last Modified: 03-22-2006 02:43 CET
======================================================================
Summary: No volume control on SPDIF on cmedia CMI8738-MC6
Description:
There is no way to control the output volume on the SPDIF/out on my CMI8738
soundcard. It can just be switched on or off..
======================================================================
----------------------------------------------------------------------
tiwai - 11-12-04 14:32
----------------------------------------------------------------------
The kernel context is non-preemtive unless the preemptive option is used.
Also, no floating point calculation and no SIMD operations are allowed on
the kernel space. Thus this kind of job can be better done on the user
space than on the kernel space.
In addition, the handling of intermediate buffer (not necessarily
physically linear) would be much easier on user space than on the kernel
space in general, too.
----------------------------------------------------------------------
rlrevell - 03-22-06 02:43
----------------------------------------------------------------------
Not a bug
Issue History
Date Modified Username Field Change
======================================================================
11-02-04 11:24 mtempels New Issue
11-02-04 11:24 mtempels Distribution => Ubuntu Linux 4.10
11-02-04 11:24 mtempels Kernel Version => Linux bubbles
2.6.8.1-3-386 #1 Tue Oct 12 12:41:57 BST 2004 i686 GNU/Linux
11-09-04 18:56 tiwai Note Added: 0002337
11-09-04 19:01 mtempels Note Added: 0002340
11-09-04 19:18 tiwai Note Added: 0002342
11-09-04 20:15 mtempels Note Added: 0002352
11-10-04 03:56 cltien Note Added: 0002355
11-10-04 03:59 cltien Note Added: 0002356
11-10-04 10:12 mtempels Note Added: 0002359
11-10-04 12:13 tiwai Note Added: 0002366
11-12-04 14:03 cltien Note Added: 0002395
11-12-04 14:32 tiwai Note Added: 0002396
03-22-06 02:43 rlrevell Status assigned => closed
03-22-06 02:43 rlrevell Note Added: 0008783
======================================================================
-------------------------------------------------------
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: [PATCH 1/1] libata-dev: Remove ATA_PROT_PIO_MULT
From: Jeff Garzik @ 2006-03-22 1:42 UTC (permalink / raw)
To: albertl; +Cc: IDE Linux
In-Reply-To: <441936FA.6060501@tw.ibm.com>
Albert Lee wrote:
> Remove the ATA_PROT_PIO_MULT protocol.
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
> ---
>
> The ATA_PROT_PIO_MULT can be handled as ATA_PROT_PIO.
> Remove it.
>
> Changes:
> - Remove the ATA_PROT_PIO_MULT protocol
> - Filter out the PIO multi commands in ATA pass through
applied. it would be nice if you would move the text following
"Changes:" from the Albert-comments section to the actual patch
description. Anything that can help describe the rationale behind the
patch belongs in the main patch description.
The section after the "---" is for related comments, questions, worries,
insults, etc. :)
Jeff
^ permalink raw reply
* Routing of channels, more than one output.
From: Tom Watson @ 2006-03-22 1:42 UTC (permalink / raw)
To: alsa development
I've got a 'problem' that involves playing around with 'asoundrc' files.
What I desire to do is by specifying a sound 'device' have the audio routed
specially. If I specify 'mono2' for example, I'd like my mono sound samples
routed to BOTH the left and right speaker. If I say 'stereo4' I'd like my
stereo channels (sent with 'writei' calls) routed to both the front AND rear
speakers. While I could write out the samples, it seems much easier to have a
definition in my 'asoundrd' file to do this, if possible. If it isn't
possible, I will take another tact.
So, my question, can this be done? If so, how? I'm not an expert at
'asoundrd' files.
I'm using an M-Audio Revolution 7.1 card if that makes any difference
(hopefully not).
Thanks. We now return you to the regularly scheduled bug reports in the
mailing list.
--
Tom Watson
tsw@johana.com
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
-------------------------------------------------------
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: [PATCH 6/6 v2] IB: userspace support for RDMA connection manager
From: Roland Dreier @ 2006-03-22 1:40 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX4011XvpFVjCRG0000000f@orsmsx401.amr.corp.intel.com>
I added this patch to the rdma_cm branch in my git tree. When I was
doing that, I noticed that it builds rdma_ucm.ko unconditionally. It
seems that we want this to depend on CONFIG_INFINIBAND_USER_ACCESS,
since that controls ib_uverbs.ko and ib_ucm.ko.
To do this I rejiggered the Kconfig and Makefile changes I made
before. I made CONFIG_INFINIBAND_ADDR_TRANS into a bool (instead of a
tristate), so that it's 'y' if INFINIBAND and INET are on, and made
the top of the Makefile look like:
infiniband-$(CONFIG_INFINIBAND_ADDR_TRANS) := ib_addr.o rdma_cm.o
user_access-$(CONFIG_INFINIBAND_ADDR_TRANS) := rdma_ucm.o
obj-$(CONFIG_INFINIBAND) += ib_core.o ib_mad.o ib_sa.o \
ib_cm.o $(infiniband-y)
obj-$(CONFIG_INFINIBAND_USER_MAD) += ib_umad.o
obj-$(CONFIG_INFINIBAND_USER_ACCESS) += ib_uverbs.o ib_ucm.o $(user_access-y)
I'm pretty sure this does exactly what we want.
- R.
^ permalink raw reply
* Re: [PATCH 6/6 v2] IB: userspace support for RDMA connection manager
From: Roland Dreier @ 2006-03-22 1:40 UTC (permalink / raw)
To: Sean Hefty; +Cc: netdev, linux-kernel, openib-general
In-Reply-To: <ORSMSX4011XvpFVjCRG0000000f@orsmsx401.amr.corp.intel.com>
I added this patch to the rdma_cm branch in my git tree. When I was
doing that, I noticed that it builds rdma_ucm.ko unconditionally. It
seems that we want this to depend on CONFIG_INFINIBAND_USER_ACCESS,
since that controls ib_uverbs.ko and ib_ucm.ko.
To do this I rejiggered the Kconfig and Makefile changes I made
before. I made CONFIG_INFINIBAND_ADDR_TRANS into a bool (instead of a
tristate), so that it's 'y' if INFINIBAND and INET are on, and made
the top of the Makefile look like:
infiniband-$(CONFIG_INFINIBAND_ADDR_TRANS) := ib_addr.o rdma_cm.o
user_access-$(CONFIG_INFINIBAND_ADDR_TRANS) := rdma_ucm.o
obj-$(CONFIG_INFINIBAND) += ib_core.o ib_mad.o ib_sa.o \
ib_cm.o $(infiniband-y)
obj-$(CONFIG_INFINIBAND_USER_MAD) += ib_umad.o
obj-$(CONFIG_INFINIBAND_USER_ACCESS) += ib_uverbs.o ib_ucm.o $(user_access-y)
I'm pretty sure this does exactly what we want.
- R.
^ permalink raw reply
* Re: [PATCH 1/1] libata-dev: add flush task to ata_exec_internal()
From: Jeff Garzik @ 2006-03-22 1:40 UTC (permalink / raw)
To: albertl; +Cc: Tejun Heo, IDE Linux
In-Reply-To: <44163628.2000001@tw.ibm.com>
Albert Lee wrote:
> Add ata_port_flush_task() to ata_exec_internal().
>
> Signed-off-by: Albert Lee <albertcc@tw.ibm.com>
applied
^ permalink raw reply
* [ALSA - driver 0001047]: module hangs at seemingly random times
From: bugtrack @ 2006-03-22 1:38 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1047>
======================================================================
Reported By: alien999999999
Assigned To: mjander
======================================================================
Project: ALSA - driver
Issue ID: 1047
Category: PCI - au88x0
Reproducibility: sometimes
Severity: block
Priority: normal
Status: assigned
Distribution: Mandrake
Kernel Version: 2.6.7
======================================================================
Date Submitted: 04-12-2005 20:43 CEST
Last Modified: 03-22-2006 02:38 CET
======================================================================
Summary: module hangs at seemingly random times
Description:
sometimes i start playing a song, and it starts playing a few second or so
and hangs, then i kill the application and modprobe -r all sound modules
and modprobe them again to make it work again.
BUT: sometimes not only that happens, but also when i try to kill the apps
it will not kill. when that happens, all kill, killall, top, ps aux
commands hang at the command line and cannot be killed by CTRL-C or
otherwise, i have been able to see that when i stopped my display
managener I did an lsmod and it gave something like this:
snd-pcm-oss 59752 11
snd-mixer-oss 20480 1 snd-pcm-oss
snd-au8810 43760 220
snd-ac97-codec 83408 1 snd-au8810
snd-pcm 108172 112 snd-pcm-oss,snd-au8810,snd-ac97-codec
snd-page-alloc 10384 1 snd-pcm
gameport 3840 1 snd-au8810
snd-mpu401-uart 11904 1 snd-au8810
as you can see the snd-au8810 module seem to have an impossible number of
"dependencies" (i think has to do with the number of unclosed sound-apps
trying to be played; this could be since gaim is programmed to execute an
'aplay %s')
i've had this major crash below only 3 times; and the logs didn't detect
anything specific at the time. the only thing the logs mentioned at that
time was an ntpd sync going on; so the only thing i can think of is that
at a certain moment when a sync is going on, some kind of lock is holding
cause this to happen... the only thing that i can do to fix this is
reset...
it is interesting to note that i also have an snd-emu10k1 as second card,
which never gave problems like this, and i am always able to "modprobe -r
snd-emu10k1" ...
======================================================================
----------------------------------------------------------------------
Raymond - 03-22-06 02:31
----------------------------------------------------------------------
I upload au88x0_mpu401.patch, the patch just only fix the oops in bug
0001833
It is not tested with any mpu401 devices (midi/waveblaster daugther card)
on 32/64bits platform.
Actually none of au8810 has the waveblaster connector.
I am not sure midi through joystick and wavelbaster can be used
concurrently on au8820/au8830 since I don't have any mpu401 devices
Issue History
Date Modified Username Field Change
======================================================================
04-12-05 20:43 alien999999999 New Issue
04-12-05 20:43 alien999999999 Distribution => Mandrake
04-12-05 20:43 alien999999999 Kernel Version => 2.6.7
04-12-05 20:48 alien999999999 Note Added: 0004461
04-12-05 20:49 alien999999999 File Added: au88x0.c
04-12-05 20:49 alien999999999 File Added: au88x0.h
04-12-05 20:50 alien999999999 File Added: au88x0_core.c
04-12-05 20:50 alien999999999 File Added: au88x0_mixer.c
04-12-05 20:51 alien999999999 Note Added: 0004462
08-24-05 11:13 Raymond Note Added: 0005928
10-27-05 02:27 Raymond Note Added: 0006564
01-03-06 04:04 Raymond Note Added: 0007397
01-04-06 22:08 alien999999999 Note Added: 0007455
01-05-06 07:21 Raymond Note Added: 0007462
01-05-06 20:32 shurick Issue Monitored: shurick
01-06-06 17:17 alien999999999 Note Added: 0007488
01-06-06 17:33 alien999999999 File Added: alsa-cvs-2006-01-04.patch
01-13-06 13:51 Raymond Note Added: 0007639
01-13-06 18:18 tiwai Note Added: 0007648
01-14-06 04:53 Raymond Note Added: 0007653
01-14-06 05:00 Raymond Note Edited: 0007653
01-17-06 12:27 Raymond Note Added: 0007697
01-18-06 15:51 Raymond Note Added: 0007710
01-18-06 15:52 Raymond File Added: au88x0_codec.patch
01-19-06 13:51 Raymond Note Added: 0007719
02-05-06 05:20 Raymond Note Edited: 0007710
02-05-06 05:28 Raymond Note Added: 0007930
02-13-06 16:38 Raymond Note Deleted: 0006564
02-13-06 16:41 Raymond Note Added: 0008054
03-01-06 07:39 Raymond Note Added: 0008273
03-18-06 12:28 Raymond Note Deleted: 0008273
03-20-06 17:54 Raymond File Added: au88x0_conf.patch
03-21-06 02:02 Raymond Note Added: 0008734
03-21-06 18:01 tiwai Note Added: 0008754
03-22-06 02:05 Raymond File Added: au88x0_mpu401.patch
03-22-06 02:28 Raymond Note Added: 0008779
03-22-06 02:31 Raymond Note Edited: 0008779
03-22-06 02:38 rlrevell Note Added: 0008782
======================================================================
-------------------------------------------------------
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: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
From: KAMEZAWA Hiroyuki @ 2006-03-22 1:38 UTC (permalink / raw)
To: Dave Hansen
Cc: y-goto, akpm, tony.luck, ak, linux-kernel, linux-ia64, linux-mm
In-Reply-To: <1142989698.10906.224.camel@localhost.localdomain>
On Tue, 21 Mar 2006 17:08:18 -0800
Dave Hansen <haveblue@us.ibm.com> wrote:
> If I missed it before, please refresh my memory. But, if we're
> providing arch_nid_probe(addr), then why don't we just call it inside of
> add_memory() on the start address, instead of in the generic code?
>
I think just *probe* needs it. The firmware which supports memory-hotplug, ACPI,
i386/x86_64/ia64, can tell node number as pxm.(proximity domain)
add_memory() can pass address of paddr as args, but can't pass *pxm*.
We already maintain pxm <-> nid map. But paddr <-> nid map isn't now.
If add_memory() doesn't has nid as args, we have to maintain
(1) pxm <-> nid map.
(2) paddr <-> nid map.
Becasue pfn_to_nid() is maintained by SPARSEMEM itself now, *new* paddr<->nid map
is redundant, I think. And I think the firmware already has the map before calling
add_memory().
> I'm also getting a bit confused in your patches whether add_memory() is
> the _original_ add_memory(), or the new one. It tends to get lost in 17
> patches. :(
>
maybe a big patch :(, We (I and Goto-san) are discussing to split them to
a bit small chunks.
> I don't really like the arch_nid_probe() name. We need to make it very
> apparent that it is to be used _only_ for memory hotplug operations. It
> has no meaning for anything else.
>
> hotplug_physaddr_to_nid()?
>
> Maybe with a "memory_" in front. Maybe even
> memory_add_physaddr_to_nid()?
>
Okay, we'll rename it.
> It was probably to keep from changing as little code as possible, but
> please convert the u64 values to pfns as soon as possible. I noticed
> that hotadd_new_pgdat() still deals with them, and does the shift as
> well. Is that really necessary.
>
> The u64s should not be kept for more than one level of calls. That
> level of calls should be the firmware. So, let the firmware call into
> the VM code with u64s, then have all of the plain VM code deal in pfns.
>
Okay.
-- Kame
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name
From: KAMEZAWA Hiroyuki @ 2006-03-22 1:38 UTC (permalink / raw)
To: Dave Hansen
Cc: y-goto, akpm, tony.luck, ak, linux-kernel, linux-ia64, linux-mm
In-Reply-To: <1142989698.10906.224.camel@localhost.localdomain>
On Tue, 21 Mar 2006 17:08:18 -0800
Dave Hansen <haveblue@us.ibm.com> wrote:
> If I missed it before, please refresh my memory. But, if we're
> providing arch_nid_probe(addr), then why don't we just call it inside of
> add_memory() on the start address, instead of in the generic code?
>
I think just *probe* needs it. The firmware which supports memory-hotplug, ACPI,
i386/x86_64/ia64, can tell node number as pxm.(proximity domain)
add_memory() can pass address of paddr as args, but can't pass *pxm*.
We already maintain pxm <-> nid map. But paddr <-> nid map isn't now.
If add_memory() doesn't has nid as args, we have to maintain
(1) pxm <-> nid map.
(2) paddr <-> nid map.
Becasue pfn_to_nid() is maintained by SPARSEMEM itself now, *new* paddr<->nid map
is redundant, I think. And I think the firmware already has the map before calling
add_memory().
> I'm also getting a bit confused in your patches whether add_memory() is
> the _original_ add_memory(), or the new one. It tends to get lost in 17
> patches. :(
>
maybe a big patch :(, We (I and Goto-san) are discussing to split them to
a bit small chunks.
> I don't really like the arch_nid_probe() name. We need to make it very
> apparent that it is to be used _only_ for memory hotplug operations. It
> has no meaning for anything else.
>
> hotplug_physaddr_to_nid()?
>
> Maybe with a "memory_" in front. Maybe even
> memory_add_physaddr_to_nid()?
>
Okay, we'll rename it.
> It was probably to keep from changing as little code as possible, but
> please convert the u64 values to pfns as soon as possible. I noticed
> that hotadd_new_pgdat() still deals with them, and does the shift as
> well. Is that really necessary.
>
> The u64s should not be kept for more than one level of calls. That
> level of calls should be the firmware. So, let the firmware call into
> the VM code with u64s, then have all of the plain VM code deal in pfns.
>
Okay.
-- Kame
^ permalink raw reply
* Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
From: KAMEZAWA Hiroyuki @ 2006-03-22 1:38 UTC (permalink / raw)
To: Dave Hansen
Cc: y-goto, akpm, tony.luck, ak, linux-kernel, linux-ia64, linux-mm
In-Reply-To: <1142989698.10906.224.camel@localhost.localdomain>
On Tue, 21 Mar 2006 17:08:18 -0800
Dave Hansen <haveblue@us.ibm.com> wrote:
> If I missed it before, please refresh my memory. But, if we're
> providing arch_nid_probe(addr), then why don't we just call it inside of
> add_memory() on the start address, instead of in the generic code?
>
I think just *probe* needs it. The firmware which supports memory-hotplug, ACPI,
i386/x86_64/ia64, can tell node number as pxm.(proximity domain)
add_memory() can pass address of paddr as args, but can't pass *pxm*.
We already maintain pxm <-> nid map. But paddr <-> nid map isn't now.
If add_memory() doesn't has nid as args, we have to maintain
(1) pxm <-> nid map.
(2) paddr <-> nid map.
Becasue pfn_to_nid() is maintained by SPARSEMEM itself now, *new* paddr<->nid map
is redundant, I think. And I think the firmware already has the map before calling
add_memory().
> I'm also getting a bit confused in your patches whether add_memory() is
> the _original_ add_memory(), or the new one. It tends to get lost in 17
> patches. :(
>
maybe a big patch :(, We (I and Goto-san) are discussing to split them to
a bit small chunks.
> I don't really like the arch_nid_probe() name. We need to make it very
> apparent that it is to be used _only_ for memory hotplug operations. It
> has no meaning for anything else.
>
> hotplug_physaddr_to_nid()?
>
> Maybe with a "memory_" in front. Maybe even
> memory_add_physaddr_to_nid()?
>
Okay, we'll rename it.
> It was probably to keep from changing as little code as possible, but
> please convert the u64 values to pfns as soon as possible. I noticed
> that hotadd_new_pgdat() still deals with them, and does the shift as
> well. Is that really necessary.
>
> The u64s should not be kept for more than one level of calls. That
> level of calls should be the firmware. So, let the firmware call into
> the VM code with u64s, then have all of the plain VM code deal in pfns.
>
Okay.
-- Kame
^ permalink raw reply
* Re: libata SCSI page 0x83 query
From: Jeff Garzik @ 2006-03-22 1:38 UTC (permalink / raw)
To: dougg; +Cc: Chris Paulson-Ellis, linux-ide, SCSI Mailing List
In-Reply-To: <440CC86D.7060600@torque.net>
Douglas Gilbert wrote:
> Douglas Gilbert wrote:
>
>>Jeff Garzik wrote:
>>
>>
>>>Chris Paulson-Ellis wrote:
>>>
>>>
>>>
>>>>Hi,
>>>>
>>>>I have a problem with udev persistent device naming for SATA drives
>>>>that is caused by the libata implementation of the page 0x83 SCSI
>>>>device identifier query. See this thead from hotplug-devel:
>>>>
>>>>http://marc.theaimsgroup.com/?t=113518947900002&r=1&w=2
>>>>
>>>>I can work around the problem using /etc/scsi_id.config or udev rules
>>>>(see the thread), but here is a patch to fix the problem at source.
>>>>What do you think?
>>>>
>>>>Regards,
>>>>Chris.
>>>>
>>>>--- drivers/scsi/libata-scsi.c.orig 2005-12-22 23:23:55.000000000
>>>>+0000
>>>>+++ drivers/scsi/libata-scsi.c 2005-12-22 23:56:14.000000000 +0000
>>>>@@ -1532,16 +1532,13 @@
>>>> return 0;
>>>>}
>>>>
>>>>-static const char *inq_83_str = "Linux ATA-SCSI simulator";
>>>>-
>>>>/**
>>>>* ata_scsiop_inq_83 - Simulate INQUIRY EVPD page 83, device identity
>>>>* @args: device IDENTIFY data / SCSI command of interest.
>>>>* @rbuf: Response buffer, to which simulated SCSI cmd output is
>>>>sent.
>>>>* @buflen: Response buffer length.
>>>>*
>>>>- * Returns device identification. Currently hardcoded to
>>>>- * return "Linux ATA-SCSI simulator".
>>>>+ * Returns ATA device serial number (as for page 80).
>>>>*
>>>>* LOCKING:
>>>>* spin_lock_irqsave(host_set lock)
>>>>@@ -1551,13 +1548,14 @@
>>>> unsigned int buflen)
>>>>{
>>>> rbuf[1] = 0x83; /* this page code */
>>>>- rbuf[3] = 4 + strlen(inq_83_str); /* page len */
>>>>+ rbuf[3] = 4 + ATA_SERNO_LEN; /* page len */
>>>>
>>>> /* our one and only identification descriptor (vendor-specific) */
>>>>- if (buflen > (strlen(inq_83_str) + 4 + 4 - 1)) {
>>>>+ if (buflen > (ATA_SERNO_LEN + 4 + 4 - 1)) {
>>>> rbuf[4 + 0] = 2; /* code set: ASCII */
>>>>- rbuf[4 + 3] = strlen(inq_83_str);
>>>>- memcpy(rbuf + 4 + 4, inq_83_str, strlen(inq_83_str));
>>>>+ rbuf[4 + 3] = ATA_SERNO_LEN;
>>>>+ ata_dev_id_string(args->id, (unsigned char *) rbuf + 4
>>>>+ 4,
>>>>+ ATA_ID_SERNO_OFS, ATA_SERNO_LEN);
>>>
>>>
>>>Douglas Gilbert has an improved patch along these lines...
>
>
> Oops, a minor documentation malfunction with that patch.
> Here is a second attempt ...
>
> I assume that is a prompt to roll another version
> of that VPD patch, this time against lk 2.6.16-rc5
> as my git tree is unavailable.
>
> Changelog:
> - make existing libata VPD device identification page (0x83)
> supply the ATA serial number in the libata "vendor
> specific" designator (from Chris Paulson-Ellis)
> - add a "t10 vendor id based" designator as defined in
> SAT rev 08 (section 10.3.4.2.3) that supplies ATA
> model and serial numbers
> - make the libata VPD page 0x83 more extensible (for
> adding more designators in the future).
> - rename EVPD to VPD in various places. Enable Vital
> Product Data (EVPD) is a bit in the INQUIRY cdb.
>
> Signed-off-by: Douglas Gilbert <dougg@torque.net>
after further thought and a spec consult... applied.
^ permalink raw reply
* [ALSA - driver 0001850]: source available
From: bugtrack @ 2006-03-22 1:38 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1850>
======================================================================
Reported By: coz
Assigned To:
======================================================================
Project: ALSA - driver
Issue ID: 1850
Category: PCI - echoaudio
Reproducibility: always
Severity: major
Priority: normal
Status: new
Distribution: ubuntu/breezy/Debian
Kernel Version: 2.6.12.10.386
======================================================================
Date Submitted: 02-16-2006 13:05 CET
Last Modified: 03-22-2006 02:38 CET
======================================================================
Summary: source available
Description:
can't start layla24
======================================================================
----------------------------------------------------------------------
pochini - 03-20-06 22:10
----------------------------------------------------------------------
You have to install lib before tools and utils, otherwise you just can't
compile them. There are not other dependencies. If you don't say what is
the problem I can't help.
----------------------------------------------------------------------
coz - 03-22-06 02:38
----------------------------------------------------------------------
hello,
well the problem is when I installall of the required elements I still
get no sound. i also get no errors.
As I metioned before, a fellow from ubuntu even wlked me through this and
he was stumped as well.
i hae noidea , apparently, how to do this but even with someone who is
familiar with alsa installation it turned out not to work.
So, I can keep trying, alsa driver first then lib then tools then u
tilities right/
i can try again. thanks
Coz
Issue History
Date Modified Username Field Change
======================================================================
02-16-06 13:05 coz New Issue
02-16-06 13:05 coz Distribution => ubuntu/breezy/Debian
02-16-06 13:05 coz Kernel Version => 2.6.12.10.386
02-18-06 13:34 pochini Note Added: 0008119
02-20-06 03:30 coz Note Added: 0008140
02-20-06 22:02 pochini Note Added: 0008150
03-13-06 19:49 coz Note Added: 0008456
03-13-06 22:38 pochini Note Added: 0008465
03-13-06 23:02 johnrigg Note Added: 0008466
03-16-06 14:54 coz Note Added: 0008605
03-18-06 22:02 pochini Note Added: 0008676
03-18-06 22:07 pochini Note Edited: 0008676
03-19-06 16:05 coz Note Added: 0008690
03-20-06 22:10 pochini Note Added: 0008725
03-22-06 02:38 coz Note Added: 0008781
======================================================================
-------------------------------------------------------
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: Any missing patches?
From: Lee Revell @ 2006-03-22 1:37 UTC (permalink / raw)
To: Takashi Iwai; +Cc: alsa-devel
In-Reply-To: <s5hmzfl9cql.wl%tiwai@suse.de>
On Mon, 2006-03-20 at 19:45 +0100, Takashi Iwai wrote:
> Hi,
>
> if someone has patches intended for merging to ALSA tree, please
> submit them ASAP.
>
> I think the current ALSA CVS tree is forming to a relatively good
> shape now, and it's good time to push Linux kernel tree, too.
> Let's be not too late to ride a bus.
>
Can you look at bug #1952 (speakers not disabled when headphones plugged
with hda-intel + STAC92xx)? amixer output shows no "Jack sense"
controls present. It looks like it just needs an HP_MUTE quirk (or
whatever the hda-intel equivalent is)
Lee
-------------------------------------------------------
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: qemu pcnet emulation problems.
From: Nivedita Singhvi @ 2006-03-22 1:36 UTC (permalink / raw)
To: Don Fry; +Cc: xen-devel
In-Reply-To: <20060322010235.GA16108@us.ibm.com>
Don Fry wrote:
> There are/may be several other bugs with the qemu pcnet emulation. I do
Not sure if Don mentioned this earlier, but for the benefit of those
who might need the context, please see Xen Bugzilla #574/#575.
> not know if there is any other serialization outside of this code, but if
> both a transmit and a receive operation were to be performed at the same
> time on different cpus, since the same buffer is used for both transmit
> and receive, that would also cause data corruption.
>
> Does anyone else know how this is prevented, or is this another source
> of corruption?
>
> Another thing I noticed, that will reduce throughput if corrected, is
> that the wrong bit is being examined in the receive path, to determine
> if mac level crc should be computed. Right now, the wrong bit is being
> checked and no mac level crc is being calculated. If the right bit were
> looked at, mac level crc would need to be computed, slowing down the
> transfers. However, since no driver cares about the crc right now,
> since neither Linux or XP complain, could the code to compute the crc be
> deleted? Maybe just comment that the crc should be computed.
>
> Any recommendations?
I'd really like to continue to avoid the CRC computation between
domains, but intentionally, this time, in a clean way :).
thanks,
Nivedita
^ permalink raw reply
* Re: Accessing kernel information from a module
From: Sumit Narayan @ 2006-03-22 1:36 UTC (permalink / raw)
To: Anand SVR; +Cc: Arjan van de Ven, linux-kernel
In-Reply-To: <48a4d13c0603210809n681c3594mcdb41b7578a36dbd@mail.gmail.com>
You can use kernel probes (kprobe & jprobe) for accessing any
variables in the kernel. But ofcourse, this would be running-kernel
specific.
Link http://www.redhat.com/magazine/005mar05/features/kprobes/
Changing the kernel parameters is gonna be a very dangerous act,
unless you are sure of what you are doing.
-- Sumit
On 3/22/06, Anand SVR <anand.svr@gmail.com> wrote:
> Hi,
>
> I forgot to mention one more context. In the embedded environment where
> one is memory constrained, the lightweight and low memory foot-print
> module I am referring to becomes relevant. In addition, since it is
> highly reliable, and remotely manageable as listed below I feel it is
> worth pursuing.
>
> Thanks for your time.
>
> Regards
> Anand
> On 3/21/06, Anand SVR <anand.svr@gmail.com> wrote:
> > Hi,
> >
> > The code is not yet ready :) I have a basic version that gives part of
> > memory statistics.
> >
> > Why I want to do it in kernel ? Following are the reasons.
> >
> > - Not all the information is available to the user space. There may be
> > situations where kernel developers, carrier grade server mainatainers,
> > and the like might want to access some internal run-time information
> > for debugging, fine-tuning and so on.
> >
> > - Keep it light weight, and least intrusive to the run-time behavior
> > of the system. No need for tcp/udp socket communication.
> >
> > - There could be impending catastrophic situations where in kernel
> > cannot schedule user level processes, perhaps due to lack of memory or
> > whatever.
> >
> > - Ability for the remote node to change/control certain kernel
> > parameters by interacting with the module. This paves way for both
> > diagnosing and controlling kernel.
> >
> > Regards
> > Anand
> >
> > On 3/21/06, Arjan van de Ven <arjan@infradead.org> wrote:
> > > On Tue, 2006-03-21 at 16:32 +0530, Anand SVR wrote:
> > > > Hi,
> > > >
> > > > I am in the process of writing a module that collects kernel
> > > > information of various kernel subsytems and pass this on to a remote
> > > > monitoring/management node. The information could be statistical data
> > > > maintained in data structures of memory, process, network and so on.
> > > > Or it could be any kernel variables that are of interest.
> > >
> > > you forgot to attach your source code ;)
> > >
> > > > Is there a way of accessing proc information from the module ?
> > >
> > > eh why on earth is your code in the kernel then? Shouldn't your code be
> > > in userspace if you want to send such information to a remote system???
> > >
> > >
> > >
> >
> -
> 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: [PATCH] fix memory leak in mm/slab.c::alloc_kmemlist() (try #3)
From: Christoph Lameter @ 2006-03-22 1:35 UTC (permalink / raw)
To: Jesper Juhl; +Cc: Pekka Enberg, Andrew Morton, linux-kernel
In-Reply-To: <200603220154.16266.jesper.juhl@gmail.com>
On Wed, 22 Mar 2006, Jesper Juhl wrote:
> Fix memory leak in mm/slab.c::alloc_kmemlist().
> If one allocation fails we have to roll-back all allocations made up to the
> point of failure.
Sorry but you cannot roll back. alloc_kmemlist() could have been used for
tuning the cpucache while accesses to the slab continue. "Rolling back"
would partially destroy the slab for some nodes and likely cause the
system to crash. We can only roll back if this is actually an initial
allocation and we are assured that the whole thing is not yet in use.
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 1:34 UTC (permalink / raw)
To: Yu, Luming, Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>
>Hmm, you seems to prefer depth-first search algorithm?
>I like it too. :-)
>
>
>>
>>One bug is quite repeatable and we know a lot about it. With all zones
>>except THM0 commented out, the system hung. With the EC0.UPDT line in
>>THM0._TMP also commented out, the system didn't hang. So there's a
>>problem related to the EC, even with only THM0. And finding that
>>problem may giveideas for what else may be wrong.
>
>We can do bisection in EC0.UPDT to find out which statement cause hang?
>Hmm, we are going to fix BIOS. :-)
You can insert debug statements in EC0.UPDT to help debug:
Store (IGNR, Debug)
Store (" before relase I2CM", Debug)
Store (HBS7, TMP7)
....
>
>My assumption is that since Windows works well, then these BIOS code
>should have been tested ok. The only possible excuse for BIOS is that
>Linux is using unnecessary/untested code path for Suspend/resume.
>So, Eventually, we need to disable unnecessary BIOS call for
>suspend/resume
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 1:34 UTC (permalink / raw)
To: Yu, Luming, Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>
>Hmm, you seems to prefer depth-first search algorithm?
>I like it too. :-)
>
>
>>
>>One bug is quite repeatable and we know a lot about it. With all zones
>>except THM0 commented out, the system hung. With the EC0.UPDT line in
>>THM0._TMP also commented out, the system didn't hang. So there's a
>>problem related to the EC, even with only THM0. And finding that
>>problem may giveideas for what else may be wrong.
>
>We can do bisection in EC0.UPDT to find out which statement cause hang?
>Hmm, we are going to fix BIOS. :-)
You can insert debug statements in EC0.UPDT to help debug:
Store (IGNR, Debug)
Store (" before relase I2CM", Debug)
Store (HBS7, TMP7)
....
>
>My assumption is that since Windows works well, then these BIOS code
>should have been tested ok. The only possible excuse for BIOS is that
>Linux is using unnecessary/untested code path for Suspend/resume.
>So, Eventually, we need to disable unnecessary BIOS call for
>suspend/resume
^ permalink raw reply
* [ALSA - driver 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 1:30 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1572>
======================================================================
Reported By: mjsb
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1572
Category: PCI - hda-intel
Reproducibility: always
Severity: major
Priority: normal
Status: assigned
Distribution: Gentoo Linux
Kernel Version: 2.1.13-gentoo-r3
======================================================================
Date Submitted: 11-17-2005 16:31 CET
Last Modified: 03-22-2006 02:30 CET
======================================================================
Summary: Simultaneous sound from speakers and headphone
Description:
I cannot ear headphones without having sound from front speakers
simultaneously.
Volume of headphones is adjusted by front speakers and when muting front
speakers also mutes headphones.
(in MS Windows, inserting headphones automatically disables sound from
front speakers)
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
has duplicate 0001663 LW20 bugs with headphone input, realtek...
======================================================================
----------------------------------------------------------------------
crissi - 03-22-06 02:27
----------------------------------------------------------------------
Its cvs :(
So we have a new one:
https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1952
----------------------------------------------------------------------
rlrevell - 03-22-06 02:30
----------------------------------------------------------------------
mjsb: have you had a chance to test tiwai's recommendation yet?
Issue History
Date Modified Username Field Change
======================================================================
11-17-05 16:31 mjsb New Issue
11-17-05 16:31 mjsb Distribution => Gentoo Linux
11-17-05 16:31 mjsb Kernel Version => 2.1.13-gentoo-r3
11-17-05 16:33 mjsb Issue Monitored: mjsb
12-08-05 21:23 mjsb Note Added: 0006962
01-16-06 11:19 mjsb Note Added: 0007685
01-19-06 18:27 rlrevell Relationship added has duplicate 0001663
01-21-06 03:24 mjsb Note Added: 0007730
01-21-06 03:25 mjsb File Added: HPoff-speakeron
01-21-06 03:25 mjsb File Added: HPon-speakeroff
01-21-06 03:30 mjsb Note Edited: 0007730
01-25-06 11:47 blackr2d Issue Monitored: blackr2d
01-25-06 11:56 blackr2d Note Added: 0007778
01-25-06 11:59 blackr2d Note Edited: 0007778
01-25-06 12:00 blackr2d Note Edited: 0007778
01-25-06 12:36 blackr2d Note Edited: 0007778
02-14-06 05:36 richardfish Issue Monitored: richardfish
02-14-06 05:37 richardfish Note Added: 0008069
02-16-06 13:49 mjsb Note Added: 0008096
03-01-06 18:00 mpt Issue Monitored: mpt
03-15-06 15:36 tiwai Note Added: 0008552
03-22-06 01:33 crissi Note Added: 0008766
03-22-06 01:33 crissi Issue Monitored: crissi
03-22-06 01:42 rlrevell Note Added: 0008768
03-22-06 01:44 rlrevell Note Added: 0008769
03-22-06 01:55 crissi Note Added: 0008772
03-22-06 01:58 rlrevell Note Added: 0008773
03-22-06 02:09 crissi Note Added: 0008774
03-22-06 02:25 rlrevell Note Added: 0008777
03-22-06 02:26 rlrevell Note Deleted: 0008768
03-22-06 02:26 rlrevell Note Deleted: 0008773
03-22-06 02:26 rlrevell Note Deleted: 0008769
03-22-06 02:27 rlrevell Note Deleted: 0008777
03-22-06 02:27 crissi Note Added: 0008778
03-22-06 02:30 rlrevell Note Added: 0008780
======================================================================
-------------------------------------------------------
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: Re: [iproute2] IPoIB link layer address bug
From: Jason Gunthorpe @ 2006-03-22 1:30 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev, openib-general, lartc
In-Reply-To: <20060321155617.3ae419b2@localhost.localdomain>
On Tue, Mar 21, 2006 at 03:56:17PM -0800, Stephen Hemminger wrote:
> Okay, but there are number of other places in iproute2 that call ll_addr_a2n()
> with ifr.ifr_hwaddr.sa_data. And that is 14 bytes. If you want to fix those
> it will be harder since it would increase the sizeof(struct sockaddr) and potentially
> break compatibility.
Maybe the best thing is to upgrade ip (and or netlink?) to use netlink
messages instead of ioctls for the remaining problematic operations.
Since netlink already supports an arbitary length hwaddr there should
be no compatability problem.
Just browsing I see usages of SIOCSIFHWBROADCAST, SIOCSIFHWADDR,
SIOCADDMULTI, SIOCDELMULTI and SIOCGIFHWADDR that use a struct ifreq..
I know SIOCGIFHWADDR can be done over netlink, but I'm not too
familiar with the others..
Jason
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 1:30 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>Two more experiments:
>
> With a vanilla kernel, I faked EC0.UPDT() to just return
>0x00, and the
> system hung on the second sleep.
>
> Then, again in the DSDT, I also faked the 4 _TMP methods (one in each
> thermal zone), and the system hung on the second sleep.
>
>I think we've raced too far ahead by trying to debug many thermal zones
>at once. Perhaps there are two bugs. So let's find them one by one.
Hmm, you seems to prefer depth-first search algorithm?
I like it too. :-)
>
>One bug is quite repeatable and we know a lot about it. With all zones
>except THM0 commented out, the system hung. With the EC0.UPDT line in
>THM0._TMP also commented out, the system didn't hang. So there's a
>problem related to the EC, even with only THM0. And finding that
>problem may giveideas for what else may be wrong.
We can do bisection in EC0.UPDT to find out which statement cause hang?
Hmm, we are going to fix BIOS. :-)
My assumption is that since Windows works well, then these BIOS code
should have been tested ok. The only possible excuse for BIOS is that
Linux is using unnecessary/untested code path for Suspend/resume.
So, Eventually, we need to disable unnecessary BIOS call for
suspend/resume
Thanks,
Luming
^ permalink raw reply
* RE: 2.6.16-rc5: known regressions [TP 600X S3, vanilla DSDT]
From: Yu, Luming @ 2006-03-22 1:30 UTC (permalink / raw)
To: Sanjoy Mahajan
Cc: linux-kernel, Linus Torvalds, Andrew Morton, Tom Seeley,
Dave Jones, Jiri Slaby, michael, mchehab, Brian Marete,
Ryan Phillips, gregkh, Brown, Len, linux-acpi, Mark Lord,
Randy Dunlap, jgarzik, Duncan, Pavlik Vojtech, Meelis Roos
>Two more experiments:
>
> With a vanilla kernel, I faked EC0.UPDT() to just return
>0x00, and the
> system hung on the second sleep.
>
> Then, again in the DSDT, I also faked the 4 _TMP methods (one in each
> thermal zone), and the system hung on the second sleep.
>
>I think we've raced too far ahead by trying to debug many thermal zones
>at once. Perhaps there are two bugs. So let's find them one by one.
Hmm, you seems to prefer depth-first search algorithm?
I like it too. :-)
>
>One bug is quite repeatable and we know a lot about it. With all zones
>except THM0 commented out, the system hung. With the EC0.UPDT line in
>THM0._TMP also commented out, the system didn't hang. So there's a
>problem related to the EC, even with only THM0. And finding that
>problem may giveideas for what else may be wrong.
We can do bisection in EC0.UPDT to find out which statement cause hang?
Hmm, we are going to fix BIOS. :-)
My assumption is that since Windows works well, then these BIOS code
should have been tested ok. The only possible excuse for BIOS is that
Linux is using unnecessary/untested code path for Suspend/resume.
So, Eventually, we need to disable unnecessary BIOS call for
suspend/resume
Thanks,
Luming
^ permalink raw reply
* Read /dev/kmem failed
From: openbsd shen @ 2006-03-22 1:29 UTC (permalink / raw)
To: linux-c-programming
struct descriptor_idt {
unsigned short offset_low, seg_selector;
unsigned char reserved, flag;
unsigned short offset_high;
};
.......
struct descriptor_idt *descriptor;
.......
fd_kmem = open("/dev/kmem", O_RDWR);
ptr_idt = get_addr_idt();
descriptor = (struct descriptor_idt *) malloc(sizeof(struct
descriptor_idt));
......
readkmem(descriptor, ptr_idt + 8 * x, sizeof(struct descriptor_idt));
......
void readkmem(void *m, unsigned off, int size)
{
int i;
if (lseek(fd_kmem, off, SEEK_SET) != off) {
fprintf(stderr, "Error lseek. Are you root? \n");
exit(-1);
}
if ((i = read(fd_kmem, m, size)) != size) {
fprintf(stderr, "Error read kmem, only read %d bytes\n",i);
perror("read");
exit(-1);
}
}
unsigned long get_addr_idt(void)
{
unsigned char idtr[6];
unsigned long idt;
__asm__ volatile ("sidt %0":"=m" (idtr));
idt = *((unsigned long *) &idtr[2]);
return (idt);
}
----------------------------------------------------------------------
When run it, the output is:
Error read kmem, only read 0 bytes
read: Success
I don't know why read error?
^ permalink raw reply
* [ALSA - driver 0001047]: module hangs at seemingly random times
From: bugtrack @ 2006-03-22 1:28 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1047>
======================================================================
Reported By: alien999999999
Assigned To: mjander
======================================================================
Project: ALSA - driver
Issue ID: 1047
Category: PCI - au88x0
Reproducibility: sometimes
Severity: block
Priority: normal
Status: assigned
Distribution: Mandrake
Kernel Version: 2.6.7
======================================================================
Date Submitted: 04-12-2005 20:43 CEST
Last Modified: 03-22-2006 02:28 CET
======================================================================
Summary: module hangs at seemingly random times
Description:
sometimes i start playing a song, and it starts playing a few second or so
and hangs, then i kill the application and modprobe -r all sound modules
and modprobe them again to make it work again.
BUT: sometimes not only that happens, but also when i try to kill the apps
it will not kill. when that happens, all kill, killall, top, ps aux
commands hang at the command line and cannot be killed by CTRL-C or
otherwise, i have been able to see that when i stopped my display
managener I did an lsmod and it gave something like this:
snd-pcm-oss 59752 11
snd-mixer-oss 20480 1 snd-pcm-oss
snd-au8810 43760 220
snd-ac97-codec 83408 1 snd-au8810
snd-pcm 108172 112 snd-pcm-oss,snd-au8810,snd-ac97-codec
snd-page-alloc 10384 1 snd-pcm
gameport 3840 1 snd-au8810
snd-mpu401-uart 11904 1 snd-au8810
as you can see the snd-au8810 module seem to have an impossible number of
"dependencies" (i think has to do with the number of unclosed sound-apps
trying to be played; this could be since gaim is programmed to execute an
'aplay %s')
i've had this major crash below only 3 times; and the logs didn't detect
anything specific at the time. the only thing the logs mentioned at that
time was an ntpd sync going on; so the only thing i can think of is that
at a certain moment when a sync is going on, some kind of lock is holding
cause this to happen... the only thing that i can do to fix this is
reset...
it is interesting to note that i also have an snd-emu10k1 as second card,
which never gave problems like this, and i am always able to "modprobe -r
snd-emu10k1" ...
======================================================================
----------------------------------------------------------------------
tiwai - 03-21-06 18:01
----------------------------------------------------------------------
Could you send the series of fix patches to alsa-devel ML and to me ? (Not
URLs but real patches, please.) I cannot follow which patches should be
merged.
Thanks.
----------------------------------------------------------------------
Raymond - 03-22-06 02:28
----------------------------------------------------------------------
I upload au88x0_mpu401.patch, the patch just only fix the oops in bug
0001833
It is not tested with any mpu401 devices (midi/waveblaster daugther card)
on 32/64bits platform.
Actually none of au8810 has the waveblaster connector.
Issue History
Date Modified Username Field Change
======================================================================
04-12-05 20:43 alien999999999 New Issue
04-12-05 20:43 alien999999999 Distribution => Mandrake
04-12-05 20:43 alien999999999 Kernel Version => 2.6.7
04-12-05 20:48 alien999999999 Note Added: 0004461
04-12-05 20:49 alien999999999 File Added: au88x0.c
04-12-05 20:49 alien999999999 File Added: au88x0.h
04-12-05 20:50 alien999999999 File Added: au88x0_core.c
04-12-05 20:50 alien999999999 File Added: au88x0_mixer.c
04-12-05 20:51 alien999999999 Note Added: 0004462
08-24-05 11:13 Raymond Note Added: 0005928
10-27-05 02:27 Raymond Note Added: 0006564
01-03-06 04:04 Raymond Note Added: 0007397
01-04-06 22:08 alien999999999 Note Added: 0007455
01-05-06 07:21 Raymond Note Added: 0007462
01-05-06 20:32 shurick Issue Monitored: shurick
01-06-06 17:17 alien999999999 Note Added: 0007488
01-06-06 17:33 alien999999999 File Added: alsa-cvs-2006-01-04.patch
01-13-06 13:51 Raymond Note Added: 0007639
01-13-06 18:18 tiwai Note Added: 0007648
01-14-06 04:53 Raymond Note Added: 0007653
01-14-06 05:00 Raymond Note Edited: 0007653
01-17-06 12:27 Raymond Note Added: 0007697
01-18-06 15:51 Raymond Note Added: 0007710
01-18-06 15:52 Raymond File Added: au88x0_codec.patch
01-19-06 13:51 Raymond Note Added: 0007719
02-05-06 05:20 Raymond Note Edited: 0007710
02-05-06 05:28 Raymond Note Added: 0007930
02-13-06 16:38 Raymond Note Deleted: 0006564
02-13-06 16:41 Raymond Note Added: 0008054
03-01-06 07:39 Raymond Note Added: 0008273
03-18-06 12:28 Raymond Note Deleted: 0008273
03-20-06 17:54 Raymond File Added: au88x0_conf.patch
03-21-06 02:02 Raymond Note Added: 0008734
03-21-06 18:01 tiwai Note Added: 0008754
03-22-06 02:05 Raymond File Added: au88x0_mpu401.patch
03-22-06 02:28 Raymond Note Added: 0008779
======================================================================
-------------------------------------------------------
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.