[02:26] hello [02:26] why are there no sound drivers in the Hardy Heron AMD64 Kernel? [02:27] jumpkick: They're in the linux-ubuntu-modules package. [02:29] johanbr: okay thanks.... [02:29] that was a wrinkle from upgrading gutsy -> hardy that didn't go quite right I guess [02:31] jumpkick: Oh, okay. How did you upgrade? [02:35] 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] change sources.list, dist-upgrade, upgrade, upgrade, still have a prob with ialib32 compat libs and vmware-server... but anyway [02:36] Ok. Then it's not so strange that you missed the l-u-m package. [02:37] 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] I don't have any special privileges. If I can edit that, so can you. :) [02:40] okay I'll make a login and try === dhaval_away is now known as dhaval [06:36] 9/c === dhaval is now known as dhaval_away === dhaval_away is now known as dhaval === dhaval is now known as dhaval_away [08:23] dmesg: "Marking TSC unstable due to: possible TSC halt in C2." Is this a Ubuntu design error or a feature? [08:38] bullgard4: neither. It is a Linux kernel feature. If this is new hardware, try with clocksource=hpet in the kernel command line. [08:40] i hope this is the place of ubuntu kernel developers ?? [08:41] i have a question....is the development of kernel only/fully in C [08:42] devindia: you would have more success if you actually tried downloading the kernel and looking at it instead of repeating your questions. [08:42] devindia: try the irc channel on http://kernelnewbies.org/IRC [08:43] bullgard4: to find out alternative clocksources, use: sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource [08:44] hey... amitk: please don get tensed..the question i asked just because of curiosity... i will download the kernel [08:44] now [08:44] ;-) [08:45] tense... hmmm [08:47] heh [08:47] not too much coffee? [08:48] cking: naaah... I don't drink coffee. But perhaps I should just log out of here and enjoy the sunshine [08:49] amitk: Is May 1st a holiday for you? [08:49] amitk: yup [08:49] cking: yup [08:49] yeah.. I need to get out [08:49] ..well then.. go and enjoy the day off. [08:49] bye [08:56] 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] bullgard4: I'll be here all day, so any questions, I will try to answer. [08:59] hpet is probably the best bet if you have it, ignore jiffies and tsc if possible. [09:01] http://en.wikipedia.org/wiki/Time_Stamp_Counter - explains why tsc can cause problems. [11:08] 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] bullgard4: referring to tsc, I am unsure why time decreases off the top of my head - I need to investigate that one. [11:11] have you tried the other clock sources? And can your processor change frequency? === rikai_ is now known as rikai === dhaval_away is now known as dhaval [13:22] 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] 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] smb: the hardware workk fine in windows and live cd... i'ce also set udma2 in bios, but nothing to do [13:30] does the same CD/DVD work in the other driver ? [13:30] *drive [13:30] smb: with hdparm i see that the udma is set to udma4 [13:31] ogra: yes it work [13:32] snikker: from the messages it really sound like problems talking to the drive. can you use hdparm to set udma2 and try? [13:33] snikker: or maybe, is that cd you try a self-burned one? [13:33] smb: now i try, even if i don't know how to set udma2 with hdparm.... [13:34] -Xudma2 [13:37] don't work, same error [13:37] http://pastebin.com/m3af0258e [14:01] any other hints? [14:03] 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] ok thanks, now i check [18:30] hi guys, is there anybody here that know something about loading 2 cross-dependant modules? [18:39] Battery: sudo modprobe mod1 mod2 maybe [18:40] johanbr: thanks - i'll give it a go... [19:01] 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] Battery: try modprobe -a mod1 mod2 [19:36] smb: I'm curious as to what you think about the hald issue... bug 209971 [19:37] c'mon ubotu -- i know you can do it [19:37] anyway, you'll see my email within seconds / minutes [19:37] [Hardy Regression] cx22702 no longer works [19:38] yeah -- bug is a total misnomer [19:38] mkrufky: I just saw your mail [19:38] cx22702 works on all other boards [19:38] its only broken on hvr1300, because hald is futzing with gpios [19:38] fwiw, the mpeg encoder is ALSO broken on that board, for the same reason [19:38] *and* the analog tuner [19:39] 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] 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] mkrufky: From the reports it sounded like only the radio part was broken. [19:41] this is what's REALLY happening... [19:41] and to qualify this, i am employed by hauppauge, and i looked this up in schematics [19:41] mkrufky: If this is tied to hal, I wonder what is behind that. hal itself I suppose, acts rather as a relay [19:41] the gpios are used on that board as a mechanism to toggle the cx22702 in or out of reset [19:42] likewise, when the cx22702 is in reset, the cx23416 is in line [19:42] when the cx22702 is in line, the cx23416 is tristated [19:42] the cx22702 acts as an "i2c gate" [19:42] ie: one cannot access the tuner via i2c if the i2c gate is closed [19:42] now... === thegodfather is now known as fabbione [19:42] hald is trashing the gpios of any input where the gpios are undefined [19:43] whomever initially added support for the hvr1300, was obviopusly not interested in supporting radio [19:43] so, they left it off [19:43] somehow, this allowed hald to trash those gpios [19:43] sending the cx22702 / cx23416 bus control into an unknown state [19:43] potentially rendering the tuner useless, without communication to it throught the i2c gate [19:44] i think that covers the background info [19:44] now, i have no idea how HAL is actually trashing the gpios [19:44] but we were able to prevent the issue by defining those gpios for the only undefined input source [19:44] now radio is supported, and the issue is gone, for THAT board [19:44] however......... [19:45] any other board, which may have crucial ic's reset lines tied to the cx2388x GPIOs will have the same issue [19:45] (i have yet to hear any other problem reports, however) [19:45] 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] (ok, i think im done now) ;-) [19:48] 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] 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] sorry, was afk for a moment [19:50] this doesnt *necessarily* cause problems on other boards [19:50] it can *potentially* cause such problems -- the only such board that we *know* is affected is the hvr1300 [19:50] so far the other cx22702-based cards seem to be immune [19:50] (mainly, because those other boards dont have any ic resets tied to gpios) [19:51] but yes -- certainly requires further investigation [19:51] 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] But it normally also needs a justification after release. [19:53] "prevents broken behavior, as described in bug 209971 [19:53] " [19:53] Preventing 1G of logs per hour is a reasonable justification (IMO) and acceptance by upstream is just the better [19:54] 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] Being in that progress was the reason for the mail you saw on the kernel-team list [19:55] yes [20:02] smb: did anything come of the cx88 / saa7134 issue, building those out-of-tree ? [20:04] mkrufky: The drivers (except alsa modules) were taken out of lum. [20:04] oh, nice [20:05] i didnt get that update yet, myself... but i'll do a full-upgrade when i get home and test it out [20:05] thank you :-) [20:05] mkrufky: This will first show up with hardy-proposed [20:05] ah [20:05] ok [20:06] mkrufky: So you have to enable that. But the uploads are either in progress or will be done soon. [20:06] So you still need a bit of patience. ;-) [20:07] im patient -- i am fixing other upstream bugs in the meanwhile :-P [20:07] mkrufky: :) [21:06] 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] ph8: try the 2.6.25 kernel and LUM packages from https://edge.launchpad.net/~timg-tpi/+archive [21:08] sounds like a plan! :) will let you know how it goes shortly [21:11] bizarelly works in 2.6.22 (or whatever gutsy is on) [21:31] rtg: System doesn't appear to boot at all under .25-1 unfortunately [21:31] stops after it attaches disks [21:31] my connection's appalling this evening === asac_ is now known as asac