[02:26] <jumpkick> hello
[02:26] <jumpkick> why are there no sound drivers in the Hardy Heron AMD64 Kernel?
[02:27] <johanbr> jumpkick: They're in the linux-ubuntu-modules package.
[02:29] <jumpkick> johanbr: okay thanks....
[02:29] <jumpkick> that was a wrinkle from upgrading gutsy -> hardy that didn't go quite right I guess
[02:31] <johanbr> jumpkick: Oh, okay. How did you upgrade?
[02:35] <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:36] <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:37] <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:39] <johanbr> I don't have any special privileges. If I can edit that, so can you. :)
[02:40] <jumpkick> okay I'll make a login and try
[06:36] <TheMuso> 9/c
[08:23] <bullgard4> dmesg: "Marking TSC unstable due to: possible TSC halt in C2." Is this a Ubuntu design error or a feature?
[08:38] <amitk> bullgard4: neither. It is a Linux kernel feature. If this is new hardware, try with clocksource=hpet in the kernel command line.
[08:40] <devindia> i hope this is the place of ubuntu kernel developers ??
[08:41] <devindia> i have a question....is the development of kernel only/fully in C
[08:42] <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:43] <cking> bullgard4: to find out alternative clocksources, use: sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource 
[08:44] <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:45] <amitk> tense... hmmm
[08:47] <pwnguin> heh
[08:47] <cking> not too much coffee?
[08:48] <amitk> cking: naaah... I don't drink coffee. But perhaps I should just log out of here and enjoy the sunshine
[08:49] <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:56] <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:57] <cking> bullgard4: I'll be here all day, so any questions, I will try to answer.
[08:59] <cking> hpet is probably the best bet if you have it, ignore jiffies and tsc if possible.
[09:01] <cking> http://en.wikipedia.org/wiki/Time_Stamp_Counter - explains why tsc can cause problems.
[11:08] <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:11] <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?
[13:22] <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:28] <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:30] <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:31] <snikker> ogra: yes it work
[13:32] <smb> snikker: from the messages it really sound like problems talking to the drive. can you use hdparm to set udma2 and try?
[13:33] <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:34] <smb> -Xudma2
[13:37] <snikker> don't work, same error
[13:37] <snikker> http://pastebin.com/m3af0258e
[14:01] <snikker> any other hints?
[14:03] <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:04] <snikker> ok thanks, now i check
[18:30] <Battery> hi guys, is there anybody here that know something about loading 2 cross-dependant modules?
[18:39] <johanbr> Battery: sudo modprobe mod1 mod2 maybe
[18:40] <Battery> johanbr: thanks - i'll give it a go...
[19:01] <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:13] <alex_joni> Battery: try modprobe -a mod1 mod2
[19:36] <mkrufky> smb: I'm curious as to what you think about the hald issue... bug 209971
[19:37] <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:38] <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:39] <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:40] <smb> mkrufky: From the reports it sounded like only the radio part was broken.
[19:41] <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:42] <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] <mkrufky> hald is trashing the gpios of any input where the gpios are undefined
[19:43] <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:44] <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:45] <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:46] <mkrufky> (ok, i think im done now) ;-)
[19:48] <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:49] <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:50] <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:51] <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:52] <smb> But it normally also needs a justification after release. 
[19:53] <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:54] <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:55] <mkrufky> yes
[20:02] <mkrufky> smb: did anything come of the cx88 / saa7134 issue, building those out-of-tree ?
[20:04] <smb> mkrufky: The drivers (except alsa modules) were taken out of lum. 
[20:04] <mkrufky> oh, nice
[20:05] <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:06] <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:07] <mkrufky> im patient -- i am fixing other upstream bugs in the meanwhile :-P
[20:07] <smb> mkrufky: :)
[21:06] <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:07] <rtg> ph8: try the 2.6.25 kernel and LUM packages from https://edge.launchpad.net/~timg-tpi/+archive
[21:08] <ph8> sounds like a plan! :) will let you know how it goes shortly
[21:11] <ph8> bizarelly works in 2.6.22 (or whatever gutsy is on)
[21:31] <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