headers
Alan Cox | 1 Aug 2002 02:08
Picon

Re: [PATCH] 2.5.29: some compilation fixes for irq frenzy [OSS + i8x0 audio]

On Wed, 2002-07-31 at 22:50, Andy Pfiffer wrote: 
> On Tue, 2002-07-30 at 15:47, Alan Cox wrote:
> > On Tue, 2002-07-30 at 22:19, Andy Pfiffer wrote:
> > > As luck would have it, I booted the kernel and played the tunes on a
> > > 2-way P4 Xeon system.  Nothing wedged, but then again, I didn't try to
> > > break it.
> > > 
> > > So, what did I break?
> > 
> > SMP support I think. A lot of the save_flags/cli stuff you changed looks
> > like it needs to also lock out interrupts on the other processors,
> > otherwise you can get a DMA pointer being updated under you.
> 
> After reading the code in question, it appears to me that the existing
> save_flags/cli constructs are being used to atomically query/modify
> elements of an audio_devs[N] entry.  I can see how it might be possible
> for the patch to break SMP.
> 
> Would a spinlock_t for each "struct audio_operations" be the preferred
> solution over, say, a global spinlock_t for all "struct
> audio_operations?"
> 
> And while I'm asking: I'm a bit perplexed by the "naked" sti()'s in
> audio_write() and audio_read() for the case where CNV_MU_LAW conversion
> is required.  The intent appears to be to force interrupts back on
> during the format conversion.  I don't see any corresponding cli() on
> the return path, however.
> 
> Does anyone have any idea why those sti()'s just seem to be stuck there?
>
(Continue reading)

Permalink | Reply | 0 comments |
headers
Alan Cox | 1 Aug 2002 02:08
Picon

Re: [PATCH] 2.5.29: some compilation fixes for irq frenzy [OSS + i8x0 audio]

On Wed, 2002-07-31 at 22:50, Andy Pfiffer wrote:
> After reading the code in question, it appears to me that the existing
> save_flags/cli constructs are being used to atomically query/modify
> elements of an audio_devs[N] entry.  I can see how it might be possible
> for the patch to break SMP.

The cli() is doing a lock across all processors. The local_irqsave won't
protect other processors against the modifications. The ISA side of the
OSS audio world is midbogglingly ugly for this and for lock_kernel
horrors but the PCI side isnt too bad.

The DMA pointers in ISA OSS are also touched by interrupt handling code
- which again cli() locked across all processors and lock_irq* doesn't.

Rusty submitted a much better patch for this - deleting all the old OSS
ISA drivers, so that people can just fix and use the ALSA code instead.
I'm not saying don't analyse the locks and interrupt paths and fix the
OSS audio for ISA stuff, just that it might not be the best use of time
even if you do get it sorted out.
Permalink | Reply | 2 comments |
headers
Dave Jones | 1 Aug 2002 01:02
Picon

Re: [PATCH] 2.5.29: some compilation fixes for irq frenzy [OSS + i8x0 audio]

On Thu, Aug 01, 2002 at 01:08:12AM +0100, Alan Cox wrote:
 > Rusty submitted a much better patch for this - deleting all the old OSS
 > ISA drivers, so that people can just fix and use the ALSA code instead.
 > I'm not saying don't analyse the locks and interrupt paths and fix the
 > OSS audio for ISA stuff, just that it might not be the best use of time
 > even if you do get it sorted out.

Are there any OSS drivers for any particular cards for which we don't have
an equivalent ALSA driver ?  If we're ultimately going to be dropping
any of the OSS drivers, I'd rather know about it so I don't waste time
pushing the ~200kb of patches in that area I'm currently carrying
towards Linus.  (Given that most of them don't compile right now due to
the collateral damage from the cli() etc changes , I'd *love* to take
the lazy^Weasy option and just drop them)

        Dave

--

-- 
| Dave Jones.        http://www.codemonkey.org.uk
| SuSE Labs
Permalink | Reply | 1 comment |
headers
Russell King | 1 Aug 2002 01:00
Picon

Re: [PATCH] console part 2.

On Wed, Jul 31, 2002 at 03:27:57PM -0700, James Simmons wrote:
> Here is the second patch. It has many fixes and alot of major changes
> internally.

A quick read through reveals:

-		printk("mdacon: MDA card not detected.\n");
+		printk("KERN_WARNING mdacon: MDA card not detected.\n");

KERN_WARNING and friends should be outside the quotes.

Secondly, the absolutely gigantic "switch (vc_state) {" stuff with
extra layers of switch statements below it in decvte.c - I find this
rather disgusting to read.  I bet the resulting asm is also disgusting.
Isn't there a cleaner solution to this?  (I've been carrying around
since 2.2 patches to the console layer to split this up mainly because
some older versions of ARM gcc choked on it.  I'm not certain about
current versions though.)

Also, something that should probably be fixed one day, but I wouldn't
call it a show stopper:

-#define SIZE(x) (sizeof(x)/sizeof((x)[0]))
+#define SIZE(x)	(sizeof(x)/sizeof((x)[0]))

We have ARRAY_SIZE(x) in linux/kernel.h which does this already.

--

-- 
Russell King (rmk <at> arm.linux.org.uk)                The developer of ARM Linux
             http://www.arm.linux.org.uk/personal/aboutme.html
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Cox | 1 Aug 2002 02:34
Picon

Re: Interrupt trouble due to IRQ router VIA?

On Wed, 2002-07-31 at 21:15, Kathy Frazier wrote:
> another system.  In this system, the driver times out on the 
> interruptible_sleep_on_timeout waiting for the interrupt.  One thing that I 

There is a classic kernel programming error which goes something like
this

my_interrupt()
{
	foo->ready = 1;
	wake_up(&foo_pending);
}

foo_read()
{
	while(!foo->ready && !signal_pending(current))
		interruptible_sleep_on(&foo_pending);

}

What happens then is this

	foo->ready = 0 - true
	signal pending = 0 - ok

		INTERRUPT
			foo->ready=1
			wake up
		END INTERRUPT
(Continue reading)

Permalink | Reply | 1 comment |
headers
Alan Cox | 1 Aug 2002 02:37
Picon

Re: Linux 2.4.19ac3rc3 on IBM x330/x340 SMP - "ps" time skew

On Wed, 2002-07-31 at 20:14, Albert D. Cahalan wrote:
> Alan Cox writes:
> > On Wed, 2002-07-31 at 13:59, David Luyer wrote:
> 
> >>   printf("%d\n", sysconf(_SC_NPROCESSORS_CONF));
> >> }
> >> luyer <at> praxis8:~$ ./cpus
> >> 4
> >> luyer <at> praxis8:~$ grep 'processor        ' /proc/cpuinfo
> >> processor       : 0
> >> processor       : 1
> >
> > In which case I suggest you file a glibc bug. sysconf looks at the /proc
> > stuff as I understand it
> 
> First you blame ps. Then you blame libc. How about you
> place the fault right where it belongs?

ps is certainly buggy. HZ is 100. ps grovelling around in /proc is bogus
to say the least. That code wasn't exactly well written.

> Counting processors in /proc/cpuinfo is a joke of an ABI.
> 
> Add a proper ABI now, and userspace can transition to it
> over the next 4 years.

Which is what I've been talking to Ulrich about.
Permalink | Reply | 3 comments |
headers
Alan Cox | 1 Aug 2002 02:31
Picon

Re: [2.6] The List, pass #2

On Wed, 2002-07-31 at 21:34, Trond Myklebust wrote:
> Care to comment on why it is not GPL compatible? Given that they are
> interested in merging their code into the standard kernel ASAP, I know
> that they'd be interested in correcting any incompatibilities.

The 3 clause BSD though very much a completely free/open license has
requirements conflicting with the GPL 

http://www.fsf.org/licenses/license-list.html#GPLIncompatibleLicenses
http://www.fsf.org/philosophy/bsd.html

An additional problem with a BSD like license is that it makes no
statement on patents - regrettably a critical issue now days in the
USSA. That means nothing prevents CITI from providing BSD licensed code
and then 6 months later sueing everyone who used it. I don't see CITI
doing that but the basic problem is still there.

If it is all their own code, and they want to have a BSD licensed copy
for other reasons - eg to merge the same code into BSD, sell it to
proprietary vendors or whatever, then it would be immensely saner if
they would submit a copy for the Linux kernel under the GPL and keep it
dual licensed. As the owner of a work they can license it many many ways
all at the same time.

The random driver has a nice example of this.

Alan
Permalink | Reply | 2 comments |
headers
Alan Cox | 1 Aug 2002 02:41
Picon

Re: [PATCH] 2.5.29: some compilation fixes for irq frenzy [OSS + i8x0 audio]

On Thu, 2002-08-01 at 00:02, Dave Jones wrote:
> Are there any OSS drivers for any particular cards for which we don't have
> an equivalent ALSA driver ?  If we're ultimately going to be dropping
> any of the OSS drivers, I'd rather know about it so I don't waste time
> pushing the ~200kb of patches in that area I'm currently carrying
> towards Linus.  (Given that most of them don't compile right now due to
> the collateral damage from the cli() etc changes , I'd *love* to take
> the lazy^Weasy option and just drop them)

ALSA should have complete coverage of everything but some weird corner
cases like the bose speaker setup. For those its going to be far better
to fix ALSA (and plugging a new isa card into alsa is really easy) than
lug the entire OSS mess around for it.
Permalink | Reply | 0 comments |
headers
Rusty Russell | 1 Aug 2002 01:28
Picon
Gravatar

Re: [PATCH] automatic module_init ordering

In message <Pine.LNX.4.44.0207311201000.19799-100000 <at> chaos.physics.uiowa.edu> y
ou write:
> On Wed, 31 Jul 2002, Rusty Russell wrote:
> 
> > My PARAM code actually maps - to _ in parameter parsing, for exactly
> > this reason.  And only a complete idiot would put , in a module name,
> > so I don't care 8)
> 
> Tell that to the author of 53c7,8xx.o ;)

Consider that done.

> > As it happens, the configuration doesn't allow more than one to be
> > built in (they can all be modules though), so it's not actually a
> > problem even after parameter unification.
> 
> Hmmh, I think that'll need some testing. It will be fine if only one of 
> the three is "y", the others being "n/undef". However, it looks like it's 
> possible to have sth like "m/m/y", which would go wrong with the current 
> approach.

That's a bug.  That configuration makes no sense (the modules won't
load).  Hmmm... more Config.in complexity coming up 8(

Rusty.
--
  Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
Permalink | Reply | 0 comments |
headers
Matt_Domsch | 1 Aug 2002 01:38
Picon
Favicon

RE: 2.5.28 and partitions

> Matt> What's wrong with EFI GUID scheme (GPT) (other than it wasn't
> Matt> invented by Linux folks)?
> 
> Nothing, except it's not used on all platforms yet.

(set boot issues aside for now)
It could.  I use it on x86 and IA-64 now.  I think Richard Hirst found the
last (knock on wood) of my endianness bugs about 6 months ago, so I know it
works on BE and LE non-Intel machines.  It's in the partitioning menu, not
specific to arch.  The only arch dependency in code is on asm-ia64/efi.h for
some typedefs, which is annoying but not hard to fix if desired (move
relevant bits to include/linux/efi.h).

> For my machines the *only* reason for having a legacy partitioning
> scheme is to allow booting.

As you point out, booting is BIOS-specific.  So for now boot a disk with a
native scheme (where your OS resides already) and mount that 64XB file
system for data afterwords.  By the time that doesn't work, 32-bit CPUs will
be dead anyhow.

Thanks,
Matt

--
Matt Domsch
Sr. Software Engineer, Lead Engineer, Architect
Dell Linux Solutions www.dell.com/linux
Linux on Dell mailing lists  <at>  http://lists.us.dell.com
#1 US Linux Server provider for 2001 and Q1/2002! (IDC May 2002)
(Continue reading)

Permalink | Reply | 0 comments |

Gmane