December 2008 - Alsa-devel - mailman.alsa-project.org

[alsa-devel] [ASoc] TDM over one SSC channel on AT91 possible?
by Friedrich Lobenstock 24 Jun '11

24 Jun '11

Hello! The background: I'm just designing an ATMEL AT91RM9200 based board which got two TLV320AIC33 on board. It is either possible to hook up the two TLV320AIC33 to a separate SSC (synchronous serial control) channel each or use one SSC channel and configure it for TDM (time division multiplex) mode. There is already a driver for TLV320AIC14k/TLV320AIC2k in the development tree, so adding support for the TLV320AIC33 should be feasible. What I'm not sure about is the fact if ASOC is prepared for using channels, especially SSC, in TDM mode. Is the core ASOC structure prepared to handle that? Would we be better off instantiate one drive twice each time with different parameters for the SSC channel? Thanks for any feedback. -- MfG / Regards Friedrich Lobenstock _________________________________________________________ SCOTTY Group Austria GmbH a SCOTTY Group plc company, http://www.scottygroup.com/ _________________________________________________________

4 3

Re: [alsa-devel] Patchmix-style application for EMU cards
by Camilo Polymeris 30 Aug '10

30 Aug '10

Hello > That is more or less what I had figured out, but it how are playback_1 to > > _16 channels routed to DSP0-15? It seems that it depends on the setting > of > > Front, Surround, LFE, etc. mixer controls. If they are turned up, I > don't > > understand what happens, sound to playback channels appears on various > DSP > > buses, at different levels. > > Really? Well, I didn't much experiment with surround mode. In source code, > I > can see that there are up to playback 8 channels at hw:0,0 with can be > controlled by faders in alsamixer. I tried surround40 and surroun51 on my > emu1616m and it worked as expected. The channles were mapped to first > couple > of DSP ports in a correct order. In fact this should work the same as > audigy > does, except the result is passed to DSP ports instead of physical > outputs. > On my card, playback channels 1 & 2 (hw:0,3) appear on all DSP busses associated with surround. Say you turn up the "Side" fader in alsamixer, channels 1 & 2 will appear at the relevant DSPs (6-7, I think) Whatever, for now I am just keeping all surround controls down (that is, Front, Surround, Center, Side & LFE). > Anyway, I think if there is another layer of routing done in audigy DSP, > it > shouldn't be used in EMU specific application. Or at least not for now. > The > most important thing is to provide all the switches and FPGA routing > scheme > for each EMU model. Or, to be precise, three routing schemes for each EMU > model, because for "double speed" (e.g. 96kHz) and "quadro speed" (e.g. > 192kHz) modes of operation the numebr of both physical and virtual > channels > changes. > I think the switches and enums for the card models are rather trivial, one can handle it with a customized version of qamix (done with a simple XML file), for example. A separate application would not be necessary for only that. > > If I turn the Front/Surround/LFE/etc. faders down, I can mix playback > > channels to DSP using the "Multichannel PCM Send/Routing/Volume" faders, > in > > a more or less intuitive way, besides that routing values do not map > > directly to DSP buses (i.e. 14-15 map to DSP0-1, but 2-3 map to DSP2-3). > Handling of this controls motivated me to write the application in the first place. No sound at all will appear if I don't set the appropiate controls for each playback channel: Multichannel PCM Volume (full), Multichannel PCM Send (an index of 8 controls, the first 4 select the target DSP) & Multichannel PCM Send Volume (again faders 0-3 of 8) By the way, only DSP0-7 work in this way. I have no idea how to make DSP8-31 work. On which card you did tested it? The driver was primary written for the > 1820M/1212M V1, so some things may not work well on other models and need > to > be fixed. I have a 1212m, don't know which version, but I think it's V1-- it does have firewire. I am using driver version 1.0.16. Thanks, Camilo.

3 3

[alsa-devel] Audio buffer mmap-ing on sh arch vs. cache aliasing problem
by Pawel MOLL 16 Jan '10

16 Jan '10

Hi Guys, Recently I was investigating an issue with capturing audio using USB Audio Class device on a sh4-based board. "Bad voice quality" was reported... Finally I have traced the problem to something which is (unfortunately) well known to sh developers as a D-cache aliasing (or synonym) problem. Briefly speaking: due to some MMU design decisions, one can have two different virtual address pointing to the same physical location, which is fine, but going via different cache slots! So if there was a value of "0" in the memory and user "A" will write "1" there, user "B" will still read "0"... The solution is to ensure all TLB entries (so virtual memory areas) are beginning from a 16kB-aligned virtual address. Otherwise it is necessary to flush the cache between accesses from "A" and "B" sides. And now. The USB Audio Class driver (sound/usb/usbaudio.c) is allocating the sound buffer like this... static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { [...] runtime->dma_area = vmalloc(size); [...] } ... and vmalloc will return a page(4k)-aligned pointer, possibly not 16k-aligned one. This is the source of all evil ;-) When using RW transfers everything is fine, as data is memcopied between two independent buffers. In a case of MMAP mode we will end up with such a situation: 1. The driver will memcpy data from an URB to the buffer. It will populate several cache lines. Let's call it a "kernel cache". 2. As the library has mapped the non-16k-aligned address via different cache line ("user cache"), it will read some rubbish from the physical memory, populating the "user cache" by the way. 3. Some time later the "kernel cache" is flushed, writing the data to the memory. 4. Some new data from URB is entering "kernel cache". 5. The library will access mmap-ed area again, going via the "user cache", which may or may not reflect the correct data (depending on the fact was the "user cache" flushed or not) etc. Of course this cycle is completely not deterministic, so some of the "kernel cache" lines will be flushed before being accessed from user space, other not... The final effect is... hmm... bizarre :-) First, of course, you will get a (probably loud) glitch (rubbish from buffer's underlying memory, before the first valid data is written back), and then something that could be described as an "echo" ;-) I mean - you are capturing "1 2 3 4 5 6 7..." and the result is (G stands for Glitch ;-) "G 1 23 3 4 4 6 67..." As a quick-and-dirty work-around I have modified snd_pcm_alloc_vmalloc_buffer() to allocate always 12kB more and then use 16k-aligned pointer: static int snd_pcm_alloc_vmalloc_buffer(struct snd_pcm_substream *subs, size_t size) { struct snd_pcm_runtime *runtime = subs->runtime; if (runtime->dma_addr) { if (runtime->dma_bytes >= size) return 0; /* already large enough */ vfree((void *)runtime->dma_addr); } runtime->dma_addr = (unsigned long)vmalloc(size + 12 * 1024); if (!runtime->dma_addr) return -ENOMEM; runtime->dma_area = (void *)ALIGN(runtime->dma_addr, 16 * 1024); runtime->dma_bytes = size; return 0; } Of course it cannot be regarded as anything more as a hack. And definitely not as a solution... So my question is: Any idea how the "proper solution" should look like? I see no obvious method to get an arch-independent "mmap-compliant" buffer. This problem was found on a sh arch, using an USB Audio Class device, however out there some other architectures are suffering from this MMU "feature" as well (ie. see http://docs.hp.com/en/B3906-90006/ch07s09.html) and possibly other drivers could behave "wrongly" (quoted as the driver is actually innocent...) To be honest I just have absolutely no idea what to do with this all! :-O I hope I was clear enough in the description... Any feedback, advise, idea etc. will be more than appreciated. Cheers Paweł

3 11

[alsa-devel] Intel G45 8-Channel LPCM over HDMI
by Alexander Werner 11 Dec '09

11 Dec '09

Hi, I'm planning to build a linux-based, small sized PC for hearing aid acousticians. It would be highly unfavorable, if the connection between Receiver and PC was analog, because of the lower quality and the high number of cables. I searched for a appropriate mainboard, and found the DG45FC, which fits my needs perfectly, apart from the missing audio over HDMI support. Is there any plan to support multichannel LPCM output over HDMI on the Intel G45 platform? If not, is there anyone willing to implement HDMI support for the G45 chipset if I donate the needed hardware (permanently)? But if there's no chance to implement it in the near future, has anyone experience with an onboard chipset with multichannel LPCM over HDMI and ALSA support? Thanks, Alexander Werner

7 10

[alsa-devel] Trying to get unsupported CODEC to work
by Alex Austin 05 Nov '09

05 Nov '09

HelloI have an MSI Media Live DIVA motherboard. It has an AMD SB600 HD Audio controller, and two CODECs on the HDA bus. First is an ALC888 Second is an Intersil DAE-3. Two alsa-info outputs in different circumstances http://www.alsa-project.org/db/?f=20c86e755fdbbdbc8761c8c2f4de76bce2ea0c11 http://www.alsa-project.org/db/?f=15c5e5eab0104622a84b2dd0df03f26c17c7242d Output of codecgraph with "modprobe hda-intel probe_mask=2" http://pastebin.com/f54b6a9b8 What's the next step to get this supported? -- - Alex Austin (651) 238-9273 "...and then I visited Wikipedia ...and the next 8 hours are a blur."

3 13

[alsa-devel] my udev rules are breaking my dmixer setup why?
by Jelle de Jong 29 Jul '09

29 Jul '09

Hello everybody, I am trying to use udev to get fixed device names depending on the location of the device on the usb bus. The udev rules seems to be working fine, however i cant get dmix to work with the udev rules using only hw dies work. If i remove the udev rules the dmixer works fine. Can somebody look at the attachment, and maybe do some testing, i would highly appreciate it. I am also on chat.freenode.org and #alsa as tuxcrafter Thanks in advance, Jelle ls -hal /dev/snd/ total 0 drwxr-xr-x 2 root root 320 2008-11-09 15:44 . drwxr-xr-x 12 root root 4.8K 2008-11-09 15:50 .. crw-rw---- 1 root user0 116, 0 2008-11-09 15:44 controlC0 crw-rw---- 1 root user1 116, 32 2008-11-09 15:44 controlC1 crw-rw---- 1 root user2 116, 64 2008-11-09 15:44 controlC2 crw-rw---- 1 root user3 116, 96 2008-11-09 15:44 controlC3 crw-rw---- 1 root user0 116, 24 2008-11-09 15:44 pcmC0D0c crw-rw---- 1 root user0 116, 16 2008-11-09 15:49 pcmC0D0p crw-rw---- 1 root user1 116, 56 2008-11-09 15:44 pcmC1D0c crw-rw---- 1 root user1 116, 48 2008-11-09 15:44 pcmC1D0p crw-rw---- 1 root user2 116, 88 2008-11-09 15:44 pcmC2D0c crw-rw---- 1 root user2 116, 80 2008-11-09 15:44 pcmC2D0p crw-rw---- 1 root user3 116, 120 2008-11-09 15:44 pcmC3D0c crw-rw---- 1 root user3 116, 112 2008-11-09 15:44 pcmC3D0p crw-rw---- 1 root audio 116, 1 2008-11-09 15:44 seq crw-rw---- 1 root audio 116, 33 2008-11-09 15:44 timer ------------------------------------------------------------------------ udevinfo info --attribute-walk --name=/dev/snd/controlC0 ------------------------------------------------------------------------ echo 'SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="controlC[0-9]*", NAME="snd/controlC4" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="controlC[0-9]", NAME="snd/controlC5" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="controlC[0-9]", NAME="snd/controlC6" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="controlC[0-9]", NAME="snd/controlC7" SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC4D0c" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC5D0c" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC6D0c" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="hwC[0-9]D0c", NAME="snd/hwC7D0c" SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC4D0c" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC5D0c" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC6D0c" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="pcmC[0-9]D0c", NAME="snd/pcmC7D0c" SUBSYSTEM=="sound", KERNELS=="3-1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC4D0p" SUBSYSTEM=="sound", KERNELS=="3-2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC5D0p" SUBSYSTEM=="sound", KERNELS=="4-1", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC6D0p" SUBSYSTEM=="sound", KERNELS=="4-2", KERNEL=="pcmC[0-9]D0p", NAME="snd/pcmC7D0p"' | tee /etc/udev/rules.d/10-persistent-sound.rules chmod 600 /etc/udev/rules.d/10-persistent-sound.rules ------------------------------------------------------------------------ # without dmixer # this works .... echo 'pcm.softvol { type softvol slave.pcm hw:1 control.name Master control.card 1 } pcm.!default { type plug slave.pcm softvol } ctl.!default { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc ------------------------------------------------------------------------ # with dmixer # this does not work echo 'pcm.softvol { type softvol slave.pcm dmix:1 control.name Master control.card 1 } pcm.!default { type plug slave.pcm softvol } ctl.!default { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc ------------------------------------------------------------------------ # with dmixer # this does not work echo 'pcm.!default { type plug slave.pcm dmixer } pcm.dmixer { type dmix ipc_key 2048 slave.pcm hw:1 } ctl.dmixer { type hw card 1 } pcm.dsp { type plug slave.pcm dmixer } ctl.mixer { type hw card 1 }' | tee /home/user1/.asoundrc chmod 600 /home/user1/.asoundrc chown user1:user1 /home/user1/.asoundrc ------------------------------------------------------------------------

3 13

[alsa-devel] Backported sbxfi driver (UNTESTED!)
by Takashi Iwai 12 Jun '09

12 Jun '09

Hi, $SUBJECT is now on my sound-unstable git tree: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-unstable-2.6.git together with other experimental patches. If you're using 2.6.27-rc* git tree, pull the master branch of the tree above into yours, and run make oldconfig. That is, % cd /your/git-tree % git pull git://...../sound-unstable-2.6.git master If you are not using 2.6.27-rc*, or not familiar with git, you can try alsa-driver-unstable snapshot tarball available at ftp://ftp.kernel.org/pub/linux/kernel/people/tiwai/snapshot/ Run configure, make and make install as usual ALSA-driver tarball. (I didn't check whether the tarball correctly includes the sbxfi stuff. It should have been generated automatically. If not, wait for a while. If it still doesn't include sbxfi code, please report. I'll fix it tomorrow morning.) The driver is built only for 2.6.26 or later. If you have an older kernel, edit alsa-driver*/kconfig-vers and change the version of CONFIG_SND_SBXFI to 2.6.24 or whatever you want. Then run ./gitcompile, instead of configure in this case to update the configure script. **NOTE** The driver is totally untested. It's just compiled without errors, but not reviewed after a quick writing. So, don't expect it ever runs at the first try. A crash is highly possible. There are some build conditions found in sound/pci/sbxfi/sbxfi.c, starting with XXX_*. You can change it if you want. As default, it's for non-fullduplex but accept different rates. Not sure whether this works at all. Any test- (and better debugging-) reports are appreciated. thanks, Takashi

16 112

[alsa-devel] Roland/Edirol M-16DX
by Lasse Kärkkäinen 01 Jun '09

01 Jun '09

This device doesn't seem to be supported yet. Does Roland make the specifications available, etc? The device is not compatible with USB Audio, but rather uses Vendor Specific Class. lsusb -vvv is attached below and if you need more information, I can debug the device on Linux and on Vista. Bus 007 Device 025: ID 0582:00c4 Roland Corp. Device Descriptor: bLength 18 bDescriptorType 1 bcdUSB 2.00 bDeviceClass 255 Vendor Specific Class bDeviceSubClass 0 bDeviceProtocol 255 bMaxPacketSize0 64 idVendor 0x0582 Roland Corp. idProduct 0x00c4 bcdDevice 0.00 iManufacturer 1 EDIROL iProduct 2 M-16DX iSerial 0 bNumConfigurations 1 Configuration Descriptor: bLength 9 bDescriptorType 2 wTotalLength 167 bNumInterfaces 3 bConfigurationValue 1 iConfiguration 0 bmAttributes 0xc0 Self Powered MaxPower 0mA Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 06 24 f1 01 00 00 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 0 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 2 iInterface 0 ** UNRECOGNIZED: 07 24 01 01 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 02 04 18 01 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x02 EP 2 OUT bmAttributes 5 Transfer Type Isochronous Synch Type Asynchronous Usage Type Data wMaxPacketSize 0x0038 1x 56 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 0 bNumEndpoints 0 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 2 iInterface 0 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 1 bAlternateSetting 1 bNumEndpoints 1 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 2 bInterfaceProtocol 1 iInterface 0 ** UNRECOGNIZED: 07 24 01 07 00 01 00 ** UNRECOGNIZED: 0b 24 02 01 12 04 18 01 80 bb 00 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x81 EP 1 IN bmAttributes 37 Transfer Type Isochronous Synch Type Asynchronous Usage Type Implicit feedback Data wMaxPacketSize 0x01f8 1x 504 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 0 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 3 iInterface 0 ** UNRECOGNIZED: 06 24 f1 02 01 01 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Interface Descriptor: bLength 9 bDescriptorType 4 bInterfaceNumber 2 bAlternateSetting 1 bNumEndpoints 2 bInterfaceClass 255 Vendor Specific Class bInterfaceSubClass 1 bInterfaceProtocol 3 iInterface 0 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x04 EP 4 OUT bmAttributes 2 Transfer Type Bulk Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1 Endpoint Descriptor: bLength 7 bDescriptorType 5 bEndpointAddress 0x83 EP 3 IN bmAttributes 3 Transfer Type Interrupt Synch Type None Usage Type Data wMaxPacketSize 0x0200 1x 512 bytes bInterval 1

4 10

[alsa-devel] [PATCH 0/2] ASoC updates
by Mark Brown 07 May '09

07 May '09

The following changes since commit 32c8dabc97d436582298ebd0e33af041c69f5a4b: Mark Brown (1): ASoC: Remove obsolete declaration of struct snd_soc_clock_info are available in the git repository at: git://opensource.wolfsonmicro.com/linux-2.6-asoc for-tiwai Daniel Mack (1): ASoC: tlv320aic3x: control additions and cleanups Grazvydas Ignotas (1): ASoC: Add support for OMAP3 Pandora sound/soc/codecs/tlv320aic3x.c | 18 ++- sound/soc/omap/Kconfig | 8 + sound/soc/omap/Makefile | 2 + sound/soc/omap/omap3pandora.c | 311 ++++++++++++++++++++++++++++++++++++++++ 4 files changed, 334 insertions(+), 5 deletions(-) create mode 100644 sound/soc/omap/omap3pandora.c

7 20

Re: [alsa-devel] Bugs on aspire one A150
by Maxim Levitsky 16 Mar '09

16 Mar '09

Alan Jenkins wrote: > Maxim Levitsky wrote: >> 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) > > That sounds like a known issue. It has been resolved by "ACPI: EC: revert msleep patch". Happily Len submitted it for mainline this week. You will also find it if you try the acpi-test git tree. We're all hoping 2.6.28 will be much improved in terms of reliable operation of different ECs :). > 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. I see that this fix fixes the polled mode. Any chance to make irq mode work? >> ** 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. > > Well, that doesn't tell us much. Did they still happen after upgrading to 2.6.28-rc3? Can we see them? Fixed completely, looking through the git log I have seen a commit that fixes exactly same backtrace I had. No more errors in kernel log. > >> 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. This still not fixed, I ask about this again in separate mail. >> >> >> >> ** 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. 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 (I hear what I say in mic in headphones, same happens on my main notebook acer 5720) >> 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? > > 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. > > However, at the moment pciehp can cause delays of 10s of seconds during resume. I am aware of this, but don't yet have a SD card to test. > >> ** 7 - opengl is broken, I tried running neverball in fullscreen, but it shows wrong/corrupted >> textures (compiz is running, and working well thought) Without compiz neveball works fine (slow, but this is very slow hardware) >> >> 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 related to periodic key exchange WPA does? Now fixed, big thanks. >> >> * System doesn't reboot/shutdown, just hangs. > > 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. 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

3 25