* [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
* [ALSA - driver 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 1:27 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:27 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:09
----------------------------------------------------------------------
Its cvs :(
----------------------------------------------------------------------
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
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
======================================================================
-------------------------------------------------------
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 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 1:25 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:25 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:09
----------------------------------------------------------------------
Its cvs :(
----------------------------------------------------------------------
rlrevell - 03-22-06 02:25
----------------------------------------------------------------------
Yes please file a new bug then (and let's delete our comments from this one
to clean it up)
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
======================================================================
-------------------------------------------------------
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
* [Xenomai-core] Re: COMEDI over RTDM (was: rtdm_event_timedwait hang-up)
From: Alexis Berlemont @ 2006-03-22 1:24 UTC (permalink / raw)
To: Jan Kiszka; +Cc: xenomai-core
In-Reply-To: <441F5F31.70206@domain.hid>
Hi,
> > But there are plenty of things I am not happy with :
> > -> the original comedilib version is not really well suited for rtdm. In
> > this library for many reasons; for example, you can find calls to
> > malloc/free
>
> Oops, not so nice.
>
> > functions. If I stick to the original implementation, I have to either to
> > ask for adding alloc stuff in user mode in rtdm skin or use another skin
> > to manage allocations. None of these solutions seems interesting for me
> > for many reasons. A lot of people must be thinking I am overkill, it is
> > true that the comedilib allocations should be done at init time
> > (comedi_open, comedi_close) then no need to fulfull real-time constraints
> > but I think comedi should be fully rtdm compliant; this would avoid
> > tricky corner cases for
> > developpers/users. The best and simplest solution for me would be some
> > slight modifications in the comedilib API but I doubt everyone is OK with
> > that.
>
> Could you give some concrete use cases of the comedilib where dynamic
> allocation is involved? I don't know that library actually. What does it
> manage beyond calling the driver core?
In the function comedi_open() :
if(!(it=malloc(sizeof(comedi_t))))
goto cleanup;
memset(it,0,sizeof(comedi_t));
if((it->fd=rt_dev_open(fn,0))<0)
{
fprintf(stderr, "comedi_open: rt_dev_open failed (ret=%d)\n",
it->fd);
goto cleanup;
}
if(comedi_ioctl(it->fd, COMEDI_DEVINFO,
(unsigned long)&it->devinfo)<0)
goto cleanup;
it->n_subdevices=it->devinfo.n_subdevs;
get_subdevices(it);
...
We can see an allocation for a structure which will contain the result ("fd")
of rt_dev_open(). And this is not over, the function "get_subdevices()" will
make another allocation to keep info about the driver (subdevice, number of
channels, etc.). And this function "get_subdevices()" will trigger more
allocations by calling "get_rangeinfo()". In fact, "malloc()" is called eight
times.
All disallocations are done in "comedi_close()".
Starting from here, we have two alternatives:
-> preallocate enough structs the first time "comedi_open()" is called. mmh...
-> modify the comedilib API to let the developper handle the allocations.
> > -> I think the comedi structures organization (comedi_device, subdevice,
> > async, etc.) should be reviewed considering the rtdm architecture. Of
> > course, these modifications should not induce big changes in the comedi
> > drivers source.
>
> Please also give concrete examples here. RTDM devices should be
> manageable by the user via file descriptors, just like normal devices.
There is a little difference with normal devices and classical drivers. The
link between a device and a driver is not direct. The comedi layer affects a
comedi device (/dev/comedi0..9 or comedi0..9) to a specific driver at runtime
thanks to a specific ioctl (cf. comedi_config in comedilib). This is the
comedi attach stuff.
At this level, I may think it would be interesting to consider quite precisely
the layer organization. I have not well understood the architectural border
between what must be done by the driver and what must be done by the abstract
layer.
For example, here is a description of the attaching procedure:
1) the devconfig ioctl is received by the abstract comedi layer;
2) the abstract layer (in comedi/drivers.c) calls do_devconfig_ioctl() which
makes some allocations and a few setups in the structure comedi_device, the
the function comedi_device_attach() is called;
3)In comedi_device_attach(), we check if the proper driver whether available
(insmoded), if so a driver specific function is called;
4) in this driver function, we have access to the structures of the abstract
layer and we modify them (comedi_subdevice);
5) back in the abstract layer, the function "postconfig() is called to setup
the struct "comedi_async" (this struct belongs to a comedi_subdevice).
To sum up:
-> comedi_device { (managed by the abstract layer)
-> comedi_subdevice { (managed by the driver)
-> comedi_async (managed by the abstract layer)
}
}
I am not sure I am clear (it is quite hard to explain without source code),
but I think the drivers should not get direct access to the structures of the
abstract layer.
You may find this points useless, all this stuff is not directly related with
rtdm functionnalities, I just thought the rtdm port would be a good
opportunity to think about that.
> What is different, what extra information is needed?
. I just think some fields could be removed or grouped in comedi_subdevice
(lock, busy, etc.) and we could integrate in comedi_async the nonblocking
info. This is minor.
I may have some more points to share with you but I have to keep them for
tomorrow night.
> Release early, release often ;). I would offer to have a look, maybe it
> will clarify where the RTDM-specific problems are.
OK sorry for tonight, hard day...
Alexis.
^ permalink raw reply
* [ALSA - driver 0001118]: es1868 - mono recording not working properly
From: bugtrack @ 2006-03-22 1:18 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1118>
======================================================================
Reported By: MStrecke
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1118
Category: PCI - es1968
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution: Ubuntu
Kernel Version: 2.6.10
======================================================================
Date Submitted: 05-19-2005 23:36 CEST
Last Modified: 03-22-2006 02:18 CET
======================================================================
Summary: es1868 - mono recording not working properly
Description:
I'm using an old Fujitsu Lifebook E-6570. The on-board sound card is
recognized as "ESS Technology ES1978 Maestro 2E (rev 10)", ID: 125d:1978.
I'm having problems recording mono audio (mic input, line input, etc.).
Only a medium pitched tone is recorded (not a sine waveform, no feed
back). Stereo recording works without problems (using audacity).
======================================================================
----------------------------------------------------------------------
MStrecke - 03-22-06 02:15
----------------------------------------------------------------------
Yes.
I just checked it (Mono recording with Audacity), same result.
(Kernel version by now is 2.6.12-10, Ubuntu Breezy).
----------------------------------------------------------------------
rlrevell - 03-22-06 02:18
----------------------------------------------------------------------
Is the problem still present with the latest ALSA version? Kernel 2.6.12
is rather old.
Issue History
Date Modified Username Field Change
======================================================================
05-19-05 23:36 MStrecke New Issue
05-19-05 23:36 MStrecke Distribution => Ubuntu
05-19-05 23:36 MStrecke Kernel Version => 2.6.10
05-23-05 11:39 tiwai Note Added: 0004702
05-23-05 13:44 MStrecke File Added: asound.state
05-24-05 11:53 tiwai Note Added: 0004709
05-27-05 01:15 MStrecke Note Added: 0004741
05-27-05 12:29 tiwai Note Added: 0004748
05-28-05 22:18 MStrecke Note Added: 0004776
09-26-05 10:28 LawrenceG Issue Monitored: LawrenceG
03-22-06 00:38 rlrevell Note Added: 0008764
03-22-06 02:15 MStrecke Note Added: 0008775
03-22-06 02:18 rlrevell Note Added: 0008776
======================================================================
-------------------------------------------------------
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 0001118]: es1868 - mono recording not working properly
From: bugtrack @ 2006-03-22 1:15 UTC (permalink / raw)
To: alsa-devel
A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1118>
======================================================================
Reported By: MStrecke
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1118
Category: PCI - es1968
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution: Ubuntu
Kernel Version: 2.6.10
======================================================================
Date Submitted: 05-19-2005 23:36 CEST
Last Modified: 03-22-2006 02:15 CET
======================================================================
Summary: es1868 - mono recording not working properly
Description:
I'm using an old Fujitsu Lifebook E-6570. The on-board sound card is
recognized as "ESS Technology ES1978 Maestro 2E (rev 10)", ID: 125d:1978.
I'm having problems recording mono audio (mic input, line input, etc.).
Only a medium pitched tone is recorded (not a sine waveform, no feed
back). Stereo recording works without problems (using audacity).
======================================================================
----------------------------------------------------------------------
rlrevell - 03-22-06 00:38
----------------------------------------------------------------------
Do you still consider this a bug?
----------------------------------------------------------------------
MStrecke - 03-22-06 02:15
----------------------------------------------------------------------
Yes.
I just checked it (Mono recording with Audacity), same result.
(Kernel version by now is 2.6.12-10, Ubuntu Breezy).
Issue History
Date Modified Username Field Change
======================================================================
05-19-05 23:36 MStrecke New Issue
05-19-05 23:36 MStrecke Distribution => Ubuntu
05-19-05 23:36 MStrecke Kernel Version => 2.6.10
05-23-05 11:39 tiwai Note Added: 0004702
05-23-05 13:44 MStrecke File Added: asound.state
05-24-05 11:53 tiwai Note Added: 0004709
05-27-05 01:15 MStrecke Note Added: 0004741
05-27-05 12:29 tiwai Note Added: 0004748
05-28-05 22:18 MStrecke Note Added: 0004776
09-26-05 10:28 LawrenceG Issue Monitored: LawrenceG
03-22-06 00:38 rlrevell Note Added: 0008764
03-22-06 02:15 MStrecke Note Added: 0008775
======================================================================
-------------------------------------------------------
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 0001952]: Simultaneous sound from speakers and headphone on DELL Inspiron 9400
From: bugtrack @ 2006-03-22 1:12 UTC (permalink / raw)
To: alsa-devel
The following issue has been SUBMITTED.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1952>
======================================================================
Reported By: crissi
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1952
Category: PCI - hda-intel
Reproducibility: always
Severity: minor
Priority: normal
Status: assigned
Distribution:
Kernel Version:
======================================================================
Date Submitted: 03-22-2006 02:12 CET
Last Modified: 03-22-2006 02:12 CET
======================================================================
Summary: Simultaneous sound from speakers and headphone on
DELL Inspiron 9400
Description:
This still happens with cvs.
======================================================================
Issue History
Date Modified Username Field Change
======================================================================
03-22-06 02:12 crissi New Issue
======================================================================
-------------------------------------------------------
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
* [RFC] [PATCH] Reducing average ext2 fsck time through fs-wide dirty bit]
From: Valerie Henson @ 2006-03-22 1:10 UTC (permalink / raw)
To: linux-kernel, ext2-devel; +Cc: Arjan van de Ven, Theodore Ts'o, Zach Brown
Hi all,
I am working on reducing the average time spent on fscking ext2 file
systems. My initial take on the problem is to avoid fscking when the
file system is not being modified. If we're not actively modifying
the file system when we crash, it seems intuitive that we could avoid
fsck on next mount. The obvious way to implement this is to add a
clean/dirty bit to the superblock, check every so often to see if the
file system is not being written, sync out all outstanding writes, and
mark the file system clean. On boot, fsck should check for the clean
bit and mark the file system as valid, thereby avoiding a full fsck.
I call this the fs-wide dirty bit solution.
Our intuition is not quite right on at least two points: (1) orphan
inodes, (2) preallocated blocks. To solve the orphan inode problem, I
ported the ext3 orphan inode code to ext2. Fsck does orphan inode
recovery without regard to whether the file system is ext2 or ext3, so
it Just Works with existing fsck. Solving the preallocated blocks
problem is a little harder. When ext2 preallocates blocks, it ends up
writing the block pointers and allocated bits to disk. The extra
preallocated blocks are cleaned up when fsck checks the number of
blocks against i_size. Adding all inodes with preallocated blocks to
the orphan inode list is obviously wrong. Ted and Arjan both
suggested porting Mingming Cao's ext3 reservation window code to ext2
to solve this, which I will look into.
The combination of the orphan inode and preallocation blocks problem
led me to another idea: create in-memory-only allocation bitmaps for
both inodes and blocks. These bitmaps would track blocks and inodes
allocated only for the life of this mount (or a file open) in memory
rather than on disk. I haven't implemented this yet but I think it is
a promising approach.
The current version of the fs-wide dirty bit patch is included below.
This is an RFC-only patch. It does not handle preallocated blocks, so
full fsck must still be run, and it still uses the orphan inode list
instead of an in-memory-only inode allocation bitmap. I have only
tested it on UML; don't use it on any file system you consider
valuable.
Comments, criticisms, new ideas, old ideas I have forgotten, welcome.
Thanks to Zach Brown, Ted T'so, and Arjan Van de Ven for various
discussions and other help while I was writing these patches.
Patch is against 2.6.16-rc5-mm3.
-VAL
diff -x '*~' -uNr vanilla-linux/fs/ext2/balloc.c uml-clean/fs/ext2/balloc.c
--- vanilla-linux/fs/ext2/balloc.c 2006-03-07 16:17:00.000000000 -0800
+++ uml-clean/fs/ext2/balloc.c 2006-03-08 16:21:30.000000000 -0800
@@ -140,9 +140,10 @@
}
}
-static int group_reserve_blocks(struct ext2_sb_info *sbi, int group_no,
+static int group_reserve_blocks(struct super_block *sb, int group_no,
struct ext2_group_desc *desc, struct buffer_head *bh, int count)
{
+ struct ext2_sb_info *sbi = EXT2_SB(sb);
unsigned free_blocks;
if (!desc->bg_free_blocks_count)
@@ -154,6 +155,7 @@
count = free_blocks;
desc->bg_free_blocks_count = cpu_to_le16(free_blocks - count);
spin_unlock(sb_bgl_lock(sbi, group_no));
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bh);
return count;
}
@@ -170,6 +172,7 @@
desc->bg_free_blocks_count = cpu_to_le16(free_blocks + count);
spin_unlock(sb_bgl_lock(sbi, group_no));
sb->s_dirt = 1;
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bh);
}
}
@@ -245,6 +248,7 @@
}
}
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bitmap_bh);
if (sb->s_flags & MS_SYNCHRONOUS)
sync_dirty_buffer(bitmap_bh);
@@ -378,7 +382,7 @@
goto io_error;
}
- group_alloc = group_reserve_blocks(sbi, group_no, desc,
+ group_alloc = group_reserve_blocks(sb, group_no, desc,
gdp_bh, es_alloc);
if (group_alloc) {
ret_block = ((goal - le32_to_cpu(es->s_first_data_block)) %
@@ -414,7 +418,7 @@
desc = ext2_get_group_desc(sb, group_no, &gdp_bh);
if (!desc)
goto io_error;
- group_alloc = group_reserve_blocks(sbi, group_no, desc,
+ group_alloc = group_reserve_blocks(sb, group_no, desc,
gdp_bh, es_alloc);
}
if (!group_alloc) {
@@ -500,6 +504,7 @@
}
write_unlock(&EXT2_I(inode)->i_meta_lock);
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bitmap_bh);
if (sb->s_flags & MS_SYNCHRONOUS)
sync_dirty_buffer(bitmap_bh);
diff -x '*~' -uNr vanilla-linux/fs/ext2/dir.c uml-clean/fs/ext2/dir.c
--- vanilla-linux/fs/ext2/dir.c 2006-03-07 16:25:43.000000000 -0800
+++ uml-clean/fs/ext2/dir.c 2006-03-08 16:21:30.000000000 -0800
@@ -67,6 +67,7 @@
struct inode *dir = page->mapping->host;
int err = 0;
dir->i_version++;
+ ext2_mark_fs_dirty(dir->i_sb);
page->mapping->a_ops->commit_write(NULL, page, from, to);
if (IS_DIRSYNC(dir))
err = write_one_page(page, 1);
diff -x '*~' -uNr vanilla-linux/fs/ext2/ext2.h uml-clean/fs/ext2/ext2.h
--- vanilla-linux/fs/ext2/ext2.h 2006-03-07 16:25:43.000000000 -0800
+++ uml-clean/fs/ext2/ext2.h 2006-03-16 22:17:05.000000000 -0800
@@ -66,6 +66,7 @@
#endif
rwlock_t i_meta_lock;
struct inode vfs_inode;
+ struct list_head i_orphan; /* unlinked but open inodes */
};
/*
@@ -148,6 +149,14 @@
__attribute__ ((format (printf, 3, 4)));
extern void ext2_update_dynamic_rev (struct super_block *sb);
extern void ext2_write_super (struct super_block *);
+extern void ext2_prepare_super (struct super_block *);
+extern void __ext2_mark_fs_clean (struct super_block *);
+extern void ext2_mark_fs_dirty (struct super_block *);
+extern void ext2_mark_inode_dirty (struct inode *);
+extern void ext2_orphan_add(struct inode *);
+extern void ext2_orphan_del(struct inode *);
+/* XXX Gross */
+#define mark_inode_dirty(x) ext2_mark_inode_dirty(x)
/*
* Inodes and files operations
@@ -173,3 +182,7 @@
/* symlink.c */
extern struct inode_operations ext2_fast_symlink_inode_operations;
extern struct inode_operations ext2_symlink_inode_operations;
+
+/* state.c */
+extern void ext2_dirtyd_start_thread(struct super_block *sb);
+extern void ext2_dirtyd_kill_thread(struct super_block *sb);
diff -x '*~' -uNr vanilla-linux/fs/ext2/ialloc.c uml-clean/fs/ext2/ialloc.c
--- vanilla-linux/fs/ext2/ialloc.c 2006-03-07 16:17:00.000000000 -0800
+++ uml-clean/fs/ext2/ialloc.c 2006-03-08 16:21:30.000000000 -0800
@@ -85,6 +85,7 @@
if (dir)
percpu_counter_dec(&EXT2_SB(sb)->s_dirs_counter);
sb->s_dirt = 1;
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bh);
}
@@ -154,6 +155,7 @@
"bit already cleared for inode %lu", ino);
else
ext2_release_inode(sb, block_group, is_directory);
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bitmap_bh);
if (sb->s_flags & MS_SYNCHRONOUS)
sync_dirty_buffer(bitmap_bh);
@@ -528,6 +530,7 @@
err = -ENOSPC;
goto fail;
got:
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bitmap_bh);
if (sb->s_flags & MS_SYNCHRONOUS)
sync_dirty_buffer(bitmap_bh);
@@ -562,6 +565,7 @@
spin_unlock(sb_bgl_lock(sbi, group));
sb->s_dirt = 1;
+ ext2_mark_fs_dirty(sb);
mark_buffer_dirty(bh2);
inode->i_uid = current->fsuid;
if (test_opt (sb, GRPID))
diff -x '*~' -uNr vanilla-linux/fs/ext2/inode.c uml-clean/fs/ext2/inode.c
--- vanilla-linux/fs/ext2/inode.c 2006-03-07 16:25:43.000000000 -0800
+++ uml-clean/fs/ext2/inode.c 2006-03-09 01:07:13.000000000 -0800
@@ -75,6 +75,7 @@
if (is_bad_inode(inode))
goto no_delete;
+ ext2_orphan_del(inode);
EXT2_I(inode)->i_dtime = get_seconds();
mark_inode_dirty(inode);
ext2_update_inode(inode, inode_needs_sync(inode));
@@ -1121,6 +1122,7 @@
*/
for (n = 0; n < EXT2_N_BLOCKS; n++)
ei->i_data[n] = raw_inode->i_block[n];
+ INIT_LIST_HEAD(&ei->i_orphan);
if (S_ISREG(inode->i_mode)) {
inode->i_op = &ext2_file_inode_operations;
diff -x '*~' -uNr vanilla-linux/fs/ext2/Makefile uml-clean/fs/ext2/Makefile
--- vanilla-linux/fs/ext2/Makefile 2006-01-02 19:21:10.000000000 -0800
+++ uml-clean/fs/ext2/Makefile 2006-03-16 22:16:47.000000000 -0800
@@ -5,7 +5,7 @@
obj-$(CONFIG_EXT2_FS) += ext2.o
ext2-y := balloc.o bitmap.o dir.o file.o fsync.o ialloc.o inode.o \
- ioctl.o namei.o super.o symlink.o
+ ioctl.o namei.o super.o symlink.o state.o
ext2-$(CONFIG_EXT2_FS_XATTR) += xattr.o xattr_user.o xattr_trusted.o
ext2-$(CONFIG_EXT2_FS_POSIX_ACL) += acl.o
diff -x '*~' -uNr vanilla-linux/fs/ext2/namei.c uml-clean/fs/ext2/namei.c
--- vanilla-linux/fs/ext2/namei.c 2006-03-07 16:25:43.000000000 -0800
+++ uml-clean/fs/ext2/namei.c 2006-03-10 01:23:52.000000000 -0800
@@ -267,6 +267,8 @@
inode->i_ctime = dir->i_ctime;
inode_dec_link_count(inode);
+ if (!inode->i_nlink)
+ ext2_orphan_add(inode);
err = 0;
out:
return err;
@@ -328,6 +330,8 @@
if (dir_de)
new_inode->i_nlink--;
inode_dec_link_count(new_inode);
+ if (!new_inode->i_nlink)
+ ext2_orphan_add(new_inode);
} else {
if (dir_de) {
err = -EMLINK;
diff -x '*~' -uNr vanilla-linux/fs/ext2/state.c uml-clean/fs/ext2/state.c
--- vanilla-linux/fs/ext2/state.c 1969-12-31 16:00:00.000000000 -0800
+++ uml-clean/fs/ext2/state.c 2006-03-16 21:41:30.000000000 -0800
@@ -0,0 +1,135 @@
+/*
+ * Kernel thread to keep track of clean/dirty state of ext2 file system
+ */
+#include "ext2.h"
+
+#define EXT2_DIRTY_TIMEOUT 1 /* Time in secs to check for dirty */
+#define EXT2_DIRTY_JIFFIES (EXT2_DIRTY_TIMEOUT * HZ)
+
+extern void sys_sync(void); /* XXX Gross */
+
+/*
+ * ext2_update_state runs periodically to check to see if the file
+ * system has any ongoing write traffic. If no one has written to the
+ * file system recently, then we sync the file system and check if any
+ * metadata writes occurred while we were doing the sync. If no
+ * writes occurred, we go ahead and mark the file system clean. Any
+ * operation that changes the metadata must first mark the file system
+ * dirty (via ext2_mark_fs_dirty()) before any other writes hit disk.
+ *
+ * For debugging and measurement, we are keeping some statistics on
+ * how often the file system is dirty/clean in any given period in the
+ * superblock. They will go away if this hits production.
+ *
+ * FIXME: We are using sys_sync() here. We really need to sync only
+ * this file system instead of all file systems.
+ */
+
+static void ext2_update_state(struct super_block *sb)
+{
+ struct ext2_sb_info *sbi = EXT2_SB(sb);
+ struct ext2_super_block *es = EXT2_SB(sb)->s_es;
+
+ lock_super(sb);
+ sb->s_dirt = 1;
+ if (sbi->s_dirty_lately == EXT2_FS_DIRTY) {
+ es->s_dirty_count =
+ cpu_to_le32(le32_to_cpu(es->s_dirty_count) + 1);
+ /* Reset our dirty flag for the next interval */
+ sbi->s_dirty_lately = EXT2_FS_CLEAN;
+ } else {
+ es->s_clean_count =
+ cpu_to_le32(le32_to_cpu(es->s_clean_count) + 1);
+ /*
+ * This fs has not been written to recently. If it is
+ * currently marked dirty, sync all outstanding writes
+ * and see if we are still clean. If so, mark the fs
+ * clean.
+ */
+ if (es->s_fs_dirty != EXT2_FS_CLEAN) {
+ unlock_super(sb);
+ /* Sync all outstanding writes to file system */
+ sys_sync(); /* XXX Hack-o-rama - syncs all fs's */
+ lock_super(sb);
+ /* New writes may have occurred during the
+ * sync, recheck */
+ if (sbi->s_dirty_lately == EXT2_FS_CLEAN)
+ __ext2_mark_fs_clean(sb);
+ else
+ printk(KERN_DEBUG "fs dirtied during sync\n");
+ }
+ /*
+ * We don't flush the superblock if the file system
+ * was already marked clean. Otherwise we'll be
+ * writing to the disk continuously while the file
+ * system is idle. This means the stats won't
+ * necessarily get written to disk until the fs is
+ * unmounted.
+ */
+ }
+ unlock_super(sb);
+}
+
+static void ext2_print_stats(struct super_block *sb)
+{
+ struct ext2_super_block *es = EXT2_SB(sb)->s_es;
+ unsigned int clean, dirty, total, percent;
+
+ clean = le32_to_cpu(es->s_clean_count);
+ dirty = le32_to_cpu(es->s_dirty_count);
+ total = dirty + clean;
+
+ if (total == 0)
+ percent = 0;
+ else
+ percent = (clean * 100) / total;
+ /* XXX add fs mount point */
+ printk(KERN_DEBUG "ext2: dirty:%u clean:%u total:%u percent clean: %u\n",
+ dirty, clean, total, percent);
+}
+
+static int ext2_dirtyd(void *arg)
+{
+ struct super_block *sb = (struct super_block *) arg;
+ struct ext2_sb_info *sbi = EXT2_SB(sb);
+
+ daemonize("ext2_dirtyd");
+
+ printk(KERN_INFO "ext2_dirtyd starting, interval %d seconds\n",
+ EXT2_DIRTY_TIMEOUT);
+
+ init_waitqueue_head(&sbi->s_wait);
+ sbi->s_process = current;
+ ext2_print_stats(sb);
+
+ while (1) {
+ schedule_timeout_interruptible(EXT2_DIRTY_JIFFIES);
+ if (sbi->s_quit)
+ break;
+ if (freezing(current)) {
+ refrigerator();
+ }
+ ext2_update_state(sb);
+ }
+
+ ext2_print_stats(sb);
+ sbi->s_done = 1;
+ wake_up(&sbi->s_wait);
+
+ return 0;
+}
+
+void ext2_dirtyd_start_thread(struct super_block *sb)
+{
+ kernel_thread(ext2_dirtyd, sb, CLONE_VM|CLONE_FS|CLONE_FILES);
+}
+
+void ext2_dirtyd_kill_thread(struct super_block *sb)
+{
+ struct ext2_sb_info *sbi = EXT2_SB(sb);
+
+ sbi->s_quit = 1;
+ wake_up_process(sbi->s_process);
+ wait_event(sbi->s_wait, sbi->s_done != 0);
+}
+
diff -x '*~' -uNr vanilla-linux/fs/ext2/super.c uml-clean/fs/ext2/super.c
--- vanilla-linux/fs/ext2/super.c 2006-03-07 16:25:43.000000000 -0800
+++ uml-clean/fs/ext2/super.c 2006-03-16 22:37:57.000000000 -0800
@@ -113,6 +113,7 @@
int i;
struct ext2_sb_info *sbi = EXT2_SB(sb);
+ ext2_dirtyd_kill_thread(sb);
ext2_xattr_put_super(sb);
if (!(sb->s_flags & MS_RDONLY)) {
struct ext2_super_block *es = sbi->s_es;
@@ -129,6 +130,7 @@
percpu_counter_destroy(&sbi->s_freeblocks_counter);
percpu_counter_destroy(&sbi->s_freeinodes_counter);
percpu_counter_destroy(&sbi->s_dirs_counter);
+ kfree(sbi->s_esp);
brelse (sbi->s_sbh);
sb->s_fs_info = NULL;
kfree(sbi);
@@ -164,6 +166,7 @@
if ((flags & (SLAB_CTOR_VERIFY|SLAB_CTOR_CONSTRUCTOR)) ==
SLAB_CTOR_CONSTRUCTOR) {
rwlock_init(&ei->i_meta_lock);
+ INIT_LIST_HEAD(&ei->i_orphan);
#ifdef CONFIG_EXT2_FS_XATTR
init_rwsem(&ei->xattr_sem);
#endif
@@ -649,9 +652,23 @@
/*
* Note: s_es must be initialized as soon as possible because
* some ext2 macro-instructions depend on its value
+ *
+ * We used to operate on the on-disk superblock directly
+ * inside the buffer in the superblock bh. However, now that
+ * we need to do an asynchronous write of the superblock, we
+ * have to allocate a separate in-memory buffer for the
+ * superblock. For simplicity, we allocate a buffer that is
+ * as large as device block size and then set the sbi->s_es
+ * pointer to the beginning of the superblock inside the
+ * buffer. -VAL
*/
- es = (struct ext2_super_block *) (((char *)bh->b_data) + offset);
- sbi->s_es = es;
+ sbi->s_esp = kmalloc(bh->b_size, GFP_KERNEL);
+ if (!sbi->s_esp)
+ goto failed_sbi;
+ memcpy(sbi->s_esp, bh->b_data, bh->b_size);
+ sbi->s_es = (struct ext2_super_block *) sbi->s_esp + offset;
+ es = sbi->s_es;
+
sb->s_magic = le16_to_cpu(es->s_magic);
if (sb->s_magic != EXT2_SUPER_MAGIC)
@@ -726,6 +743,7 @@
/* If the blocksize doesn't match, re-read the thing.. */
if (sb->s_blocksize != blocksize) {
brelse(bh);
+ kfree(sbi->s_esp);
if (!sb_set_blocksize(sb, blocksize)) {
printk(KERN_ERR "EXT2-fs: blocksize too small for device.\n");
@@ -740,8 +758,13 @@
"2nd try.\n");
goto failed_sbi;
}
- es = (struct ext2_super_block *) (((char *)bh->b_data) + offset);
- sbi->s_es = es;
+ sbi->s_esp = kmalloc(bh->b_size, GFP_KERNEL);
+ if (!sbi->s_esp)
+ goto failed_sbi;
+ memcpy(sbi->s_esp, bh->b_data, bh->b_size);
+ sbi->s_es = (struct ext2_super_block *) sbi->s_esp + offset;
+ es = sbi->s_es;
+
if (es->s_magic != cpu_to_le16(EXT2_SUPER_MAGIC)) {
printk ("EXT2-fs: Magic mismatch, very weird !\n");
goto failed_mount;
@@ -894,6 +917,8 @@
ext2_count_free_inodes(sb));
percpu_counter_mod(&sbi->s_dirs_counter,
ext2_count_dirs(sb));
+ INIT_LIST_HEAD(&sbi->s_orphan);
+ ext2_dirtyd_start_thread(sb); /* XXX be smarter about starting/stopping */
return 0;
cantfind_ext2:
@@ -910,27 +935,79 @@
kfree(sbi->s_debts);
failed_mount:
brelse(bh);
+ kfree(sbi->s_esp);
failed_sbi:
sb->s_fs_info = NULL;
kfree(sbi);
return -EINVAL;
}
+/*
+ * Helper function to copy the in-memory superblock into the buffer
+ * used to write it to disk.
+ */
+
+void ext2_prepare_super(struct super_block * sb)
+{
+ struct buffer_head *bh = EXT2_SB(sb)->s_sbh;
+ char *esp = EXT2_SB(sb)->s_esp;
+
+ lock_buffer(bh);
+ memcpy(bh->b_data, esp, bh->b_size);
+ unlock_buffer(bh);
+}
+
static void ext2_commit_super (struct super_block * sb,
struct ext2_super_block * es)
{
+ struct buffer_head *bh = EXT2_SB(sb)->s_sbh;
+
es->s_wtime = cpu_to_le32(get_seconds());
- mark_buffer_dirty(EXT2_SB(sb)->s_sbh);
+ ext2_prepare_super(sb);
+ mark_buffer_dirty(bh);
sb->s_dirt = 0;
}
+static void ext2_end_async_io(struct buffer_head *bh, int uptodate)
+{
+ /* XXX Deal with failed write of dirty fs bit? */
+ if (uptodate)
+ set_buffer_uptodate(bh);
+ else
+ clear_buffer_uptodate(bh);
+ unlock_buffer(bh);
+}
+
+/*
+ * Submit the superblock for writing, but don't wait - we only need a
+ * write barrier here (has to hit disk after previous writes and
+ * before any subsequent writes).
+ */
+static
+void ext2_write_super_async(struct super_block *sb, struct ext2_super_block *es)
+{
+ struct buffer_head *bh = EXT2_SB(sb)->s_sbh;
+ char *esp = EXT2_SB(sb)->s_esp;
+
+ lock_buffer(bh);
+ bh->b_end_io = ext2_end_async_io;
+ clear_buffer_dirty(bh);
+ memcpy(bh->b_data, esp, bh->b_size);
+ submit_bh(WRITE_BARRIER, bh);
+ sb->s_dirt = 0;
+ /* bh unlocked in end io function */
+}
+
static void ext2_sync_super(struct super_block *sb, struct ext2_super_block *es)
{
+ struct buffer_head *bh = EXT2_SB(sb)->s_sbh;
+
es->s_free_blocks_count = cpu_to_le32(ext2_count_free_blocks(sb));
es->s_free_inodes_count = cpu_to_le32(ext2_count_free_inodes(sb));
es->s_wtime = cpu_to_le32(get_seconds());
- mark_buffer_dirty(EXT2_SB(sb)->s_sbh);
- sync_dirty_buffer(EXT2_SB(sb)->s_sbh);
+ ext2_prepare_super(sb);
+ mark_buffer_dirty(bh);
+ sync_dirty_buffer(bh);
sb->s_dirt = 0;
}
@@ -943,12 +1020,19 @@
* flags to 0. We need to set this flag to 0 since the fs
* may have been checked while mounted and e2fsck may have
* set s_state to EXT2_VALID_FS after some corrections.
+ *
+ * Now we are keeping a copy of the superblock elsewhere in memory
+ * (pointed to by sbi->s_es, and copying it into the buffer on need
+ * (see ext2_prepare_super()). This is so we can use the superblock
+ * to contain the fs-wide dirty bit. We need to be able to submit an
+ * asynchronous I/O to update this bit without having the superblock
+ * information change while it is in flight. -VAL
*/
void ext2_write_super (struct super_block * sb)
{
struct ext2_super_block * es;
- lock_kernel();
+ lock_kernel(); /* XXX Need to lock_kernel() when writing sb?? */
if (!(sb->s_flags & MS_RDONLY)) {
es = EXT2_SB(sb)->s_es;
@@ -956,8 +1040,10 @@
ext2_debug ("setting valid to 0\n");
es->s_state = cpu_to_le16(le16_to_cpu(es->s_state) &
~EXT2_VALID_FS);
- es->s_free_blocks_count = cpu_to_le32(ext2_count_free_blocks(sb));
- es->s_free_inodes_count = cpu_to_le32(ext2_count_free_inodes(sb));
+ es->s_free_blocks_count =
+ cpu_to_le32(ext2_count_free_blocks(sb));
+ es->s_free_inodes_count =
+ cpu_to_le32(ext2_count_free_inodes(sb));
es->s_mtime = cpu_to_le32(get_seconds());
ext2_sync_super(sb, es);
} else
@@ -967,6 +1053,193 @@
unlock_kernel();
}
+/*
+ * Functions for marking fs as dirty or clean with respect to ongoing
+ * write activity. Note this is different from the fs valid bit,
+ * which determines whether the fs has been cleanly unmounted.
+ *
+ * sb->s_lock MUST be held while calling this function.
+ */
+
+static void
+__ext2_mark_super(struct super_block *sb, int state)
+{
+ struct ext2_sb_info *sbi = EXT2_SB(sb);
+ struct ext2_super_block *es = sbi->s_es;
+
+ if (sb->s_flags & MS_RDONLY)
+ return;
+ if (es->s_fs_dirty == state)
+ return;
+
+ es->s_fs_dirty = state;
+ es->s_wtime = cpu_to_le32(get_seconds());
+ /*
+ * If it's dirty, don't update free block/inode counts -
+ * that's expensive, and we have to rebuild them anyway.
+ *
+ * If it's clean, update the free block/inode counts, they
+ * have to be correct now.
+ */
+ if (state == EXT2_FS_DIRTY) {
+ printk(KERN_DEBUG "marking fs dirty\n");
+ sbi->s_dirty_lately = EXT2_FS_DIRTY;
+ } else {
+ printk(KERN_DEBUG "marking fs clean\n");
+ es->s_free_blocks_count =
+ cpu_to_le32(ext2_count_free_blocks(sb));
+ es->s_free_inodes_count =
+ cpu_to_le32(ext2_count_free_inodes(sb));
+ /* We only reset the dirty_lately flag in ext2_update_state */
+ }
+ ext2_write_super_async(sb, es);
+}
+
+static void
+__ext2_mark_fs_dirty(struct super_block *sb)
+{
+ __ext2_mark_super(sb, EXT2_FS_DIRTY);
+}
+
+void
+__ext2_mark_fs_clean(struct super_block *sb)
+{
+ __ext2_mark_super(sb, EXT2_FS_CLEAN);
+}
+
+/*
+ * This function must be called every time we modify file system
+ * metadata, and must be called BEFORE any write I/O is scheduled.
+ */
+
+void
+ext2_mark_fs_dirty(struct super_block *sb)
+{
+ /* XXX get around locking super every write ? */
+ lock_super(sb);
+ __ext2_mark_super(sb, EXT2_FS_DIRTY);
+ unlock_super(sb);
+}
+
+/*
+ * Whenever we mark an inode dirty, we must also mark the file system
+ * dirty.
+ *
+ * XXX Currently mark_inode_dirty() is #defined as
+ * ext2_mark_inode_dirty(), hence the bogus use of
+ * __mark_inode_dirty(). I don't want to replace all instances of
+ * mark_inode_dirty until I'm sure this is what I want to do.
+ */
+
+static void
+__ext2_mark_inode_dirty(struct inode *inode)
+{
+ __ext2_mark_fs_dirty(inode->i_sb);
+ __mark_inode_dirty(inode, I_DIRTY);
+}
+
+void
+ext2_mark_inode_dirty(struct inode *inode)
+{
+ ext2_mark_fs_dirty(inode->i_sb);
+ __mark_inode_dirty(inode, I_DIRTY);
+}
+
+/*
+ * orphan inode stuff, stolen from ext3
+ *
+ * This is a temporary solution for the orphan inode problem. The
+ * long term solution ought to be in-memory-only allocation bitmaps.
+ */
+
+static inline struct inode *orphan_list_entry(struct list_head *l)
+{
+ return &list_entry(l, struct ext2_inode_info, i_orphan)->vfs_inode;
+}
+
+static void dump_orphan_list(struct super_block *sb, struct ext2_sb_info *sbi)
+{
+ struct list_head *l;
+
+ printk(KERN_DEBUG "sb_info orphan list:\n");
+ list_for_each(l, &sbi->s_orphan) {
+ struct inode *inode = orphan_list_entry(l);
+ printk(KERN_DEBUG " "
+ "inode %s:%ld at %p: mode %o, nlink %d, next %d\n",
+ inode->i_sb->s_id, inode->i_ino, inode,
+ inode->i_mode, inode->i_nlink,
+ NEXT_ORPHAN(inode));
+ }
+}
+
+/*
+ * ext2_orphan_add() links an unlinked inode into a list of such
+ * inodes, starting at the superblock, in case we crash before the
+ * file is closed and deleted.
+ *
+ * We depend on the ext3 orphan recovery code in fsck to clean up.
+ */
+void ext2_orphan_add(struct inode *inode)
+{
+ struct super_block *sb = inode->i_sb;
+ struct ext2_sb_info *sbi = EXT2_SB(sb);
+ struct ext2_super_block *es = sbi->s_es;
+
+ lock_super(sb);
+ if (!list_empty(&EXT2_I(inode)->i_orphan)) {
+ unlock_super(sb);
+ return;
+ }
+ /* Insert this inode at the head of the on-disk orphan list... */
+ NEXT_ORPHAN(inode) = le32_to_cpu(es->s_last_orphan);
+ es->s_last_orphan = cpu_to_le32(inode->i_ino);
+ /* Add to in-memory list */
+ list_add(&EXT2_I(inode)->i_orphan, &EXT2_SB(sb)->s_orphan);
+ __ext2_mark_inode_dirty(inode);
+ dump_orphan_list(sb, EXT2_SB(sb));
+ unlock_super(sb);
+ return;
+}
+
+/*
+ * ext2_orphan_del() removes an unlinked inode from the list of such
+ * inodes stored on disk, because it is finally being cleaned up.
+ */
+void ext2_orphan_del(struct inode *inode)
+{
+ struct list_head *prev;
+ struct super_block *sb = inode->i_sb;
+ struct ext2_inode_info *ei = EXT2_I(inode);
+ struct ext2_sb_info *sbi;
+ unsigned long ino_next;
+
+ lock_super(sb);
+ if (list_empty(&ei->i_orphan)) {
+ unlock_super(sb);
+ return;
+ }
+
+ ino_next = NEXT_ORPHAN(inode);
+ prev = ei->i_orphan.prev;
+ sbi = EXT2_SB(sb);
+
+ list_del_init(&ei->i_orphan);
+
+ if (prev == &sbi->s_orphan) {
+ sbi->s_es->s_last_orphan = cpu_to_le32(ino_next);
+ } else {
+ struct inode *i_prev =
+ &list_entry(prev, struct ext2_inode_info,
+ i_orphan)->vfs_inode;
+ NEXT_ORPHAN(i_prev) = ino_next;
+ __ext2_mark_inode_dirty(i_prev);
+ }
+ __ext2_mark_inode_dirty(inode);
+ dump_orphan_list(sb, EXT2_SB(sb));
+ unlock_super(sb);
+ return;
+}
+
static int ext2_remount (struct super_block * sb, int * flags, char * data)
{
struct ext2_sb_info * sbi = EXT2_SB(sb);
@@ -993,6 +1266,10 @@
sb->s_flags = (sb->s_flags & ~MS_POSIXACL) |
((sbi->s_mount_opt & EXT2_MOUNT_POSIX_ACL) ? MS_POSIXACL : 0);
+ /* Superblock may have changed on disk, reread into memory copy */
+
+ memcpy(sbi->s_esp, sbi->s_sbh->b_data, sbi->s_sbh->b_size);
+
es = sbi->s_es;
if (((sbi->s_mount_opt & EXT2_MOUNT_XIP) !=
(old_mount_opt & EXT2_MOUNT_XIP)) &&
diff -x '*~' -uNr vanilla-linux/fs/ext2/xattr.c uml-clean/fs/ext2/xattr.c
--- vanilla-linux/fs/ext2/xattr.c 2006-03-07 16:17:00.000000000 -0800
+++ uml-clean/fs/ext2/xattr.c 2006-03-08 16:21:30.000000000 -0800
@@ -345,6 +345,7 @@
lock_super(sb);
EXT2_SB(sb)->s_es->s_feature_compat |=
cpu_to_le32(EXT2_FEATURE_COMPAT_EXT_ATTR);
+ ext2_prepare_super(sb);
sb->s_dirt = 1;
mark_buffer_dirty(EXT2_SB(sb)->s_sbh);
unlock_super(sb);
diff -x '*~' -uNr vanilla-linux/include/linux/ext2_fs.h uml-clean/include/linux/ext2_fs.h
--- vanilla-linux/include/linux/ext2_fs.h 2006-01-02 19:21:10.000000000 -0800
+++ uml-clean/include/linux/ext2_fs.h 2006-03-16 22:26:50.000000000 -0800
@@ -117,6 +117,12 @@
#endif
/*
+ * Macro for dealing with orphan inode list
+ */
+
+#define NEXT_ORPHAN(inode) EXT2_I(inode)->i_dtime
+
+/*
* Macro-instructions used to manage fragments
*/
#define EXT2_MIN_FRAG_SIZE 1024
@@ -296,6 +302,15 @@
*/
#define EXT2_VALID_FS 0x0001 /* Unmounted cleanly */
#define EXT2_ERROR_FS 0x0002 /* Errors detected */
+/*
+ * Bits defining whether the file system is currently clean or not.
+ * Note that in file systems created by old code, the bit would be set
+ * to 0. To be safe, we must define 0 as dirty and 1 as clean.
+ *
+ * XXX Should convert to state bits, but need to fix fsck first.
+ */
+#define EXT2_FS_CLEAN 1
+#define EXT2_FS_DIRTY 0
/*
* Mount flags
@@ -407,7 +422,12 @@
__u16 s_reserved_word_pad;
__le32 s_default_mount_opts;
__le32 s_first_meta_bg; /* First metablock block group */
- __u32 s_reserved[190]; /* Padding to the end of the block */
+ __u32 s_journal_reserved[18]; /* Used by ext3 journaling */
+ __u8 s_fs_dirty; /* Fs-wide dirty bit */
+ __u8 s_bytes_reserved[3]; /* Padding */
+ __u32 s_clean_count; /* Intervals in which fs was clean */
+ __u32 s_dirty_count; /* Intervals in which fs was dirty */
+ __u32 s_reserved[169]; /* Padding to the end of the block */
};
/*
diff -x '*~' -uNr vanilla-linux/include/linux/ext2_fs_sb.h uml-clean/include/linux/ext2_fs_sb.h
--- vanilla-linux/include/linux/ext2_fs_sb.h 2006-01-02 19:21:10.000000000 -0800
+++ uml-clean/include/linux/ext2_fs_sb.h 2006-03-16 22:27:57.000000000 -0800
@@ -34,7 +34,11 @@
unsigned long s_desc_per_block; /* Number of group descriptors per block */
unsigned long s_groups_count; /* Number of groups in the fs */
struct buffer_head * s_sbh; /* Buffer containing the super block */
- struct ext2_super_block * s_es; /* Pointer to the super block in the buffer */
+ struct ext2_super_block * s_es; /* Pointer to the in memory super block */
+ char * s_esp; /* Pointer to kmalloc'd memory
+ * containing ext2_super_block
+ * - might be offset inside
+ * buffer */
struct buffer_head ** s_group_desc;
unsigned long s_mount_opt;
uid_t s_resuid;
@@ -53,6 +57,12 @@
struct percpu_counter s_freeinodes_counter;
struct percpu_counter s_dirs_counter;
struct blockgroup_lock s_blockgroup_lock;
+ wait_queue_head_t s_wait;
+ struct list_head s_orphan; /* For quick access to orphan inodes */
+ int s_dirty_lately;
+ unsigned int s_quit;
+ unsigned int s_done;
+ void * s_process;
};
#endif /* _LINUX_EXT2_FS_SB */
^ permalink raw reply
* Re: [PATCH] fix memory leak in mm/slab.c::alloc_kmemlist() (try #3)
From: Christoph Lameter @ 2006-03-22 1:10 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:
> --- linux-2.6.16-rc6-mm2-orig/mm/slab.c 2006-03-18 16:55:55.000000000 +0100
> +++ linux-2.6.16-rc6-mm2/mm/slab.c 2006-03-21 22:33:45.000000000 +0100
> @@ -3399,12 +3399,17 @@ EXPORT_SYMBOL_GPL(kmem_cache_name);
> static int alloc_kmemlist(struct kmem_cache *cachep)
> {
> int node;
> + int count = -1;
Count? One could simply go backwards on the node and undo all
allocations for present nodes. That may be much simpler.
while (node >= 0 && node_isset(node, node_online_map) {
....
node--;
}
> struct kmem_list3 *l3;
> - int err = 0;
Ok. err is removed sinc we never set it to a nonzero value.
> + struct array_cache *new;
> + struct array_cache **new_alien;
Ok. Also not checked.
^ permalink raw reply
* Re: [PATCH] powerpc: Add FSL SEC node to documentation
From: Kim Phillips @ 2006-03-22 1:10 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev
In-Reply-To: <3C6218C3-3FC0-437E-A798-3AD6FEB69713@kernel.crashing.org>
On Tue, 21 Mar 2006 12:21:47 -0600
Kumar Gala <galak@kernel.crashing.org> wrote:
> Drop the part about Most modern... in five years when someone reads
> this it will not be modern anymore.
>
[snip]
>
> ditto about modern.
>
[snip]
>
> Would this be a bit more clear, if you explicitly stated that the
> DESC_TYPE value directly corresponds to the bit encoding, like you
> did for EU_SEL0.
>
[snip]
ok, here's the replacement replacement patch with the above fixes:
Documentation: Added FSL SOC SEC node definition
Updated the documentation to include the definition of the SEC device
node format for Freescale SOC devices.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
commit e1e1b8f7d958d7f25a0085ec529a3ebbd6dc1fa5
tree 2e2b12fe07b6d367da4c5609971178838c9321a2
parent 6b0efd3e3b07afc9fc7222066b0b37ecd1d31e44
author Kim Phillips <kim.phillips@freescale.com> Tue, 21 Mar 2006 16:43:16 -0600
committer Kim Phillips <kim.phillips@freescale.com> Tue, 21 Mar 2006 16:43:16 -0600
Documentation/powerpc/booting-without-of.txt | 72 ++++++++++++++++++++++++++
1 files changed, 72 insertions(+), 0 deletions(-)
diff --git a/Documentation/powerpc/booting-without-of.txt b/Documentation/powerpc/booting-without-of.txt
index d02c649..d6626b6 100644
--- a/Documentation/powerpc/booting-without-of.txt
+++ b/Documentation/powerpc/booting-without-of.txt
@@ -1365,6 +1365,78 @@ platforms are moved over to use the flat
};
+ g) Freescale SOC SEC Security Engines
+
+ Required properties:
+
+ - device_type : Should be "crypto"
+ - model : Model of the device. Should be "SEC1" or "SEC2"
+ - compatible : Should be "talitos"
+ - reg : Offset and length of the register set for the device
+ - interrupts : <a b> where a is the interrupt number and b is a
+ field that represents an encoding of the sense and level
+ information for the interrupt. This should be encoded based on
+ the information in section 2) depending on the type of interrupt
+ controller you have.
+ - interrupt-parent : the phandle for the interrupt controller that
+ services interrupts for this device.
+ - num-channels : An integer representing the number of channels
+ available.
+ - channel-fifo-len : An integer representing the number of
+ descriptor pointers each channel fetch fifo can hold.
+ - exec-units-mask : The bitmask representing what execution units
+ (EUs) are available. It's a single 32 bit cell. EU information
+ should be encoded following the SEC's Descriptor Header Dword
+ EU_SEL0 field documentation, i.e. as follows:
+
+ bit 0 = reserved - should be 0
+ bit 1 = set if SEC has the ARC4 EU (AFEU)
+ bit 2 = set if SEC has the DES/3DES EU (DEU)
+ bit 3 = set if SEC has the message digest EU (MDEU)
+ bit 4 = set if SEC has the random number generator EU (RNG)
+ bit 5 = set if SEC has the public key EU (PKEU)
+ bit 6 = set if SEC has the AES EU (AESU)
+ bit 7 = set if SEC has the Kasumi EU (KEU)
+
+ bits 8 through 31 are reserved for future SEC EUs.
+
+ - descriptor-types-mask : The bitmask representing what descriptors
+ are available. It's a single 32 bit cell. Descriptor type
+ information should be encoded following the SEC's Descriptor
+ Header Dword DESC_TYPE field documentation, i.e. as follows:
+
+ bit 0 = set if SEC supports the aesu_ctr_nonsnoop desc. type
+ bit 1 = set if SEC supports the ipsec_esp descriptor type
+ bit 2 = set if SEC supports the common_nonsnoop desc. type
+ bit 3 = set if SEC supports the 802.11i AES ccmp desc. type
+ bit 4 = set if SEC supports the hmac_snoop_no_afeu desc. type
+ bit 5 = set if SEC supports the srtp descriptor type
+ bit 6 = set if SEC supports the non_hmac_snoop_no_afeu desc.type
+ bit 7 = set if SEC supports the pkeu_assemble descriptor type
+ bit 8 = set if SEC supports the aesu_key_expand_output desc.type
+ bit 9 = set if SEC supports the pkeu_ptmul descriptor type
+ bit 10 = set if SEC supports the common_nonsnoop_afeu desc. type
+ bit 11 = set if SEC supports the pkeu_ptadd_dbl descriptor type
+
+ ..and so on and so forth.
+
+ Example:
+
+ /* MPC8548E */
+ crypto@30000 {
+ device_type = "crypto";
+ model = "SEC2";
+ compatible = "talitos";
+ reg = <30000 10000>;
+ interrupts = <1d 3>;
+ interrupt-parent = <40000>;
+ num-channels = <4>;
+ channel-fifo-len = <24>;
+ exec-units-mask = <000000fe>;
+ descriptor-types-mask = <073f1127>;
+ };
+
+
More devices will be defined as this spec matures.
^ permalink raw reply related
* Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
From: Dave Hansen @ 2006-03-22 1:08 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: y-goto, akpm, tony.luck, ak, linux-kernel, linux-ia64, linux-mm
In-Reply-To: <20060322090514.6d6826fc.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2006-03-22 at 09:05 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 21 Mar 2006 10:00:12 -0800
> Dave Hansen <haveblue@us.ibm.com> wrote:
> > At some point in the process, you need to export the NUMA node layout to
> > the rest of the system, to say which pages go in which node. I'm just
> > saying that you should do that _before_ add_memory().
> >
> To do so, we have to maintain new pfn_to_nid() function.
> We have to maintain a new table/list and have to consider name of it :).
I completely spaced out, and forgot that we use sparsemem and 'struct
pages' for pfn_to_nid() now. I've been buried too deep in the i386
discontigmem physnode_map[]. Sorry.
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'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. :(
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()?
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.
-- Dave
^ permalink raw reply
* Re: [PATCH: 002/017]Memory hotplug for new nodes v.4.(change name old add_memory() to arch_add_memory())
From: Dave Hansen @ 2006-03-22 1:08 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: y-goto, akpm, tony.luck, ak, linux-kernel, linux-ia64, linux-mm
In-Reply-To: <20060322090514.6d6826fc.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2006-03-22 at 09:05 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 21 Mar 2006 10:00:12 -0800
> Dave Hansen <haveblue@us.ibm.com> wrote:
> > At some point in the process, you need to export the NUMA node layout to
> > the rest of the system, to say which pages go in which node. I'm just
> > saying that you should do that _before_ add_memory().
> >
> To do so, we have to maintain new pfn_to_nid() function.
> We have to maintain a new table/list and have to consider name of it :).
I completely spaced out, and forgot that we use sparsemem and 'struct
pages' for pfn_to_nid() now. I've been buried too deep in the i386
discontigmem physnode_map[]. Sorry.
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'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. :(
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()?
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.
-- Dave
--
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
* [ALSA - driver 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 1:09 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:09 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...
======================================================================
----------------------------------------------------------------------
rlrevell - 03-22-06 01:58
----------------------------------------------------------------------
If you test CVS and it does not work then yes.
----------------------------------------------------------------------
crissi - 03-22-06 02:09
----------------------------------------------------------------------
Its cvs :(
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
======================================================================
-------------------------------------------------------
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
From: Dave Hansen @ 2006-03-22 1:08 UTC (permalink / raw)
To: KAMEZAWA Hiroyuki
Cc: y-goto, akpm, tony.luck, ak, linux-kernel, linux-ia64, linux-mm
In-Reply-To: <20060322090514.6d6826fc.kamezawa.hiroyu@jp.fujitsu.com>
On Wed, 2006-03-22 at 09:05 +0900, KAMEZAWA Hiroyuki wrote:
> On Tue, 21 Mar 2006 10:00:12 -0800
> Dave Hansen <haveblue@us.ibm.com> wrote:
> > At some point in the process, you need to export the NUMA node layout to
> > the rest of the system, to say which pages go in which node. I'm just
> > saying that you should do that _before_ add_memory().
> >
> To do so, we have to maintain new pfn_to_nid() function.
> We have to maintain a new table/list and have to consider name of it :).
I completely spaced out, and forgot that we use sparsemem and 'struct
pages' for pfn_to_nid() now. I've been buried too deep in the i386
discontigmem physnode_map[]. Sorry.
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'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. :(
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()?
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.
-- Dave
^ permalink raw reply
* qemu pcnet emulation problems.
From: Don Fry @ 2006-03-22 1:02 UTC (permalink / raw)
To: xen-devel
There are/may be several other bugs with the qemu pcnet emulation. I do
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?
--
Don Fry
brazilnut@us.ibm.com
^ permalink raw reply
* [ALSA - driver 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 0:58 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 01:58 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 01:55
----------------------------------------------------------------------
should I open a new bug?
----------------------------------------------------------------------
rlrevell - 03-22-06 01:58
----------------------------------------------------------------------
If you test CVS and it does not work then yes.
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
======================================================================
-------------------------------------------------------
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 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 0:55 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 01:55 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...
======================================================================
----------------------------------------------------------------------
rlrevell - 03-22-06 01:44
----------------------------------------------------------------------
crissi: This is not the same bug as your problem (this one is for ALC880
codec, you have STAC92xx):
00-01: STAC92xx Digital : STAC92xx Digital : playback 1
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2
----------------------------------------------------------------------
crissi - 03-22-06 01:55
----------------------------------------------------------------------
should I open a new bug?
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
======================================================================
-------------------------------------------------------
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] fix memory leak in mm/slab.c::alloc_kmemlist() (try #3)
From: Jesper Juhl @ 2006-03-22 0:54 UTC (permalink / raw)
To: Pekka Enberg, Andrew Morton; +Cc: linux-kernel, Christoph Lameter, Jesper Juhl
In-Reply-To: <9a8748490603200055p7be38dc8lac2e78f4798e6def@mail.gmail.com>
Hi Pekka, Andrew, Christoph & everyone else,
On Monday 20 March 2006 09:55, Jesper Juhl wrote:
> Hi Pekka,
>
> On 3/19/06, Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> > On 3/18/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > > Currently the only caller of alloc_kmemlist() will BUG() if alloc_kmemlist()
> > > fails, but that doesn't mean we shouldn't clean up properly IMHO. Also, the
> > > caller (do_tune_cpucache()) could maybe be changed in the future to do
> > > something more clever than just BUG() and in that case we really shouldn't
> > > be leaking memory when we return -ENOMEM.
> >
> > Yeah, and BUG() can be no-op for embedded.
> >
> > On 3/18/06, Jesper Juhl <jesper.juhl@gmail.com> wrote:
> > > The patch has been compile and boot tested on x86, but since I'm not very
> > > intimate with the slab code I'd appreciate it if someone would take a close
> > > look on the changes before merging them.
> >
> > You probably didn't hit the error path on your x86 box. The patch
> > looks good to me for -mm although there's few comments below.
> >
> > > +/*
> > > + If one or more allocations fail we need to undo all allocations done up to
> > > + this point.
> > > + Unfortunately this means yet another loop, but since this only happens on
> > > + failure and frees up memory in a memory-tight situation, it's not too bad.
> > > + */
> >
> > The formatting of this comment looks strange.
> >
> > > + for_each_online_node(node) {
> > > + if (count <= 0)
> > > + break;
> > > + if (cachep->nodelists[node]) {
> >
> > Would probably make sense to extract the above expression into local
> > variable to reduce kernel text size.
> >
> > > + kfree(cachep->nodelists[node]->shared);
> > > + free_alien_cache(cachep->nodelists[node]->alien);
> > > + kfree(cachep->nodelists[node]);
> > > + cachep->nodelists[node] = NULL;
> > > + }
> > > + count--;
> > > + }
> > > + return -ENOMEM;
> >
>
> Thank you very much for your feedback.
>
> I'll create an updated patch with the changes you suggest. They make
> perfect sense.
>
Here's the latest version of my patch to fix the mem leak in alloc_kmemlist().
It should address Pekkas's comments.
Andrew: Do you think this could go into -mm and get some field testing, so
perhaps it has a chance of making 2.6.17?
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.
Signed-off-by: Jesper Juhl <jesper.juhl@gmail.com>
---
mm/slab.c | 36 ++++++++++++++++++++++++++++++------
1 files changed, 30 insertions(+), 6 deletions(-)
--- linux-2.6.16-rc6-mm2-orig/mm/slab.c 2006-03-18 16:55:55.000000000 +0100
+++ linux-2.6.16-rc6-mm2/mm/slab.c 2006-03-21 22:33:45.000000000 +0100
@@ -3399,12 +3399,17 @@ EXPORT_SYMBOL_GPL(kmem_cache_name);
static int alloc_kmemlist(struct kmem_cache *cachep)
{
int node;
+ int count = -1;
struct kmem_list3 *l3;
- int err = 0;
+ struct array_cache *new;
+ struct array_cache **new_alien;
for_each_online_node(node) {
- struct array_cache *nc = NULL, *new;
- struct array_cache **new_alien = NULL;
+ struct array_cache *nc = NULL;
+
+ new = NULL;
+ new_alien = NULL;
+ count++;
#ifdef CONFIG_NUMA
new_alien = alloc_alien_cache(node, cachep->limit);
if (!new_alien)
@@ -3447,10 +3452,29 @@ static int alloc_kmemlist(struct kmem_ca
cachep->batchcount + cachep->num;
cachep->nodelists[node] = l3;
}
- return err;
+ return 0;
+/**
+ * If one or more allocations fail we need to undo all allocations done up to
+ * this point. Unfortunately this means yet another loop, but since this only
+ * happens on failure and frees up memory in a memory-tight situation, it's
+ * not too bad.
+ */
fail:
- err = -ENOMEM;
- return err;
+ kfree(new);
+ free_alien_cache(new_alien);
+ for_each_online_node(node) {
+ if (count <= 0)
+ break;
+ l3 = cachep->nodelists[node];
+ if (l3) {
+ kfree(l3->shared);
+ free_alien_cache(l3->alien);
+ kfree(l3);
+ cachep->nodelists[node] = NULL;
+ }
+ count--;
+ }
+ return -ENOMEM;
}
struct ccupdate_struct {
^ permalink raw reply
* Re: [PATCH] Add SA_PERCPU_IRQ flag support
From: Dimitri Sivanich @ 2006-03-22 0:52 UTC (permalink / raw)
To: Andrew Morton; +Cc: linux-kernel, hch, clameter, jes
In-Reply-To: <20060321153747.79f18016.akpm@osdl.org>
On Tue, Mar 21, 2006 at 03:37:47PM -0800, Andrew Morton wrote:
> hm. Last time around I pointed out that we should be checking that all
> handlers for this IRQ agree about the percpuness. What happened to
> that?
I believe this version has what you are looking for.
Signed-off-by: Dimitri Sivanich <sivanich@sgi.com>
Index: linux-2.6.15/kernel/irq/manage.c
===================================================================
--- linux-2.6.15.orig/kernel/irq/manage.c 2006-03-20 13:11:01.766522017 -0600
+++ linux-2.6.15/kernel/irq/manage.c 2006-03-21 18:44:52.297990979 -0600
@@ -209,10 +209,14 @@ int setup_irq(unsigned int irq, struct i
p = &desc->action;
if ((old = *p) != NULL) {
/* Can't share interrupts unless both agree to */
- if (!(old->flags & new->flags & SA_SHIRQ)) {
- spin_unlock_irqrestore(&desc->lock,flags);
- return -EBUSY;
- }
+ if (!(old->flags & new->flags & SA_SHIRQ))
+ goto mismatch;
+
+#if defined(ARCH_HAS_IRQ_PER_CPU) && defined(SA_PERCPU_IRQ)
+ /* All handlers must agree on per-cpuness */
+ if ((old->flags & IRQ_PER_CPU) != (new->flags & IRQ_PER_CPU))
+ goto mismatch;
+#endif
/* add new interrupt at end of irq queue */
do {
@@ -223,7 +227,10 @@ int setup_irq(unsigned int irq, struct i
}
*p = new;
-
+#if defined(ARCH_HAS_IRQ_PER_CPU) && defined(SA_PERCPU_IRQ)
+ if (new->flags & SA_PERCPU_IRQ)
+ desc->status |= IRQ_PER_CPU;
+#endif
if (!shared) {
desc->depth = 0;
desc->status &= ~(IRQ_DISABLED | IRQ_AUTODETECT |
@@ -241,6 +248,12 @@ int setup_irq(unsigned int irq, struct i
register_handler_proc(irq, new);
return 0;
+
+mismatch:
+ spin_unlock_irqrestore(&desc->lock, flags);
+ printk(KERN_ERR "%s: irq handler mismatch\n", __FUNCTION__);
+ dump_stack();
+ return -EBUSY;
}
/*
^ permalink raw reply
* Re: More detailed Acer (Intel HDA)
From: Lee Revell @ 2006-03-22 0:51 UTC (permalink / raw)
To: Jonathan Woithe; +Cc: Rimas Kudelis, ALSA devel
In-Reply-To: <200603220041.k2M0f8uA011967@auster.physics.adelaide.edu.au>
On Wed, 2006-03-22 at 11:11 +1030, Jonathan Woithe wrote:
> On these Acer laptops the evidence thus far indicates that there is no
> audio connection between the CD drive and the sound card.
I haven't seen any evidence at all, just speculation, apparently no one
is willing to try Windows to verify this. Until there's some evidence
IMHO the CD control should stay.
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: Execute command via samba on windows machine?
From: Adrian C. @ 2006-03-22 0:50 UTC (permalink / raw)
To: matt; +Cc: linux-admin
In-Reply-To: <3394.82.33.83.247.1142988188.squirrel@mail.mattstone.net>
# windows client logon
logon drive = L:
logon script = scripts/logon.bat
logon path = \\foghorn\profile\%U
There is ^this thing, but again this only works at logon.
--Adrian.
> >
> >
> > I'm trying to script a remote install routine from a linux box. What it's
> > supposed to do is this:
> > - Copy file(s) over to a windows 2k/XP
> > target
> > - Execute installation commands via windows RPC
^ permalink raw reply
* Re: [PATCH 4/11] powerpc: Replace platform_is_lpar() with a firmware feature
From: Michael Ellerman @ 2006-03-22 0:48 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Stephen Rothwell, paulus
In-Reply-To: <20060322113508.08b07cb4.sfr@canb.auug.org.au>
[-- Attachment #1: Type: text/plain, Size: 1053 bytes --]
On Wed, 22 Mar 2006 11:35, Stephen Rothwell wrote:
> On Tue, 21 Mar 2006 20:45:59 +1100 Michael Ellerman <michael@ellerman.id.au>
wrote:
> > It has been decreed that platform numbers are evil, so as a step in that
> > direction, replace platform_is_lpar() with a FW_FEATURE_LPAR bit.
> >
> > Currently FW_FEATURE_LPAR really means i/pSeries LPAR, in the future we
> > might have to clean that up if we need to be more specific about what
> > LPAR actually means. But that's another patch ...
> >
> > Signed-off-by: Michael Ellerman <michael@ellerman.id.au>
>
> Just wondering if you considered just #defining platform_is_lpar() to be
> firmware_has_feature(FW_FEATURE_LPAR) ...
Thought about it, but decided it was ugly, and obscures what's really
happening, ie. LPAR-ness is just a FW_FEATURE bit.
cheers
--
Michael Ellerman
IBM OzLabs
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [ALSA - driver 0001663]: LW20 bugs with headphone input, realtek.com.tw has a fix, please intergrate it!
From: bugtrack @ 2006-03-22 0: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=1663>
======================================================================
Reported By: mikael
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1663
Category: PCI - hda-intel
Reproducibility: always
Severity: feature
Priority: normal
Status: assigned
Distribution: Archlinux
Kernel Version: 2.4.13.4
======================================================================
Date Submitted: 12-20-2005 19:11 CET
Last Modified: 03-22-2006 01:47 CET
======================================================================
Summary: LW20 bugs with headphone input, realtek.com.tw has a
fix, please intergrate it!
Description:
My new laptop has a HDA Intel (Realtek ALC880) soundcard.
It though for some reason do not turn off the main speaker when you insert
headphones. On the site
http://www.realtek.com.tw/downloads/dlhd-2.aspx?lineid=2004052&famid=2004052&series=2004061&Software=True
there is a patched alsa package available which fixes this issue by adding
a "Headphone" mixer which you can turn on/off and also gives you the
availability to mute the main speakers without (as in 1.0.10/11-rc1)
muting the headphones aswell.
Can you please intergrate this? I struggled trying to intergrate this
properly but their alsa is built on 1.0.9 and I suppose I am not the
sharpest of programers either for the job.
Greets,
Mikael
======================================================================
Relationships ID Summary
----------------------------------------------------------------------
duplicate of 0001572 Simultaneous sound from speakers and he...
======================================================================
----------------------------------------------------------------------
mjsb - 01-19-06 14:05
----------------------------------------------------------------------
I had submited bug #0001572 describing the same problem back in November
17, 2005.
The bug still applies to current alsa-driver 1.0.11_rc2.
I'm running the same laptop LG LW20 with gentoo linux (kernel 2.6.14).
----------------------------------------------------------------------
rlrevell - 03-22-06 01:47
----------------------------------------------------------------------
Is this fixed with the latest ALSA CVS sources?
Issue History
Date Modified Username Field Change
======================================================================
12-20-05 19:11 mikael New Issue
12-20-05 19:11 mikael Distribution => Archlinux
12-20-05 19:11 mikael Kernel Version => 2.4.13.4
01-16-06 16:22 mikael Note Added: 0007688
01-16-06 19:24 rlrevell Note Added: 0007691
01-17-06 00:05 mikael Note Added: 0007693
01-19-06 14:05 mjsb Note Added: 0007720
01-19-06 14:31 mjsb Issue Monitored: mjsb
01-19-06 18:27 rlrevell Relationship added duplicate of 0001572
03-01-06 18:00 mpt Issue Monitored: mpt
03-22-06 01:47 rlrevell Note Added: 0008771
======================================================================
-------------------------------------------------------
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 0001462]: Internal OSS emulation doesn't use the hardware mixer?
From: bugtrack @ 2006-03-22 0:45 UTC (permalink / raw)
To: alsa-devel
The following issue has been CLOSED
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1462>
======================================================================
Reported By: mador
Assigned To: tiwai
======================================================================
Project: ALSA - driver
Issue ID: 1462
Category: PCI - hda-intel
Reproducibility: always
Severity: minor
Priority: normal
Status: closed
Distribution: Fedora Core 4
Kernel Version: 2.6.12-1.1456_FC4smp #1 SMP Thu Sep 22 02:23:57 EDT
2005 x86_64 x86_64 x86_64 GNU/Linux
Resolution: open
Fixed in Version:
======================================================================
Date Submitted: 09-26-2005 16:38 CEST
Last Modified: 03-22-2006 01:45 CET
======================================================================
Summary: Internal OSS emulation doesn't use the hardware
mixer?
Description:
When using the alsa hardware device (not dmix) I can play multiple sounds
in parallel but not with the OSS device. In addition, the OSS device shows
as in use while Alsa device is used and vice-versa, the Alsa device is
blocked when the OSS device is used. More then that the alsa
infrastructure reports that there is only one available subdevice as if
hardware mixing wasn't available. But when playing on hw:0 with aplay, I
can have multiple sound files mixed.
On ESS cards with 4 hardware mixed channels I was able to use in parallel
the alsa and the oss devices and I would like to be possible to use the
emulated oss and not the aoss wrapper for the oss only applications.
======================================================================
----------------------------------------------------------------------
rlrevell - 09-26-05 19:10
----------------------------------------------------------------------
You card does not support hardware mixing so this is not possible. You'll
have to use aoss.
----------------------------------------------------------------------
rlrevell - 03-22-06 01:45
----------------------------------------------------------------------
Not a bug
Issue History
Date Modified Username Field Change
======================================================================
09-26-05 16:38 mador New Issue
09-26-05 16:38 mador Distribution => Fedora Core 4
09-26-05 16:38 mador Kernel Version => 2.6.12-1.1456_FC4smp
#1 SMP Thu Sep 22 02:23:57 EDT 2005 x86_64 x86_64 x86_64 GNU/Linux
09-26-05 19:10 rlrevell Note Added: 0006395
03-22-06 01:45 rlrevell Status assigned => closed
03-22-06 01:45 rlrevell Note Added: 0008770
======================================================================
-------------------------------------------------------
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 0001572]: Simultaneous sound from speakers and headphone
From: bugtrack @ 2006-03-22 0: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=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 01:44 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...
======================================================================
----------------------------------------------------------------------
rlrevell - 03-22-06 01:42
----------------------------------------------------------------------
Try CVS or the upcoming 1.0.11-rc4 release
----------------------------------------------------------------------
rlrevell - 03-22-06 01:44
----------------------------------------------------------------------
crissi: This is not the same bug as your problem (this one is for ALC880
codec, you have STAC92xx):
00-01: STAC92xx Digital : STAC92xx Digital : playback 1
00-00: STAC92xx Analog : STAC92xx Analog : playback 1 : capture 2
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
======================================================================
-------------------------------------------------------
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.