headers
Martin Loschwitz | 28 Mar 01:08

Problems on Apple iBook with ALSA and snd-powermac [2.6.11.5]

Hi folks,

given that the alsa-user-mailinglist has some strange kind of authentication
mechanism, and admin-authorization and whatever, I'm writing this mail to the
LKML (it would have been CCed here anyway).

The current snd-powermac module from ALSA seems to have trouble with modern
Apple iBook computers (and possible other Apple notebooks, but I can't tell
for sure). With 2.6.11.5 and having snd-powermac loaded, playing some sound
results in a very noisy playback; you can only hear that if you turn volume
on the PCM and VOL mixers up to the maximum, and even then, it's very hard 
to hear. After removing snd-powermac and loading the "old" pmac-driver, the
sound playback works just fine.

I have been able to find out that with 2.6.8 (at least with the version that
Debian ships currently), the problem does not appear; snd-powermac does its
job very nicely there. Given that 2.6.11 included some ALSA changes, I just
compiled 2.6.10 on this box and booted it, and had the same problems I have
with snd-powermac on 2.6.11.5.

Is this a known problem and is a fix available for it? If not, what can I do
to help with hunting this bug? I really like ALSA and prefer it over the old
pmac-sound-driver.

--

-- 
  .''`.   Martin Loschwitz           Debian GNU/Linux developer
 : :'  :  madkiss <at> madkiss.org        madkiss <at> debian.org
 `. `'`   http://www.madkiss.org/    people.debian.org/~madkiss/
   `-     Use Debian GNU/Linux 3.0!  See http://www.debian.org/
(Continue reading)

Permalink | Reply | 2 comments |
headers
linux-os | 28 Mar 01:13

Re: [PATCH] no need to check for NULL before calling kfree()-fs/ext2/

On Sun, 27 Mar 2005, Arjan van de Ven wrote:

> On Sat, 2005-03-26 at 18:21 -0500, linux-os wrote:
>> On Sat, 26 Mar 2005, Arjan van de Ven wrote:
>>
>>> On Fri, 2005-03-25 at 17:29 -0500, linux-os wrote:
>>>> Isn't it expensive of CPU time to call kfree() even though the
>>>> pointer may have already been freed?
>>>
>>> nope
>>>
>>> a call instruction is effectively half a cycle or less, the branch
>>
>> Wrong!
>
> oh? a call is "push eip + a new eip" effectively. the new eip is
> entirely free, the push eip takes half a cycle (or 1 full cycle but only
> one of the two/three pipelines).
>
>>
>>> predictor of the cpu can predict perfectly where the next instruction is
>>> from. The extra if() you do in front is a different matter, that can
>>> easily cost 100 cycles+. (And those are redundant cycles because kfree
>>> will do the if again anyway). So what you propose is to spend 100+
>>> cycles to save half a cycle. Not a good tradeoff ;)
>>>
>>
>> Wrong!
>
> Is it wrong that the cpu can predict the target perfectly? No. Unless
(Continue reading)

Permalink | Reply | 0 comments |
headers
Greg KH | 28 Mar 01:09
Gravatar

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

On Sun, Mar 27, 2005 at 11:16:54AM -0800, Aaron Gyes wrote:
> > And then the user want to upgrade the 2.0 kernel that shipped with this 
> > box although the company that made the hardware went bankrupt some years 
> > ago.
> > 
> > If the user has the source of the driver, he can port the driver or hire 
> > someone to port the driver (this "obscure piece of hardware" might also 
> > be an expensive piece of hardware).
> 
> So what? Sure, GPL'd drivers are easier for an end-user in that case.
> What does that have to do with law? What about what's better for the
> company that made the device? Should NVIDIA be forced to give up their
> secrets to all their competitors because some over zealous developers
> say so? Should the end-users of the current drivers be forced to lose
> out on features such as sysfs and udev compatability?

It's not zealotry, it's called being compliant with the license of the
kernel.  It's as simple as that.  

If you ignore the license, you will suffer the consequences of it, just
like if you ignore the license of any closed source chunk of software.
Would you expect the owner of that software to turn a blind eye toward
violators?

greg k-h
Permalink | Reply | 0 comments |
headers
Mauro Mozzarelli | 28 Mar 01:37

imps2 mouse driver and bug 2082

The mouse driver, re-developed for kernel 2.6, ever since the earliest
2.6 release lost the ability to reset a broken link with an IMPS2 mouse
(this happens when disconnecting the mouse plug either physically or
through a "non imps2" KVM switch). The result is that the mouse can no
longer be controlled, with the only solution being a RE-BOOT!

This issue has been filed as bug 2082
(http://bugme.osdl.org/show_bug.cgi?id=2082) . A fix was posted for
2.6.8, but this patch never made its way into the kernel main stream.
"Vojtech", author of the 2.6 mouse driver, keeps modifying his code
version after version, therefore breaking compatibility with the posted
patch. I adapted the patch for 2.6.9 and 2.6.10 (there are now three
versions for 2.6.8, 2.6.9 and 2.6.10). Kernel 2.6.11(.6) was released
recently, still with the same bug, and would require further adaptation
of the posted patch.

I was wondering if some business related priority could be set for this
issue.

Given that most Linux deployments are in server farms, where boxes
share a console attached to a KVM that might good enough, but not
properly supporting IMPS2, please, could we include this patch in the
kernel main stream before adding support for any new mouse device that
hardly anyone running a server would be interested in?

Mauro
Permalink | Reply | 2 comments |
headers
Benjamin Herrenschmidt | 28 Mar 01:42

Mac mini sound woes

Hi Takashi !

I'm looking into adding proper sound support for the Mac Mini. The
problem is that from what I've seen (Apple driver is only partially
opensource nowadays it seems, and the latest darwin drop is both
incomplete and doesn't build), that beast only has a fixed function D->A
converter, no HW volume control.

It seems that Apple's driver has an in-kernel framework for doing volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they get DMA'ed (gack !)

I want to avoid something like that. How "friendly" would Alsa be to
drivers that don't have any HW volume control capability ? Does typical
userland libraries provide software processing volume control ? Do you
suggest I just don't do any control ? Or should I implement a double
buffer scheme with software gain as well in the kernel driver ?

Ben.
Permalink | Reply | 25 comments |
headers
Jesper Juhl | 28 Mar 01:51
Picon

Re: [RFC] spinlock_t & rwlock_t break_lock member initialization (patch seeking comments included)

On Sun, 27 Mar 2005, Zwane Mwaikambo wrote:

> On Sun, 27 Mar 2005, Jesper Juhl wrote:
> 
> > I've now been running kernels (both PREEMPT, SMP, both and without both) 
> > with the patch below applied for a few days and I see no ill effects. I'm 
> > still interrested in comments about wether or not something like this 
> > makes sense and is acceptable ?
> 
> The concept seems fine to me, although i think you should be using named 
> initialisers instead.
> 
I wrote it the way I did to keep it similar to how the other members were 
initialized, I wouldn't mind a different approach, but doing it this way 
seemed to be what would "fit in" best, and it did the trick for me 
(silenced the annoying warnings) and seemed safe.

Thank you for taking the time to comment on this trivial issue.

--

-- 
Jesper
Permalink | Reply | 1 comment |
headers
Steven Rostedt | 28 Mar 01:54
Gravatar

Re: Can't use SYSFS for "Proprietry" driver modules !!!.

On Mon, 2005-03-28 at 00:01 +0200, Adrian Bunk wrote:
> On Sun, Mar 27, 2005 at 01:37:11PM -0500, Steven Rostedt wrote:
> >...
> > Wasn't this long ago proven in court that the license of headers can't
> > control the code that calls them.  IIRC, it was with X Motif and making
> > free libraries for that. So, actually it was for a free solution for a
> > non free one (the other way around).  I believe the case sided on the
> > free use. But then again the free code may have had to write their own
> > headers and only the API was free. So if you want to compile against the
> > kernel, you may need to work on rewriting the headers from scratch. Ah,
> > but what do I know?
> >...
> 
> How do you define "proven in court"?
> 
> Decided by an US judge based on US laws?
> Decided by a German judge based on German laws?
> Decided by a Chinese judge based on Chinese laws?
> ...
> 

OK, I was talking about US courts since that case was done in the US.
But this is all what I remember about reading some 10 years ago. So I
could be all wrong about what happened. I don't have any references and
I'm too busy now to look them up. So I may be just speaking out of my
ass. :-)

> If you distribute software you can be sued in every country you 
> distribute it.
>
(Continue reading)

Permalink | Reply | 4 comments |
headers
Benjamin Herrenschmidt | 28 Mar 02:24

[PATCH] radeonfb: Fix mode setting on CRT monitors

Hi !

Current radeonfb is a bit "anal" about accepting CRT modes, it basically only
accepts modes that have the exact resolution, which tends to break with fbcon
on console switches as it provides "approximate" modes. This patch fixes it
by having the driver chose the closest possible mode instead of looking for
an exact match.

Signed-off-by: Benjamin Herrenschmidt <benh <at> kernel.crashing.org>

--- linux-work.orig/drivers/video/aty/radeon_monitor.c	2005-03-11 16:54:25.000000000 +1100
+++ linux-work/drivers/video/aty/radeon_monitor.c	2005-03-11 16:58:04.000000000 +1100
@@ -903,7 +903,7 @@
  */

 /*
- * This is used when looking for modes. We assign a "goodness" value
+ * This is used when looking for modes. We assign a "distance" value
  * to a mode in the modedb depending how "close" it is from what we
  * are looking for.
  * Currently, we don't compare that much, we could do better but
@@ -912,13 +912,11 @@
 static int radeon_compare_modes(const struct fb_var_screeninfo *var,
 				const struct fb_videomode *mode)
 {
-	int goodness = 0;
+	int distance = 0;

-	if (var->yres == mode->yres)
-		goodness += 10;
(Continue reading)

Permalink | Reply | 2 comments |
headers
Jim Carter | 28 Mar 02:27

Re: Disc driver is module, software suspend fails

On Fri, 25 Mar 2005, Pavel Machek wrote:

> There's another feature that enables you to start resume manually with
> some echo to /sys... Perhaps it needs to be documented better, I'm
> looking for a patch ;-).

But how can it resume from a swap device for which it has no driver?
Even if you copied the needed module(s) onto the swap device, the kernel
needs the modules to be loaded before it can read anything.  The driver 
would be there if resuming happened after the initrd loaded it.  But
I wasn't able to make that actually work.

James F. Carter          Voice 310 825 2897    FAX 310 206 6673
UCLA-Mathnet;  6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: jimc <at> math.ucla.edu  http://www.math.ucla.edu/~jimc (q.v. for PGP key)
Permalink | Reply | 3 comments |
headers
Benjamin Herrenschmidt | 28 Mar 02:27

Re: Problems on Apple iBook with ALSA and snd-powermac [2.6.11.5]

On Mon, 2005-03-28 at 01:08 +0200, Martin Loschwitz wrote:
> Hi folks,
> 
> given that the alsa-user-mailinglist has some strange kind of authentication
> mechanism, and admin-authorization and whatever, I'm writing this mail to the
> LKML (it would have been CCed here anyway).
> 
> The current snd-powermac module from ALSA seems to have trouble with modern
> Apple iBook computers (and possible other Apple notebooks, but I can't tell
> for sure). With 2.6.11.5 and having snd-powermac loaded, playing some sound
> results in a very noisy playback; you can only hear that if you turn volume
> on the PCM and VOL mixers up to the maximum, and even then, it's very hard 
> to hear. After removing snd-powermac and loading the "old" pmac-driver, the
> sound playback works just fine.

Have you tried disabling DRC Or increasing the DRC range level ?

> I have been able to find out that with 2.6.8 (at least with the version that
> Debian ships currently), the problem does not appear; snd-powermac does its
> job very nicely there. Given that 2.6.11 included some ALSA changes, I just
> compiled 2.6.10 on this box and booted it, and had the same problems I have
> with snd-powermac on 2.6.11.5.
> 
> Is this a known problem and is a fix available for it? If not, what can I do
> to help with hunting this bug? I really like ALSA and prefer it over the old
> pmac-sound-driver.
> 
--

-- 
Benjamin Herrenschmidt <benh <at> kernel.crashing.org>
(Continue reading)

Permalink | Reply | 0 comments |

Gmane