Alsa question.

Hi,

Use 2.6.0-test9-mm1 play xmms use OSS emulation sound sometimes distorted (did renice xmms to -10)
but apart from the time it got distorted, soudn quality is really good. If use
through esd the distorted is gone, but sound quality a bit worse.

The question is? How can I make xmms not distorted? SHould I specify the
option non_block mode to snd-pcm-oss? If yes how to do that as I compile alsa built
into the kernel (not a modules) so which kernel parameters do the job?

Plese CC me to haiquy <at> yahoo.com

Thanks

Steve Kieu

Homepage http://scorpius.spaceports.com/~skieu/

PGP Key http://scorpius.spaceports.com/~skieu/steve-pub.key

[2.6] GUI config targets fail with "make O=..."

Hi, Sam -

There's something in the 2.6 kbuild infrastructure that does some rather
wrong things for the gconfig and xconfig targets when object files
should go to a separate directory.

It looks like HOSTCXXFLAGS is being mangled somehow.  Here are the
interesting details:

make -C /home/bos/bk/kernel/key O=/tmp/build-i686-smp xconfig

This results in the following invocation of g++, which chokes:

g++ -Wp,-MD,scripts/kconfig/.qconf.o.d  -O2 \
	-I/home/bos/bk/kernel/key//usr/lib/qt-3.1/include \
	-c -o scripts/kconfig/qconf.o \
	/home/bos/bk/kernel/key/scripts/kconfig/qconf.cc

There are two problems here.  The first is the mangling of -I$(QTDIR) so
that it has a bizarre prefix.  The second is that -I$O/scripts/kconfig
is missing, so the compiler can't find the generated file lkc_defs.h
(which is generated correctly).

Any ideas on how to fix this?

	<b

Re: [PATCH] remove useless highmem bounce from loop/cryptoloop

On Fri, 31 Oct 2003 01:55:00 -0800, Andrew Morton wrote:
> Ben Slusky <sluskyb <at> paranoiacs.org> wrote:
> > The current memory allocation procedure really is inadequate. It worked
> > ok up thru 2.4 because the loop device was used almost exclusively
> > as a nifty hack to make an initrd or to double-check the ISO you just
> > created.
> 
> mm..  Last time I looked the 2.4 loop driver is fairly robust from the
> memory management point of view.

Memory management is fine after we've allocated the memory. The problem is
in the approach of going back to square one if only n-1 out of n pages
could be allocated. That approach is inherently prone to deadlock.

> Here's the patch; feel free to benchmark it.  It kills 200 lines of code
> and unifies the block-backed and file-backed codepaths.  That surely is a
> good thing.

I will benchmark it soon... meantime I have a real concern about what
you've done to block-backed loop reads. Now the loop thread has to read
and transform (decrypt) each bio, whereas in the old code reading was
done asynchronously in the backing block device driver, leaving the loop
thread free to do some transforms at the same time. I don't see how this
could not hurt performance.

> It fixes bug 1198 too, it appears.

The file-backed loop code path allocates memory in a sane fashion.
File-backed loops never manifested the bug.

pthread mutex question

Hi,
I am looking for an idea as to how to implement timed mutex using pthread
libraries on linux.
Basically I want to associate a timeout value with the wait function i,e
pthread_mutex_lock() which returns once the timeout expires instaed of
waiting for ever.
Pls help

thx..

Sankarshana M

Cyclic Scheduling for linux

> I am working on providing a cyclic scheduling policy
> to the current non real time version of the linux to
> support hard real time tasks as part of one of my
> projects. This policy should be able to support
> aperiodic, periodic and sporadic tasks too. Could any
> one pour some light on how to go about achieving it?.
>
> Any Helpful tips, project reports, links or advices
> are greatly appreciated.

I suppose you expect to write this, but if not,
you can get it in Concurrent's Red Hawk Linux
product.

Marketing says:

"RedHawk's Frequency-Based Scheduler (FBS) is a
high-resolution task scheduler that enables the
user to run processes in cyclical execution patterns.
FBS can control the periodic execution of multiple,
coordinated processes utilizing major and minor
cycles with overrun detection. A performance
monitor is also provided to view CPU utilization
during each scheduled execution frame."

That's on a "real" Linux kernel, not like RTAI
or RT-Linux. There are some other cool real-time
features as well, and an Ada compiler if you're
so inclined.

[Patch]Kernel 2.6.0-test9 compile on x86-64

I must say this is my first experience with a 2.6 kernel and it is very
fast and responsive.

I found that when compiling the 2.6.0-test9 for an athlon64 that the
symbol "ip_compute_csum" was not found by several network modules
including sk98lin with concerned me in perticular. A quick google search
revealed that IA64 had a similar problem in test6 and that ksyms for
x86-64 need to export "ip_compute_csum" to fix the problem.

Here's a diff of the change I made.

$ pwd
/usr/src/linux-2.6.0-test9/arch/x86_64/kernel

$ diff x8664_ksyms.c x8664_ksyms.c~
217c217
< EXPORT_SYMBOL(ip_compute_csum);
---
>

After making this change I was able to recompile my kernel and it works
because I am using my SK9521 to send this email.

regards,

--

-- 
Mark Lane, CET
Hard Data Ltd www.harddata.com
mark <at> harddata.com
780-456-9771

Re: pthread mutex question

Its C++, but you could have a look at the boost::thread::timed_mutex 
(www.boost.org) implementation, which makes use of pthread_cond_timedwait.

Regards

Arve Knudsen

On Fri, 31 Oct 2003 16:43:14 -0800, sankar <san_madhav <at> hotmail.com> wrote:

> Hi,
> I am looking for an idea as to how to implement timed mutex using pthread
> libraries on linux.
> Basically I want to associate a timeout value with the wait function i,e
> pthread_mutex_lock() which returns once the timeout expires instaed of
> waiting for ever.
> Pls help
>
> thx..
>
> Sankarshana M

Re: Something corrupts raid5 disks slightly during reboot

Try:

hdparm -W0 /dev/hdX

for each of your ide drives.  This turns off write-caching which is 
usually a bad thing with ide drives anyway.

Ville Herva wrote:

>I've been experiencing strange corruption on a raid5 volume for some time.
>Basically, after unmounting the filesystem, I can mount it again without
>problems. I can also raidstop the raid device in between and all is still
>fine:
>
>  
>
>>umount /dev/md4; mount /dev/md4
>>    
>>
>    - no corruption
>  
>
>>umount /dev/md4; raidstop /dev/md4; raidstart /dev/md4; mount /dev/md4
>>    
>>
>    - no corruption
>
>But after a reboot, the filesystem is corrupted:
>
>  

Re: Something corrupts raid5 disks slightly during reboot

On Fri, Oct 31, 2003 at 07:41:30PM -0600, Jeffrey E. Hundstad wrote:
> Try:
> 
> hdparm -W0 /dev/hdX
> 
> for each of your ide drives.  This turns off write-caching which is 
> usually a bad thing with ide drives anyway.
> 

Also try installing smartmontools, and run smartmon -a on each of the
drives.  It might tell you one of the drives is going bad...

[BLOCK] phys_contig implies hw_contig

Hi:

In ll_merge_requests_fn, it is checking blk_hw_contig_segments even if
blk_phys_contig_segments succeeds.  This means that it may cause two
physically contiguous segments to be separated because the hw check
fails.

This patch fixes that.

Cheers,
-- 
Debian GNU/Linux 3.0 is out! ( http://www.debian.org/ )
Email:  Herbert Xu ~{PmV>HI~} <herbert <at> gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Index: kernel-source-2.5/drivers/block/ll_rw_blk.c
===================================================================
RCS file: /home/gondolin/herbert/src/CVS/debian/kernel-source-2.5/drivers/block/ll_rw_blk.c,v
retrieving revision 1.9
diff -u -r1.9 ll_rw_blk.c
--- kernel-source-2.5/drivers/block/ll_rw_blk.c	11 Oct 2003 06:29:20 -0000	1.9
+++ kernel-source-2.5/drivers/block/ll_rw_blk.c	1 Nov 2003 02:24:52 -0000
 <at>  <at>  -1046,16 +1046,16  <at>  <at> 
 		return 0;

 	total_phys_segments = req->nr_phys_segments + next->nr_phys_segments;
-	if (blk_phys_contig_segment(q, req->biotail, next->bio))
+	total_hw_segments = req->nr_hw_segments + next->nr_hw_segments;