You are not logged in.
Thx adrianx - that one really looked like it was working, and then I got this:
make[2]: *** No rule to make target `arch/x86/xen/vga.o', needed by `arch/x86/xen/built-in.o'. Stop.
make[1]: *** [arch/x86/xen] Error 2
make: *** [arch/x86] Error 2
==> ERROR: A failure occurred in build().
Aborting...
Offline
Can you build a vanilla kernel with no patches all the way through? If not, we need to solve that first.
If so, can you please paste the rejects file (occurring when you have the patch in my configuration)? Im really curious to see whats in there! Nothing is jumping out at me now..
Offline
I had some problems myself until I copied the patch directly from here - https://bugzilla.kernel.org/attachment.cgi?id=64722
Everything from "Signed-off-by: Oliver Neukum <oneukum@suse.de>" to "1.7.1"
Not sure why it made a difference, but could it have something to do with the BBCode code blocks or character encoding.... I don't know? Maybe the indentation is also important "@@ -41,6 +41,9 @@"?
It definitely is a very syntax-driven process..
Offline
Has the new kernel in testing addressed this yet? Kernel 3.0.4? I noticed this entry in the changelog:
Date: Fri Aug 19 07:55:10 2011 +0200
ALSA: usb-audio - Fix missing mixer dB information
commit 38b65190c6ab0be8ce7cff69e734ca5b5e7fa309 upstream.
The recent fix for testing dB range at the mixer creation time seems
to cause regressions in some devices. In such devices, reading the dB
info at probing time gives an error, thus both dBmin and dBmax are still
zero, and TLV flag isn't set although the later read of dB info succeeds.
This patch adds a workaround for such a case by assuming that the later
read will succeed. In future, a similar test should be performed in a
case where a wrong dB range is seen even in the later read.
Not sure if this applies or not.
Offline
Has the new kernel in testing addressed this yet? Kernel 3.0.4? I noticed this entry in the changelog:
Date: Fri Aug 19 07:55:10 2011 +0200
ALSA: usb-audio - Fix missing mixer dB information
commit 38b65190c6ab0be8ce7cff69e734ca5b5e7fa309 upstream.
The recent fix for testing dB range at the mixer creation time seems
to cause regressions in some devices. In such devices, reading the dB
info at probing time gives an error, thus both dBmin and dBmax are still
zero, and TLV flag isn't set although the later read of dB info succeeds.
This patch adds a workaround for such a case by assuming that the later
read will succeed. In future, a similar test should be performed in a
case where a wrong dB range is seen even in the later read.Not sure if this applies or not.
I upgraded to vanilla 3.0.4 and again I had the chipmunk. I patched as I did in the above instructions, it built fine, and the chipmunk is now gone running a patched 3.0.4 kernel..
Offline
I have yet to get it to build, keep getting compilation errors like this one
LD [M] fs/xfs/xfs.o
LD fs/built-in.o
==> ERROR: A failure occurred in build().
Aborting...
Arg. I'll have to set aside time to really work on this. Just wish it would be incorporated into the kernel by default.
Offline
I have yet to get it to build, keep getting compilation errors like this one
LD [M] fs/xfs/xfs.o
LD fs/built-in.o
==> ERROR: A failure occurred in build().
Aborting...Arg. I'll have to set aside time to really work on this. Just wish it would be incorporated into the kernel by default.
If its just that one and you dont use XFS, you could try uncommenting the make menuconfig option in the PKGBUILD and ensure that you dont select XFS as a filesystem for the kernel to have. Any others?
For now, I would just stay on 3.0.3 and add linux and linux-headers to /etc/pacman.conf until youve got some time..
I think they want to avoid incorporating into the main kernel because this patch disables USB autosuspend for the particular device you are patching. This is considered undesirable since it means the device consumes more juice and isnt in the state it should be in when not used. It doesnt really matter for a desktop user..
Offline
I uncommented xfs and it appears to be working. No chipmunk voice
I really appreciate you helping out with this.
Offline
I uncommented xfs and it appears to be working. No chipmunk voice
I really appreciate you helping out with this.
Just to make sure- you did enable all the other stuff you need right? I fear I might have made it unclear: unless something has changed (I use vanilla + patch- no make menuconfig for me), you do need to select the stuff you want the kernel to have, including the modules/built-in support for your filesystem of choice and for hardware such as wireless and such. This is why I suggested waiting until you had time (well, echoed your own thought to wait). Let us know how it goes..
**EDIT** Im an idiot- I took appears to be working as a sign it was building, completely failing to interpret "No chipmunk voice" as an indicator that youre running the kernel
Glad it worked..
Last edited by GSF1200S (2011-09-01 18:40:22)
Offline
Everything seems to work. Have skype going, my nvidia graphics. No crashes or strange behavior. Using btrf as my filesystem. I will keep an eye on things though.
Offline
Everything seems to work. Have skype going, my nvidia graphics. No crashes or strange behavior. Using btrf as my filesystem. I will keep an eye on things though.
Haha, ok- read my edit above
Yeah, last time I did a make menuconfig I figured it would leave everything as it would normally build (without uncommenting make menuconfig in the PKGBUILD), allowing me to just deselect some bloat. However, it did way more than that- it didnt select my RAID driver and so I couldnt even find my root filesystem on booting Had to chroot to fix that one..
Just a heads up- if you have an elaborate hardware setup, make sure to double check that you get all the hardware drivers built in before you leave yourself stranded.
Offline
Any chance this will be fixed in a new kernel version some time soon? Is there a bug report about it I can track? I am hoping requiring a patch and manual rebuild of the kernel is not going to remain necessary to get my webcam microphone working again...
Offline
Any chance this will be fixed in a new kernel version some time soon? Is there a bug report about it I can track? I am hoping requiring a patch and manual rebuild of the kernel is not going to remain necessary to get my webcam microphone working again...
kernel.org is down right now but here is one that the maintainer seems to have stopped replying to: https://bugzilla.kernel.org/show_bug.cgi?id=35922
I guess a new report needs to be opened for each hardware. I have two listed there in the meantime.
Offline
Hello,
I have the same problem with my Logitech C600!
But now kernel.org is down.
My kernel is the latest arch kernel (3.0.4).
Can we solve the problem, or should we wait until kernel.org is up?
Thank you!
Sorry for my english, i'm french
Offline
Hello,
I have the same problem with my Logitech C600!
But now kernel.org is down.My kernel is the latest arch kernel (3.0.4).
Can we solve the problem, or should we wait until kernel.org is up?Thank you!
Sorry for my english, i'm french
You can fix it by rebuilding the kernel with a small patch like listed above. You just need to run lsusb to find out what your webcam id is and use that in the patch instead. Here's an alternative mirror to use in your PKGBUILD: http://kambing.ui.ac.id/linux/v3.0/. You *should not* have to change the md5sums.
Offline
alexdaums wrote:Hello,
I have the same problem with my Logitech C600!
But now kernel.org is down.My kernel is the latest arch kernel (3.0.4).
Can we solve the problem, or should we wait until kernel.org is up?Thank you!
Sorry for my english, i'm french
You can fix it by rebuilding the kernel with a small patch like listed above. You just need to run lsusb to find out what your webcam id is and use that in the patch instead. Here's an alternative mirror to use in your PKGBUILD: http://kambing.ui.ac.id/linux/v3.0/. You *should not* have to change the md5sums.
I tried rebuilding the module, but it failed due to the vermagic not being correct. I don't really want to compile a kernel on my netbook though... Any other suggestions, other than just wait?
There is a difference between bleeding [edge] and haemorrhaging. - Allan
Offline
Hi guys , I still have this problem using alsa , can we achive something like that with .asoundrc?
http://forums.logitech.com/t5/Video-Cha … 944#M12191
seems a solution for win7...
what do you think about it , alsa gurus?
Offline
dgbaley27 wrote:alexdaums wrote:Hello,
I have the same problem with my Logitech C600!
But now kernel.org is down.My kernel is the latest arch kernel (3.0.4).
Can we solve the problem, or should we wait until kernel.org is up?Thank you!
Sorry for my english, i'm french
You can fix it by rebuilding the kernel with a small patch like listed above. You just need to run lsusb to find out what your webcam id is and use that in the patch instead. Here's an alternative mirror to use in your PKGBUILD: http://kambing.ui.ac.id/linux/v3.0/. You *should not* have to change the md5sums.
I tried rebuilding the module, but it failed due to the vermagic not being correct. I don't really want to compile a kernel on my netbook though... Any other suggestions, other than just wait?
OK I've gotten it to work . Just in case someone else has my problem (or can't work stuff out)...
1. Follow this post: https://bbs.archlinux.org/viewtopic.php … 64#p978764
(as kernel.org is currently down, you can get the kernel from: http://ftp.nluug.nl/pub/os/Linux/system/kernel/v3.0/ (md5sum was the same for a PKGBUILD - try 3.0.4 (same as what Arch currently is))
2. Follow the instructions, for the 'sed' one, stick it in a file and run "sh file" - I didn't do that (sed noob) and it didn't work first time around, but it works by sticking it in a file to be sh'd.
3. To generate a new initrd (use https://wiki.archlinux.org/index.php/Mkinitcpio), but it can be done by executing by/through root
mkinitcpio -g /boot/custom.img
(you can rename the custom.img to something else .img as the extension.
4. Afterwards, stick it in /boot/ and modify grub or append to the end of /boot/grub/menu.lst to accept a new initrd (best to create a new menu entry in case things are fraked).
This should work.
There is a difference between bleeding [edge] and haemorrhaging. - Allan
Offline
I've just been using the LTS kernel when I wanna run skype and Linux-CK the rest of the time. I doubt this will get fixed any time soon, if at all.
Offline
This is fixed for me in linux-3.0.6
Offline
This is fixed for me in linux-3.0.6
I wish I could say the same.
Kernel: 3.0.6-2
Webcam: Logitech, Inc. Webcam C200
Offline
no luck either with the c250 & kernel 3.0.6
Offline
Hi all,
I have had the same problem on my arch for a couple of months.
The only problem is when using microphone on webcam.
Finally, I've successfully made microphone to work as expected,
but is little work around. I'm interested in using microphone in skype
for video/audio conversations only.
In order to use microphone without "chipmunk sound",
every time I try to reach some one, or someone tries to reach me via skype,
I go very fast to skype Options, Video Devices, and click to Test,
and leave it running in background, so at the end I call someone or
answer to call while webcam is "testing in background".
Also, every time I want to call someone else or answer to different call,
I have to unplug then plug again webcam, and start Test.
I've noticed that webcam "restarts" video stream during call,
and visual effects are seen as video stretching vertically,
and on next restart it gets back to normal, and so on,
every ~5-10 mins.
I'm using linux 3.0.6-2, skype 2.2.0.35-1, and xfce 4.8 on x86_64.
Have in mind, that I don't have custom drivers/modules, linux kernel,
or any other special settings.
Cheers
Offline
fedora seems to have fixed the issue with this patch for a bunch of models
https://bugzilla.redhat.com/show_bug.cgi?id=742010
I've opened a bug here for including the patch , go vote!
https://bugs.archlinux.org/task/26528
Offline
fedora seems to have fixed the issue with this patch for a bunch of models
https://bugzilla.redhat.com/show_bug.cgi?id=742010
I've opened a bug here for including the patch , go vote!
https://bugs.archlinux.org/task/26528
Voted. I suggest people list what their webcams are as well as the output for the webcam via lsusb. I commented the bug repoort and added the relevant line from the patch file I use to fix the kernel (when building from ABS).
Kernel 3.0.6, same issue. Building via ABS with patch fixes the problem.
Offline