On Wed, Sep 05, 2007 at 06:46:57PM +0200, Takashi Iwai wrote:
> Great, then I'll add this entry to ALSA tree.
> It's Aspire 9303, right?
That's what it says on the box.
But it also says 9300 too, if I see a different 9300 I'll check
it pci devs, but there weren't any other 93xx models even
Thanks for picking this up again Andew.
On Wed, Sep 05, 2007 at 06:05:44PM +0200, Takashi Iwai wrote:
> The patch would definitely break many other machines, so no, it can't
> be applied as is. Note that there is an equivalent workaround by
> adding "model=auto" module option.
Ah, I hadn't
Thanks for picking this up again Andew.
On Wed, Sep 05, 2007 at 06:05:44PM +0200, Takashi Iwai wrote:
The patch would definitely break many other machines, so no, it can't
be applied as is. Note that there is an equivalent workaround by
adding model=auto module option.
Ah, I hadn't spotted
On Wed, Sep 05, 2007 at 06:46:57PM +0200, Takashi Iwai wrote:
Great, then I'll add this entry to ALSA tree.
It's Aspire 9303, right?
That's what it says on the box.
But it also says 9300 too, if I see a different 9300 I'll check
it pci devs, but there weren't any other 93xx models even listed
Hi
I'm fighting a problem with my (new) Acer laptop. (Aspire 9303)
In 2.6.18 the audio worked fine, but now I've upgraded to 2.6.22
it has stopped working.
I note that there is a acer specific quirk mode in patch_realtek.c
enabled for all acer devices introduced in the timeframe. Disabling
Hi
I'm fighting a problem with my (new) Acer laptop. (Aspire 9303)
In 2.6.18 the audio worked fine, but now I've upgraded to 2.6.22
it has stopped working.
I note that there is a acer specific quirk mode in patch_realtek.c
enabled for all acer devices introduced in the timeframe. Disabling
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
> Roger Gammans <[EMAIL PROTECTED]> said:
>
> People who want to take over "because it is s00 k3w1 to be a maintainer"
> with no real interest in the code, just in the fact that it is orphaned...
On Sun, Apr 22, 2001 at 01:49:16PM -0300, Rik van Riel wrote:
> On Sun, 22 Apr 2001, Eric S. Raymond wrote:
> > David Woodhouse <[EMAIL PROTECTED]>:
> > > Then you're going to conjure up maintainers for the code which is currently
> > > orphaned?
> >
> > That's a *really* hard problem. I don't
On Sun, Apr 22, 2001 at 01:49:16PM -0300, Rik van Riel wrote:
On Sun, 22 Apr 2001, Eric S. Raymond wrote:
David Woodhouse [EMAIL PROTECTED]:
Then you're going to conjure up maintainers for the code which is currently
orphaned?
That's a *really* hard problem. I don't know how to
On Tue, Apr 24, 2001 at 09:14:41AM -0400, Horst von Brand wrote:
Roger Gammans [EMAIL PROTECTED] said:
People who want to take over because it is s00 k3w1 to be a maintainer
with no real interest in the code, just in the fact that it is orphaned...
No. People who want to give something back
On Thu, Apr 19, 2001 at 01:17:38PM -0400, Eric S. Raymond wrote:
> Go on. Tell me this isn't an error...
>
> CONFIG_ARCH_CLPS7110: arch/arm/kernel/arch.c
> CONFIG_ARCH_CLPS711X: arch/arm/Makefile arch/arm/config.in arch/arm/kernel/Makefile
>arch/arm/kernel/entry-armv.S
On Thu, Apr 19, 2001 at 01:17:38PM -0400, Eric S. Raymond wrote:
Go on. Tell me this isn't an error...
CONFIG_ARCH_CLPS7110: arch/arm/kernel/arch.c
CONFIG_ARCH_CLPS711X: arch/arm/Makefile arch/arm/config.in arch/arm/kernel/Makefile
arch/arm/kernel/entry-armv.S arch/arm/kernel/debug-armv.S
On Sat, Mar 24, 2001 at 02:54:55AM -0300, Rik van Riel wrote:
> On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
> > - trying to kill a task that is permanently in TASK_UNINTERRUPTIBLE
> >will probably deadlock the machine [or the random OOM killer will
> >kill the box].
>
> This could
On Sat, Mar 24, 2001 at 02:54:55AM -0300, Rik van Riel wrote:
On Fri, 23 Mar 2001, Szabolcs Szakacsits wrote:
- trying to kill a task that is permanently in TASK_UNINTERRUPTIBLE
will probably deadlock the machine [or the random OOM killer will
kill the box].
This could indeed be
Hi
If you don't pay attention (yeah, I know) Its easy to write
kernel commond lines like 'console=ttyS0, console=.., etc'
The lack of a baud rate after the comma causes the kernel
to panic. The patch below will cause the kernel in treat the
non-existant baud rate specifier as the default
Hi
If you don't pay attention (yeah, I know) Its easy to write
kernel commond lines like 'console=ttyS0, console=.., etc'
The lack of a baud rate after the comma causes the kernel
to panic. The patch below will cause the kernel in treat the
non-existant baud rate specifier as the default
Hi
Actually I think this might be PCI related, the machines detais are:-
SIS 530 based motherboard..., 256Mbytes ram, limited to 240,
with mem statement (Mem detect fails on 2.2.13, untested 2.2.18).
Networks cards uses PNIC ,with old_tulip driver and RTL8139 with
rtl8139
Hi
Actually I think this might be PCI related, the machines detais are:-
SIS 530 based motherboard..., 256Mbytes ram, limited to 240,
with mem statement (Mem detect fails on 2.2.13, untested 2.2.18).
Networks cards uses PNIC ,with old_tulip driver and RTL8139 with
rtl8139
On Mon, Jan 08, 2001 at 12:02:49PM +, Stephen C. Tweedie wrote:
> Right. There are two distinct meanings:
>
> 1) Do not write to this medium, ever (physical readonly); and
>
> 2) Do not allow modifications to the filesystem (logical readonly).
>
> The fact is that the kernel confuses the
On Mon, Jan 08, 2001 at 12:02:49PM +, Stephen C. Tweedie wrote:
Right. There are two distinct meanings:
1) Do not write to this medium, ever (physical readonly); and
2) Do not allow modifications to the filesystem (logical readonly).
The fact is that the kernel confuses the two,
20 matches
Mail list logo
