=== dashua`__ is now known as dashua [01:26] to whoever fixed the usb quirk for the "microsoft sound system 80" thanks, it works perfectly now === asac_ is now known as asac === TheMuso_ is now known as TheMuso === asac_ is now known as asac === alex_jon1 is now known as alex_joni [08:03] hello all [08:03] Can I ask a quick question please, might take a long answer [08:04] How can I take .inf file and create a driver for ubuntu 8.04 [08:05] or would it work, I have tried ndisgtk and ndiswrapper [08:24] Johninky: You can't [08:24] I can what [08:24] cant^^ [08:25] oh never mind I was a little slow on that one [08:25] sorry [09:02] moin [16:43] i moved from 7.10 to 8.04 in my laptop and now i have no wifi and no ethernet [16:44] can i downgrade to ipw3945 ? [16:44] ipl is giving me lots of errors and isn't working [16:46] is there a ipw3945 .deb i can d/l for 8.04 ? [16:53] is there an IPW3945 PACKAGE for UBUNTU 8.04 ?? [16:57] DB42: install linux-backports-modules in order to get iwlwifi 1.2.25 [17:00] ok i've submitted bug report with my problem: https://bugs.launchpad.net/ubuntu/+bug/219268 [17:00] Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New] [17:01] rtg: hmm [17:02] DB42: support in 1.2.25 for the 3945 is a little better. [17:02] rtg: which one is for the -generic ? [17:02] rtg: is there a way to revert to ipw / [17:03] for the time being ? [17:03] (without moving to 2.6.22) [17:03] DB42: ipw is gone. [17:03] no .deb package ? :| [17:03] i tried compiling it, no go [17:03] rtg: which backports do i need to install for 2.6.24-16-generic ? [17:04] DB42: try 'sudo apt-get install linux-backports-modules-hardy' [17:05] installing now [17:05] rebooting laptop, let's hope for the best [17:06] i need to do anything after instaling and before rebooting ? [17:06] DB42: nope [17:08] btw this is a backport from what ? 8.10 ? [17:08] :( same error [17:08] problem still there [17:09] it's 1.2.25 [17:10] rtg: any other idea ? [17:10] DB42: looking... [17:12] btw, using wicd as network manager if it's of any use [17:14] DB42: what kind of AP connection are you trying to make? WPA Enterprise? Add that to the LP report as well as any noise from /var/log/syslog. Attach it to the LP report, not pastebin. I'll make sure Intel sees the bug report. [17:14] WPA yes [17:15] hmm.. i'll try an unsecure one, and see if it works [17:15] DB42: personal or enterprise? [17:15] personal [17:18] BenC: is it possible to do sysrq-like actions programmatically, e.g. through sysfs or proc? [17:18] rtg: another problem [17:18] my ethernet card isn't working in 2.6.24-16-generic as well ... [17:18] there's /proc/sysrq-trigger... [17:18] hwlist -C networ tells me it's disabled [17:19] mdz: probably, but if the hang is "system", then I'm not sure that would help [17:19] BenC: yeah [17:20] DB42: the rt8139 is well supported. Is this an HP laptop? [17:20] is it possible to serially debug our kernel without modifications? [17:20] I'm getting a base install so I can run the erase command from command line [17:20] rtg: check the bug report, lenovo 3000 n100 [17:20] it's an 8139too driver [17:21] i connect a ethernet cable and i don't get in dmesg "link up or down" but the module for 8139too is loaded [17:21] DB42: i see it now. Is the cable plugged in (since you've been using wireless) ? [17:21] yeah [17:22] DB42: never mind [17:22] it's plugged in, but doesn't apear in ifconfig [17:22] and nothing in dmesg [17:22] cjwatson, soren: does blockdev-wipe run on the physical drive, or on the encrypted lvm? [17:22] BenC: the former [17:23] DB42: 'ifconfig -a' ? [17:23] So the fact that this happens for encrypted is just that blockdev-wipe gets run when it normally doesn't [17:23] BenC: well, it runs on the device underlying the encrypted one, AIUI [17:23] rtG: i see eth0 and eth1 [17:23] not the physical drive but an unencrypted block device [17:23] mdz: so the wipe isn't being encrypted, right? [17:23] DB42: eth0 is likely the realtek controller. [17:23] yeap [17:23] ok [17:23] check my dmesg on the bug report [17:24] BenC: I think not, but I don't have it in front of me [17:24] it has the RealTek anme there [17:24] alt+f2 during the erase and ps [17:24] DB42: what happens if you 'sudo ifconfig eth0 up' [17:24] rtg: i need to go to a place with ethernet connection and check :) [17:24] sec [17:25] BenC: lib/crypto-base.sh:crypto_wipe_device in partman-crypto [17:26] BenC: seems to say it is in fact writing through dm-crypt when it does the wipe [17:26] rtg: thanks, eth works now [17:27] DB42: so, pluggin it in to a switch fixed it? [17:27] no [17:27] ifconfig eth0 up did [17:27] DB42: hmm. Are you running NetworkManager? [17:27] no, as i said i'm using wicd [17:27] DB42: wicd only works on wireless, right? [17:27] NM didn't work well with my wireless card in 7.10 [17:28] nop, wired as well [17:28] DB42: you ought to try NM again. maybe it'll work better with the i3945. [17:29] rtg: i'm trying to conect unencrtyped now and see if it's ok [17:29] how so ? the problem is in the microcode.. [17:29] and when i boot to 2.4.22 for wifi now (on 8.04) i still need the wicd [17:29] and i can't have them both [17:29] DB42: indeed, but it could be a function of the kind of packets being transmitted. who knows. [17:29] mdz: so does d-i call blockdev-wipe for this progress? [17:30] BenC: yes [17:30] DB42: you could boot with the lice-cd and try it. that way you don't have to re-install. [17:30] s/lice-cd/live-cd/ [17:30] rtg: i rather d/l it when the final is out :| [17:31] /bin/blockdev-wipe -s 65536 $dev > $fifo & [17:31] also don't have media to burn it on [17:31] [...] while read x <&9; do [17:31] db_progress STEP 1 [17:31] DB42: the RC was announced an hour ago. [17:32] btw, i reported a bug in my sound card and did a system update 2 days after, and the bug disappered :) [17:32] that was pretty cool [17:32] DB42: probably a function of updated ALSA in LUM. [17:33] mdz: I can't get blockdev-wipe to reproduce from command line [17:33] the model i had needed to be added to usbquirks.h or so [17:33] (it worked ok in 7.10, but not in 8.04) [17:34] BenC: soren was trying that as well [17:35] The fact that blockdev-wipe output is useless after 24 lines doesn't help either [17:35] wonder if I can easily wrap it in some shell script to put the asterisks on a single line instead of separate [17:36] I see that the release candidate includes the 2.6.24-16.30 of Ubuntu but will the final version include Kernel 2.6.25 since it came out yesterday [17:36] BenC: | grep -n --line-buffered '' [17:36] CYREX: how so ? [17:36] CYREX: no [17:36] CYREX: 8.04 is freezed already [17:37] is frozen mean no kernel changing [17:37] mean no change at all besides bug fixes [17:37] mean no change at all besides bug fixes [17:37] oki thank you [17:38] mdz: not particularly supported by busybox grep [17:38] :) [17:38] oh, you're in d-i [17:38] figure that's the best way to repro it [17:38] BenC: |while read x; do date; done ? [17:39] or similar [17:40] rtg: i'm trying a manual connection, how do i list SSIDs ? [17:43] DB42: sudo iwlist wlan0 scanning [17:44] i get "Failed to read scan data: Resource temporarily unavilable" [17:45] DB42: probably because the firmware has crashed. [17:46] tried removing / reloading the iwl, didn't help .. [17:47] i'll try restarting with no wifi, seing if it helps [17:47] how do i blacklist auto-loading of iwl3945 @ boot ? [17:47] (in kernel boot lie) [17:51] mdz: | while read x; do echo -n "$x"; done [17:51] DB42: add it to /etc/modprobe.d/blacklist [17:51] that worked [17:52] rtg: yeah i wanted it in boot though (since i already reboot) [17:52] but nm, i did a check [17:52] it happens as soon as i type in CLI "iwlist eth1 scan" without even using a network manager [17:52] i updated my bug report to reflect it [17:53] https://bugs.launchpad.net/ubuntu/+bug/219268 [17:53] Launchpad bug 219268 in ubuntu "iwl3945 doesn't work with my wifi card (ipw3945 did)" [Undecided,New] [17:54] welp for now i guess i'll go back to 2.4.24 [17:54] i mean 2.6.22 ... :) [17:54] rtg: no .deb package no backport no nothing for ipw ? :| [17:55] DB42: nope. the regulatory daemon is gone. [17:57] what is "LBM" and "LUM" ? [17:57] linux-backports-modules, linux-ubuntu-modules [17:58] k [17:58] now for the big test, checking if hibernation is fixed in 8.04 for my laptop :) [18:06] yippy [18:06] cool, the cpu fan seems to work after hibernation [18:06] it didn't in 7.10 [18:08] so rtg need anything else for my report ? [18:08] will the intel people respond on the bug report itself ? [18:09] DB42: they might, but I think they are losing interest in 3945 in favor or more recent adapters (4965) [18:10] ouch :( [18:11] well if this isn't a specific case of mine, there are still lots of people with 3945 out there (the lenovo 3000 n100 is popular i belive) [18:11] i also think it might be tramuatic for some users that load ubuntu and won't have wifi [18:11] DB42: it doesn't fail for everyone, but I have seen the microcode issue before. [18:12] is there any documentation of the chipset that can tell me what is that specific error ? [18:12] DB42: not that I'm aware of [18:13] mdz: I'm starting to wonder if this is a blockdev-wipe issue...from one run to the next, it goes at different speeds [18:13] like now I'm at 47%, and it would have been done by now on the run before this [18:14] BenC: what are you using for the source? urandom? [18:16] BenC: there's some debugging available if you recompile it, but it's pretty dead simple [18:17] mdz: the stock d-i one, so it's /dev/zero [18:17] mdz: does d-i use default /dev/zero, or does it -f=/dev/urandom? [18:17] BenC: urandom, I believe [18:17] where is the d-i log kept nowadays? [18:18] BenC: oh, nm [18:18] it's using /dev/zero, but writing through a random cryptoloop [18:18] ok [18:18] so blockdev-wipe writes zeros, but what gets written to the device should be random [18:18] ok [18:18] maybe the intervening cryptoloop is what's getting hung up [18:19] are you setting that up in your test environment? [18:19] well, what gets written isn't really random, just encrypted 0's [18:20] * BenC chuckles at encrypted 0's [18:21] BenC: maybe it would go faster with unencrypted zeroes :) [18:22] -f=/dev/unencrypted-zeroes [18:22] ENODEV [18:27] mdz: I'm using the devices setup by d-i [18:27] switching to console [18:28] ...after partman runs [18:30] BenC: well, it's encrypting with a random key from /dev/urandom, so it should be pretty random [18:30] I wonder why it does it this way rather than just writing random data to the device [18:30] Ok, I just got a completely different hang [18:30] straight from /dev/urandom to whatever without going through device-mapper [18:30] during dhcp...keyboard started it up again... [18:31] wonder if that's a red herring, or for real hang like we are seeing otherwise [18:32] whoope, nope, same hang repeated [18:32] mdz: Ok, this isn't blockdev-wipe related then [18:33] I got network dhcp screen to hang twice in a row [18:33] stayed at 100% until I hit shift key [18:33] * BenC starts to blame kvm [18:34] and note that even though nothing in d-i uses the mouse, the kernel and kvm both pay attention to it, so that would explain the kickstart from it as well [18:34] BenC: others (including jdstrand) have reported hangs in other parts of the installer [18:34] 3 times dhcp hung... [18:34] even before partitioning [18:35] shift key reliably starts it back up [18:35] there is, as far as I know, only one unconfirmed report of this happening outside of KVM [18:35] right, so I'm thinking these are two separate bugs [18:36] One in kvm (dunno if it's userspace or kernel), and one on that specific bit of hardware [18:36] I'm going to try this -server install on some hardware to try and reproduce [18:37] BenC: dendrobates said that mathiaz experienced some mysterious unreproducible hangs on real hardware when doing server enablement, but I have no information [18:37] Bringing dendrobates here, hopefully hash this out a bit more [18:37] * BenC summons the frog [18:38] I pasted him a log excerpt [18:41] BenC: here [18:41] dendrobates-: I can always tell when you're here because my xchat-gnome window resizes to accomodate your nick === dendrobates- is now known as dendrobates [18:45] kirkland: are you able to reproduce this easily? [18:45] mdz: I have not reproduced this at all [18:45] mdz: I've only tried on real hardware [18:45] ah, I see [18:45] dendrobates: I reproduced the hang...but, I was able to reproduce it during dhcp as well as during crypt erase [18:46] mdz: and with a 300G drive, the device zero'ing takes FOREVER [18:46] Ben and I are starting to think that the primary bug here is kvm-specific [18:46] and there may be a separate issue or two which are hardware-specific [18:46] kirkland: you can manually adjust the size of the device to mitigate that; I did it yesterday [18:46] dendrobates: so this isn't specific to blockdev-wipe usage...which leads to believe even more than what we are seeing in kvm is not likely the same bug as what was reported on real hw [18:47] BenC: have you given any thought to the empty entropy suggestion one commenter gave? [18:47] even in kvm it is not limited to blockdev-wipe. [18:47] kirkland: blockdev-wipe uses /dev/zero, and a key, so there's no entropy involved [18:48] kirkland: plus, it's not just during that operation [18:48] BenC: right, my question is probably more d-i specific... anywhere else in the installer that might rely on /dev/random? [18:48] kirkland: not on a recurring basis [18:48] both jdstrand and I are seeing it appear at various places during the install, but it always occurs during blockdev-wipe. [18:48] particularly something that might have been introduced in hardy, since this is looking like a regression since gutsy [18:49] I think the encryption aspect is a red herring [18:49] mdz: I do as well. [18:49] the installer just spends a lot of time (and makes a lot of system calls) there [18:50] All I know for sure is that it is easy to reproduce with lvm+crypt. [18:53] I'm going to try and reproduce under kvm on gutsy [18:53] that should give us a reliable answer [18:54] we have already tried to reproduce it installing Gutsy on a Hardy kvm, with no success. That seems to point to someting in Hardy. [18:55] dendrobates: Ok, I'll try the other way (install hardy on gutsy) [18:55] dendrobates: but yeah, that's an interesting point too [18:56] I am going to try a pre-beta hardy image. [18:57] I have a daily build from dec-5 [18:58] All I have are 32-bit 7.10 CD's [18:58] Where are the gutsy live cd's? [18:59] BenC: http://releases.ubuntu.com/7.10/ [18:59] BenC: can't you reproduce it in 32bit? [18:59] thanks [18:59] dendrobates: I'm sticking with what soren told me...haven't tried 32-bit yet :) [19:00] well, I did on my laptop, but it wouldn't repro there [19:00] BenC: OK, it does not seem to matter though. [19:04] That's an interesting regression [19:04] hardy nv driver only does 800x600 on my plasma screen, while gutsy starts up at 1280x1024 [19:07] Ok, I happen to have 32-bit handy, so I'll try that [19:12] I was not able to reproduce it with an older hardy iso, but, the hardy daily from Dec does not do the erase on lvm+crypt, which is the most reliable way I have found to reproduce it. [19:13] mdz: do we have an archive of the daily builds somewhere? [19:14] or the alpha releases? [19:15] dendrobates: slangasek would know [19:15] I'm sure we do, but I don't know where [19:15] (of milestones at least) === mdomsch is now known as fedora_linux_mdo === fedora_linux_mdo is now known as fdr_lnx_mdomsch === rikai_ is now known as rikai [19:54] hmm === fdr_lnx_mdomsch is now known as fedora_mdomsch [19:54] This might not be possible to test [19:55] Gutsy kvm doesn't support the gfx boot it seems [19:56] BenC: there is a sed line to "fix" the gfxboot issue [19:56] (if that's useful) [19:56] Sure [19:57] B$ sed -e 's/GFXBOOT bootlogo/#FXBOOT bootlogo/g' < ubuntu-7.10-server-amd64.iso > ubuntu-7.10-server-amd64-nogfxboot.iso [19:57] dendrobates: thanks [19:57] a little brutish, but it works. [19:57] can I hexedit it instead? :) [19:58] it's documented on https://wiki.ubuntu.com/KvmVirtManagerEtc#head-80f0e334a1de270252f62ac69183da2ed58edf3f [19:58] (the sed line) [19:58] BTW: does anybody know when vmware server & which version will be available for hardy? (question from someone I know who uses it professionally) [20:02] yep, hexedit is much faster, it solved it, thanks [20:07] what processor is ubuntus kernel optimized for? [20:08] arcticpenguin380: depends on which kernel you mean ;) [20:08] hardys. [20:09] hardy has several kernels included [20:09] but -generic kernel is optimized for 686 IIRC [20:09] are all hardys kernels 2.6.24? [20:09] yes [20:11] oh and is ext4dev compiled? [20:14] I don't think so [20:15] well, /proc/filesystems doesn't list it [20:43] soren: is there supposed to be a way to make kvm emulate 64-bit when running under a 32-bit kernel? [20:44] otherwise, I gotta download a 32-bit -server CD :/ [21:13] BenC: No can do. [21:35] Ok, I'm off, and will return in a few hours to continue tracking this down (and over the weekend) [21:47] rtg: here ? [21:48] rtg: http://ubuntuforums.org/showthread.php?p=4612681 fixes the problem === doko_ is now known as doko === fedora_mdomsch is now known as mdomsch [22:26] is anybody actively working on Bug #88746? if so, i'm willing to provide needed info [22:26] Launchpad bug 88746 in linux-source-2.6.22 "ehci_hcd module causes I/O errors in USB 2.0 devices" [Undecided,Invalid] https://launchpad.net/bugs/88746 [22:27] having usb2 broken in feisty, gutsy, _and_ hardy is a bit much [22:31] for perspective, i've had the very same issue on a different machine with a different chipset, a different usb device, and a different distro [22:31] the common element appears to be multifunction usb devices [22:32] do any of the workarounds ... work for you? [22:33] modprobe -r ehci-hcd [22:33] so in the absence of a fix that works for everyone, you at least have a viable workaround [22:34] the rest are a bit hard to keep track of [22:34] and that workaround is NOT viable, just like the bug comments say [22:35] after all, apparently that workaround _does_ work for _everybody_ [22:36] that's precisely what I mean. [22:36] /you/ have a viable workaround. [22:36] huh? [22:36] I asked if any of the workarounds work for /you/, and you responded with "modprobe -r ehci-hcd" [22:37] (obviously it's not preferable) [22:37] but you said "in the absence of a fix that works for everyone" -- either there's no such absence or there's no such fix [22:39] there's a reason ehci-hcd isn't just blacklisted by default [22:39] as we're both well aware, and I have no interest in arguing [22:40] so far, i have not encountered any machine with an amd cpu where ehci-hcd works with a multifunction usb device [22:40] strangely, it seems ok on p4's [22:45] what i'm interested in is contributing to whatever efforts to fix this issue once and for all [22:45] crimsun: any fix on the horizon for snd_hda_intel suspend/hibernate issue (needs to be removed after resume, otherwise no sound)? [22:47] tjaalton: I don't head up sound anymore (and haven't for a year). What's the issue? [22:47] tjaalton: meaning, I need to know what HDA codec/model is affected [22:47] crimsun: oh sorry.. let's see.. [22:48] crimsun: 8086:293e I guess [22:48] need the line afterward. [22:48] (`lspci -nv|grep -A1 0403') [22:49] Subsystem: 1043:829f [22:50] I can guess that's a Realtek, but can you confirm by looking in /proc/asound/card0/codec#0? [22:51] yeah.. Realtek ALC883 [22:51] shame on intel.. [22:52] tjaalton: ok, please pastebin that codec spew. [22:53] crimsun: http://pastebin.ubuntu.com/7440/ [22:53] thanks, looking [22:53] does it need some hal/suspend quirk? [22:54] hmm, i just tried a suspend, and no more sound... [22:54] ALC885 [22:58] interesting, there's no unmute for autoconfig [22:58] tjaalton: I presume you're not passing a model= in /etc/modprobe.d/* ? [22:59] crimsun: nope [22:59] i know i'm not -- it gets config from the bios [23:04] tjaalton: ok, I'll ping you. Looking closer. [23:05] crimsun: excellent, thanks