This is a known issue that I'm going to be looking at soon... I've noticed this in 2.6.5-2.6.7, and I've heard it's never worked. fvdpol is going to test it out on amd64 for me since my amd64 box is a production system that I can't afford to lockup and wait 3 hours for RAID to resync =). Thanks. I really want this issue solved before we tackle the cs4231 problems on sparc.
Alsa has a bug for this at https://bugtrack.alsa-project.org/alsa-bug/bug_view_page.php?bug_id=0000167
I bit the bullet and verrified that it was sparc specific... so it's probably some asm-* or endian issue...
Some new info about this on the sparclinux ml recently. The following is from davem; On Thu, 11 Nov 2004 12:00:24 +0100 sjoerd@spring.luon.net (Sjoerd Simons) wrote: > After some debugging it seems that some alsa ioctl have a pointer to a > userspace pointer in their argument struct. When doing a copy_to_user in the > native ioctl to that address (thus directly to the 32bit userspace program > while get_fs() == KERNEL_DS), the machine just hangs. Is this something > that can't be done on sparc64 ? That's right, this action is illegal and will hang the machine. Unfortunately, on x86_64 this happens to work and that appears to be where most of the ioctl32 compat stuff gets tested and developed. If get_fs() == KERNEL_DS all "user" pointers are expected to be in kernel space and thus access to real user addresses will fail.
whee... that's good news. I've got test hell this week, but maybe next week we can et this working
On Tue, Nov 16, 2004 at 09:55:23PM -0800, Jeremy Huddleston wrote: > Hi, > > I've been keeping this very issue on the backburner for quite some time > now as it's been a real pain in the arse to debug. Do you have a patch > that you could provide? Have you fixed the other ioclt or atleast have > a list of the ones you haven't gotten to yet? I had the one mentioned in my mail fixed, but it's pretty easy. Hopefully i can play again this weekend to get the others ``fixed''. I saw there were some fixes to the ioctl32 stuff in 2.6.10-rc2, so it's worth to start there. Basically to find the wrong ioctls, just grep for compat_ptr in sound/core/ioctl32. I think it makes for a total of 3 or 4 ioctl's that need fixing. Sjoerd
Created attachment 44333 [details, diff] fixes SNDRV_CTL_IOCTL_ELEM_LIST This fixes SNDRV_CTL_IOCTL_ELEM_LIST (NOT ALL OF THEM). I made this patch based on the suggestions mentioned above from list... this gets 'amixer' to work...
Created attachment 44336 [details, diff] Fixes all but pcm32.c Ok, this patch fixes two more IOCTL32 problems... and the only ones left to fix are in pcm32.c ... but it's 2am, and I'm wiggin' out... if someone else wants to finish this and leave me a nice present in the morning, I'll be very happy... otherwise, I'll try to get to it this weekend...
Created attachment 44338 [details, diff] Fixes all but pcm32.c 2am brainfart... #fi -> #endif ... lala ok...
Created attachment 44339 [details, diff] Fixes all but pcm32.c silly symlinking in alsa-driver caused the patch to "double"... proof again that I need to get sleep...
ok, patch submitted upstream, added to alsa-driver-1.0.7, and I've made a patch to linux-2.6.7 which will hopefully be in g-d-s-2.6.7-r15 soon... at that point, I'll make a sub-profile to unmask the alsa USE flag and setup package.mask to block versions with bad ioctl32.
in portage... YAY!
