jumpkick | hello | 02:26 |
---|---|---|
jumpkick | why are there no sound drivers in the Hardy Heron AMD64 Kernel? | 02:26 |
johanbr | jumpkick: They're in the linux-ubuntu-modules package. | 02:27 |
jumpkick | johanbr: okay thanks.... | 02:29 |
jumpkick | that was a wrinkle from upgrading gutsy -> hardy that didn't go quite right I guess | 02:29 |
johanbr | jumpkick: Oh, okay. How did you upgrade? | 02:31 |
jumpkick | johanbr: I tried to do the Kubntu upgrade, but it crashed my X when I clicked on the details box, so I ended up just doing it from the shell | 02:35 |
jumpkick | change sources.list, dist-upgrade, upgrade, upgrade, still have a prob with ialib32 compat libs and vmware-server... but anyway | 02:36 |
johanbr | Ok. Then it's not so strange that you missed the l-u-m package. | 02:36 |
jumpkick | johanbr: if you have privs can you edit https://help.ubuntu.com/community/SoundTroubleshooting and just stick a line in there that says "make sure you have linux-ubuntu-modules installed"? | 02:37 |
johanbr | I don't have any special privileges. If I can edit that, so can you. :) | 02:39 |
jumpkick | okay I'll make a login and try | 02:40 |
=== dhaval_away is now known as dhaval | ||
TheMuso | 9/c | 06:36 |
=== dhaval is now known as dhaval_away | ||
=== dhaval_away is now known as dhaval | ||
=== dhaval is now known as dhaval_away | ||
bullgard4 | dmesg: "Marking TSC unstable due to: possible TSC halt in C2." Is this a Ubuntu design error or a feature? | 08:23 |
amitk | bullgard4: neither. It is a Linux kernel feature. If this is new hardware, try with clocksource=hpet in the kernel command line. | 08:38 |
devindia | i hope this is the place of ubuntu kernel developers ?? | 08:40 |
devindia | i have a question....is the development of kernel only/fully in C | 08:41 |
amitk | devindia: you would have more success if you actually tried downloading the kernel and looking at it instead of repeating your questions. | 08:42 |
amitk | devindia: try the irc channel on http://kernelnewbies.org/IRC | 08:42 |
cking | bullgard4: to find out alternative clocksources, use: sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource | 08:43 |
devindia | hey... amitk: please don get tensed..the question i asked just because of curiosity... i will download the kernel | 08:44 |
devindia | now | 08:44 |
devindia | ;-) | 08:44 |
amitk | tense... hmmm | 08:45 |
pwnguin | heh | 08:47 |
cking | not too much coffee? | 08:47 |
amitk | cking: naaah... I don't drink coffee. But perhaps I should just log out of here and enjoy the sunshine | 08:48 |
cking | amitk: Is May 1st a holiday for you? | 08:49 |
amitk | amitk: yup | 08:49 |
amitk | cking: yup | 08:49 |
amitk | yeah.. I need to get out | 08:49 |
cking | ..well then.. go and enjoy the day off. | 08:49 |
amitk | bye | 08:49 |
bullgard4 | cking: Before you will leave this channel also, let me say thank you for your help. I am still studying how the 4 available clocksources on this computer function. Still, I consider it a nuisance that the 'time' jumps backwards in dmesg output. | 08:56 |
cking | bullgard4: I'll be here all day, so any questions, I will try to answer. | 08:57 |
cking | hpet is probably the best bet if you have it, ignore jiffies and tsc if possible. | 08:59 |
cking | http://en.wikipedia.org/wiki/Time_Stamp_Counter - explains why tsc can cause problems. | 09:01 |
bullgard4 | cking: The article http://en.wikipedia.org/wiki/Time_Stamp_Counter rather vaguely states: "If the processor frequency changes (via SpeedStep for example), the timer no longer accurately measures wall clock time." I have no AMD processor and no multiprocessor. Still, the dmesg output 'time' displayed decreases sometimes. What is the reason? | 11:08 |
cking | bullgard4: referring to tsc, I am unsure why time decreases off the top of my head - I need to investigate that one. | 11:11 |
cking | have you tried the other clock sources? And can your processor change frequency? | 11:11 |
=== rikai_ is now known as rikai | ||
=== dhaval_away is now known as dhaval | ||
snikker | when i insert a cd/dvd in a second dvd drive, the system don't mount it and in dmesg, i've got this: http://pastebin.com/m1cc3d71c it's a kernel bug? | 13:22 |
smb | snikker: sounds rather like hardware trouble. maybe bad cables? or try to force a slower dma rate through the bios and see whether that helps. | 13:28 |
snikker | smb: the hardware workk fine in windows and live cd... i'ce also set udma2 in bios, but nothing to do | 13:30 |
ogra | does the same CD/DVD work in the other driver ? | 13:30 |
ogra | *drive | 13:30 |
snikker | smb: with hdparm i see that the udma is set to udma4 | 13:30 |
snikker | ogra: yes it work | 13:31 |
smb | snikker: from the messages it really sound like problems talking to the drive. can you use hdparm to set udma2 and try? | 13:32 |
smb | snikker: or maybe, is that cd you try a self-burned one? | 13:33 |
snikker | smb: now i try, even if i don't know how to set udma2 with hdparm.... | 13:33 |
smb | -Xudma2 | 13:34 |
snikker | don't work, same error | 13:37 |
snikker | http://pastebin.com/m3af0258e | 13:37 |
snikker | any other hints? | 14:01 |
smb | snikker: hdparm seems to have problems with changing dma. Maybe http://www.kernel.org/doc/Documentation/kernel-parameters.txt (libata.dma=1) helps to temporarily check whether drive works without dma | 14:03 |
snikker | ok thanks, now i check | 14:04 |
Battery | hi guys, is there anybody here that know something about loading 2 cross-dependant modules? | 18:30 |
johanbr | Battery: sudo modprobe mod1 mod2 maybe | 18:39 |
Battery | johanbr: thanks - i'll give it a go... | 18:40 |
Battery | nope, neither modprobe mod1 mod2 nor insmod mod1 mod2 works - it just loads mod1 and then moans about the missing symbols (that's in mod2) | 19:01 |
alex_joni | Battery: try modprobe -a mod1 mod2 | 19:13 |
mkrufky | smb: I'm curious as to what you think about the hald issue... bug 209971 | 19:36 |
mkrufky | c'mon ubotu -- i know you can do it | 19:37 |
mkrufky | anyway, you'll see my email within seconds / minutes | 19:37 |
smb | [Hardy Regression] cx22702 no longer works | 19:37 |
mkrufky | yeah -- bug is a total misnomer | 19:38 |
smb | mkrufky: I just saw your mail | 19:38 |
mkrufky | cx22702 works on all other boards | 19:38 |
mkrufky | its only broken on hvr1300, because hald is futzing with gpios | 19:38 |
mkrufky | fwiw, the mpeg encoder is ALSO broken on that board, for the same reason | 19:38 |
mkrufky | *and* the analog tuner | 19:38 |
mkrufky | basically... the entire card is broken under ubuntu... the only error visible in dmesg is the cx22702 error, and thats why users point a finger to cx22702 | 19:39 |
mkrufky | dont get me wrong -- by all means, please merge the workaround patch ... but, it would be nice to get to the bottom of the REAL issue | 19:39 |
smb | mkrufky: From the reports it sounded like only the radio part was broken. | 19:40 |
mkrufky | this is what's REALLY happening... | 19:41 |
mkrufky | and to qualify this, i am employed by hauppauge, and i looked this up in schematics | 19:41 |
smb | mkrufky: If this is tied to hal, I wonder what is behind that. hal itself I suppose, acts rather as a relay | 19:41 |
mkrufky | the gpios are used on that board as a mechanism to toggle the cx22702 in or out of reset | 19:41 |
mkrufky | likewise, when the cx22702 is in reset, the cx23416 is in line | 19:42 |
mkrufky | when the cx22702 is in line, the cx23416 is tristated | 19:42 |
mkrufky | the cx22702 acts as an "i2c gate" | 19:42 |
mkrufky | ie: one cannot access the tuner via i2c if the i2c gate is closed | 19:42 |
mkrufky | now... | 19:42 |
=== thegodfather is now known as fabbione | ||
mkrufky | hald is trashing the gpios of any input where the gpios are undefined | 19:42 |
mkrufky | whomever initially added support for the hvr1300, was obviopusly not interested in supporting radio | 19:43 |
mkrufky | so, they left it off | 19:43 |
mkrufky | somehow, this allowed hald to trash those gpios | 19:43 |
mkrufky | sending the cx22702 / cx23416 bus control into an unknown state | 19:43 |
mkrufky | potentially rendering the tuner useless, without communication to it throught the i2c gate | 19:43 |
mkrufky | i think that covers the background info | 19:44 |
mkrufky | now, i have no idea how HAL is actually trashing the gpios | 19:44 |
mkrufky | but we were able to prevent the issue by defining those gpios for the only undefined input source | 19:44 |
mkrufky | now radio is supported, and the issue is gone, for THAT board | 19:44 |
mkrufky | however......... | 19:44 |
mkrufky | any other board, which may have crucial ic's reset lines tied to the cx2388x GPIOs will have the same issue | 19:45 |
mkrufky | (i have yet to hear any other problem reports, however) | 19:45 |
mkrufky | i have only heard of this issue on the hvr1300 under hardy, but that could simply be because it is a popular card ... who knows if other devices are affected. | 19:45 |
mkrufky | (ok, i think im done now) ;-) | 19:46 |
smb | mkrufky: Ok. :) For me this sound like this requires further investigation. So at least this should be noted down into the bug report. When I quickly looked at the patch I saw likewise undefined portions for other boards, so I was already wondering why only one is affected. | 19:48 |
smb | I sure am not that well into hal to have an answer on what hal does there, but maybe someone jumps in and can. | 19:49 |
mkrufky | sorry, was afk for a moment | 19:49 |
mkrufky | this doesnt *necessarily* cause problems on other boards | 19:50 |
mkrufky | it can *potentially* cause such problems -- the only such board that we *know* is affected is the hvr1300 | 19:50 |
mkrufky | so far the other cx22702-based cards seem to be immune | 19:50 |
mkrufky | (mainly, because those other boards dont have any ic resets tied to gpios) | 19:50 |
mkrufky | but yes -- certainly requires further investigation | 19:51 |
mkrufky | and... in my opinion.... this gpio fix will likely get accepted into 8.04 anyway, since , to my knowledge, ubuntu does keep up with the -stable series | 19:51 |
smb | But it normally also needs a justification after release. | 19:52 |
mkrufky | "prevents broken behavior, as described in bug 209971 | 19:53 |
mkrufky | " | 19:53 |
smb | Preventing 1G of logs per hour is a reasonable justification (IMO) and acceptance by upstream is just the better | 19:53 |
ph8 | Hi all, i've just upgrade to hardy and the new kernel recognises my on board ethernet - bizarrely though i can't connect to my network over static OR dhcp - if i change back to the old kernel it works fine - i've got up to date -restricted -modules and even -backports packages according to apt - can anyone help shed any light on this? | 19:54 |
smb | Being in that progress was the reason for the mail you saw on the kernel-team list | 19:54 |
mkrufky | yes | 19:55 |
mkrufky | smb: did anything come of the cx88 / saa7134 issue, building those out-of-tree ? | 20:02 |
smb | mkrufky: The drivers (except alsa modules) were taken out of lum. | 20:04 |
mkrufky | oh, nice | 20:04 |
mkrufky | i didnt get that update yet, myself... but i'll do a full-upgrade when i get home and test it out | 20:05 |
mkrufky | thank you :-) | 20:05 |
smb | mkrufky: This will first show up with hardy-proposed | 20:05 |
mkrufky | ah | 20:05 |
mkrufky | ok | 20:05 |
smb | mkrufky: So you have to enable that. But the uploads are either in progress or will be done soon. | 20:06 |
smb | So you still need a bit of patience. ;-) | 20:06 |
mkrufky | im patient -- i am fixing other upstream bugs in the meanwhile :-P | 20:07 |
smb | mkrufky: :) | 20:07 |
ph8 | Hi all, sorry i got disconnected after my query. After a bit more research it appears i'm using an nvidia chipset as referenced here: https://bugs.launchpad.net/linux/+bug/181081 - i can't get an IP from DHCP (or static) - can anyone help me? I'm assuming the patch referenced at the bottom isn't in the kernel at the moment - when can i expect it to be updated? I'm probably going to have to wipe and install gutsy.. | 21:06 |
rtg | ph8: try the 2.6.25 kernel and LUM packages from https://edge.launchpad.net/~timg-tpi/+archive | 21:07 |
ph8 | sounds like a plan! :) will let you know how it goes shortly | 21:08 |
ph8 | bizarelly works in 2.6.22 (or whatever gutsy is on) | 21:11 |
ph8 | rtg: System doesn't appear to boot at all under .25-1 unfortunately | 21:31 |
ph8 | stops after it attaches disks | 21:31 |
ph8 | my connection's appalling this evening | 21:31 |
=== asac_ is now known as asac |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!