Re: getting FUSD compiled with current kernels
On Sunday 30 September 2007, Florian Schmidt wrote: > On Sunday 30 September 2007, Lee Revell wrote: > > On 9/29/07, Florian Schmidt <[EMAIL PROTECTED]> wrote: > > > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a > > > later goal is to create a virtual ALSA soundcard [which would multiplex > > > access to a real non hw-mixing capable soundcard] to finally end the > > > dmix software mixing woes linux users have to endure for the last years > > > :) > > > > What problems with ALSA's userspace mixing are you trying to solve? [snip] Thinking about it some more i think the plan isn't quite as simple to implement as i thought.. Some more work would have to be done than to simply provide the device file infrastructure of an ALSA device driver.. Well, right now, i'm happy enough to have oss2jack and kfusd built and running.. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Sunday 30 September 2007, Lee Revell wrote: > On 9/29/07, Florian Schmidt <[EMAIL PROTECTED]> wrote: > > My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later > > goal is to create a virtual ALSA soundcard [which would multiplex access > > to a real non hw-mixing capable soundcard] to finally end the dmix > > software mixing woes linux users have to endure for the last years :) > > What problems with ALSA's userspace mixing are you trying to solve? I think that for example the aoss approach to providing software mixing to OSS apps is fundamentally flawed. The LD_PRELOAD_LIBRARY mechanism does not work for all applications. The OSS emultion in ALSA that does work for pretty much all OSS apps is the kernel level OSS emulation [which directly provides the OSS conform device files] sitting directly on an ALSA device driver module. Having a virtual ALSA soundcard which would route back to userspace one could make the OSS emu use this device instead providing to-userspace routing of all OSS apps.. The same argument, though in a weaker form holds for badly coded ALSA apps which open soundcards "directly" via "hw:0" pcm device names. It would be cool, if these could be made to play nice trivially. Here again, a virtual ALSA device which routes back to userspace would be great.. Simply make the virtual device card 0 in the system.. Dmix wouldn't be obsoleted by this at all. I'm not sure on the details (still learning), but the virtual ALSA device routing the signal back to user space could then in turn use dmix on a real alsa device to provide the sw mixing (it would indeed be a very thin userspace driver as it basically directly uses an ALSA pcm as "slave").. This is not thought of as a replacement for ALSA userspace libasound2.. Not at all. It's just a cool thing to have (tm) in many situations, solving these cases which drive some ALSA users (me included) nuts :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Sunday 30 September 2007, Lee Revell wrote: On 9/29/07, Florian Schmidt [EMAIL PROTECTED] wrote: My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal is to create a virtual ALSA soundcard [which would multiplex access to a real non hw-mixing capable soundcard] to finally end the dmix software mixing woes linux users have to endure for the last years :) What problems with ALSA's userspace mixing are you trying to solve? I think that for example the aoss approach to providing software mixing to OSS apps is fundamentally flawed. The LD_PRELOAD_LIBRARY mechanism does not work for all applications. The OSS emultion in ALSA that does work for pretty much all OSS apps is the kernel level OSS emulation [which directly provides the OSS conform device files] sitting directly on an ALSA device driver module. Having a virtual ALSA soundcard which would route back to userspace one could make the OSS emu use this device instead providing to-userspace routing of all OSS apps.. The same argument, though in a weaker form holds for badly coded ALSA apps which open soundcards directly via hw:0 pcm device names. It would be cool, if these could be made to play nice trivially. Here again, a virtual ALSA device which routes back to userspace would be great.. Simply make the virtual device card 0 in the system.. Dmix wouldn't be obsoleted by this at all. I'm not sure on the details (still learning), but the virtual ALSA device routing the signal back to user space could then in turn use dmix on a real alsa device to provide the sw mixing (it would indeed be a very thin userspace driver as it basically directly uses an ALSA pcm as slave).. This is not thought of as a replacement for ALSA userspace libasound2.. Not at all. It's just a cool thing to have (tm) in many situations, solving these cases which drive some ALSA users (me included) nuts :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Sunday 30 September 2007, Florian Schmidt wrote: On Sunday 30 September 2007, Lee Revell wrote: On 9/29/07, Florian Schmidt [EMAIL PROTECTED] wrote: My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal is to create a virtual ALSA soundcard [which would multiplex access to a real non hw-mixing capable soundcard] to finally end the dmix software mixing woes linux users have to endure for the last years :) What problems with ALSA's userspace mixing are you trying to solve? [snip] Thinking about it some more i think the plan isn't quite as simple to implement as i thought.. Some more work would have to be done than to simply provide the device file infrastructure of an ALSA device driver.. Well, right now, i'm happy enough to have oss2jack and kfusd built and running.. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Saturday 29 September 2007, Florian Schmidt wrote: > On Saturday 29 September 2007, Florian Schmidt wrote: > > Hi, > > > > I'm trying to build FUSD [1] against current kernels [2.6.22]. I get > > errors [2]: > > Oh i forgot to show the code snippets in question. I put them to the Oh and i also forget to mention that i get the same errors when using: KDIR=/usr/src/linux-source-2.6.22/ make [Where the ubuntu kernel package put the source. I configured it with the default ubuntu .config and make oldconfig]. I get one more message though: ~/source/build_stuff/fusd/kfusd$ KDIR=/usr/src/linux-source-2.6.22/ make make -C /usr/src/linux-source-2.6.22/ SUBDIRS=/home/tapas/source/build_stuff/fusd/kfusd EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../include modules make[1]: Entering directory `/usr/src/linux-source-2.6.22' WARNING: Symbol version dump /usr/src/linux-source-2.6.22/Module.symvers is missing; modules will have no dependencies and modversions. CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing pointer to incomplete type [...] Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Saturday 29 September 2007, Florian Schmidt wrote:
> Hi,
>
> I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors
> [2]:
Oh i forgot to show the code snippets in question. I put them to the
crresponding error below [matching line number is marked with [*]]:
>
> [2] ~/source/build_stuff/fusd$ make
> make -C libfusd
> make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd'
> make[1]: Nothing to be done for `default'.
> make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd'
> make -C kfusd
> make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd'
> make -C /lib/modules/2.6.22-11-generic/build
> SUBDIRS=/home/tapas/source/build_st
> uff/fusd/kfusd
> EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu
> de modules
> make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic'
> CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing
> poin
> ter to incomplete type
static inline struct kobject * to_kobj(struct dentry * dentry)
{
struct sysfs_dirent * sd = dentry->d_fsdata;
if(sd)
return ((struct kobject *) sd->s_element); [*]
else
return NULL;
}
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In
> function ‘fusd_register_de
> vice’:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
> kset’ has
> no member named ‘kset’
[...]
if(classdir2){
// jackpot. extract the class.
struct kobject *ko = to_kobj(classdir2);
sys_class = (ko?to_class(ko):NULL); [*]
if(!sys_class)
RDEBUG(2, "WARNING: sysfs entry for %s has no kobject!
\n",register_msg.clazz);
}
[...]
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type
> defaults t
> o ‘int’ in declaration of ‘__mptr’
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning:
> initialization
>
> >from incompatible pointer type
>
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
> kset’ has
> no member named ‘kset’
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level:
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown
> field ‘wr
> itev’ specified in initializer
STATIC struct file_operations fusd_fops = {
owner:THIS_MODULE,
open: fusd_open,
read: fusd_read,
write:fusd_write,
writev: fusd_writev, [*]
release: fusd_release,
poll: fusd_poll,
};
> /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning:
> initialization
>
> >from incompatible pointer type
>
> make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1
> make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2
> make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic'
> make[1]: *** [default] Error 2
> make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd'
> make: *** [default] Error 2
>
> [3] http://fort.xdas.com/~kor/oss2jack/
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
getting FUSD compiled with current kernels
Hi, I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors [2]: I tried looking into it but not being a kernel hacker i must admit i didn't even find out where sysfs_dentry is defined (so i can make the type complete). Or whether this would even be the correct way to fix it.. My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal is to create a virtual ALSA soundcard [which would multiplex access to a real non hw-mixing capable soundcard] to finally end the dmix software mixing woes linux users have to endure for the last years :) I don't expect you to fix it for me. I would just be glad about infos on where to get more infos enabling me to fix this :) Of course the more concise and practical the advice the better :) Regards, Flo [1] http://svn.xiph.org/trunk/fusd [2] ~/source/build_stuff/fusd$ make make -C libfusd make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd' make[1]: Nothing to be done for `default'. make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd' make -C kfusd make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd' make -C /lib/modules/2.6.22-11-generic/build SUBDIRS=/home/tapas/source/build_st uff/fusd/kfusd EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu de modules make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic' CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing poin ter to incomplete type /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘fusd_register_de vice’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’ has no member named ‘kset’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type defaults t o ‘int’ in declaration of ‘__mptr’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: initialization from incompatible pointer type /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’ has no member named ‘kset’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown field ‘wr itev’ specified in initializer /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning: initialization from incompatible pointer type make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1 make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd' make: *** [default] Error 2 [3] http://fort.xdas.com/~kor/oss2jack/ -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
getting FUSD compiled with current kernels
Hi, I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors [2]: I tried looking into it but not being a kernel hacker i must admit i didn't even find out where sysfs_dentry is defined (so i can make the type complete). Or whether this would even be the correct way to fix it.. My goal is to hack up oss2jack [3] to use ALSA pcm devices.. And a later goal is to create a virtual ALSA soundcard [which would multiplex access to a real non hw-mixing capable soundcard] to finally end the dmix software mixing woes linux users have to endure for the last years :) I don't expect you to fix it for me. I would just be glad about infos on where to get more infos enabling me to fix this :) Of course the more concise and practical the advice the better :) Regards, Flo [1] http://svn.xiph.org/trunk/fusd [2] ~/source/build_stuff/fusd$ make make -C libfusd make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd' make[1]: Nothing to be done for `default'. make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd' make -C kfusd make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd' make -C /lib/modules/2.6.22-11-generic/build SUBDIRS=/home/tapas/source/build_st uff/fusd/kfusd EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu de modules make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic' CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing poin ter to incomplete type /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘fusd_register_de vice’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’ has no member named ‘kset’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type defaults t o ‘int’ in declaration of ‘__mptr’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: initialization from incompatible pointer type /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct kset’ has no member named ‘kset’ /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown field ‘wr itev’ specified in initializer /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning: initialization from incompatible pointer type make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1 make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2 make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic' make[1]: *** [default] Error 2 make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd' make: *** [default] Error 2 [3] http://fort.xdas.com/~kor/oss2jack/ -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Saturday 29 September 2007, Florian Schmidt wrote:
Hi,
I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors
[2]:
Oh i forgot to show the code snippets in question. I put them to the
crresponding error below [matching line number is marked with [*]]:
[2] ~/source/build_stuff/fusd$ make
make -C libfusd
make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/libfusd'
make[1]: Nothing to be done for `default'.
make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/libfusd'
make -C kfusd
make[1]: Entering directory `/home/tapas/source/build_stuff/fusd/kfusd'
make -C /lib/modules/2.6.22-11-generic/build
SUBDIRS=/home/tapas/source/build_st
uff/fusd/kfusd
EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../inclu
de modules
make[2]: Entering directory `/usr/src/linux-headers-2.6.22-11-generic'
CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing
poin
ter to incomplete type
static inline struct kobject * to_kobj(struct dentry * dentry)
{
struct sysfs_dirent * sd = dentry-d_fsdata;
if(sd)
return ((struct kobject *) sd-s_element); [*]
else
return NULL;
}
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In
function ‘fusd_register_de
vice’:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
kset’ has
no member named ‘kset’
[...]
if(classdir2){
// jackpot. extract the class.
struct kobject *ko = to_kobj(classdir2);
sys_class = (ko?to_class(ko):NULL); [*]
if(!sys_class)
RDEBUG(2, WARNING: sysfs entry for %s has no kobject!
\n,register_msg.clazz);
}
[...]
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning: type
defaults t
o ‘int’ in declaration of ‘__mptr’
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: warning:
initialization
from incompatible pointer type
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2049: error: ‘struct
kset’ has
no member named ‘kset’
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: At top level:
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: error: unknown
field ‘wr
itev’ specified in initializer
STATIC struct file_operations fusd_fops = {
owner:THIS_MODULE,
open: fusd_open,
read: fusd_read,
write:fusd_write,
writev: fusd_writev, [*]
release: fusd_release,
poll: fusd_poll,
};
/home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:2603: warning:
initialization
from incompatible pointer type
make[3]: *** [/home/tapas/source/build_stuff/fusd/kfusd/kfusd.o] Error 1
make[2]: *** [_module_/home/tapas/source/build_stuff/fusd/kfusd] Error 2
make[2]: Leaving directory `/usr/src/linux-headers-2.6.22-11-generic'
make[1]: *** [default] Error 2
make[1]: Leaving directory `/home/tapas/source/build_stuff/fusd/kfusd'
make: *** [default] Error 2
[3] http://fort.xdas.com/~kor/oss2jack/
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: getting FUSD compiled with current kernels
On Saturday 29 September 2007, Florian Schmidt wrote: On Saturday 29 September 2007, Florian Schmidt wrote: Hi, I'm trying to build FUSD [1] against current kernels [2.6.22]. I get errors [2]: Oh i forgot to show the code snippets in question. I put them to the Oh and i also forget to mention that i get the same errors when using: KDIR=/usr/src/linux-source-2.6.22/ make [Where the ubuntu kernel package put the source. I configured it with the default ubuntu .config and make oldconfig]. I get one more message though: ~/source/build_stuff/fusd/kfusd$ KDIR=/usr/src/linux-source-2.6.22/ make make -C /usr/src/linux-source-2.6.22/ SUBDIRS=/home/tapas/source/build_stuff/fusd/kfusd EXTRA_CFLAGS=-I/home/tapas/source/build_stuff/fusd/kfusd/../include modules make[1]: Entering directory `/usr/src/linux-source-2.6.22' WARNING: Symbol version dump /usr/src/linux-source-2.6.22/Module.symvers is missing; modules will have no dependencies and modversions. CC [M] /home/tapas/source/build_stuff/fusd/kfusd/kfusd.o /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c: In function ‘to_kobj’: /home/tapas/source/build_stuff/fusd/kfusd/kfusd.c:135: error: dereferencing pointer to incomplete type [...] Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Miklos Szeredi wrote: > > > > Not as if it would be hard to add ioctl support to fuse. What fuse > > > > can't handle is the data argument of ioctl(), so the most it could do > > > > is give the filesystem a pid (tid) and a virtual address. The > > > > userspace fs could then get/put the data through /proc//mem. > > > > > > Hork... > > > > > > Identify the generic ioctls that are relevant to a FUSE file system and > > > have real meaning *and* are useful. > > > > I don't think there are any such. > > > > The point in this thread was I think about emulating an OSS sound > > device through a fuse fs. In that case fuse would need _generic_ > > ioctl support, which simply can't be done without weird userspace > > hacks. > > Well, had a look at what FUSD does. It assumes that the ioctl > argument is stuctured according to the command. If all OSS ioctls are > like that, then fine, fuse can support it properly. > > The drawback of this is that ioctls which aren't structured properly > could cause weird failures due to wrong data being accessed by the > poor unknowing kernel. > > Miklos Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Miklos Szeredi wrote: Not as if it would be hard to add ioctl support to fuse. What fuse can't handle is the data argument of ioctl(), so the most it could do is give the filesystem a pid (tid) and a virtual address. The userspace fs could then get/put the data through /proc/pid/mem. Hork... Identify the generic ioctls that are relevant to a FUSE file system and have real meaning *and* are useful. I don't think there are any such. The point in this thread was I think about emulating an OSS sound device through a fuse fs. In that case fuse would need _generic_ ioctl support, which simply can't be done without weird userspace hacks. Well, had a look at what FUSD does. It assumes that the ioctl argument is stuctured according to the command. If all OSS ioctls are like that, then fine, fuse can support it properly. The drawback of this is that ioctls which aren't structured properly could cause weird failures due to wrong data being accessed by the poor unknowing kernel. Miklos Included with the docs there's a list of the OSS ioctls. I don't understand enough of the problem to judge whether they are suitable to be handled by FUSE: http://manuals.opensound.com/developer/ioctl.html [version 4] http://www.4front-tech.com/pguide/oss.pdf [version 3] I don't know which API version is supposed to be supported though. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Anton Petrusevich wrote: > On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: > > Sadly it seems pretty much everyone, especially closed source apps get > > this wrong (but to be fair: loads of open source software gets it wrong, > > too, ekiga for example). > > Isn't that because there's a perferct documentation for programming ALSA > but authors of those apps can't read? No, like i said, the docs are unclear on these issues :) That's why so many people get it wrong. > But in real life I have to use flashplayer, for example. Yes, in these cases flashplayer should use either the default pcm device [which the user can then tweak to his liking] or provide some means to configure it. for example via a dotfile in the user's homedir. This is not ALSA's fault. > I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but > now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a > user. I agree that it would be nice to have a tool to select the default device in ALSA. > > But skype is a piece of crap anyways. It also doesn't get any sounds out > > of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a > > beep. And yeah, the device is available [and even has hardware > > multiplexing].. > > > > But 99.9% of problems people have with ALSA are due to badly coded apps.. > > "Those apps are crap and ALSA is perfect". I hoped some ALSA-developers > would think of improving usability of ALSA, or I would not talk here. ALSA must be improved, too. But that doesn't change a thing about these apps misusing the ALSA API and people blaming ALSA lateron. Which is wrong. > It's good that people are not thinking that ALSA is already perfect, it > leaves us (me) a hope it will be improved. I don't think any serious person believes that ALSA is perfect :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Adrian Bunk wrote: > There is also a userspace OSS emulation for ALSA not suffering from > these problems. Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to intercept library calls that open the /dev/dsp devices etc.. This doesn't always work. I suppose the best way to provide OSS emu is to use something like FUSD [similar to the OSS2JACK package] [1] to provide the OSS device files and then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD doesn't really get actively developed anymore it seems. And FUSE can't handle ioctls. [1] http://www.circlemud.org/~jelson/software/fusd/ Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Anton Petrusevich wrote:
> > > I have ICE1724, a very good sound card to my taste, works like a charm.
> > > But with ALSA I had a really hard time to configure it properly, wanna
> > > see my .asoundrc?
> >
> > Not particularly. I don't count as a great fan of the config file syntax
> > and don't use any configuration myself.
>
> Do you have an SPDIF out? If you don't then you don't need .asoundrc of
> course.
With a properly coded ALSA app, one doesn't need a .asoundrc. You would
enter "plug:spdif" [or something similar] into the pcm device name entry text
field.
Or if you want to point all apps to that device you actually could add this to
your .asoundrc:
pcm.!default {
type plug
slace.pcm "spdif"
}
[or something similar. Too lazy to look up the exact syntax now]. And then
every app using the ALSA API _correctly_ should use that device [if
configured to use the default device, which should be the _default_ ;)]
Sadly it seems pretty much everyone, especially closed source apps get this
wrong (but to be fair: loads of open source software gets it wrong, too,
ekiga for example).
What they do wrong is that they try to present a list of devices to the user
from which he can choose [which isn't bad in itself] and also do _not_ offer
any way to specify an arbitrary PCM device name.
Sadly, the ALSA api docs do not stress this point often enough, so it gets
missed pretty often.
I once posted an [not original, i suppose people before me got that idea, too]
idea to the alsa-dev list a while back, proposing a way to be able
to "register" pcm devices defined in .asoundrc/asound.conf, so that apps that
want to present a list to the user can simply ask ALSA for a list of devices
nd hav the user defined ones included. Sadly i don't think it ever went
anywhere..
> Because I want to route it differently, sometimes to spdif, sometimes to
> headphones, sometimes to mix sounds from different apps. Well, my config
> may be a bit ancient as it was written when dmix was not default.
Well, like i said, the application in question should allow you to enter any
pcm name you want. If it doesn't it's broken.
> I have read some advices for ice1724 already. The main reason I wrote to
> lkml -- I hate .asounrc and reading docs about it. I hate "flexebility"
> that requires restarting apps after changing sound routes.
I own a ice1712, too, but i only use it for JACK and it works brilliantly
there. But i know it can be a bitch to configure since it sports a 10/12
channel device which can be too complicated for some ALSA apps making
assumptions about the device they get ;)
> I perfectly know this one. I would like to use some really user-friendly
> tool.
I don't know of any. But any text editor will do.
> > > I want to be able to hear sound from flashplayer on my reciever or in
> > > my headphones -- how?
> >
> > Not sure? Is your receiver on an analog output and are your headphones
>
> My receiver is on spdif out.
The flashplayer has been another one of these badly coded apps ;) Maybe that
has changed in recent releases.
> > It's not working without an .asoundrc?
>
> Looks like it's not working with. As skype is not so informative.
But skype is a piece of crap anyways. It also doesn't get any sounds out of my
other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And
yeah, the device is available [and even has hardware multiplexing]..
> I am not about ice1724 or .asounrc here. I am trying to talk about
> user-friendliness of ALSA. It's very unfriendly.
I agree. ALSA is not very userfriendly. Especially the missing proper device
enumeration support is a problem.
But 99.9% of problems people have with ALSA are due to badly coded apps..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Anton Petrusevich wrote:
I have ICE1724, a very good sound card to my taste, works like a charm.
But with ALSA I had a really hard time to configure it properly, wanna
see my .asoundrc?
Not particularly. I don't count as a great fan of the config file syntax
and don't use any configuration myself.
Do you have an SPDIF out? If you don't then you don't need .asoundrc of
course.
With a properly coded ALSA app, one doesn't need a .asoundrc. You would
enter plug:spdif [or something similar] into the pcm device name entry text
field.
Or if you want to point all apps to that device you actually could add this to
your .asoundrc:
pcm.!default {
type plug
slace.pcm spdif
}
[or something similar. Too lazy to look up the exact syntax now]. And then
every app using the ALSA API _correctly_ should use that device [if
configured to use the default device, which should be the _default_ ;)]
Sadly it seems pretty much everyone, especially closed source apps get this
wrong (but to be fair: loads of open source software gets it wrong, too,
ekiga for example).
What they do wrong is that they try to present a list of devices to the user
from which he can choose [which isn't bad in itself] and also do _not_ offer
any way to specify an arbitrary PCM device name.
Sadly, the ALSA api docs do not stress this point often enough, so it gets
missed pretty often.
I once posted an [not original, i suppose people before me got that idea, too]
idea to the alsa-dev list a while back, proposing a way to be able
to register pcm devices defined in .asoundrc/asound.conf, so that apps that
want to present a list to the user can simply ask ALSA for a list of devices
nd hav the user defined ones included. Sadly i don't think it ever went
anywhere..
Because I want to route it differently, sometimes to spdif, sometimes to
headphones, sometimes to mix sounds from different apps. Well, my config
may be a bit ancient as it was written when dmix was not default.
Well, like i said, the application in question should allow you to enter any
pcm name you want. If it doesn't it's broken.
I have read some advices for ice1724 already. The main reason I wrote to
lkml -- I hate .asounrc and reading docs about it. I hate flexebility
that requires restarting apps after changing sound routes.
I own a ice1712, too, but i only use it for JACK and it works brilliantly
there. But i know it can be a bitch to configure since it sports a 10/12
channel device which can be too complicated for some ALSA apps making
assumptions about the device they get ;)
I perfectly know this one. I would like to use some really user-friendly
tool.
I don't know of any. But any text editor will do.
I want to be able to hear sound from flashplayer on my reciever or in
my headphones -- how?
Not sure? Is your receiver on an analog output and are your headphones
My receiver is on spdif out.
The flashplayer has been another one of these badly coded apps ;) Maybe that
has changed in recent releases.
It's not working without an .asoundrc?
Looks like it's not working with. As skype is not so informative.
But skype is a piece of crap anyways. It also doesn't get any sounds out of my
other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And
yeah, the device is available [and even has hardware multiplexing]..
I am not about ice1724 or .asounrc here. I am trying to talk about
user-friendliness of ALSA. It's very unfriendly.
I agree. ALSA is not very userfriendly. Especially the missing proper device
enumeration support is a problem.
But 99.9% of problems people have with ALSA are due to badly coded apps..
Regards,
Flo
--
Palimm Palimm!
http://tapas.affenbande.org
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Thursday 28 June 2007, Adrian Bunk wrote: There is also a userspace OSS emulation for ALSA not suffering from these problems. Yeah, it suffers from other problems though. It uses an LD_PRELOAD hack to intercept library calls that open the /dev/dsp devices etc.. This doesn't always work. I suppose the best way to provide OSS emu is to use something like FUSD [similar to the OSS2JACK package] [1] to provide the OSS device files and then redirect to user space, so all ALSA pcm devices can be used.. Sadly FUSD doesn't really get actively developed anymore it seems. And FUSE can't handle ioctls. [1] http://www.circlemud.org/~jelson/software/fusd/ Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Is it time for remove (crap) ALSA from kernel tree ?
On Friday 29 June 2007, Anton Petrusevich wrote: On Friday 29 June 2007 12:30:54 Florian Schmidt wrote: Sadly it seems pretty much everyone, especially closed source apps get this wrong (but to be fair: loads of open source software gets it wrong, too, ekiga for example). Isn't that because there's a perferct documentation for programming ALSA but authors of those apps can't read? No, like i said, the docs are unclear on these issues :) That's why so many people get it wrong. But in real life I have to use flashplayer, for example. Yes, in these cases flashplayer should use either the default pcm device [which the user can then tweak to his liking] or provide some means to configure it. for example via a dotfile in the user's homedir. This is not ALSA's fault. I am with Linux since 1997, I know bunch of them. I used to use XEmacs, but now I prefer VIM. But I am not a .asoundrc programmer, I want to be just a user. I agree that it would be nice to have a tool to select the default device in ALSA. But skype is a piece of crap anyways. It also doesn't get any sounds out of my other [non ice1712] card. Neither in OSS nor in ALSA mode. Not a beep. And yeah, the device is available [and even has hardware multiplexing].. But 99.9% of problems people have with ALSA are due to badly coded apps.. Those apps are crap and ALSA is perfect. I hoped some ALSA-developers would think of improving usability of ALSA, or I would not talk here. ALSA must be improved, too. But that doesn't change a thing about these apps misusing the ALSA API and people blaming ALSA lateron. Which is wrong. It's good that people are not thinking that ALSA is already perfect, it leaves us (me) a hope it will be improved. I don't think any serious person believes that ALSA is perfect :) Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC priorities, can they be changed?
On Thursday 15 February 2007, Mike Panetta wrote: > I did try that. The BIOS only allows me to either allocate an IRQ to be > a PCI interrupt, or reserve it (for what I have no idea). The IRQ's > listed in the BIOS are also different from the ones Linux sees. I think > the BIOS is seeing the XT-PIC IRQ numbers and Linux is seeing the APIC > numbers. For example the little bios blurb that prints before the > system boots says the USB controller I am interested in is > assigned/using IRQ 10, Linux sees it using IRQ 18. > > I have found that I can keep Linux from using the APIC by disabling it > with a kernel command line switch, but that does not help, it just makes > Linux use the XT-PIC instead of the IO-APIC to do IRQ routing. > > So I guess I'm back to my original question of 'Would changing the > vector numbers do what I want?' and if the answer is 'yes', how would I > do it? With XT-PIC, there was a way to change the priotrities used by the IRQ. It was called irqtune iirc. Ah ya, http://cae.best.vwh.net/irqtune/ Dunno if there's something similar available for APIC.. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: APIC priorities, can they be changed?
On Thursday 15 February 2007, Mike Panetta wrote: I did try that. The BIOS only allows me to either allocate an IRQ to be a PCI interrupt, or reserve it (for what I have no idea). The IRQ's listed in the BIOS are also different from the ones Linux sees. I think the BIOS is seeing the XT-PIC IRQ numbers and Linux is seeing the APIC numbers. For example the little bios blurb that prints before the system boots says the USB controller I am interested in is assigned/using IRQ 10, Linux sees it using IRQ 18. I have found that I can keep Linux from using the APIC by disabling it with a kernel command line switch, but that does not help, it just makes Linux use the XT-PIC instead of the IO-APIC to do IRQ routing. So I guess I'm back to my original question of 'Would changing the vector numbers do what I want?' and if the answer is 'yes', how would I do it? With XT-PIC, there was a way to change the priotrities used by the IRQ. It was called irqtune iirc. Ah ya, http://cae.best.vwh.net/irqtune/ Dunno if there's something similar available for APIC.. Regards, Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 "IRQ handler type mismatch for IRQ 4"
On Monday 12 February 2007, Alan wrote: > > [ 23.783913] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ > > sharing enabled > > [ 23.787063] pnp: Device 00:0c activated. > > [ 23.787420] 00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A > > So the PnP layers put a device on IRQ 4, which is sensible > > > [ 37.516000] eth1: orinoco_cs at 0.0, irq 4, io 0x0100-0x013f > > The PCMCIA layer then ignores this and takes IRQ 4 simply because > although PnP has used it the IRQ isnt currently live > > > [ 53.58] IRQ handler type mismatch for IRQ 4 > > [ 53.58] current handler: pcmcia0.0 > > The serial IRQ setup fails > > > [ 53.58] [] setup_irq+0x135/0x1e0 > > [ 53.58] [] serial8250_interrupt+0x0/0xf0 > > [ 53.58] [] request_irq+0xa3/0xc0 > > [ 53.58] [] serial8250_startup+0x47e/0x4b0 > > [ 53.58] [] uart_startup+0x48/0x160 > > [ 53.58] [] uart_open+0xbf/0x460 > > This is all scary and generally not needed spew but handy for debug. > > Looks like a PCMCIA layer bug. It should be respecting IRQ assignment > (not just allocation) by other resource configuration layers. Ah thanks for taking a look. I was slowly getting the impression from older lkml posts, that this isn't really what stopped my wifi from functioning. It seems there are other reasons and i just stumbled across this harmless message in dmesg.. Thanks for clearing it up :) Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20 IRQ handler type mismatch for IRQ 4
On Monday 12 February 2007, Alan wrote: [ 23.783913] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled [ 23.787063] pnp: Device 00:0c activated. [ 23.787420] 00:0c: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A So the PnP layers put a device on IRQ 4, which is sensible [ 37.516000] eth1: orinoco_cs at 0.0, irq 4, io 0x0100-0x013f The PCMCIA layer then ignores this and takes IRQ 4 simply because although PnP has used it the IRQ isnt currently live [ 53.58] IRQ handler type mismatch for IRQ 4 [ 53.58] current handler: pcmcia0.0 The serial IRQ setup fails [ 53.58] [c0141a25] setup_irq+0x135/0x1e0 [ 53.58] [c0230930] serial8250_interrupt+0x0/0xf0 [ 53.58] [c0141b73] request_irq+0xa3/0xc0 [ 53.58] [c023086e] serial8250_startup+0x47e/0x4b0 [ 53.58] [c022bf58] uart_startup+0x48/0x160 [ 53.58] [c022cb9f] uart_open+0xbf/0x460 This is all scary and generally not needed spew but handy for debug. Looks like a PCMCIA layer bug. It should be respecting IRQ assignment (not just allocation) by other resource configuration layers. Ah thanks for taking a look. I was slowly getting the impression from older lkml posts, that this isn't really what stopped my wifi from functioning. It seems there are other reasons and i just stumbled across this harmless message in dmesg.. Thanks for clearing it up :) Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.20 "IRQ handler type mismatch for IRQ 4"
Hi, i upgraded my system from ubuntu edgy to feisty and a new kernel came with it (2.6.15 vs. 2.6.20). Sadly my wireless card (pcmcia) has stopped working under this system. Seeing a backttrace in the dmesg output made me believe it's a kernel problem. I built a vanilla kernel to see if maybe ubuntu mods are the issue, but no dice. I tried different combinations of boot parameters (pci=routeirq, etc..) It seems this message comes about when hald is started, but i don't know for sure. Anyways, here's my dmesg output (the relevant message is near the end, but i thought that maybe i should include it all). I'm grateful for all pointers, etc.. If you need more info, please let me know. Thanks, Flo [0.00] Linux version 2.6.20vanilla ([EMAIL PROTECTED]) (gcc version 4.1.2 20070129 (prerelease) (Ubuntu 4.1.1-31ubuntu2)) #1 Sat Feb 10 19:50:29 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize end [0.00] copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 [0.00] copy_e820_map() start: 000e size: 0002 end: 0010 type: 2 [0.00] copy_e820_map() start: 0010 size: 17ef end: 17ff type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 17ff size: ec00 end: 17ffec00 type: 3 [0.00] copy_e820_map() start: 17ffec00 size: 1400 end: 1800 type: 4 [0.00] copy_e820_map() start: fff8 size: 0008 end: 0001 type: 2 [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 17ff (usable) [0.00] BIOS-e820: 17ff - 17ffec00 (ACPI data) [0.00] BIOS-e820: 17ffec00 - 1800 (ACPI NVS) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] 0MB HIGHMEM available. [0.00] 383MB LOWMEM available. [0.00] Entering add_active_range(0, 0, 98288) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 -> 4096 [0.00] Normal 4096 ->98288 [0.00] HighMem 98288 ->98288 [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 ->98288 [0.00] On node 0 totalpages: 98288 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 735 pages used for memmap [0.00] Normal zone: 93457 pages, LIFO batch:31 [0.00] HighMem zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v000 PTLTD ) @ 0x000f7180 [0.00] ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x17ff4ea7 [0.00] ACPI: FADT (v001 IBMTP-T21 0x0604 0x) @ 0x17ffeb65 [0.00] ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x0604 LTP 0x0001) @ 0x17ffebd9 [0.00] ACPI: DSDT (v001 IBMTP-T21 0x0604 MSFT 0x010c) @ 0x [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] Allocating PCI resources starting at 2000 (gap: 1800:e7f8) [0.00] Detected 796.579 MHz processor. [ 14.103182] Built 1 zonelists. Total pages: 97521 [ 14.103188] Kernel command line: root=/dev/hda1 irqpoll [ 14.103232] Misrouted IRQ fixup and polling support enabled [ 14.103237] This may significantly impact system performance [ 14.103672] Local APIC disabled by BIOS -- you can enable it with "lapic" [ 14.103694] mapped APIC to d000 (01302000) [ 14.103703] Enabling fast FPU save and restore... done. [ 14.103710] Enabling unmasked SIMD FPU exception support... done. [ 14.103732] Initializing CPU#0 [ 14.103827] PID hash table entries: 2048 (order: 11, 8192 bytes) [ 14.105743] Console: colour VGA+ 80x25 [ 14.108609] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 14.110053] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 14.148765] Memory: 347012k/393152k available (1893k kernel code, 45576k reserved, 843k data, 316k init, 0k highmem) [ 14.148857] virtual kernel memory layout: [ 14.148860] fixmap : 0xfffa9000 - 0xf000 ( 344 kB) [ 14.148864] pkmap : 0xff80 - 0xffc0 (4096 kB) [ 14.148868] vmalloc : 0xd880 - 0xff7fe000 ( 623 MB) [ 14.148872] lowmem : 0xc000 -
2.6.20 IRQ handler type mismatch for IRQ 4
Hi, i upgraded my system from ubuntu edgy to feisty and a new kernel came with it (2.6.15 vs. 2.6.20). Sadly my wireless card (pcmcia) has stopped working under this system. Seeing a backttrace in the dmesg output made me believe it's a kernel problem. I built a vanilla kernel to see if maybe ubuntu mods are the issue, but no dice. I tried different combinations of boot parameters (pci=routeirq, etc..) It seems this message comes about when hald is started, but i don't know for sure. Anyways, here's my dmesg output (the relevant message is near the end, but i thought that maybe i should include it all). I'm grateful for all pointers, etc.. If you need more info, please let me know. Thanks, Flo [0.00] Linux version 2.6.20vanilla ([EMAIL PROTECTED]) (gcc version 4.1.2 20070129 (prerelease) (Ubuntu 4.1.1-31ubuntu2)) #1 Sat Feb 10 19:50:29 CET 2007 [0.00] BIOS-provided physical RAM map: [0.00] sanitize start [0.00] sanitize end [0.00] copy_e820_map() start: size: 0009f800 end: 0009f800 type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 0009f800 size: 0800 end: 000a type: 2 [0.00] copy_e820_map() start: 000e size: 0002 end: 0010 type: 2 [0.00] copy_e820_map() start: 0010 size: 17ef end: 17ff type: 1 [0.00] copy_e820_map() type is E820_RAM [0.00] copy_e820_map() start: 17ff size: ec00 end: 17ffec00 type: 3 [0.00] copy_e820_map() start: 17ffec00 size: 1400 end: 1800 type: 4 [0.00] copy_e820_map() start: fff8 size: 0008 end: 0001 type: 2 [0.00] BIOS-e820: - 0009f800 (usable) [0.00] BIOS-e820: 0009f800 - 000a (reserved) [0.00] BIOS-e820: 000e - 0010 (reserved) [0.00] BIOS-e820: 0010 - 17ff (usable) [0.00] BIOS-e820: 17ff - 17ffec00 (ACPI data) [0.00] BIOS-e820: 17ffec00 - 1800 (ACPI NVS) [0.00] BIOS-e820: fff8 - 0001 (reserved) [0.00] 0MB HIGHMEM available. [0.00] 383MB LOWMEM available. [0.00] Entering add_active_range(0, 0, 98288) 0 entries of 256 used [0.00] Zone PFN ranges: [0.00] DMA 0 - 4096 [0.00] Normal 4096 -98288 [0.00] HighMem 98288 -98288 [0.00] early_node_map[1] active PFN ranges [0.00] 0:0 -98288 [0.00] On node 0 totalpages: 98288 [0.00] DMA zone: 32 pages used for memmap [0.00] DMA zone: 0 pages reserved [0.00] DMA zone: 4064 pages, LIFO batch:0 [0.00] Normal zone: 735 pages used for memmap [0.00] Normal zone: 93457 pages, LIFO batch:31 [0.00] HighMem zone: 0 pages used for memmap [0.00] DMI 2.3 present. [0.00] ACPI: RSDP (v000 PTLTD ) @ 0x000f7180 [0.00] ACPI: RSDT (v001 PTLTDRSDT 0x0604 LTP 0x) @ 0x17ff4ea7 [0.00] ACPI: FADT (v001 IBMTP-T21 0x0604 0x) @ 0x17ffeb65 [0.00] ACPI: BOOT (v001 PTLTD $SBFTBL$ 0x0604 LTP 0x0001) @ 0x17ffebd9 [0.00] ACPI: DSDT (v001 IBMTP-T21 0x0604 MSFT 0x010c) @ 0x [0.00] ACPI: PM-Timer IO Port: 0x1008 [0.00] Allocating PCI resources starting at 2000 (gap: 1800:e7f8) [0.00] Detected 796.579 MHz processor. [ 14.103182] Built 1 zonelists. Total pages: 97521 [ 14.103188] Kernel command line: root=/dev/hda1 irqpoll [ 14.103232] Misrouted IRQ fixup and polling support enabled [ 14.103237] This may significantly impact system performance [ 14.103672] Local APIC disabled by BIOS -- you can enable it with lapic [ 14.103694] mapped APIC to d000 (01302000) [ 14.103703] Enabling fast FPU save and restore... done. [ 14.103710] Enabling unmasked SIMD FPU exception support... done. [ 14.103732] Initializing CPU#0 [ 14.103827] PID hash table entries: 2048 (order: 11, 8192 bytes) [ 14.105743] Console: colour VGA+ 80x25 [ 14.108609] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes) [ 14.110053] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes) [ 14.148765] Memory: 347012k/393152k available (1893k kernel code, 45576k reserved, 843k data, 316k init, 0k highmem) [ 14.148857] virtual kernel memory layout: [ 14.148860] fixmap : 0xfffa9000 - 0xf000 ( 344 kB) [ 14.148864] pkmap : 0xff80 - 0xffc0 (4096 kB) [ 14.148868] vmalloc : 0xd880 - 0xff7fe000 ( 623 MB) [ 14.148872] lowmem : 0xc000 - 0xd7ff
Re: [Jackit-devel] Re: jack, PREEMPT_DESKTOP, delayed interrupts?
On Wed, 31 Aug 2005 07:08:08 -0500 "Jack O'Quin" <[EMAIL PROTECTED]> wrote: > JACK sources already include a CHECK_PREEMPTION() macro which expands > to Ingo's special gettimeofday() calls. The trace is turned on and > then off automatically before and after the realtime critical section > in the process thread (see libjack/client.c). Just for completeness sake: you need to build jackd with --enable-preemption-check Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [Jackit-devel] Re: jack, PREEMPT_DESKTOP, delayed interrupts?
On Wed, 31 Aug 2005 07:08:08 -0500 Jack O'Quin [EMAIL PROTECTED] wrote: JACK sources already include a CHECK_PREEMPTION() macro which expands to Ingo's special gettimeofday() calls. The trace is turned on and then off automatically before and after the realtime critical section in the process thread (see libjack/client.c). Just for completeness sake: you need to build jackd with --enable-preemption-check Flo -- Palimm Palimm! http://tapas.affenbande.org - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
On Sat, 19 Feb 2005 02:33:00 +0100 sylvanino b <[EMAIL PROTECTED]> wrote: > Hi, > > Sorry, it's meant to run on linux. > Actually, patch provided is for linux 2.6.9 + kdb 4.4 > > > I have uploaded a new tarball and updated the webpage. > should be ok, > > Sylvain For some reason all i ever get to see is the front page.. Any link just leads to an empty page like this [screenshot]: http://affenbande.org/~tapas/kernelanalyzer_web.png I second lee's idea to move the project to sf.net or berlios. flo -- Palimm Palimm! http://affenbande.org/~tapas/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I wrote a kernel tool for monitoring / web page
On Sat, 19 Feb 2005 02:33:00 +0100 sylvanino b [EMAIL PROTECTED] wrote: Hi, Sorry, it's meant to run on linux. Actually, patch provided is for linux 2.6.9 + kdb 4.4 I have uploaded a new tarball and updated the webpage. should be ok, Sylvain For some reason all i ever get to see is the front page.. Any link just leads to an empty page like this [screenshot]: http://affenbande.org/~tapas/kernelanalyzer_web.png I second lee's idea to move the project to sf.net or berlios. flo -- Palimm Palimm! http://affenbande.org/~tapas/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
