login
Search
I have just bought an Aspire one A150, XP version, as it was the only available here, and installed ubuntu on it. Bugs I discovered so far: ** 1 - embedded controler works in polling mode, due to this: [ 0.708571] ACPI: EC: non-query interrupt received, switching to interrupt mode [ 1.224043] ACPI: EC: missing confirmations, switch off interrupt mode. Maybe this is the reason for the fact that gnome power manager freezes when I unplug the AC, and freezes often when I try to see battery status. (Note: same is seen on my acer aspire 5720) ** 2 - wireless: not to mention the fact that ath5k wasn't installed by default in ubuntu... wireless more or less works, but kernel log is full of backtraces. Was able to connect to my WPA2 access point. Sometimes wireless fails completely, especially after suspend to ram. Advanced features like monitor/injection work, but when I changed the card's mac address it stopped working. I also noticed that if I then start airodump, then wireless works with new mac. ** 3 - internal mic doesn't work. tried model=acer, model=auto. Overall it seems that alsa misprograms O/B realteck codec. I talk about this later. Have same issue on my acer 5720 ** 4 - wireless led doesn't work. ath5k devs, can you fix this? ** 5 - coretemp doesn't show cpu temperature, I have seen somewhere that atom support same thermal diode as core2 and only patch to detect it is needed. Please include such path in 2.6.28 if exists. ** 6 - both card readers are missing from lspci, is this normal? ** 7 - opengl is broken, I tried running neverball in fullscreen, but it shows wrong/corrupted textures (compiz is running, and working well thought) Now I installed 2.6.28-rc3 (actually latest -git) Sadly nothing improved. I only found few regressions: * Wireless now drops connection from my WPA2 access point after few minutes. I changed temporarily its wireless protection to WEP and open mode, and both work fine, maybe this is ...
A similar bug has been reported as a regression: <http://bugzilla.kernel.org/show_bug.cgi?id=11828> so one assumes that it worked on the machines with linux pre-installed. Hopefully without requiring any hacks. It seems that for now a workaround may be to pass the option debug_quirks=1 to the sdhci module... <http://marc.info/?l=linux-kernel&m=122509648027303&w=2> ...or that it may help if you insert an SD card before booting. Apparently the reporter also investigated pcie hotplug. Probably the BIOS doesn't provide the normal support. You can try "modprobe pciehp pciehp_force=1", maybe it helps the kernel discover the devices. It worked for something else on my EeePC. But then it will reportedly disappear the ethernet controller. Could be this: <http://bugzilla.kernel.org/show_bug.cgi?id=11942> As a fix, 8fd145917fb62368a9b80db59562c20576238f5a was reverted from the acpi tree. This has also been submitted to mainline. Thanks for your work! If you continue with this, I suggest CC'ing <kernel-testers@vger.kernel.org>. That will help Rafael the regression hunter pick it up. Alan --
Yes, this almost fixes all issues with that. Almost because, it looks like the EC changes screen brightness on his own when battery is plugged/unplugged, but so does the gnome-power-manager, and thus it still hangs as before on battery removal (but doesn't hang otherwise) I disabled that behaver in gnome-power-manager and now no more hangs. Fixed completely, looking through the git log I have seen a commit that fixes exactly same backtrace I had. Surprisingly, this is almost fixed. I can record from both internal mic and external mic (Quality is not so good, but is the same as in windows) Almost, is that to increase capture level, I have to set "one" channel of it. Eg: if I set 100% left and 100% right then capture level is very low. But when I set 100% left and 0% right or vice versa it works fine. Also the "mic boost" doesn't change capture volume for internal mic. also the "mic boost" if set to high value works like analog loopback Also fixed big thanks. Also noticed another bug: If I suspend/resume with compiz running, on resume I see wallpaper and mouse cursor, everything hangs for minute or two, and sometimes forever. 2.6.27 worked fine. Also hibernate doesn't work on my main notebook, but it is probably fixed, I update kernel to really latest -git and tell you. Big thanks for bugfixes, you saved me a lot of work and bisecting. Biggest solvable problem now is sound support now I think, datasheets are there, and I take a look at them. Best regards, Maxim Levitsky --
[Only about sound stuff, stripped irrelevant addresses from cc] At Sun, 09 Nov 2008 02:52:05 +0200, Interesting. Is it with or without model option? There is a model option specific for aspire one (acer-aspire). Doesn't it work better? For comparing the hardware setting, please you run alsa-info.sh with --no-upload option, and attach the generated file at each state. This shows the real codec register values. Also, please run the same procedure for acer 5720, too. thanks, Takashi --
Hi, I had already tried 2.6.28-rc3 on A110L (also plus hand-patched digital-mic patch of patch_realtek.c) and it still didn't work for me. I didn't use the acer one model parameter, though. Well, now I just did use it, and it didn't work either AFAICT, with lots of mixer fumbling again. And I'm not sure whether the model name should be "acer-aspire" instead of "acer-aspireone" since Aspire is the name of an entire series which might possibly have incompatible requirements. Also, I'm not really happy with the fact that snd_hda_intel doesn't even log the model name chosen/selected on module initialisation. Frankly I've had so much snd_hda_intel codec-specific trouble on pretty much all of the few notebooks/machines that I touched in the last year (that's not an understatement!) that I think it would be a very nice idea to write a _very_ visible HOWTO (search words: intel-hda alsa HOWTO codec etc.) detailling how to improve codec-specific support for snd_hda_intel (this should best be done by explaining how one arrived at a particular patch for a certain codec, e.g. take the recent ALC268 work, i.e. check /proc/asound/Intel/codec#0 and look at which part is not supported by the snd_hda_intel patch file yet and then explain how to add stuff to it, in very verbose and generic words to let layman people know how to do this). As already said, I've (and certainly not only me!) been bitten again and again and AGAIN by incomplete codec support in snd_hda_intel, thus we need to make damn sure people can help themselves as well as remotely possible, to ensure sufficiently fast and sufficiently complete support for new HDA codecs (which seem to appear each new month or week even, unfortunately!). If people don't even know how to tackle this easily, then patch submissions for new codecs aren't too likely... And the A110L has been on the shelves for 4 or 5 months already (with 5 to 6 million units sold, they say!!), a time where full support would have been in order. But it's ...
Hi,
OK, _THIS_ time I actually did get the correct model (last time I tried
modprobe with model=acer-aspire, but apparently it then used the
/etc/modprobe.d/ model=toshiba setting, since this time gamix showed
entirely different controls with i-Mic etc.) - all the more reason to
log the model name chosen/selected by the driver!!
--> I have to admit that usability sucks^Hcould be a lot better.
It's perfectly fine for ALSA to not have support for newish codecs or newish
machines with weird setups, but basic usability and or documentation
should thus be as good as can be to make sure that weaknesses can get detected
and fixed in no time, even by "interested parties".
OK, here it is (-rc3 with model=acer-aspire):
name=root&type=33&description=/tmp/alsa-info.txt&expiry=&s=Submit+Post&content=
!!################################
!!ALSA Information Script v 0.4.48
!!################################
!!Script ran on: Sun Nov 9 16:00:38 CET 2008
!!Linux Distribution
!!------------------
Ubuntu 8.10 \n \l DISTRIB_ID=Ubuntu DISTRIB_DESCRIPTION="Ubuntu 8.10"
!!Kernel Information
!!------------------
Kernel release: 2.6.28-rc3
Operating System: GNU/Linux
Architecture: i686
Processor: unknown
SMP Enabled: Yes
!!ALSA Version
!!------------
Driver version: 1.0.18rc3
Library version:
Utilities version: 1.0.17
!!Loaded ALSA modules
!!-------------------
snd_hda_intel
!!Soundcards recognised by ALSA
!!-----------------------------
0 [Intel ]: HDA-Intel - HDA Intel
HDA Intel at 0x38540000 irq 16
!!PCI Soundcards installed in the system
!!--------------------------------------
00:1b.0 Audio device: Intel Corporation 82801G (ICH7 Family) High Definition Audio Controller (rev 02)
!!Advanced information - PCI Vendor/Device/Susbsystem ID's
!!--------------------------------------------------------
00:1b.0 0403: 8086:27d8 (rev 02)
Subsystem: 1025:015b
!!Modprobe ...At Sun, 9 Nov 2008 16:13:23 +0100, Build with the debug option (why turned off even if you *are* One would call it rather debuggability than usability. OK, then something is missing. But you should test by arecord first than any complicated applications as a primary test. Anyway, the acer-aspire support code was written by Realtek guys, so it'd be best to ask them... thanks, --
Hmm, right, that would have been an (very useful) option, but not for the majority of users OTOH. Especially since this is a user-visible module parameter which should thus be confirmed in mainstream user code, via logging. Admittedly not many modules log their settings during startup, but for snd_hda_intel with its two myriads of codec/machine variants Good point, will do. Indeed, and far too late (they have submitted it in September I think) for guaranteeing non-problematic hardware behaviour... (I'd guesstimate the Realtek submission to be based on Acer activity) Anyway, still very nice to see that companies do submit patches after all. Thanks, Andreas --
At Sun, 9 Nov 2008 21:09:29 +0100, You can check via /sys/modules/snd_hda_intel/parameters/model whether Passing the model option is already a kind of debugging work, IMO. Try hda-verb program. Build your kernel with CONFIG_SND_HDA_HWDEP=y and access via the hwdep device. ftp://ftp.suse.com/pub/people/tiwai/misc/hda-verb-0.2.tar.bz2 Takashi --
Hi, I pretty much studied the datasheet and driver, and this is what I found: btw, my acer 5720 and aspire one share same ALC268. Some stuff is trivially fixable, some seems to be unfixable at all: model=acer is used on my regular laptop. model-acer-aspire is used on aspire one laptop, and it needs to be renamed, as both are aspire. 1) internal beep volume/mute isn't preserved on resume on acer (I call the big laptop this way). 2) aspire one, has same beep routing, but it isn't supported by this model, it should be added I think. 3) on acer internal mic is mapped wrongly, it assumes that it is a digital mic, while in fact this is analog mic, and pin configs are set correctly, but they are ignored. fix is trivial, but might break other laptops. Maybe add this as a new input, like analog mic, at least it can be added for aspire 5720. 4) There is really no internal mic boost on aspire, it is digital, not a bug. 5) Codec supports two ADCs, and so does the driver, but for some models second ADC is ignored. alc268_capture_alt_mixer is used instead of alc268_capture_mixer. Here on acer both ADCs are present, and it might be worth to use them both (record from line in and mic) on aspire one there is only external and internal mic, probably doesn't worth it. 6) Codec supports two DACs too, so it is in theory possible to play different streams on speakers and headphones. 2nd DAC is connected only to headphones, while 1st DAC is connected to all. But here on acer they reversed the connections and connected speakers to headphones output and headphones to speakers, so probably useless, and besides this doesn't worth the trouble probably. 7) SPDIF is supported on my notebook, but no by the driver, don't yet have a device to test it againt thought, but adding support should be easy. it is shared with headphones output. How we can detect that digital headphones are connected, don't know, probably impossible in hardware. 8) The issue of capture volume on aspire one: when I ...
Hi, Wow, what an extremely in-depth analysis! I just intended to dive into getting mic routing corrected myself, +1 (your analysis of both being rather different - as already pondered - Sounds like really bad circuit design then. One would think that the Intel HDA architecture might have builtin measures to compensate for this if needed? DC offset issues on I've actually had a peek at the .inf files since I thought that it would already contain register values in those registry keys that it creates on install, but yeah, that's all in-driver it seems. Probably time to ask Acer about specifics, especially since I didn't spot any hda-intel changes in their linux-2.6.23.9lw source. Thank you very much, Andreas Mohr --
Small update: 1) The dc offset isn't present on aspire one, really is a circuit design bug I guess 2) Internal mic works perfectly on aspire one, can reproduce the strange behaver at all, Probably this was mixer bug. So aspire one support is almost, only need to add support to restore beep volume after resume. Best regards, Maxim Levitsky --
Finally, I found how to reproduce that bug, I mean to get normal volume on internal mic, I have to increase volume only on left or right channel. So, this happens always, and _only_ when recording _mono_ sound from internal mic. Since hardware doesn't support hardware mono input, tested with -D hw:0 I suspect this to be alsa-lib bug, any ideas? Happens with arecord -D plughw:0 -c1 . Best regards, --
Hi, Wow, nice analysis! I had already intended to report that you're #2 who told me that Mic does work (and I was starting to feel weird since I'm the only one who cannot get it to work!) Given your analysis, things start to make a lot more sense now. That probably means that Ekiga Wizard uses mono input (since it does not work for me), whereas many other apps use stereo input as (natively!) supported by this hardware setup? --> alsa lib bug sounds like a good guess. Thanks, Andreas Mohr --
At Sat, 22 Nov 2008 21:00:18 +0200, What does show with -v option? Takashi --
Hi,
OK, I could fully reproduce this now (sorry for the delay!).
Currently 2.6.28, u8.10, model acer-aspire, libasound2 1.0.17a-0ubuntu4,
libasound2-plugins 1.0.17-0ubuntu5.
Recording from i-Mic does work (minus some pretty annoying background noise)
if in gamix I open either left _or_ right channel of the "Capture" control,
but the more both channel sliders progress towards an (almost) equal level,
the more the recording gets reduced to bit changes distantly resembling
the time curve of the recorded signal (but this is not a linear effect,
only the last 5% difference of the slider are dramatic).
IOW you get a "bit buzzing" which clearly distantly resembles the speech
you recorded, something like
"Hello, Test!" --> "crch........crch......crch..."
"(H).ee.(l)..oooo..(T).eee.(st)."
I'm wondering whether these are MSB bit, not LSB, remains of the original
signal here... (since they are clearly audible which LSB wouldn't be)
Anyway, we clearly have some differential logic of the two channels
here, which certainly shouldn't be the case, IOW most likely a bug.
Working test (Capture sliders NOT equal, recorded signal audible):
andi@andinet:~$ arecord -v -D plughw:0 -c1 test.wav
Recording WAVE 'test.wav' : Unsigned 8 bit, Rate 8000 Hz, Mono
Plug PCM: Rate conversion PCM (48000, sformat=U8)
Its setup is:
stream : CAPTURE
access : RW_INTERLEAVED
format : U8
subformat : STD
channels : 1
rate : 8000
exact rate : 8000 (8000/1)
msbits : 8
buffer_size : 2730
period_size : 682
period_time : 85333
tstamp_mode : NONE
period_step : 1
avail_min : 682
period_event : 0
start_threshold : 1
stop_threshold : 2730
silence_threshold: 0
silence_size : 0
boundary : 178913280
Slave: Route conversion PCM (sformat=S16_LE)
Transformation table:
0 <- 0*0.5 + 1*0.5
Its setup is:
stream : CAPTURE
access : MMAP_INTERLEAVED
format : U8
...Hi, Same microphone behaviour on 2.6.29-rc8 (additionally remembered to enable CONFIG_SND_HDA_HWDEP for further testing!), u9.04, model acer-aspire, libasound2 1.0.18-1ubuntu7, libasound2-plugins 1.0.18-1ubuntu4 (yes, I've just done some monster upgrade). Will try to eventually analyze things using your _HWDEP-related tools. 2.6.29-rc8, in contrast to several other kernel upgrade occasions, seems pretty solid so far, BTW. Andreas Mohr --
At Mon, 16 Mar 2009 13:03:12 +0100, The question in the top priority is whether it's a kernel driver issue or alsa-lib converter issue. Could you check whether the sounds recorded with -Dhw (and with matching rate, format, etc) have the same noise problem at first? And, if it's about the alsa-lib conversion problem, we can reproduce without the hardware, e.g. via file plugin... thanks, Takashi --
Hi, OK, tried arecord -v -D hw:0 -c1 test.wav, which ended with arecord: set_params:961: Sample format non available . arecord -v -D hw:0 -c1 -f S16_LE test.wav then ended with arecord: set_params:966: Channels count non available thus completing it into a arecord -v -D hw:0 -c2 -f S16_LE test.wav worked. Trying this line with plughw then worked (of course, since two channels never has any problems). Interestingly when using plughw there seems to be some LPF effect, since with hw I get lots of white noise whereas with plughw the recorded sound is dark (no higher-frequency components at all). And audio is always being recorded properly no matter which Capture sliders position. To state it more clearly, both hw and plughw have no issues whatsoever with -c2 -f S16_LE, any sliders position. If I then switch to plughw:0 -c2 -f U8 (IOW change to U8 format), no problems either. Trouble starts if I then change to -c1 and have both channel sliders about equal (if they're not equal then I'm getting Thank You, Andreas --
At Mon, 16 Mar 2009 14:30:01 +0100, So, the following is also problematic % arecord -fdat -c1 -Dplughw ng.wav while the below works? Does the conversion by sox from good.wav to a mono-channel file work? Takashi --
Hi, Indeed, the above has problems with problematic slider positions whereas I assume I should be using sox good.wav -c1 good1.wav ? If so, yes, this works, audio is there. Side note: I've got HDA power management activated (with some bad effects - no sound at all on entire first playback after idle), but this shouldn't matter here. Andreas --
At Mon, 16 Mar 2009 15:31:58 +0100, Just to be sure - what about below? sox good.wav -c1 good1.wav mixer 0.5,0.5 Takashi --
Hi, Hmm, I thought I was... (elsewhere) In the problematic case (using plughw), whenever left channel / right channel sliders are equal, no sound gets recorded. IOW, there has to be a huge difference (in either direction) between left and right channel slider to hear anything. And that is Not Yep, still works. Thanks, Andreas --
At Mon, 16 Mar 2009 15:50:36 +0100, What are "sliders"? Takashi --
Hi, Umm, volume level controls. Andreas --
At Mon, 16 Mar 2009 17:02:08 +0100, Yes but there are many of such :) More exactly, from the driver perspective, there are no volume controls but only there are control elements with integer values. Do you mean "Capture Volume" control or which one? And, is the behavior consistent regardless of the value high, i.e. the key is only whether the values for both channels are identical? Takashi --
At Mon, 16 Mar 2009 17:06:35 +0100,
BTW, what if you record with the following definition?
Put the below to ~/.asoundrc
pcm.imix {
type plug
slave.pcm "hw"
ttable.0.0 0.5
ttable.0.1 -0.5
}
and record like
% aplay -Dimix -c1 foo.wav
Takashi
--
Hi, Hmm, ok, this needs to be more precise: Does NOT exhibit the "equal sliders == no sound" bug (apart from this sliders are acting normally, i.e. slider low == no sound), despite being a "plug" type definition (this is what you wanted to discern, right? ;). Thanks! Andreas --
At Mon, 16 Mar 2009 18:00:15 +0100, Yeah, that's more understandable :) BTW, does "Capture Volume" influence on the recording level even for the built-in mic, right? I'm asking this because the digital mic on STAC/IDT codecs isn't controlled via "Capture Volume" control that is bound to an ADC widget. (That's why "Digital Capture Volume" control exists. It's a value used by alsa-lib softvol plugin for "default" Interesting. This implies that one channel is inverted indeed. As default the alsa-lib plugin downmixes a stereo stream to a mono stream simply by left/2 + right/2. The above changes the routing policy as left/2 - right/2. So we need to pass some information to change this kind of thing... But a question still remains; why conversion with sox worked. Maybe it didn't mix? Or, the code alsa-lib could be buggy... A simple test would be to just sum all 16bit samples in a stereo stream file externally. That is, first record a RAW file via % arecord -Dhw -traw -fdat foo.dat Then create a mono stream just do 16bit left/2 + right/2 calculation by any way (a good homework for kids :). Is it also problematic? thanks, Takashi --
Hi, Yes, Capture Volume does influence i-Mic level. The Digital Capture control, however, doesn't influence level. Oh, you mean "inverted" as in "_hardware_ channel which provides opposite That exactly matches my current stream of thought (while reading That's something specific to ALC268 codec setup, right? OK, I know what you're up to, I'll do this external proof ASAP, will take a couple more minutes. Andreas --
At Mon, 16 Mar 2009 18:30:00 +0100, The "Digital Capture Volume" has effect only when "default" PCM is used. Right. My guess is that the hardware provides left (or right) channel No. It's specific to the digital-mic side. Takashi --
I just tried connecting a headset and switching to E-Mic. What I can say is: - opposite levels does NOT happen there (E-Mic is "analog micro"-based, right?) - leaving E-Mic unplugged will actually record from i-Mic (due to properly working EAPD mechanism, right?) BTW, the output (of arecord -Dplughw:0 -c2 -traw -fdat foo.wav) _does_ have inverted channels: 00000130 2A 02 D2 FD 65 02 A5 FD 10 00 E7 FF 99 FF 72 00 *...e.........r. 00000140 53 FE A7 01 ED FF 12 00 4F FF A6 00 86 00 81 FF S.......O....... ... and so on in the entire file ... One question still: is this a hardware defect (i.e. could this possibly be swapped cables of the microphone connector in this model or so? Not plausible but...), or is this an existing property of the HDA's dig-mic base? You indicated it's the latter I think... Andreas --
At Mon, 16 Mar 2009 19:06:38 +0100, The record from mic-jack is via analog path. The phase-inversion My guess is that it's a hardware implementation. Maybe for the noise suppression via mic array. The question is whether the left / right channels recorded from digital mic are really raw data, or they are for modified data (for differential, etc)... It's hard to guess without the actual data. Takashi --
Hi, I don't quite follow you here. Is there anything I could do about this? Thanks, Andreas --
What about exposing the i-mic as a mono only device to userspace? It is mono after all? Best regards, Maxim Levitsky --
At Tue, 17 Mar 2009 02:52:19 +0200, No, it's a mic-array. And HD-audio cannot handle a mono stream. Takashi --
No problem. Lets just lie to usespace that it is mono, in kernel driver can pick one of channels? Maybe this is an array, but this doesn't explain the 'quality' of it. It is so low (in windows too). Best regards, Maxim Levitsky --
At Tue, 17 Mar 2009 13:30:12 +0200, No, the hardware provides only the stereo streams, so the driver, too. The downmixing is the job of the user-space. For example, try the Properly using the mic-array would reduce the noise fairly well. XP has no mic-array support, IIRC. Of course, it's possible that Aspire* have badly equipped mic arrays that don't help much noise suppression... Takashi --
At Mon, 16 Mar 2009 22:22:27 +0100, The mic array on a laptop is used for beam forming and noise suppressions. These require the software manipulation, of course. The question is what kind of data is read from the hardware. Thus, providing the raw streams for both mic inputs makes sense. Obviously the stream read from the codec chip is a PCM while usually the digital mic gives the output as PDM. So PDM -> PCM isn't needed here. But, still a question is why a phase inversion in the second channel. Whether it's intentional (e.g. to make the further conversion easier) or not. Would be interesting if you can figure out which digital-mic component is used on your laptop (and if we can have any chip information by luck). Takashi --
Hi, Well, as some manufacturers/types of digital microphones I found Akustica (AKU 1126 / 2000 / 2001 / 2002 / 2004 / 2103), Analog Devices (ADMP421), National Semiconductor (digital microphones, amplifiers LMV1024, LMV1026) [1], [2], [3] and Andrea Digital Array Microphones. ALC268 specs [4] say that they actually support interfacing LMV1024/1026, SPD0205ND (what the heck is this one?), AKU2000. Umm wait, Aspire One has ALC269. ALC269 datasheet doesn't say anything about microphone manufacturers. Note that eeepc models 901++ have ALC269 as well and - surprise, surprise - an inverted noise cancellation issue as well!!!!!: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/331130 "Dreamcom 10 Laptop" [7]: " integrated Realtek HD audio processor, two built-in Akustica digital microphones and two built-in stereo speakers" This was the only reference up and down that I could find to _any_ notebook's microphone manufacturer listing. I suspect that Aspire One has an Akustica microphone array as well since Akustica seems to be the leading brand (hmm, any ideas about where the second microphone is located if at all existing, but it must exist!!? - probably at the front bottom?). Note that I found that the 16bit inverted data is NOT exactly a sum of 0x10000, IOW those _are_ two _separate_, inverted streams of audio data (for noise cancellation somehow I guess). OH WAIT!! If most Acer models have _both_ microphones at the screen bezel (left and right side) yet Aspire One has them (as I'd guess) at the top of the bezel (known) and at the front bottom, then this would mean - hold your breath - that the microphone array's physical properties (regarding noise cancellation) are moved by 90 degrees, possibly exactly explaining the malfunctioning (this would explain why Aspire One and eeepcs have issues whereas other Aspire models probably don't have them!?!?). Hmm OTOH providing an audio source from somewhere on the left side / right side of the netbook doesn't suddenly ...
NOPE. Aspire One most definitely has a Fortemedia SAM (small array microphone) due to this output: http://sites.google.com/site/kengell/acer-aspire-one---dmesg " ... ForteMedia SAM-Soft Library Loaded! ALC INIT ... " I had already wanted to add the mention of Fortemedia as microphone manufacturer (forgot this last time), then I researched more and found it. Fortemedia device names include FM2018-380, not sure yet which one is in Aspire One. http://www.fortemedia.com/products/index.htm ( especially http://www.fortemedia.com/products/fm1182.htm ) Andreas --
http://www.wpgholdings.com/event/S/SACg_04_ForteMedia_SAM.pdf mentions "FM201x" and www.sacg.com.tw (this one could be useful!). Searching Google "FM201[0-9] Fortemedia" comes up with FM2010 and FM2018 and thus http://www.hengdasheng.com.cn/uploadfile/391/cfile/2008102414057847.pdf which is a relatively informative datasheet. Andreas --
At Tue, 17 Mar 2009 11:47:55 +0100,
I'm not sure whether FM2018 is on a netbook. Rather my guess is it's
a digital-mic component by FortMedia together with their software
library for SAM handling.
BTW, a simple "fix" for the mono capture problem, you can patch
the config file for HD-audio in alsa-lib like below. Then the first
channel will be used for mono capture instead of averages.
Give it a try.
(But, this won't fix programs that prefer "hw" access such as
pulseaudio, of course.)
Takashi
---
diff --git a/src/conf/cards/HDA-Intel.conf b/src/conf/cards/HDA-Intel.conf
index 800281e..d3ac002 100644
--- a/src/conf/cards/HDA-Intel.conf
+++ b/src/conf/cards/HDA-Intel.conf
@@ -57,6 +57,8 @@ HDA-Intel.pcm.default {
max_dB 30.0
resolution 121
}
+ # to avoid possible phase inversions with digital mics
+ route_policy copy
}
hint.device 0
}
--
Hi, I had the same thoughts later. Since they use an extensive SAM handling library, there probably isn't such a chip, otherwise they probably wouldn't need it ;) Could you thus implement a nice beam-forming sound evaluation SAM library for ALSA pretty pretty please? ;) ...or, is that SAM library available to us given that it exists in the I'm not *quite* sure whether this is really what you meant, but I patched /usr/share/alsa/cards/HDA-Intel.conf (libasound2 1.0.18-1ubuntu7) in exactly this way and then did arecord -Dplughw:0 -fdat -c1 test.wav; aplay test.wav but well, with equal slider positions there was no audio again. Andreas --
At Tue, 17 Mar 2009 17:18:28 +0100, An easy one would be a relatively simple algorithm, but I don't know Don't use -Dplughw:0. Then the default setup will be used. % arecord -fdat -c1 test.wav Takashi --
Hi, Not at the moment at least, sorry. But that would make for a nice Tried that, didn't help. /usr/share/alsa/cards/HDA-Intel.conf still contains the patch, but equal Capture Volume sliders still silenced audio input, whereas non-equal worked. Hmm. Andreas --
At Wed, 18 Mar 2009 10:05:07 +0100, What is the output with -v option? Takashi --
Hi, Sorry for the delay! $ arecord -fdat -c1 -v test.wav; aplay test.wav Recording WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono ALSA <-> PulseAudio PCM I/O Plugin Its setup is: stream : CAPTURE access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 1 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 1 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 ^CAborted by signal Interrupt... Playing WAVE 'test.wav' : Signed 16 bit Little Endian, Rate 48000 Hz, Mono andi@andinet:/tmp$ Hmm. Note the pulseaudio stuff above... I did verify that this test run using -v did exhibit failure again. Thanks, Andreas --
At Fri, 20 Mar 2009 19:56:40 +0100, Yes, that's the very reason. If you don't PA and avoid the default configuration override (e.g. defined in /etc/asound.conf) my patch should work. Takashi --
Hi, Sorry, but how would I achieve "don't PA"? I've tried some Ubuntu suggestions (e.g. http://ubuntuforums.org/showthread.php?t=852518 ; didn't work, it's Jaunty here), I tried asoundconf (un)set-pulseaudio (~/.asoundrc contents looked ok then but didn't really help), I tried pasuspender -- arecord -fdat -c1 -v test.wav I always ended up with "ALSA <-> PulseAudio PCM I/O Plugin" mode. (I didn't even attempt the ultimate solution, removing all traces of PA packages, since that would be a ridiculous thing to do) gnome-sound-properties didn't seem overly helpful either... (Sound capture was already set as "ALSA") If things are that impractical, then there needs to be another builtin way to always have the microphone output end up correct, automatically, instead of having to go through incredible convolutions to try to access the raw ALSA device (which would probably provide a correct mic stream) directly, by default. Or, to put it another way, in many cases the default ALSA device wouldn't be used (by sound layers or apps or whatever), thus the patch above wouldn't work there if I'm not mistaken, thus there needs to be a different way to fix the microphone. Or, to have it even more condensed, the more you have to fiddle to make the patch work, the more distance gets between you and the usual Linux distribution use case. Any ideas or suggestions? Thanks, Andreas --
At Sun, 22 Mar 2009 13:55:17 +0100, I'm no Ubuntu user, so no idea. Takashi --
For the reference this this list of nodes on ALC268 (main mobo): 0x01 - params output streams: 0x02 - DAC1 + volume 0x03 - DAC2 + volume (only headphones) 0x06 - s/pdif-out 0x1D - BEEP input streams: 0x07 - ADC1 0x23 - ADC1 multiplexer + volume 0x08 - ADC2 0x24 - ADC2 multiplexer + volume output pins(*): (***) 0x14 - LINE-OUT headphones <- 0x0f - line-out (mixer) <- DAC1 + beep 0x15 - HP-OUT speakers <- 0x10 - hp-out (mixer) <- DAC1 + DAC2 + beep 0x16 - MONO-OUT N/A <- 0x0e - mono out (mixer) <- DAC1 0x1E - spdif input pins(**): 0x12 - DMIC1/2 N/A 0x13 - DMIC3/4 N/A 0x18 - MIC1 external mic + boost 0x19 - MIC2 internal mic + boost 0x1A - LINE-IN line-in + boost 0x1C - CD-IN N/A * Most output pins may be used as input pins ** LINE-IN, MIC1 might be output of DAC1 *** those are pins that are connected on my main mobo. /proc/asound/card0/codec#0 is attached (also for main computer, I will test the 'one' tomorrow Best regards, Maxim Levitsky
At Wed, 12 Nov 2008 12:08:28 +0100, BTW, for whom would like to fulfill the masochistic joy of debugging on HD-audio, I uploaded my half-finished HD-audio emulator program. The package is found at: ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/misc/hda-emu-0.0.1.tar.gz or ftp://ftp.suse.com/pub/people/tiwai/misc/hda-emu-0.0.1.tar.gz Have fun, Takashi --
Please do report it as an ACPI EC bug. It's popular hardware, and if
nothing else it is important that upstream be aware of the workarounds
Probably not. It doesn't seem important, it may not be possible, and
even if you could fix the EC driver for your hardware, there's the risk
of breaking other peoples hardware.
The presumption is that you have weird hardware and it genuinely needs a
polling workaround. It's not too bad, now it uses udelay() it should
not impose any wakeups or significant latency, just some extra cpu time
in a busy loop. EC events such as acpi hotkeys are still received as
interrupts (although we then have to query the type of event using a
polled transaction).
I assume you get something like (text not exact):
"EC: started in polling mode"
...
"EC: non-query interrupt received, switching to interrupt mode"
...
"EC: missing confirmations, switching to polling mode"
all during boot.
There's one outstanding issue on a different machine, where the
occasional EC read fails and triggers polling mode sometime _after_
boot. It can be fixed by retrying the transaction
http://bugzilla.kernel.org/show_bug.cgi?id=11896
but I don't really expect your machine has the same problem.
Weird.
Did you try sysrq-W during the hang? That's supposed to dump a list of
But suspend to ram works? Usually it is the other way round :). If you
haven't already, you might read
Documentation/power/basic-pm-debugging.txt
I can't take credit for actual fixes. But I'm very happy to help people
avoid bisecting for known problems. I hope you have time to crack the
unknown ones :).
Alan
--
Well, I see the wallpaper and can move the mouse, I will try to suspend from console I think this is graphics bug. nether ctrl+alt+bks nor SAK kill X. After 2 minute wait, kernel log doesn't show anything unusual. printk times, jump that 2 minutes around wireless association, but I tested it without ath5k loaded and still the same happens. Well, this is long story details at http://lkml.org/lkml/2008/9/20/75 speaking shortly, bios doesn't pass control to kernel on second resume. Thus I don't test it, but I see how it works now. Suspend to disk still doesn't work. First of all system hangs in the end of image writeout. If I power it down manually, and boot, system resumes from disk, and then hangs. 2.6.27 works fine. Best regards, Maxim Levitsky PS: sorry for late reply --
Patch for that does exits, but doesn't apply to latest git, I will apply in manually. Got, a SD card, and with help of pciehp it works almost perfectly in both slots. Almost, due to the fact that R/O switch is ignored. (Just as I expected, a s/w switch, couldn't they think more, and include a hardware switch?) On my main acer R/O switch works. However I have to use pciehp_force=1, I understand that probably acpi tables are broken, but could you add a workaround (dmi quirk?) Also, there is a acpiphp driver, which doesn't work here. pciehp is supposed to support so called native mode, don't yet know what it is, I almost sure why this happens, opengl application is out of textures, I need to install gem enabled intel driver here, and see how it works. Best regards, Maxim Levitsky --
Matthew Garret tells me the Aspire One should be handled by acpiphp patches he posted on the linux acpi mailing list recently. -- --
I applied his first patch, and now acpiphp works great (loads fast, and detects both readers) Best regards, Maxim Levitsky --
Excellent, good to know. -- Matthew Garrett | mjg59@srcf.ucam.org --
Did you get noise calibration failures in dmesg at this point? Felix posted Currently all the LED code we have in there is for setting a particular gpio for particular laptops (and they differ between models). We only have quirks for IBM and HP, none for Acer. Also, the legacy-hal seems to have a different strategy for 2425 chips. I can try to hack up some code for you to test. -- Bob Copeland %% www.bobcopeland.com --
Yep, but they seems to be gone in latest -git too. I have seen on the web that madwifi did support the led with some gpio settings sysctl -w dev.wifi0.ledpin=3 sysctl -w dev.wifi0.softled=1 from https://help.ubuntu.com/community/AspireOne Best regards, Maxim Levitsky --
i think that some led settings are stored on EEPROM, let me check it out... -- GPG ID: 0xD21DB2DB As you read this post global entropy rises. Have Fun ;-) Nick --
Yeah, we appear to only set the mac address at probe time to the one in the eeprom. It should be easy enough to fix. -- Bob Copeland %% www.bobcopeland.com --
As a first stab, can you try this patch? This sets the address on
add_interface and clears it on remove_interface, instead of only doing
it at probe time. I only compile-tested it.
diff --git a/drivers/net/wireless/ath5k/base.c b/drivers/net/wireless/ath5k/base.c
index 5ef8cc4..6c56893 100644
--- a/drivers/net/wireless/ath5k/base.c
+++ b/drivers/net/wireless/ath5k/base.c
@@ -2765,6 +2765,7 @@ static int ath5k_add_interface(struct ieee80211_hw *hw,
/* Set to a reasonable value. Note that this will
* be set to mac80211's value at ath5k_config(). */
sc->bintval = 1000;
+ ath5k_hw_set_lladdr(sc->ah, conf->mac_addr);
ret = 0;
end:
@@ -2777,11 +2778,13 @@ ath5k_remove_interface(struct ieee80211_hw *hw,
struct ieee80211_if_init_conf *conf)
{
struct ath5k_softc *sc = hw->priv;
+ u8 mac[ETH_ALEN] = {};
mutex_lock(&sc->lock);
if (sc->vif != conf->vif)
goto end;
+ ath5k_hw_set_lladdr(sc->ah, mac);
sc->vif = NULL;
end:
mutex_unlock(&sc->lock);
--
Bob Copeland %% www.bobcopeland.com
--
Works almost perfectly, when I load the module, then run macchanger, and then ifconfig wlan0 up then it works, if I do an ifconfig up once, then ifdowning the interface, it doesn't. my iwl3945 allows me to ifconfig wlan0 down macchanger .... ifconfig wlan0 up The noise floor calibration issue bites me again and gain. When it shows up, usually card continues to work, but at next assotiation stops working. Maybe this is unrelated, don't know. Reboot doesn't help, only a cold reboot/suspend to ram helps. (Module reload doesn't help too). Transfer speeds are unusually low: Currently I compile kernel on main laptop, and copy files over nfs to aspire one. Copying takes ages, and transfer speeds are at 200 Kbytes/s. (AP isn't involved in direct transfers between stations, right?) Both notebooks are in same room. Also noticed, that continued transfer of large volumes (like the above) triggers noise calibration time-outs, and when it does transfer speeds drop to 50Kbytes/s Next assotiation usually fails, and only on/off cycle fixes this. Best regards, and big thanks for help, Maxim Levitsky --
Yeah, I had actually written more for that patch originally, but didn't post it because it was a bit more invasive. I think the issue is just that start() shouldn't program the mac at all and let add_interface handle that. Does this help? You can try using the minstrel rate control algorithm, it may help. -- Bob Copeland %% www.bobcopeland.com --
This actually seems to be iwl3945 bug. This is the tests I did: 1 . Upload / download from my desktop computer (connected via wired interface) Speeds are rock solid 1.3 Mbytes/s in both directions 2. Then I tried to upload to my laptop (iwl3945) Speeds were around 600 Kbytes/s, then after few minutes the ath5k dropped association, associated again and transfer speed dropped below 64 Kbyte/s (They didn't stall thought) 3. Then I reloaded the ath5k, it didn't help, 64 Kbyte/s again. 4. Then I tried to transfer files to desktop, 1.3 Mbytes/s again. 5. then tried the laptop, 64 Kbyte/s again 6. Then I reloaded the iwl3945 on laptop, and got 600 Kbytes/s. It still isn't very clear who is responsible, but this is very fishy. Maybe the ath5k shouldn't drop association, though. 600 Kbytes/s isn't good ether. Also ath5k stopped working at all, when I did long test transfer between desktop and laptop, dmesg was full of some strange message repeated, I haven't been able to reproduce that again, when I do, I will post that message. In general, ath5k works nice here, big thanks to you for such great work. Best regards, Maxim Levitsky --
Hi, Any update on that? Best regards, --
I have seen ine gone to 24 and 36 Mb/s, doing a copy in gnome GUI via
sftp (at a couple feet from the router ;).
But at some point, the copy blocked and dmesg said:
ath5k phy0: unsupported jumbo
ath5k phy0: unsupported jumbo
Apart from that, and the led problem, wifi works pretty fine.
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2009.1 (Cooker) for x86_64
Linux 2.6.27.5-desktop-1mnb (gcc 4.3.2 (GCC) #1 Sun Nov
--
Which BIOS ? Mine is 3304, kernel is 2.6.28-rc8, and LEFT card is not detected
unless I use this option:
options sdhci debug_quirks=1
I have downloaded BIOS 3308, but it is to big to fit in my 1.4 floppy image
(I still have a flooy image I dd on a USB flash, but have not managed to grow
it - wouldn't you know how to do it ?)
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2009.1 (Cooker) for x86_64
Linux 2.6.27.5-desktop-1mnb (gcc 4.3.2 (GCC) #1 Sun Nov
--
v0.3301 left read was and does work fine, but before some time it wasn't present on boot, if there were no card in it, but was hotplugged using acpiphp when I put it there, but now it is present regardless of card, and I did no changes in system, so it must be a hardware malfunction/bug. Best regards, Maxim Levitsky --
But how do you load acpiphp ? I try and I just get:
one:/etc# modprobe acpiphp debug=1
FATAL: Error inserting acpiphp (/lib/modules/2.6.28-desktop-0.rc8.1mnb/kernel/drivers/pci/hotplug/acpiphp.ko.gz): No such device
from syslog:
acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
acpiphp_glue: Total 0 slots
??
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2009.1 (Cooker) for x86_64
Linux 2.6.27.5-desktop-1mnb (gcc 4.3.2 (GCC) #1 Sun Nov
--
And this is the past one in my list...
With latest updates (kernel rc8, intel video driver 2.5.1, ...), MTRRs are
setup ok:
one:~# cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 512MB, count=1: write-back
reg01: base=0x01f500000 ( 501MB), size= 1MB, count=1: uncachable
reg02: base=0x01f600000 ( 502MB), size= 2MB, count=1: uncachable
reg03: base=0x01f800000 ( 504MB), size= 8MB, count=1: uncachable
But X still has some kind of problem:
[drm] Initialized drm 1.1.0 20060810
pci 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
pci 0000:00:02.0: setting latency timer to 64
[drm] Initialized i915 1.6.0 20080730 on minor 0
X:2877 conflicting memory types 20000000-30000000 write-combining<->uncached-minus
reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining
X:2877 conflicting memory types 20000000-30000000 write-combining<->uncached-minus
reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining
X:3008 freeing invalid memtype 20000000-30000000
X:2877 conflicting memory types 20000000-30000000 write-combining<->uncached-minus
reserve_memtype failed 0x20000000-0x30000000, track write-combining, req write-combining
X:3009 freeing invalid memtype 20000000-30000000
Don't know it its a problem, as DRI works and 'gears' (I know, gears is not
a benchmark...) has raised from about 500 in the best times I remember to
750!!.
Perhaps if X could set its MTRR things would be even faster ??
TIA
--
J.A. Magallon <jamagallon()ono!com> \ Software is like sex:
\ It's better when it's free
Mandriva Linux release 2009.1 (Cooker) for x86_64
Linux 2.6.27.5-desktop-1mnb (gcc 4.3.2 (GCC) #1 Sun Nov
--