[01:52] <DBO> BenC, just a follow up on what we talked about yesterday.  In a spurt of amazingly horrible luck... its not panicing...
[01:52] <BenC> lol
[01:52] <DBO> if I didnt have bad luck, I wouldnt have any
[01:53] <DBO> Im sure it will go eventually, when I first installed I went about 3 days before it started locking
[02:03] <BenC> Ok, just let me know when :)
[02:04] <crimsun> is this the snd-pcm-oss freeze, or...?
[02:05] <DBO> no
[02:05] <crimsun> ok.
[02:05] <DBO> its a more generic issue, im sorry I been running in circles
[02:08] <DBO> to be honest crimsun, I am getting very frustrated, but I want to thank you for the help you provided earlier.  We are using kexec tools (with bens help) to fiqure out the exact cause of the panic now.  Only thing is... its not doing it...
[02:08] <DBO> Sods law
[10:10] <flukebox_> hi
[10:10] <flukebox_> anybody here ??
[11:01] <dade`> BenC: i think that the gutsy kernel sould have CONFIG_TIMER_STATS enabled by default
[11:01] <dade`> to use linuxpowertop
[11:21] <elmarco> I have a T60, when I dock it, the serial interface (ttyS0) is not working anymore 
[11:21] <elmarco> should I file a bug in kernel.org, or launchpad?
[11:21] <elmarco> or is it a non-bug?
[11:21] <elmarco> (dock/undock)
[11:30] <maks_> mjg59 if you have an ipw2200 patch i can test it on my x41
[11:30] <maks_> preferably against 2.6.21, but otherwise fine too
[01:35] <Keybuk> http://linux-ata.org/shutdown.html
[01:35] <Keybuk> ^ so that explains *those* bgs
[01:36] <kylem> yeah.
[01:36] <kylem> grumble.
[01:36] <kylem> want me to fix upstart?
[01:36] <Keybuk> nah, it's ok, I'll tackle it -- I want to sort out the ide bits while in there
[02:15] <Keybuk> actually, this description is wrong, so I'm going to write to the author
[02:21] <Keybuk> kylem: could I borrow you for a moment
[02:21] <kylem> ys.
[02:22] <Keybuk> so, ide_device_shutdown()
[02:22] <Keybuk> this is called during the reboot() syscall, right?
[02:23] <kylem> looks like it.
[02:24] <Keybuk> kernel_power_off -> kernel_shutdown_prepare -> device_shutdown -> *.shutdown -> ide_device_shutdown
[02:24] <Keybuk> this would appear to just flush the cache on everything except power off
[02:24] <Keybuk> for power off, it calls suspend() on the bus? is that right?
[02:25] <kylem> hrm.
[02:26] <kylem> looks like it, yeah.
[02:27] <Keybuk> that would appear to be generic_ide_suspend()
[02:28] <Keybuk> which pushes the state machine into flushing the cache and powering down the drive
[02:42] <Keybuk> kylem: have mailed linux-ide, that page is particularly unclear to me
[02:42] <Keybuk> it seems to refer to workarounds that other distros (not us) have done
[02:42] <Keybuk> and penalises us for never having broken things in the first place
[02:43] <Keybuk> at least that explains the clicking noise bugs we've had for ages
[02:43] <Keybuk> (for the ide subsystem, not libata:
[02:43] <kylem> yup.
[02:43] <Keybuk>  - reboot standbys the drive
[02:43] <Keybuk>  - calls reboot()
[02:43] <Keybuk>  - which flushes the cache, spinning the drive back up
[02:43] <Keybuk>  - and standbys the drive again
[02:43] <Keybuk> )
[02:44] <Keybuk> it doesn't explain why we should have to touch libata, since we never tried anything with those
[02:44] <Keybuk> and since I'm going to have to write code for libata, allegedly, I'd rather get an answer *why* we have to, if there's code to be written, it's just as easy to write it in the kernel
[02:49] <BenC> Keybuk: but it would be specific to our kernel :/
[02:50] <BenC> since they obviously know they can't put the real fix in the kernel because other distros already fucked up, it means we'll be carrying around a patch just for us
[02:52] <Keybuk> actually, I mean for the case where halt/reboot still apparently has to issue the commands on a per-disk/driver basis
[02:52] <Keybuk> if it's "a few drivers haven't been fixed yet", then it's easier for us to fix those drivers than halt/reboot, no?
[02:53] <BenC> ah, true
[02:53] <Keybuk> my concern is that even after writing 0, I might need that code
[02:53] <Keybuk> and since I'll have to write that code, is there more useful code I could write instead?
[02:59] <ogra> BenC, i did some measurements for the ltsp slowness comparing tcp and udp based nfsroot ... and found very intresting numbers ... 
[03:00] <BenC> ogra: udp is faster?
[03:00] <ogra> would you agree that udp should be faster ? 
[03:00] <BenC> I would think so, but depends I guess
[03:00] <ogra> using the classmate as client:
[03:00] <ogra> udp 10.9M/s , real: 9.420s
[03:00] <ogra> tcp 11.6M/s , real: 8.887s
[03:00] <ogra> using the slow e2300 jim tested with as client:
[03:00] <ogra> udp 2.4M/s , real: 42.763s
[03:00] <ogra> tcp 3.6M/s , real: 28.656s
[03:00] <mjg59> This is on 100MBit?
[03:00] <BenC> wow
[03:01] <ogra> thats always dding a 100M file from the nfsroot to /dev/null
[03:01] <ogra> mjg59, yep, a gigabit card in my lappie which acts as server dmegs tells me it negotiates 100M FD
[03:02] <BenC> so it's a direct cable too, no switch/hub?
[03:02] <kylem> nfs sucks, news at 11.
[03:02] <mjg59> I think the classmate figures are close enough together for the difference not to be terribly meaningful
[03:02] <ogra> i would expect some significat difference between udp and tcp
[03:02] <mjg59> On a duplex connection?
[03:02] <ogra> yeah
[03:02] <mjg59> Why? The overhead isn't going to be that great
[03:03] <BenC> I think the more important numbers are the 2.4M/s on the e2300 compared to the 10.9M/s on the classmate :)
[03:03] <mjg59> The e2300 figures are much more interesting
[03:03] <ogra> hmm, but udp is even slower .... i would expect a connectionless thing to be always faster
[03:03] <mjg59> ogra: On the Classmate, the figures are close enough that they're probably effectively identical
[03:03] <ogra> well, the e2300 has a 200Mhz CPU
[03:03] <ogra> the classmate is a celeron 900
[03:03] <ogra> *celeron M
[03:04] <mjg59> The Classmate is clearly limited by the network
[03:04] <ogra> yeah
[03:04] <mjg59> The question is what the limiting factor on the e2300 is
[03:04] <mjg59> What does top look like during that?
[03:04] <ogra> where ? on the server 
[03:04] <ogra> i cant run top wile booting
[03:04] <ogra> *while
[03:04] <ogra> (on the client)
[03:04] <mjg59> You're dding a file
[03:04] <mjg59> To /dev/null
[03:05] <mjg59> If you can do that, you can run top :)
[03:05] <ogra> ah, that yeah
[03:05] <ogra> indeed, i'm into bootspeeds etm, sorry
[03:05] <ogra> *atm
[03:05] <ogra> let me reboot to get to a shell ... 
[03:05] <ogra> takes 3 min ...
[03:07] <ogra> oh, btw i'm using busybox mount for udp atm as opposed to klibc nfsmount for tcp ...
[03:07] <mjg59> Should make no difference
[03:08] <ogra> dd takes 90% CPU
[03:08] <ogra> 95 now
[03:08] <ogra> 3% for rpciod
[03:09] <ogra> intrestingly i also seem to get no caching ... running the dd command a second time should give faster results, no ?
[03:11] <mjg59> Not if the file is approximately all your memory, no...
[03:11] <ogra> well i have 128M
[03:11] <ogra> oh, wait
[03:11] <ogra> why does top only show 64 ?
[03:11] <ogra> hmm
[03:12] <mjg59> ...
[03:14] <ogra> ok, 64M videoram and 64M shared mem ...
[03:14] <ogra> switched that to 8M each
[03:15] <ogra> ok, that looks different ... 118M now
[03:18] <ogra> ok, caching seems to work ....
[03:18] <ogra> dropped from 24 sec to 12
[03:18] <ogra> on the second run
[03:20] <BenC> ogra: oooh...64Megs of mem, that'll do it
[03:20] <BenC> I accidentally booted to gnome desktop with 64Megs of mem while doing kdump stuff
[03:20] <BenC> was horrible
[03:21] <ogra> well, it didnt help much
[03:21] <ogra> still 24sec for that file 
[03:21] <ogra> and still 3min bootimes
[03:21] <ogra> 3min+
[03:22] <ogra> while ltsp 4.2 stays below a minute
[03:22] <mjg59> ogra: And top while dding it (for the first time, avoiding caching)?
[03:23] <BenC> 4.2 is the one that doesn't do nfsroot, but does nfsmount and symlinks, right?
[03:23] <ogra> dd eats all CPU it can
[03:23] <ogra> BenC, right, we tried that in our initramfs ... smae results
[03:23] <mjg59> Ok. So you're CPU limited, not network limited.
[03:23] <ogra> right
[03:23] <mjg59> Can you try an older kernel?
[03:24] <ogra> but there is still that significant difference between 4.2 and 5
[03:24] <ogra> yeah
[03:24] <mjg59> Try the 4.2 kernel
[03:24] <ogra> i tried the edgy one already (4.2 uses 2.6.18) 
[03:24] <mjg59> And?
[03:24] <ogra> no difference
[03:25] <mjg59> Then this would seem to be the wrong place to be bringing the issue up :)
[03:25] <ogra> no difference between our kernels i mean
[03:26] <mjg59> And with the LTSP kernel?
[03:26] <Mithrandir> have you tried ltsp 4.2 with the feisty kernel too?
[03:26] <ogra> not yet
[03:27] <ogra> i'll poke around with both today ... but clearly something is different with our nfsroot ...
[03:27] <ogra> debians kernel isnt much faster btw
[03:27] <Mithrandir> all this is pointing towards this being a userspace problem, then.
[03:28] <ogra> we tried their chroot as well
[03:28] <mjg59> Either there's a difference between the ltsp 4.2 kernel and our kernel
[03:28] <ogra> well, i thought i found the magic bullet when i saw the 4.2 is only faking nfsroot with tmpfses ... but that didnt change anything for us
[03:28] <mjg59> Or it's a userspace issue
[03:29] <ogra> hmm
[03:29] <mjg59> So, test performance with the 4.2 kernel
[03:29] <ogra> will do
[03:29] <mjg59> If it's three times better, then we have a kernel issue
[03:29] <mjg59> If not, it sounds like a userspace one
[03:31] <ogra> ok
[03:34] <zul> BenC: whats on the agenda?
[03:34] <BenC> basically just recap of UDS
[03:35] <zul> cool
[03:53] <ogra> oh, i just noticed ... CPU: Vendor unknown using generic init ....
[03:53] <ogra> but according to jammcq that shows up in 4.2 as well
[04:53] <maks_> BenC: do you disable CONFIG_IRQBALANCE ?
[04:53] <maks_> "The in-kernel irq balancer is obsolete and wakes the CPU up far more than needed."
[04:53] <maks_> says powertop
[04:54] <BenC> disabled in last kernel upload
[04:54] <maks_> thanks for info :)
[04:59] <BenC> sorry for time change, meeting is scheduled for 1 minute from now
[05:00] <zul_> ack..
[05:12] <Mithrandir> UTC is hard. :-P
[05:13] <racarr> I'm even more confused by the fact that it's supposed to be a kernel meeting but they seem to be confirming new members.
[05:14] <zul> well obviously its not a kernel meeting just yet
[05:14] <Mithrandir> it's because the previous meeting used too much time
[05:14] <Mithrandir> they're rounding up now
[05:18] <maks_> heya
[05:18] <BenC> everyone here that needs to be?
[05:19] <BenC> pkl_, rtg, kylem, cjwatson, zul: ping?
[05:19] <zul> yep
[05:19] <pkl_> BenC: here
[05:19] <rtg> BenC: hmm?
[05:20] <BenC> Ok, so basically this meeting was just to go over some things from UDS
[05:20] <BenC> I'm late getting a real agenda up, so please bare with me
[05:21] <BenC> Some of the topics we discussed at UDS (and kernel team, feel free to plug things I forgot):
[05:21] <BenC> * Wireless
[05:21] <BenC> * Power savings
[05:22] <BenC> * Ceashdumps
[05:22] <BenC> crashdumps I mean
[05:22] <BenC> * Ubuntu Mobile and Embedded
[05:23] <BenC> * Virtualization (lightly)
[05:23] <BenC> So we'll go from the top
[05:23] <BenC> rtg: do you want to give us a summary of wireless stuff?
[05:23] <rtg> I spent a day with Luis Rodriguez, Marcel Holtmann, and Anaky Perez Gonsales designing a frequency broker.
[05:23] <rtg> Also much activity regarding software designed radios and regulatory compliance.
[05:24] <BenC> that's the one announced to kernel-team@ that I've still to read :)
[05:24] <rtg> mac80211 development is proceeding briskly.
[05:24] <rtg> I', lookingat adding support for ntl80211 in wpa_supplicant.
[05:25] <rtg> I guess thats the big 3 items for me.
[05:25] <BenC> Sounds good
[05:26] <rtg> thats all...
[05:26] <BenC> I know Luis said that mac80211 in 2.6.22 isn't doing to be complete, but I was able to compile iwlwifi against it without problems (except an sk_buff change)
[05:26] <rtg> I haven't quite figured out how to actually use it. 
[05:27] <rtg> That was why I got distracted by wpa_supplicant 
[05:27] <BenC> Might be some docs on it somewhere
[05:27] <rtg> Its in the source :)
[05:27] <BenC> Ok, power savings, unfortunately Amit isn't with us yet
[05:27] <BenC> But we now have NO_HZ in the kernel, and TIMER_STATS, so we are able to use powertop to see what is waking up our CPU so much
[05:28] <BenC> mjg59 is already working on getting patches into userspace programs which heavily show up in powertop output
[05:29] <BenC> we have some drivers on the hitlist too, so we'll be addressing that during gutsy cycle
[05:29] <maks_> bluetooth is really bad afais
[05:29] <BenC> yeah, it's the worst offender on my laptop
[05:29] <pkl_> there was some discussion of various patches to glibc and other user-land libraries to aggregate timer ticks.
[05:29] <BenC> and ipw3945 follows behind it
[05:29] <BenC> pkl_: gnome is the main one, from what I can tell
[05:30] <BenC> not sure if it makes sense to patch up sleep in glibc to aggregate things
[05:30] <BenC> there's a spec for all this, so we can add the main issues in there
[05:30] <pkl_> there seems to be couple of patches floating around doing the samething, but diferently.
[05:31] <rtg> Intel has some kernel patches that also consolidate wakeups.
[05:31] <BenC> yeah, we'll be checking into those as well
[05:31] <rtg> http://www.linuxpowertop.org/powertop.php
[05:32] <BenC> gutsy should be a nice release for laptops, and we'll probably add powertop to our normal testing to keep from having regressions on stock desktops
[05:32] <rtg> I believe you referred to gutsy as 'a laptop users wet dream' :)
[05:32] <BenC> yes, that's a direct quote :)
[05:33] <BenC> Ok, crashdumps...
[05:34] <BenC> I've uploaded a kexec-tools that includes an init script and an initramfs script to actually grab vmcore on dumps
[05:34] <maks_> i'd be interested in merging that
[05:34] <BenC> I plan on making a simple linux-crashdump-{generic,server,...} meta package to install all the right things (kexec-tools, linux-debug-image, etc) and automatically setup grub menu to do all this
[05:35] <BenC> maks_: remind me and I'll send you the scripts
[05:35] <BenC> So the only stopper right now is that the crash program cannot process 2.6.22 vmcore's
[05:35] <maks_> ok will do, thanks
[05:36] <BenC> but I expect that will come as 2.6.22 gets closer to release
[05:36] <BenC> I want it sooner, so we can actually make use of it though
[05:36] <BenC> probably work on patching crash soon
[05:36] <BenC> Martin(pitti) is working on apport integration so we get nice automated bugs from vmcore dumps
[05:37] <BenC> and with crash we can analyze bugs that before we couldn't even see (panic's during X that locked up the system)
[05:38] <BenC> Ubuntu MaE, not a lot of discussion for this in regards to the kernel
[05:38] <BenC> we're going to have a special kernel just for this project, and will be mostly integrating patches for drivers and optimizations
[05:38] <BenC> * Virtualization, seems to be no better than it was in feisty
[05:39] <BenC> zul: any word on xen+2.6.22?
[05:39] <BenC> I'd be happy with just domU support, especially since we have a bug that says even the one kernel where xen existed, didn't support being booted as dom0 anyway :)
[05:39] <zul> BenC: updating it to xen-3.1 is going slowly, dumped suse's patch in favour of redhat's again
[05:40] <zul> as usual its going slowly again,
[05:40] <zul> oh and someone else will probbaly need to take care of openvz or I will suffer a nervous breakdown
[05:40] <BenC> I know your quite busy nowadays, perhaps checking the lists for help would be a good idea?
[05:41] <zul> yep already talking to the redhat folks
[05:41] <BenC> openvz we'll be leaving to openvz, so don't worry about that
[05:41] <zul> sweet
[05:41] <BenC> zul: there has to be some ubuntu users that are interested in xen...maybe try the ubuntu devel or kernel-team lists?
[05:41] <zul> sure Ill do that when I get home
[05:42] <BenC> I know we have vendors interested in xen on our lists, so maybe they can pitch in
[05:42] <BenC> I could give you a list of ones, but I think it's best they speak for themselves :)
[05:43] <zul> heh...actually im talking to quintela right now
[05:43] <BenC> that's the end of my list...any additional topics anyone wanted to bring up
[05:43] <BenC> ?
[05:43] <zul> he is the redhat xen kernel maintainer
[05:44] <BenC> cool
[05:44] <zdzichuBG> when feisty kernel update is planned?
[05:44] <BenC> good question
[05:44] <BenC> pkl_: how's feisty looking for an upload?
[05:44] <BenC> pkl_: could you send the current output of "debian/rules printchanges" to kernel-team for review?
[05:45] <pkl_> good, I just need to get someone to test the latest patch tifm driver
[05:45] <Keybuk> kylem: we win
[05:45] <pkl_> yeah, there's mostly security and sparc changes.
[05:45] <BenC> could probably do a i386 -generic build for the folks on the tifm bug report
[05:45] <zdzichuBG> pkl_: thinkpad sound after suspend bug?
[05:46] <BenC> pkl_: did the kvm changes in latest git get reverted to match the released kernel?
[05:46] <BenC> zdzichuBG: is there a patch?
[05:46] <pkl_> BenC: yes
[05:46] <zdzichuBG> BenC: yes, and testes kernels: https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/80893
[05:46] <BenC> pkl_: ok, do you know if current feisty git has an ABI change or not?
[05:47] <Keybuk> http://article.gmane.org/gmane.linux.ide/18846
[05:47] <pkl_> yes, ABI bumped
[05:47] <BenC> zdzichuBG: since you're interested, can you post the patch to kernel-team@, and CC Phillip Lougher <phillip.lougher@ubuntu.com>?
[05:47] <pkl_> one of the security patches, can't remember which one off-hand
[05:48] <BenC> pkl_: Ok...let's get the tifm thing tested asap, get an upload ready, and we'll do some builds for a first round of testing with distro folks
[05:48] <pkl_> OK.
[05:48] <zdzichuBG> BenC: will do
[05:49] <BenC> zdzichuBG: it wont make this upload, but we'll see about queuing it up for next one, or -updates
[05:49] <pkl_> I was looking into a Unionfs bug, but is not urgent.
[05:50] <BenC> Any other issues to speak of?
[05:50] <pkl_> this indirectly affects whether we go for Unionfs 2.x or Unionfs 1.x in Gutsy.
[05:50] <pkl_> nope.
[05:51] <BenC> Ok, thanks everyone
[05:54] <Keybuk> oops, sorry for interrupting the meting there
[05:54] <BenC> Keybuk: np, we had to move from #ubuntu-meeting because CC meeting ran long
[05:54] <maks_> BenC i've some initramfs-tools fixes that might be interesting to sync
[05:55] <maks_> i'll ping you once 0.88 is fine in sid
[05:55] <BenC> maks_: ok
[05:56] <BenC> pkl_: if you could look at the unionfs I have in linux-ubuntu-modules-2.6.22, and let me know if it's suitable for at least our livecd, I'd appreciate it
[05:57] <BenC> it's 1.x
[05:57] <Keybuk> BenC: so, the good news is, remember we talked about the whole ide spin down thing?
[05:57] <Keybuk> well, the ide subsystem is right by default - we can drop the scary ioctl shit from /sbin/reboot
[05:57] <BenC> Keybuk: yeah, I read the backlog with kyle
[05:57] <Keybuk> and the libata subsystem is in the process of being fixed; and it turns out we're getting it fixed better than the patch in 22-rc1
[05:57] <BenC> so 2.6.22 will be good?
[05:58] <Keybuk> currently there's an odd compat_shutdown patch in there, which requires us to update shutdown, blah blah blah
[05:58] <Keybuk> all this to not break one or two distros that tried to shutdown libata stuff in /sbin/halt/reboot
[05:58] <Keybuk> so the author is reworking the patch to favour distros like us by default that never broke things in the first place
[05:58] <Keybuk> yup, looks like 22 will be sweet
[05:58] <Keybuk> our /sbin/reboot can be a wrapper around reboot() :p
[05:59] <BenC> nice, I can mark the "my hd makes a horrid noise on shutdown" fixed in gutsy
[05:59] <Keybuk> it makes a nice "drive head thunking against the side of the can" noise? :p
[06:00] <BenC> yeah, some reporters even claim it flicks their laptops off the table ;)
[06:06] <Keybuk> I suspect they may be exaggerating a little
[06:12] <Keybuk> for my next mission, I will attempt to find out whether sync() is needed or not <g>
[06:20] <heno> random question: How many modules do we ship and how many of those are not in Linus' tree?
[06:20] <mjg59> Many, lots
[06:20] <heno> 10, 50, 100?
[06:20] <BenC> heno: for x86, stock kernel is about 1900 modules
[06:20] <mjg59> heno: find /lib/modules/`uname -r`/kernel | wc
[06:20] <mjg59> will give you the total number
[06:20] <mjg59> find /lib/modules/`uname-r`/kernel/ubuntu | wc
[06:20] <heno> ok, thanks
[06:20] <BenC> heno: we provide about 20
[06:21] <mjg59> will give you the ubuntu specific count
[06:21] <BenC> -type f might be a good idea there
[06:21] <BenC> lots of directories :)
[06:21] <mjg59> Oh, yeah
[06:21] <smurf> or even "-name \*.ko"
[06:21] <mjg59> BenC: I still make it 80 or so that we provide
[06:21] <heno> (I'm having a discussion about the removal of speakup on a list)
[06:21] <mjg59> Though several of those are conceptually linked
[06:22] <mjg59> Oh, not as many in gutsy
[06:22] <BenC> speakup is a good chunk there
[06:22] <mjg59> (so far)
[06:22] <heno> any idea how many of those are  from far outside the most common trees?
[06:23] <heno> (Linus and 2-3 others)
[06:24] <BenC> heno: a good chunk for modules we provided in feisty wont show up in gutsy because they are either obsolete, or crap
[06:24] <BenC> a lot of the wireless modules we provided in feisty we're to gain mac80211 features
[06:25] <heno> right, so it's a common life cycle for good features to actually go into mainline eventually
[06:25] <BenC> oh, definitely
[06:25] <BenC> there's a lot of overhead in maintaining those out-of-tree
[06:25] <heno> Are they often pushed in by us, or more often by other kernel folks?
[06:26] <mjg59> Other people, usually
[06:26] <mjg59> And there's some stuff we ship that's never going mainline in its current form
[06:26] <BenC> very rarely by us, where us is Ubuntu
[06:26] <mjg59> Like that gspca or whatever webcam monstrosity
[06:26] <BenC> right, and ndiswrapper
[06:26] <heno> right, I see the pattern, thanks
[06:29] <isidoro> hi
[06:30] <isidoro> sorry guys... help I can't mount my usb NTFS disk. I installed ntfs-config but a gnome pop up says mount_point cannot contain the following characters, newline G_DIR_SEPARATOR (usually /)
[06:31] <BenC> isidoro: sounds like your NTFS partitions has '/' in it's label name
[06:31] <BenC> relabel it
[06:39] <Keybuk> I can't see any explicit call for that in the kernel code yet
[06:40] <isidor1> BenC: can I force in some way the mount via shell??
[06:40] <BenC> isidor1: sure, use the mount command :)
[06:41] <isidor1> BenC: can you post it form me?
[06:41] <BenC> mount /dev/XXX /mnt
[06:41] <BenC> XXX all depends on what device it is
[06:42] <isidor1> sudo mount /dev/sdb1 /home/usbdisk
[06:42] <isidor1> says it not exsist
[06:44] <isidor1> impossibile trovare /dev/sdc in /etc/fstab o /etc/mtab
[06:45] <isidor1> impossibile find
[06:45] <isidor1> dmesg says sd 3:0:0:0: Attached scsi generic sg4 type 0
[06:46] <Keybuk> ...bad things; important lesson learned
[06:46] <isidor1> ?
[06:46] <isidor1> :-(
[06:47] <isidor1> what can I do???
[06:47] <mjg59> isidor1: #ubuntu is a much better place to ask this
[06:47] <mjg59> This isn't a support channel
[07:04] <isidoro> guys fixed!
[07:05] <isidoro> google is really a great friend
[08:44] <zul> BenC: I got a vanilla 2.6.21 booting with xen-3.1 ill start merging in 2.6.22-rc1 tonight
[08:45] <BenC> ok
[08:47] <BenC> I mean linux-meta
[09:32] <Spec> What's the ETA for fixing a bug like this: BUG #90902
[09:33] <Spec> oh, ubugtu isn't here, well, that bug is just a wrong version of firmware bug and it's basically fixed, is there anything i can do to speed along the fix?
[11:07] <defendguin> BenC, you got a moment?
[11:07] <BenC> defendguin: sure
[11:08] <defendguin> could you look at this bug someone submitted https://bugs.launchpad.net/ubuntu/+source/linux-source-2.6.20/+bug/114312
[11:09] <defendguin> I have this laptop and obviously i'm concerned but i have been using feisty since herd 3 and i have not noticed any fan or overheating issues
[11:11] <BenC> the bug report needs dmesg, and output from cat /proc/acpi/thermal_zone/*/temperature
[11:11] <BenC> until then it's just hand waving
[11:11] <defendguin> right
[11:12] <defendguin> would you like me to note that in the ticket?
[11:12] <BenC> yes, please
[11:15] <defendguin> Thanks Ben
[11:16] <BenC> np
[11:16] <defendguin> this guy also reported his thinkpad was over heating
[11:16] <defendguin> maybe he just needs to turn on the AC
[11:19] <BenC> or find a better place than his stove to work from
[11:20] <defendguin> oh nevermind i guess he just posted to the end of a different ticket the same issue