[09:00] <AceLan> ShapeShifter499: The steps to compile ubuntu kernel is 1. fakeroot debian/rules clean 2. fakeroot debian/rules binary-generic
[09:00] <ShapeShifter499> my patch tells me to do something else
[09:01] <AceLan> ShapeShifter499: never use "make" command
[09:01] <ShapeShifter499> why?
[09:01] <AceLan> ShapeShifter499: it will delete debian/ directory or pollute the kernel directory
[09:02] <amitk> ShapeShifter499: the ubuntu build system conflicts with the in-kernel build system
[09:02] <ShapeShifter499> ok so I apply the patch with the patch command then do the commands you posted?
[09:02] <AceLan> ShapeShifter499: right
[09:03] <ShapeShifter499> is that the same with the Linux Unified Kernel patch?
[09:03] <AceLan> ShapeShifter499: the same
[09:03] <ShapeShifter499> ok
[09:04] <ShapeShifter499> thanks for the help
[09:04] <AceLan> np :)
[09:05] <ShapeShifter499> I'll stay here in case of errors
[09:06] <ShapeShifter499> oh is there a faster way of downloading the ubuntu kernel?
[09:07] <AceLan> ShapeShifter499: are you using git and already downloaded a upstream kernel by git?
[09:07] <ShapeShifter499> no
[09:07] <ShapeShifter499> I'm new to this
[09:08] <AceLan> so, there is no faster way to download the kernel source :p
[09:08] <ShapeShifter499> whats the upstream kernel?
[09:09] <AceLan> the linux kernel maintains by community
[09:09] <ShapeShifter499> oh...
[09:15] <MTecknology> ShapeShifter499: I'd download it with git - it takes longer the first time but it's much faster in the future
[09:15] <ShapeShifter499> I know
[09:15] <ShapeShifter499> you just use the git fetch command right?
[09:15] <MTecknology> ok - jsut thought i'd mention it
[09:16] <ShapeShifter499> what happens if they update to a new kernel for my system? do I have to re download the files?
[09:17] <AceLan> ShapeShifter499: using git: git pull --rebase
[09:17] <ShapeShifter499> just to be sure that would...
[09:20] <ShapeShifter499> ...
[09:20] <ShapeShifter499> do what?
[09:21] <ShapeShifter499> anyone here?
[09:44] <kengyu> ShapeShifter499, update your kernel code base.
[11:32] <akheron> what to do with https://bugs.launchpad.net/ubuntu/+source/linux/+bug/481765 ?
[11:33] <ubot3> Malone bug 481765 in linux "ACPI: After an upgrade to Karmic, the system hangs on boot" [Undecided,New] 
[11:33] <akheron> I was able to bisect the problem to one upstream kernel commit, and reverting it fixed the issue
[11:33] <akheron> How to report this upstream, how to get it fixed in Ubuntu, etc.?
[11:33] <Appiah> upstream kernel.org ?
[11:33] <akheron> yes
[11:34] <akheron> I bisected Linus' kernel tree, found the bad commit, reverted it in karmic kernel source tree, built, and now it works
[11:34] <Appiah> then use their bug tracker
[11:35] <Appiah> http://bugzilla.kernel.org/
[11:35] <akheron> ok, but will it then be fixed in karmic or lucid at all?
[11:35] <Appiah> if its broken then they will have to fix it right? :)
[11:36] <akheron> :)
[11:36] <akheron> I mean, if the fix gets to upstream after 2.6.32, will it ever be backported to ubuntu kernels?
[12:24] <apw> Keybuk, the daily boot charts are they daily or on ISO generation, and roughly what time do i expect them to pop out if they are done on any particular day?
[12:25] <Keybuk> they're on ISO generation
[12:25] <Keybuk> so each one corresponds to a particular ISO on cdimage/daily-live
[12:25] <Keybuk> (redoing them every day with no ISO change isn't worth the effort)
[12:25] <Keybuk> currently the push-to-rookery cron is at 2pm
[12:26] <Keybuk> I'm likely going to move that forwards because there's too much gap in it
[12:34] <apw> Keybuk, don't mind when it is, just nice to know "oh its after X, if there is a new one i can look now"
[12:35] <Keybuk> I've just updated the cronjob to be ourly
[12:35] <Keybuk> (the publish one)
[12:35] <Keybuk> after verifying it's a no-op if the stuff isn't finished yet
[12:36] <Keybuk> this should just reduce the gap
[12:36] <Keybuk> it's still dependant on when the machines wake up
[12:36] <Keybuk> at a glance, looks like the SSD charts for today are up
[12:36] <Keybuk> but the HDD ones aren't
[12:38] <apw> oh yeah and thats what the web site shows now too :)
[12:38] <apw> and its showing the 5s we lost yesterday have come back ... good
[12:39] <apw> man these tables are great ... makes me want to slap people i have working on bits of that to hurry up so i can see our bit get smaller
[12:39] <Keybuk> lol
[12:39] <Keybuk> if you're not on Firefox, you get little graphs at the top
[12:40] <Keybuk> which really should be "blame" graphs
[12:40] <Keybuk> you can see exactly which bit the 8s extra boot time came from
[12:41] <apw> sadly in firefox
[12:41]  * apw must sort out having chrome
[12:48] <Keybuk> add-apt-repository ppa:chromium-daily/ppa
[12:48] <Keybuk> apt-get update
[12:48] <Keybuk> apt-get install chromium-browser
[12:49] <Keybuk> ... the chimes behind me tell me that HDD should be up any second
[13:05] <apw> Keybuk, hehe :)
[13:25] <Keybuk> who knows about the rtc wake alarm stuff?
[13:28] <Keybuk> you used it for your suspend/resume tests I think?
[14:02] <Keybuk> \o/ I have made a DOS disk
[14:04] <amitk> Keybuk: we're speed up DOS boots now?
[14:04] <amitk> *speeding
[14:07] <Keybuk> I'm trying to update the BIOS on the mini 10s to see whether I can get ACPI wake support working at all
[14:07] <Keybuk> neither wake-on-lan or RTC wakeup work :(
[14:08] <amitk> cking is our wakealarm expert but he is out till for a few weeks
[14:26] <apw> Keybuk, yeah i know some about it
[14:26] <apw> if you have a recent kernel on there then you need to use some magic to work out the delta
[14:26] <Keybuk> huh?
[14:28] <apw> Keybuk, you need to use the files in /sys/class/rtc/rtc0 ... since_epoch tells you the current time in the clock, you work out the time in seconds since the system epoch you want to wake, subtract the current since_epoch value and shove it into wakealarm
[14:28] <apw> then suspend
[14:28] <apw> if that makes any sense
[14:29] <Keybuk> right I do that
[14:29] <apw> actually no thats not right either
[14:29] <Keybuk> and checking /proc/driver/rtc says the right time too
[14:29] <Keybuk> and says it'll wake up
[14:30] <apw> you work out the time in seconds since system epoch you want to wake up, then adjust that by the current time on the system since system epoch and the since_epoch value
[14:31] <apw> wake alarm is in the same units as since_epoch and can be offset from the system time
[14:32] <Keybuk> right
[14:32] <Keybuk> though only by <1s on this machine
[14:32] <Keybuk> so that's not the problem
[14:33] <apw> so you are lucky :)
[14:34] <apw> so its not waking up for you?  the 10v ?
[14:36] <Keybuk> yeah
[14:36] <Keybuk> not at all
[14:37] <apw> Keybuk, when i try it on here it doesn't say 'alarm_pending: yes' which seems wrong
[14:38] <Keybuk> according to google, that says "no" for most people
[14:40] <Keybuk> arlarm_IRQ is the important bit apparently
[14:42] <Keybuk> in the code, it says you can write +800 to the rtc wakealarm function
[14:42] <apw> oh nice
[14:43] <Keybuk> I shall try on my laptop
[14:45] <amitk> IIRC, cking had found some bugs in the HW that reqd the wake time to be written twice for it to work
[14:45] <apw> i just shoved  +60 into my 10v and it seemed to set the time accorording to /proc/driver/rtc
[14:46] <apw> Keybuk, one thing you often have to do is clear it first by writing a 0
[14:47] <amitk> Keybuk: http://smackerelofopinion.blogspot.com/2009/08/acpi-wake-alarm-bugs.html
[14:47] <Keybuk> yeah I tried that too
[14:49] <Keybuk> the fact that wake-on-lan doesn't work either suggests they screwed the bios on these
[14:50] <apw> Keybuk, man that sucks rocks
[14:50] <apw> its not like you can even tell them to boot on power enabled i guess
[14:52] <Keybuk> yeah
[14:52] <Keybuk> they have numpty bios
[14:52] <Keybuk> otoh, my latitude just worked perfectly
[14:52] <apw> does feel that way... cirtainly cannot wake mine
[14:52] <Keybuk> echo +60 > wakealarm
[14:52] <Keybuk> pm-suspend
[14:52] <Keybuk> and it woke up
[14:52] <Keybuk> and powerwake while it's still asleep ... still wakes it up
[14:52] <Keybuk> so clearly Linux is working <g>
[14:53] <apw> powerwake ?
[14:54] <Keybuk> dustin's tool to send wake-on-lan packets
[14:54] <Keybuk> ok
[14:54] <Keybuk> that's freaky
[14:54] <Keybuk> the Laititude can wake on WLAN
[14:54] <apw> nnng
[14:54]  * apw wonders if thats reasonable ... 
[14:55] <apw> i don't think my AP passes the magic packets across the boundary
[14:55] <apw> so i ahve to do it from the same side to get it to work
[14:55] <Keybuk> looks like it just stays associated
[14:55] <Keybuk> one assumes it has to be unencrypted
[14:55] <apw> sleep mode for wifi allows remaining associated
[14:56] <apw> the AP can queue packets and all sorts
[14:56] <apw> normally doesn't work ... but
[14:56] <Keybuk> it worked without even trying on this
[14:56] <Keybuk> (linksys ap running openwrt)
[14:56] <apw> i assume in your wake on lan testing the sender and recipient were both on the same ethernet switch?
[14:57] <Keybuk> yes
[14:57] <apw> i found they needed to be on the same bridged segment and my AP was not passing them over from the WLAN
[14:57] <apw> ok so they just don't work
[14:57] <Keybuk> my network is all bridged
[14:57] <Keybuk> including the connection to the ISP
[14:57] <Keybuk> which was a bit scary when I found out that's what they did
[14:57] <Keybuk> but then realised it was a cool idea
[14:58]  * apw notes the 10v has 'wake on usb' as an option
[14:58] <apw> dunno if that could be used somehow
[14:58] <Keybuk> yeah
[14:58] <Keybuk> no idea
[14:59] <Keybuk> I always assumed that's a magic usb signal
[15:00]  * Keybuk flicks through the maplin catalogue
[15:01] <apw> Keybuk, which bios version do you have on your 10v's i don't seem to have a wake on lan option in the bios
[15:02] <apw> if you arn't enabling it there, where are you enabling it
[15:03] <Keybuk> A06
[15:03] <Keybuk> ethtool says it's enabled
[15:03]  * apw has A05 ...
[15:03] <Keybuk> but I also tried A00 and A04
[15:03] <Keybuk> if I toggle with ethtool
[15:03] <Keybuk> ethtool -s wol d eth0
[15:03] <Keybuk> ethtool -s wol g eth0
[15:03] <Keybuk> poweroff
[15:04] <Keybuk> then ... the machine promptly powers straight back up again
[15:04] <Keybuk> so it's clearly toggling *something* in the BIOS :p
[15:07] <Keybuk> actually with A06 it didn't do that
[15:07] <Keybuk> it just didn't wake up at all
[15:08] <apw> Keybuk, ok mine seems to wake up from a suspend at least
[15:09] <apw> using 'wakeonlan' i can wake it from suspend without changing any settings
[15:09] <Keybuk> really?
[15:09] <Keybuk> neither of mine will do that
[15:10] <apw> i am using the wakeonlan program from wakeonlan package
[15:11] <apw> there is something about some things only working on AC, so testing iwthout power would be different
[15:11] <Keybuk> how do you spend?
[15:11] <apw> spend?
[15:11] <Keybuk> suspend
[15:12] <apw> that was from the menu
[15:12] <apw> won't wake from power off even though the lan claims to be negociated
[15:12] <Keybuk> mine won't wake from suspend *at all* with A06 bios
[15:12] <Keybuk> and today's lucid
[15:13] <apw> even via the power button
[15:13] <Keybuk> even via that
[15:15] <Keybuk> which BIOS version do you have again?
[15:15] <apw> i believe its A05, i'll cheeck next boot
[15:15] <Keybuk> dmidecode? :p
[15:15] <apw> i think i just found sudo pm-suspend did not let me wake it
[15:15] <Keybuk> ah
[15:15] <Keybuk> I was doing pm-suspend
[15:15] <apw> not sure how that would differ from the meny
[15:15]  * apw retests
[15:16] <apw> i wish these booted faster :-P
[15:16] <apw> bios A05
[15:18] <Keybuk> noticeably the suspend light stays on
[15:18] <apw> i seem to have broken mine now, syspend from the mey isn't working
[15:18] <Keybuk> rather than pulsating
[15:18] <apw> the power light  ... same here
[15:18] <apw> and on A05 and Karmic ... never seen that before
[15:19] <apw> i am suspicious its cause the network is plugged in ... testing more to confirm
[15:20] <Keybuk> I'm sure mine were suspending ok earlier :p
[15:20] <Keybuk> maybe they only suspend before 3pm
[15:20] <apw> now its ok again ... wtf
[15:21] <apw> yeah and when i wake it, the only thing you see if the power go solid
[15:21] <apw> the screen says off till you hit a key
[15:21] <Keybuk> hmm
[15:21] <Keybuk> just tested A05 and power light still stays on solid
[15:21] <Keybuk> and won't wake
[15:21] <apw> ok try booting without the ethernet plugged in and add it after login
[15:23] <Keybuk> freaky
[15:23] <Keybuk> it's almost as if those wakeonlan packets are bouncing around the network somehow :P
[15:24] <apw> ok the wedging on suspend went away for me
[15:24] <apw> i cannot get it back now ?!?
[15:24] <apw> and suspend based wake works fine ... with a karmic kernel
[15:24] <apw> i'll get a lucid one now
[15:25] <Keybuk> lol
[15:26] <Keybuk> huh
[15:26] <Keybuk> suspend worked fine
[15:26] <Keybuk> wake on lan made the light come on
[15:26] <Keybuk> and screen when I pushed a button
[15:26] <apw> so thats working ... as in working same as me
[15:27] <apw> i think the normal screen wake occurs cause open lid and the power button are both keys
[15:27] <Keybuk> yes
[15:29]  * apw may get dropped shortly ... according to christel
[15:29] <Keybuk> now both are working
[15:29] <Keybuk> both on A06
[15:30] <apw> WTF ?
[15:30] <Keybuk> let me try powering off with ethernet
[15:30] <Keybuk> and powering up with ethernet
[15:30] <Keybuk> the only thing I did differently was not plugging the ethernet in until they were on
[15:30] <apw> i dnd't get wake from 'off' to work
[15:30]  * apw does the same experiment
[15:30] <Keybuk> maybe that's it
[15:30] <Keybuk> if you send the wol packet while it's off
[15:31] <apw> ie will suspend/wol work if i power up with ether net in
[15:31] <Keybuk> it screws suspend until you unplug the network cable
[15:31] <Keybuk> I've been trying to do wake-from-off
[15:31] <Keybuk> maybe I should put them in S3
[15:31] <apw> sounds like wol from suspend is about all thats available
[15:31] <Keybuk> ok
[15:31] <Keybuk> just rebooted one through a poweroff/on
[15:31] <Keybuk> lets see if it suspends normally
[15:33] <Keybuk> apw: ok, physical power off and human power on - suspend still works
[15:33] <Keybuk> and it looks like WoL works too
[15:34] <apw> Keybuk, worked for me
[15:34] <apw> i think sending wol packets to it when its off is the end of the world
[15:34] <apw> same experience here
[15:34] <apw> its clear the machine can take wol packets when powered off, as it keeps the phy up
[15:34] <apw> but it seems to break its mind too
[15:34] <Keybuk> yes
[15:34] <Keybuk> I just tested that
[15:34] <Keybuk> if you send a WoL packet while they were actually powered off
[15:34] <apw> something to report to superm1 me thinks
[15:35] <Keybuk> the world ends
[15:35] <Keybuk> they have to be just suspended
[15:35] <apw> well i guess that 5w instead of 40 or whatever
[15:35] <Keybuk> yeah I can live with that
[15:35] <apw> its the least of the 50 other things on :)
[15:36] <apw> oops
[15:36] <Keybuk> actually I power off my desktop now ;)
[15:36] <Keybuk> since discovering that it does WoL
[15:36] <apw> heh yeah my build servers are the same
[15:36] <Keybuk> so the only thing that stays on is the server
[15:36] <apw> yeah i have a teensy server which wakes everything the same
[15:36] <Keybuk> which I deliberately bought as an "efficient" computer
[15:36] <apw> though it will be this dell 10v will become my master i think
[15:36] <apw> one interesting thing is in theory the machine can wake on 'arp' too 
[15:37] <apw> i wonder if that work
[15:37] <Keybuk> only if you install ethtool ;)
[15:38] <Keybuk> ok
[15:38] <Keybuk> so I need a script that
[15:38] <Keybuk>  1. puts the machine to sleep
[15:38] <Keybuk>  2. checks for a new cd image
[15:38] <Keybuk>     - if there is a new image, wipes the MBR and reboots
[15:39] <Keybuk> if there isn't, we assume we were woken up by user
[15:39] <Keybuk> so stay on
[15:39] <apw> nope does support that
[15:39] <apw> doens't
[15:41] <Keybuk> apw: lol
[15:42] <Keybuk> did you set for that with ethtool first?
[15:42] <apw> ethtool tells you what the machine can do, and it can't to 'a'
[15:42] <Keybuk> ethtool -s eth0 wol a
[15:42] <apw> pubmg ... 
[15:42] <Keybuk> ahh
[15:42] <Keybuk> my desktop is just pg ;)
[15:42] <apw> my big dell can only do 'g' which is the wake on lan magic packet
[15:43] <apw> phy activity ... woh
[15:43] <apw> ahhh welll so she'll have to be on always
[15:45] <Keybuk> if you're on a switch that'll be directed activity or broadcast
[15:45] <Keybuk> which is actually not so bad
[15:45] <Keybuk> if you have no SMB, etc.
[15:45] <apw> yeah i guess so
[16:04] <Keybuk> let's see if this works then
[16:04] <Keybuk> faked a 27.1 cd
[16:05] <Keybuk> the machine should install it, then got into a suspend
[16:10] <apw> Keybuk, fingers crossed
[16:29] <Keybuk> ooh, first one just suspended
[16:29] <Keybuk> the other is still installing
[16:51] <Keybuk> right
[16:51] <Keybuk> both in suspend now
[16:51]  * Keybuk fakes a CD update
[16:52] <Keybuk> ok
[16:52] <Keybuk> now the SSD one only should wake up
[16:52] <Keybuk> it woke up, but I can't tell whether it's checking for the image :-(
[16:52] <Keybuk> oh, wow, it did
[16:52] <Keybuk> it rebooted and everything
[16:53] <Keybuk> and now the script won't wake up the HDD one because the SSD one is installing \o/
[16:53]  * Keybuk watches
[17:14] <Keybuk> apw: don't suppose you know a way to force the display awake?
[17:15] <apw> Keybuk, well xset dpms might work
[17:15] <apw> Keybuk, or xset s ... one of its might so the trick
[17:15] <apw> xset dpms force on
[17:16] <apw> perhaps
[17:16] <Keybuk> doesn't look like it matters
[17:17] <apw> ?
[17:17] <Keybuk> just means there's an odd quirk that the display is always off ;)
[17:17] <Keybuk> X starts just fine with the display off
[17:17] <Keybuk> I suspect it's just the backlight?
[17:17] <apw> heh yeah i think xset dpms force on will wake that
[17:18] <apw> Keybuk, failing that there is a dbus message that the pm stuff sends to tell the display to wake i think
[17:21]  * Keybuk tosses it in there
[17:21] <Keybuk> can't hurt after all
[17:22] <apw> Keybuk, i assume it comes back on when you reboot into the image
[17:22] <apw> xset dpms isn't working for me
[17:22] <apw> hrm
[17:22] <Keybuk> no, doesn't come back on when I reboot :p
[17:22] <apw> hmmm no dbus msg when it comes on
[17:39] <Keybuk> dpms didn't work for me :-/
[18:11] <apw> Keybuk, nor me
[18:11] <apw> i've not yet found anytinhg which wakes it up, other than a key, very odd imo
[18:15] <Keybuk> must be a BIOS thing
[18:15] <Keybuk> it doesn't seem to affect the results any
[18:15] <Keybuk> so I'm looking at it as a power saving :p
[18:42] <mjg59> vbetool should be able to force a DPMS transition before you get to X
[18:42] <mjg59> Or if you're using KMS, it ought to do that anyway
[19:50] <JanC> anybody seen/heard about a kernel panic like this with the karmic kernel: http://forum.ubuntu-nl.org/installatie/probleem-na-upgrade-ubuntu-9-10-kernel-panic-not-syncing/ (jaunty kernel boots fine) ?