=== doko_ is now known as doko
=== asac_ is now known as asac
[10:52] <lesshaste> hi
[10:54] <lesshaste> https://bugs.launchpad.net/ubuntu/+source/linux/+bug/224561 seems to indicate that my DVD drive is called hda but apparently there is hdX naming anymore in Hardy
[10:55] <lesshaste> ogra from #ubuntu-bugs asked me to confirm that this is indeed the problem
[11:07] <abogani> Arghhhh! Why nvidia kernel driver required manual depmod -a to work (after today Hardy update)?????
[11:08] <lesshaste> abogani: :)
[11:09] <abogani> lesshaste: :-?
[11:10] <tjaalton> abogani: there were no updates related to that..
[11:12] <abogani> It isn't first time...
[11:12] <tjaalton> but it's not the updates that causes it
[11:17] <abogani> I suspect that lum break something module.dep related...
[11:18] <tjaalton> do you use hardy-proposed?
[11:18] <abogani> Yeah
[11:18] <tjaalton> there are plenty of bugs against lrm about people needing to reinstall the driver every time etc
[11:18] <tjaalton> but too scary for me to debug ;)
[11:22] <abogani> tjaalton: Ahhhh ok! Are those bugs related only on lrm or on lum also?
[11:22] <abogani> tjaalton: Thanks! :-)
[11:45] <tjaalton> abogani: no idea, people at least assume it's X which broke their setup
[11:45] <abogani> tjaalton: Thank you very much! :-)
[11:46] <tjaalton> abogani: feel free to find the culprit ;)
[11:46] <abogani> :-)
[11:47] <tseliot> *cough* DKMS *cough* :-P
[11:48]  * tseliot exits DKMS zealot mode
[11:49] <tjaalton> I don't think DKMS would help here
[11:49] <tjaalton> since the modules are there
[11:50] <tjaalton> they just aren't getting loaded or something like that
[11:55] <tseliot> tjaalton: I was kidding ;) . It's weird that they are not loaded. It never happened here
[11:56] <tjaalton> for me neither
[12:16] <tseliot> tjaalton: BTW I think we should have a look at all the warnings which dpkg-shlibdeps shoots when the lrm are built
[12:17] <tseliot> we can do it in Intrepid
[12:20] <tjaalton> tseliot: those should be harmless
[12:21] <tjaalton> but yes
[12:21] <tseliot> tjaalton: yes, I know but I would like to see why it complains when I have the time
=== cradek_ is now known as cradek
[16:47] <qense> What's the purpose of the new 'envy' kernels?
[17:04] <JanC> envy kernels?
[17:09] <qense> there are kernle packages with envy in their name
[17:09] <qense> and nvidia drivers with envy in their name, ati drivers too
[17:09] <laga> you've probably installed envy-ng
[17:10] <laga> i can't see envy kernels here
[17:11] <qense> I didn't installed envy-ng as far as I know
[17:12] <qense> but I do have hardy-proposed enabled
[17:12] <qense> ah
[17:12] <qense> there are ati or nvidia drivers with envy in thier name
[17:13] <qense> is it going to be used by default in intrepid?
[17:13] <tseliot> qense: those are the drivers which I can update without touching the default lrm
[17:14] <qense> and that's better?
[17:15] <tseliot> just different
[17:15] <laga> i didn't know that NEW stuff was supposed to go through proposed. nice
[17:15] <tseliot> they use DKMS
[17:15] <qense> and DKMS can load modules dynamically whil the kernel is running?
[17:16] <tseliot> it auto-installs the modules if the kernel doesn't have one. It can do it at boot or when the package is installed
=== sn9_ is now known as sn9
=== thegodfather is now known as fabbione
[20:21] <foka> Hi!  Has anyone run into a problem with Ubuntu 8.04 LiveCD with rtl8169_init_one causing a kernel Oops and then failing to boot?  :-)
[20:25] <rtg> foka: as a matter of fact, we were just working on that. see http://people.ubuntu.com/~tspindler/r8169/
[20:26] <foka> rtg, Very cool!  Thanks!  (And packaged by Torsten too!  Nice!  We've met in Beijing.  :-))
[20:26] <rtg> I'll likely include it as an SRU upload, but the Live CD won't get reissued until 8.04.1.
[20:28] <foka> rtg, Is this the solution for the problem that caused the bug?   http://lkml.org/lkml/2008/4/17/298
[20:29] <rtg> foka: I don't know. I haven't looked at Torsten's patch. The other r8169 bug I've been following crashes in PCI probe code, so it may be related.
[20:29] <foka> rtg, Yes, I finally managed to get 8.04 installed by disabling the on-board LAN in the BIOS.  :-)
[20:30] <foka> rtg, One more thing that I'd like to ask: Is it normal (while still in initrd) that dmesg shows logs with missing numbers?  
[20:30] <foka> rtg, What I mean is this:  [    0.000] Linux version 2.6.2-1-generic (buildd@palmer) (gcc version 4.2.3 (Ubuntu 4.2.3-2ubuntu7)) #1 SMP Thu Apr 1 1:2:4 UTC 20 (Ubuntu 2.6.2-1.3-generic)
[20:30] <rtg> foka: thats essentially what the guy in Taiwan ended up doing, though he used language that made me think he clipped leads to the part.
[20:31] <rtg> foka: are you on an Atom based board? My taiwan guy had exactly the same issue.
[20:32] <rtg> foka: I had a hell of a time deciphering his stack trace 'cause random characters were missing.
[20:32] <foka> rtg, No, not an Atom AFAIK, but a desktop motherboard with 945 chipset.
[20:33] <rtg> foka: straight video though? not serial console?
[20:33] <foka> rtg, I could read the full text if I press "Shift-PageUp".
[20:34] <rtg> foka: so its in the display RAM, but isn't getting rendered at speed.
[20:34] <foka> rtg, But to save typing, I did a "dmesg > dmesg.txt" and then copied it to a USB stick (by manually modprobing sd_mod and usb-storage first)
[20:34] <foka> rtg, It is that "dmesg.txt" which is missing numbers all over the place.
[20:35] <rtg> foka: how about once its booted? do the consoles work ok?
[20:35] <foka> rtg, You're referring the Ubuntu report reported by a Dell engineer, right?  :-)
[20:35] <rtg> foka: yeah, its a dell box.
[20:35] <foka> rtg, Well you see, I couldn't get it to boot further because it some how messed up the SATA driver.
[20:36] <rtg> which is exactly where Torsten ended up. 
[20:36] <foka> rtg, With the LAN disabled, however, I could get into GNOME and all, and once there, dmesg is not missing anything.
[20:36] <rtg> maybe the problem clears up after we fix the r8169 crash.
[20:37] <foka> rtg, Yes, I hope so too.  It is weird because it appears that only "every second numbers" are missing.
[20:38] <rtg> well, who knows what the side effects of memory corruption are. I'll produce a PPA kernel later (maybe tonight0 with this fix.
[20:38] <foka> rtg, This may not be the exact rule:  Whenever there are two of [0-9] in a row, the second digit gets dropped out.
[20:39] <foka> rtg, Nice!  Thank you very much!  :-)
[20:40] <ivoks> ummm...
[20:41] <ivoks> why don't we just apply this?
[20:41] <ivoks> http://launchpadlibrarian.net/8736376/linux-source-2.6.15_nfsv4client.patch
[20:41] <ivoks> it's sitting on LP for 9 months, solves a serious issue that's confirmed by multiple people
[20:42] <ivoks> https://bugs.edge.launchpad.net/ubuntu/+source/linux-source-2.6.15/+bug/58170
[20:42] <rtg> BenC is the dapper dude.
[20:43] <BenC> rtg: Thanks, you're pretty dapper yourself
[20:43] <alex_joni> heh
[20:43] <foka> rtg, I just looked at Torsten's package (very briefly), and I saw that he did applied  "[PATCH] NET: r8169: fix oops in r8169_get_mac_version" (http://lkml.org/lkml/2008/4/17/298)
[20:44] <rtg> ho ho ho
[20:44] <foka> rtg, Looks like that's the cause.
[20:44] <BenC> foka: Ah, right, that's the crash TeTeT is seeing
[20:44] <ivoks> BenC: :) ok, so how about it? :)
[20:45] <rtg> foka: yep - I've come to the same conclusion. I'm preparing an SRU inclusion request.
[20:45] <foka> rtg, While googling randomly, I saw another patch: http://www.spinics.net/lists/netdev/msg60658.html  , I wonder if it may come in handy too?  :-)
[20:45] <BenC> ivoks: We sure can, but that bug is triggering some memories...does it cause a regression in another area?
[20:45] <ivoks> BenC: it's part of 2.6.17, if i'm not mistaken...
[20:45] <ivoks> i don't know about regressions
[20:45] <BenC> ivoks: does it apply cleanly to our 2.6.15 tree?
[20:46] <rtg> foka: one thing at a time. In order for it to satisfy SRU policy, it has to be reproducible, testable, yada, yada.
[20:46] <BenC> I think it may have huge rejects because of some CVE's we also fixed
[20:46] <foka> BenC, Yes, we experienced the same bug on a desktop motherboard here too.
[20:46] <ivoks> well, this patch was against our tree
[20:46] <ivoks> BenC: i can check, of course...
[20:46] <BenC> foka: I believe I already told TeTeT about that bug, I tracked it down, and it was triggered because the 8169 mac is unknown (but that's not the bug)
[20:47] <BenC> foka: Any chance we can get correct info for that mac in addition to the fix?
[20:47] <foka> rtg, True.
[20:48] <foka> BenC, Unfortunately, we have returned the motherboard, but I'll ask my colleague to borrow it again tomorrow.
[20:48] <BenC> foka: thanks
[20:49] <foka> BenC, Should I create a bug report on Launchpad?  (I see that there is already https://bugs.launchpad.net/bugs/223656 , but it is a "private" bug?  I finally got sneaky and managed to get a Google cache of it... :-p)
[20:50] <rtg> foka: oh, you bad boy :)
[20:50] <BenC> foka: Really?!
[20:50] <BenC> I wonder if it was public for a bit, or if there's some other bug that let google do that
[20:51] <foka> rtg, Not any more, now Google cannot find the cache.  :-D
[20:51] <rtg> foka: yeah - he marked it private.
[20:51] <foka> rtg, But it was the only relevant result when I searched "rtl8169_init_one ubuntu" or "rtl8169_init_one 8.04" or something like that.
[20:51] <foka> rtg, I don't know how Google got through either.  Maybe it got the cache before he marked it private?  Or Google got a special account or something like that?
[20:52] <rtg> foka: I'll see if I can get him to open it up. there isn't anything particularly proprietary. In fact, his help came from a public source (i.e. you).
[20:52] <ivoks> BenC: it fits in dapper git as a hand in a glow
[20:52] <BenC> ivoks: I hope you mean glove
[20:52] <ivoks> right :)
[20:53] <foka> rtg, Or should I just start a new bug report?  :-D
[20:53] <rtg> foka: no, gimme a bit. any new one would just get marked as a duplicate. 
[20:54] <foka> rtg, Gotcha.  :-)  That nicely justifies my procrastination.  :-)
[20:55]  * foka has never filed a bug report on Launchpad before.  :-)
[20:55] <rtg> foka: yeah, all that paper work, such a pain in the ass. you ought to do a bunch of SRUs. very tedious.
[20:58]  * foka goes read up about SRUs
[20:59] <foka> rtg, I got a dmesg.txt (with missing numbers here).  Would you like a copy?  (Or should I just wait until the bug becomes public and attach it to the bug report then?)
[21:00] <rtg> foka: some light reading https://wiki.ubuntu.com/StableReleaseUpdates
[21:00] <rtg> foka: as for the dmesg output, its garbled because of memory corruption.
[21:00] <foka> rtg, Yes, I'm on that page.  :-)
[21:00] <rtg> if it continues after the r8169 fix, then we'll have to figure out why.
[21:00] <foka> rtg, I see.  Thanks!
[21:02] <foka> BenC, Just to make sure I understand you correctly.  MAC addresses look VV:VV:VV:PP:PP:PP, where VV:VV:VV represents the vendor (like RealTek).  You mean the bug is caused by new network chip containing VV:VV:VV  that is not listed in the latest r8169 driver, is that right?
[21:05] <foka> BenC, So, what I should do once I get the motherboard back, is to boot up e.g. Ubuntu 7.10 LiveCD, look at "ifconfig" output, and report back to you what the MAC address is.  Is that correct?
[21:10] <noelferreira> my keys get stuck sometimes and other times don't work. can anyone help me with this huge bug: http://pastebin.com/m7bc88052
[21:11] <rtg> foka: correct, VV:VV:VV is the vendor part of the MAC address and should not be zero.
[21:12] <rtg> foka: but that code isn't looking at the MAC address, its looking the revision of the MAC processor.
[21:15] <rtg> foka: however, it does look like the current Hardy driver will FUBAR on an unknown MAC version.
[21:15] <rtg> where MAC version is the same as chip revision or model.
[21:16] <foka> rtg, I see, thanks!  Is there an easy way to get the MAC version (or whatever info you need) from the command-line?  Or should I test by playing with r8169.c source code?
[21:17] <foka> rtg, Hmm... is that revision number written on the chip itself?  I think I took a photo of the chip... let me try to dig it up...
[21:18] <rtg> foka: yeah - you'll have to instrument the code. The ID on the chip migh give you an indicator of the revision or model.
[21:18] <rtg> sometimes those numbers are just a cross reference in a parts catalog
[21:24] <rtg> foka: test kernel building at https://edge.launchpad.net/~timg-tpi/+archive. Use 2.6.24-17.32ubuntu7 or higher
[21:26] <foka> rtg, I see.  Thanks!  I finally found the picture.  Here is what is written on it:  RTL8102E // 8Z121S1 G807B
[21:26] <foka> rtg, Many thanks about the link!  I'll make note of it.
[21:28] <rtg> foka: if you look in the driver code for 'enum mac_version' you can see there isn't an 8102E, so I'm betting you'll still have problems.
[21:29] <noelferreira> my keys get stuck sometimes and other times don't work. can anyone help me with this huge bug: http://pastebin.com/m7bc88052
[21:33] <rtg> mdomsch: can you comment on bug #225811 ? Steve is asking for SRU justification, so perhaps I didn't get the explanation correct.
[21:37] <mdomsch> rtg, I did
[21:38] <mdomsch> rtg, looks like he bought it too :-)
[21:38] <rtg> mdomsch: oops. sorry. I was just reading the email trail and didn't look at the web page for the mostest currentest version.
[21:38] <mdomsch> np
[21:38] <mdomsch> I hadn't seen his follow-up comments yet
[21:40] <noelferreira> my keys get stuck sometimes and other times don't work. can anyone help me with this huge bug: http://pastebin.com/m7bc88052
[21:52] <foka> BenC, Looks like those numbers are listed here:  http://www.realtek.com.tw/Downloads/downloadsView.aspx?Langid=1&PNid=14&PFid=7&Level=5&Conn=4&DownTypeID=3&GetDown=false
[21:53] <foka> BenC, Or here: ftp://210.51.181.211/cn/nic/r8101-1.007.00.tar.bz2
[23:14] <noelferreira> my keys get stuck sometimes and other times don't work. can anyone help me with this huge bug: http://pastebin.com/m7bc88052
[23:16] <cradek> what's the launchpad bug report number?
[23:16] <noelferreira> i don't know cradek
[23:19] <cradek> filing one, if you can't find one when you search, would be the best way to get this worked on
[23:21] <cradek> in the bug report, I suggest also saying what basic debugging you have tried, like a new keyboard, usb vs ps2, etc etc.  you will get a lot more attention that way.
[23:22] <noelferreira> ok 
[23:22] <noelferreira> thanks
[23:24] <cradek> you have tried a different keyboard?
[23:26] <noelferreira> its my laptop cradek
[23:27] <cradek> ah, ouch
[23:28] <cradek> laptops are a nightmare for developers.  be sure to include all the information about it.
[23:28] <noelferreira> ok i will
[23:28] <noelferreira> thanks