| manjo | Dinh, logging off and off the hospital ... see you tomorrow | 00:00 |
|---|---|---|
| Dinh | ok..have a good one | 00:01 |
| === pace_t_zulu_ is now known as pace_t_zulu | ||
| === mdz_ is now known as mdz | ||
| ikepanhc | hi cjwatson | 09:18 |
| cjwatson | ikepanhc: can I help you? | 10:13 |
| ikepanhc | Hi cjwatson | 10:13 |
| ikepanhc | Please give me a minute | 10:14 |
| ikepanhc | I am working on bug 360966 | 10:14 |
| ubot3 | Malone bug 360966 in linux "bnx2x missing in initrd for install media" [Medium,In progress] https://launchpad.net/bugs/360966 | 10:14 |
| ikepanhc | And have some question about the installer | 10:14 |
| ikepanhc | I checked for the udeb, we dont have that module | 10:15 |
| ikepanhc | I think we could have the module after add to debian/d-i/modules/nic-module | 10:16 |
| ikepanhc | is that ok? | 10:16 |
| cjwatson | ikepanhc: yes, that's what Leann said and she's correct | 10:16 |
| cjwatson | d-i does not rely on update-initramfs | 10:16 |
| cjwatson | so looking at that is a red herring | 10:17 |
| ikepanhc | Yes, I have tested it | 10:17 |
| ikepanhc | but since jaunty has been release, shall we modify as Jaunty SRU? | 10:17 |
| ikepanhc | I ask because we have the cdimage already | 10:18 |
| cjwatson | well, you're correct that we won't be issuing updated CD images | 10:18 |
| cjwatson | however, this bug does not affect CD images, only netboot installation | 10:18 |
| cjwatson | s | 10:18 |
| cjwatson | and we do update the initrds for those from time to time | 10:19 |
| ikepanhc | so, it is necessary for a Jaunty SRC, since the netboot image will rebuild | 10:19 |
| ikepanhc | s/SRC/SRU | 10:19 |
| ikepanhc | and the final one, we still need to check the module dependence. | 10:21 |
| ikepanhc | I notice that bnx2x depends on libcrc32 | 10:21 |
| ikepanhc | Is that correct? | 10:21 |
| cjwatson | ikepanhc: I have no idea, that's your department | 10:28 |
| cjwatson | kernel-wedge will refuse to build if things aren't right there ... | 10:28 |
| ikepanhc | cjwatson: thanks. I think the dependence shall be cared | 10:29 |
| ikepanhc | cjwatson: another question, how do we test for it if we have made the udeb? | 10:29 |
| ikepanhc | eh | 10:35 |
| ikepanhc | cjwatson_: another question, how do we test for it if we have made the udeb? | 10:36 |
| === cjwatson_ is now known as cjwatson | ||
| cjwatson | 10:29 <ikepanhc> cjwatson: another question, how do we test for it if we have made the udeb? | 10:39 |
| cjwatson | 10:29 <cjwatson> if libcrc32 is already in some other udeb, it may be necessary to arrange for there to be some common udeb that contains it that both nic-modules and the other one depend on | 10:39 |
| cjwatson | 10:30 <cjwatson> test for what? | 10:39 |
| cjwatson | 10:30 <cjwatson> you mean libcrc32c, BTW | 10:39 |
| cjwatson | 10:30 <cjwatson> which is apparently already in crypto-modules | 10:39 |
| cjwatson | so this is actually slightly complicated | 10:41 |
| ikepanhc | cjwatson: I download the netboot.tar.gz. there is only a initrd.gz inside | 10:41 |
| cjwatson | ikepanhc: testing: check whether bnx2x shows up in 'dpkg -c nic-modules...udeb' :-) | 10:41 |
| cjwatson | what did you expect to be in netboot.tar.gz? :-) | 10:42 |
| ikepanhc | ah? I have some misunderstanding? | 10:42 |
| cjwatson | well, I guess you must do, what did you expect it to contain? | 10:43 |
| ikepanhc | I saw kernel image and initrd in netboot.tar.gz | 10:43 |
| cjwatson | netboot.tar.gz actually contains initrd.gz, a kernel image, and a bunch of pxelinux setup stuff | 10:43 |
| cjwatson | its purpose is that it's a convenient thing you can untar onto a pxe server and boot from | 10:44 |
| cjwatson | but that isn't really particularly relevant to this bug | 10:44 |
| cjwatson | the simplest approach to cope with libcrc32c being in multiple udebs would be to edit debian/d-i/package-list to make nic-modules depend on crypto-modules | 10:45 |
| ikepanhc | This is what I am thinking, seems a wrong thought, we will download .deb after booting the kernel in netboot.tar.gz? | 10:46 |
| cjwatson | it's not particularly elegant, but it would do the job | 10:46 |
| cjwatson | ikepanhc: um, no ... | 10:46 |
| cjwatson | ok, this is a brief sketch of how d-i works | 10:47 |
| cjwatson | the initrd is built up (when building the debian-installer source package) from a bunch of udebs | 10:47 |
| cjwatson | including, relevantly, the udebs that are spat out as part of the kernel build process | 10:47 |
| cjwatson | now, not all the udebs go into the initrd - only those that are needed to boot the installer | 10:47 |
| cjwatson | the installer knows how to fetch more bits of itself at run-time, using a similar sort of approach to apt and dpkg, although it doesn't actually use apt or dpkg directly | 10:48 |
| cjwatson | this is what's happening when you see it "Downloading installer components" | 10:48 |
| * ikepanhc reading | 10:49 | |
| cjwatson | later on, after partitioning, the installer constructs the real installed system on disk, and at *that* point it downloads .debs | 10:49 |
| cjwatson | but that's well after stuff like network configuration, for which it needs the appropriate modules to be available in udeb form | 10:49 |
| cjwatson | if you want a full paper on the subject, which talks about a lot of stuff beyond what you actually need here, see http://d-i.alioth.debian.org/doc/talks/debconf6/paper/ | 10:49 |
| ikepanhc | cjwatson: thanks very much, reading it. | 10:51 |
| ikepanhc | cjwatson: and bnx2x need to work with its firmware, so, we also need to copy the firmware image? | 10:52 |
| cjwatson | yes | 10:54 |
| cjwatson | same way as it's done for bnx2 | 10:54 |
| ikepanhc | Thanks, go to read the flow of installer :) | 10:55 |
| cjwatson | is it OK to remove the old linux-backports-modules-2.6.30 source package from karmic now? | 12:02 |
| cjwatson | we have 2.6.31 ... | 12:02 |
| === cooloney is now known as cooloney-afk | ||
| === akgraner_ is now known as akgraner | ||
| cjwatson | rtg_: oh, good morning. Is it OK to remove the old linux-backports-modules-2.6.30 source package from karmic now? We have 2.6.31 ... | 13:01 |
| rtg_ | cjwatson, definitely | 13:02 |
| cjwatson | good-oh | 13:05 |
| apw | smb, does your aspire wireless work ok on boot on karmic kernels ? | 13:49 |
| smb | apw, yes | 13:50 |
| smb | apw, The guy you see on skype right now uses it | 13:51 |
| smb | apw, I assume you look at a bug. Which driver is being used? | 13:51 |
| apw | bug #395565 | 13:52 |
| ubot3 | Malone bug 395565 in linux "atheros wifi not working with kernel 2.6.31-1" [High,Incomplete] https://launchpad.net/bugs/395565 | 13:52 |
| apw | it atheros | 13:52 |
| smb | apw, I use ath5k and believe there have been ath_pci before. | 13:53 |
| apw | it seems like the key and the wireless enable itself are two rfkill things not one | 13:54 |
| apw | tail /sys/class/rfkill/*/state | 13:54 |
| apw | what does that say on yours | 13:54 |
| smb | 1 | 13:55 |
| apw | same here | 13:56 |
| apw | which means UNBLOCKED | 13:56 |
| apw | those guys have two separate controls | 13:56 |
| smb | I am not sure the real rfkill is detectable for the OS there | 13:56 |
| smb | I usually get the effect of just timing out when I toggle the rfkill. It is all done in the hw itself | 13:57 |
| apw | hrm ... its all a big complex | 13:57 |
| apw | network manager has lost the ability to know if rfkill is enabled | 13:57 |
| apw | as the /sys files changes name with the new rfkill framework | 13:58 |
| apw | hit the botton and do that tail and see if it goes to 0 or 2 | 13:58 |
| smb | I just did and it stays at 1 as I expected | 13:58 |
| apw | thanks for testing | 13:59 |
| smb | apw, I believe nm cannot do much there. To it it must look just as a loss of connection. And indeed it starts trying to connect and fails, wants the passphrase again... bla. After toggling again all is ok | 14:00 |
| apw | smb, yeah you are simply different from these guys ... | 14:01 |
| smb | apw, Well if I look at it, those are all sorts of Acer. And we know there is acer-wmi doing soft-rfkill as well. | 14:02 |
| smb | Only the Aspire One is excluded as it does not behave anyways | 14:03 |
| apw | yeah via pcix hotplug, gah | 14:03 |
| lool | Hey folks | 14:05 |
| lool | is there a list of recommended/required kernel options for an Ubuntu userspace? | 14:05 |
| lool | e.g. udev needs inotify to work | 14:05 |
| apw | not that i know of no, when building kernels like mainline i use the ubuntu config as a seed | 14:06 |
| rtg_ | lool, 2.6.31-3 has some inotify regression patches | 14:06 |
| lool | rtg_: What I'm asking is whether there's a place which documents which options MUST be turned on or SHOULD be turned on for an Ubuntu base install to boot and work decently? | 14:08 |
| lool | apw: Okay, thanks | 14:08 |
| rtg_ | lool, oh, now that I couldn't tell you off the top of my head | 14:08 |
| lool | It's ok; it would have been handy but I'll just fix stuff as I hear it's borkne | 14:08 |
| rtg_ | lool, is borkne French for broken? | 14:09 |
| lool | rtg_: I usually typo brokne to make it clear that's it's borken | 14:13 |
| rtg_ | lool, I can't help but admire your technique :) | 14:14 |
| rtg_ | smb, you gonna create a Jaunty topic branch for the Freescale patch set? | 15:11 |
| smb | rtg_, Yes | 15:11 |
| smb | rtg_, Though not only limited to the freescale set | 15:12 |
| rtg_ | smb, an ARM specific topic branch then | 15:12 |
| smb | rtg_, Right. | 15:12 |
| smb | rtg_, Is there a specific reason you ask? | 15:13 |
| rtg_ | smb, just griding through the k-t list emails. | 15:13 |
| rtg_ | grinding, evenm | 15:13 |
| smb | Ah, ok. I got a preview of it up at my jaunty git tree (branch arm) | 15:14 |
| rtg_ | smb, is it creating a new package name? | 15:15 |
| smb | rtg_, No, not so far as I was told it would not get published by uploading it to the usual buildds | 15:15 |
| rtg_ | smb, its for OEM builds only? | 15:16 |
| smb | rtg_, Something likely. The agreement was something like we currently do for the mainline builds would be sufficient. Not that I still feel completely confident this is the final decision | 15:18 |
| smb | rtg_, Should we get different requirements the branch can be changed to name the package differently | 15:19 |
| rtg_ | smb, I think it should have a different package name from the beginning, just to ensure there is never any confusion | 15:21 |
| smb | rtg_, Well, there is the same confusion potential with the netbook branch | 15:23 |
| rtg_ | smb, wherein we have a somewhat formal agreement with the OEM team that the LPIA branch will always be compiled on their buildds and stored on their archive. We have no such arrangement with the mobile team. | 15:24 |
| smb | rtg_, Shouldn't we then rather come to an arrangement with the mobile team before going into changing the package name? | 15:25 |
| smb | rtg_, It actually would make me feel better when we knew that they know how the usecase will be, to be honest | 15:26 |
| rtg_ | smb, given that they don't have their own archive or buildd infrastructure, I'd just as soon distinguish packages by adding 'ARM' or something to the package name. | 15:27 |
| smb | rtg_, The release adds an arm similar to what the netbook branch does | 15:28 |
| rtg_ | smb, thats hard for me to know since their is no topic branch in the main repo for me to look at. | 15:28 |
| smb | When I spoke with ogra yesterday, his take was that they just need a known place where they will put resulting debs to integrate into images | 15:28 |
| smb | rtg_, That can be solved: http://kernel.ubuntu.com/git?p=smb/ubuntu-jaunty.git;a=shortlog;h=refs/heads/arm :) | 15:29 |
| apw | rtg_, also we use a different series name, so if it was uploaded to the main archive it would break (netbook tree) | 15:37 |
| apw | Keybuk, when we were talking about module probes in initramfs, did we conclude they were effectivly sequential and blocking | 15:38 |
| Keybuk | apw: not sure what you mean? | 15:39 |
| smb | apw, Hm, the series name is not changed, yet. But it sounds like a good safety switch | 15:40 |
| apw | when we were talkig about loading firmware in initramfs, the issue there was that the hung the modprobe | 15:40 |
| apw | in the initramfs script which was loading the driver in question and it was hung cause no udev | 15:40 |
| Keybuk | oh, right | 15:40 |
| Keybuk | yeah udev waits to settle in the initramfs | 15:41 |
| apw | right so if we load something in initramfs and its slow we block boot by the slowest oneb | 15:41 |
| apw | one | 15:41 |
| apw | so i think that may be what is making all these floppy missing boots slow | 15:41 |
| apw | since you added the mod alias, fd is loading in the initramfs and handing for 1 min | 15:42 |
| apw | and holding boot thereby | 15:42 |
| apw | i am suspecting if we just stop it getting onto the initramfs life might be ok | 15:42 |
| Keybuk | that makes sense | 15:43 |
| apw | thanks ... will have a look at that | 15:45 |
| apw | Keybuk, we don't support root on floppy do we? | 15:48 |
| Keybuk | nope | 15:49 |
| Keybuk | can't see how that work work <g> | 15:49 |
| Keybuk | iz a wafer thin root filesystem | 15:49 |
| apw | just one sir? | 15:51 |
| Keybuk | "Please insert Ubuntu disk 519,214" | 15:51 |
| apw | Keybuk, any idea what decides that floppy would be in the initramfs | 15:52 |
| Keybuk | it's probably hardcoded | 15:52 |
| rtg_ | apw, isn't there a module list somewhere | 15:52 |
| rtg_ | ? | 15:52 |
| Keybuk | though it's not in the initramfs | 15:53 |
| Keybuk | weird | 15:53 |
| apw | yeah but i don't see floppy on it yet it is in my initramfs | 15:53 |
| Keybuk | I think we add everything from block | 15:54 |
| apw | Keybuk, yep thats the one ... thanks | 15:54 |
| manjo | amitk, apw we found that the clock sourece bits are not set right for mx51 | 16:02 |
| manjo | amitk, making some progress now | 16:02 |
| apw | that 'wait' should be made more like | 16:02 |
| apw | for (x=0; foo != jiffies; x++) | 16:03 |
| apw | if (x == 100000) | 16:03 |
| apw | printk "STILL WAITING!!!!" | 16:03 |
| === bjf is now known as bjf-afk | ||
| amitk | manjo: in clock.c? | 16:05 |
| manjo | yeah | 16:05 |
| amitk | I wonder how that changed from the original code | 16:05 |
| amitk | unless some parent clock changed | 16:05 |
| manjo | so you need to set certain bits in the MX51 cpu if you need to get the clock working right | 16:06 |
| manjo | the code is setting for mx3 and not for mx51 | 16:06 |
| manjo | now were are figuring out the bits that need to be set | 16:06 |
| manjo | so there is some missing code for mx51 | 16:06 |
| amitk | manjo: are you looking for cpu_clk? or one of the pll clocks? | 16:06 |
| manjo | the bits that need to be set ... for the cpu_clk (GPT) | 16:07 |
| manjo | pll is turned on for sure | 16:07 |
| amitk | manjo, line 1426 in arch/arch/mach-mx51/clock.c ? | 16:10 |
| manjo | arch/arm/plat-mxc/time.c ? | 16:11 |
| manjo | ignore that ? | 16:11 |
| manjo | you will see code for 1 2 3 | 16:12 |
| manjo | and not for 51 | 16:12 |
| amitk | manjo: arch/arm/plat-mxc/time.c is definitely incorrect. I am not sure why bjf added the #ifdef CANONICAL in timer_init there. | 16:15 |
| === bjf-afk is now known as bjf | ||
| amitk | bjf: morning. Can you comment on 785269a99fae2e6ffab65efaaaab2b6475867d6e | 16:16 |
| bjf | amitk, just a sec ... | 16:16 |
| amitk | manjo: bjf: Got to step out for a bit. Be back in 30-40 mins. | 16:19 |
| pgraner | apw: I seem to have found a regression between Intrepid and Jaunty | 16:19 |
| pgraner | smb: ^^^^^^^^^ | 16:19 |
| apw | only one? | 16:19 |
| amitk | bjf: I don't see mxc_timer_init() #ifdef'ed CANONICAL in jaunty FWIW. | 16:19 |
| pgraner | apw: I can't get past this one to get to anything else :-) | 16:20 |
| apw | what you find | 16:20 |
| * smb slaps apw | 16:20 | |
| bjf | amitk, the function signatures changed | 16:20 |
| pgraner | apw: Dell Inspiron 2650 hangs on boot | 16:20 |
| smb | But yeah, there seem to be a few | 16:20 |
| pgraner | apw: if I drop back to the Intrepid kernel it boots fine | 16:20 |
| smb | pgraner, How far do you get? | 16:20 |
| pgraner | apw: booting in rescue mode http://people.ubuntu.com/~pgraner/IMG00160-20090715-1115.jpg | 16:21 |
| pgraner | apw: it will sit there forever | 16:21 |
| apw | got a dmesg from a working boot? | 16:21 |
| pgraner | apw: I can get one | 16:21 |
| smb | Probably best lets have a bug report to accumulat info | 16:21 |
| pgraner | apw: didn't know if you wanted a bug or if you had seen this before | 16:21 |
| pgraner | smb: bug inbound | 16:22 |
| smb | pgraner, Ok, I can't recall something like that | 16:22 |
| rtg_ | pgraner, try booting with pci=noacpi? | 16:23 |
| tseliot | smb: I've just filed an SRU about the patch for touchpads: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/399787 | 16:23 |
| ubot3 | Malone bug 399787 in linux "The kernel shoud set BTN_TOOL_DOUBLETAP and BTN_TOOL_TRIPLETAP only if the touchpad supports them" [Undecided,New] | 16:23 |
| smb | pgraner, Could you also take a photo of the hang with normal boot but "quiet splash" replaced by debug? | 16:24 |
| smb | tseliot, Can you post that request to the kernel-team mailing list? | 16:24 |
| smb | tseliot, preferably with the patch attached | 16:25 |
| pgraner | rtg_: worked with pci=noacpi | 16:25 |
| tseliot | smb: sure | 16:25 |
| bjf | manjo, yo! | 16:25 |
| rtg_ | pgraner, also try 2.6.31-3 | 16:25 |
| rtg_ | without the noacpi option | 16:25 |
| pgraner | rtg_: ok give me a few mins | 16:25 |
| smb | tseliot, thanks. | 16:26 |
| pgraner | rtg_: I got caught by the you need to fsck since its been 28 boots with out one.... hell | 16:26 |
| smb | rtg_, Unfortunately noacpi even helps in acpi unrelated cases *sigh* | 16:26 |
| rtg_ | and without splash you can't stop it | 16:27 |
| rtg_ | smb, indeed, but it is a clue. | 16:27 |
| smb | rtg_, sure | 16:27 |
| tseliot | smb: ok, done. Thanks | 16:35 |
| amitk | manjo: bjf: back | 16:47 |
| bjf | amitk, the signature on mxc_timer_init changes between jaunty and karmic | 16:48 |
| bjf | amitk, I chose to make that change rather than modify the FSL patches | 16:48 |
| amitk | bjf: ack | 16:51 |
| bjf | manjo, ping! | 16:59 |
| manjo | yes | 16:59 |
| bjf | manjo, fedex claims they delivered the HW | 17:00 |
| manjo | I am at dinhs house right now ... my wife might have signed for it | 17:00 |
| bjf | manjo, "left at front door" | 17:00 |
| manjo | I will walk over and take a look this afternon | 17:00 |
| manjo | ok | 17:00 |
| manjo | I will walk over there in 1hr | 17:01 |
| manjo | thanks bjf | 17:01 |
| bjf | manjo, np | 17:01 |
| === Sarvatt_ is now known as Sarvatt | ||
| manjo | who merged this cod ? | 17:15 |
| manjo | code ? | 17:15 |
| manjo | bjf, amitk take a look at arch/arm/plat-mxc/gpio.c | 17:15 |
| manjo | you have 2 files on top of each other | 17:16 |
| manjo | duplicating every funtion in it | 17:16 |
| bjf | manjo, that's because the FSL one is so different from upstream, which one should be used? | 17:17 |
| bjf | manjo, it would be our preference, to rip out the FSL version and just use the upstream version | 17:18 |
| bjf | manjo, the problem I had with this was knowing if the imx51 depended on any side effects that were only in the FSL code | 17:21 |
| bjf | manjo, what's your thinking w.r.t. that file? | 17:28 |
| tseliot | smb, rtg_: thanks a lot :-) | 17:30 |
| smb | tseliot, thanks for the preparational work :) | 17:31 |
| pgraner | rtg_: 2.6.31-3 has the issue as well | 17:33 |
| rtg_ | pgraner, you said it was a Dell 2650? | 17:36 |
| pgraner | rtg_: yep and older model | 17:36 |
| pgraner | s/and/an/ | 17:36 |
| rtg_ | I don't think I've ever seen one. Intel CPU, right? | 17:36 |
| pgraner | rtg_: yep a celeron | 17:37 |
| pgraner | rtg_: its just funny that it was working just fine with Intrepid and stopped with Jaunty | 17:41 |
| rtg_ | pgraner, I'm trying acpi.debug_level=ACPI_DEBUG, but its not recognized. | 17:43 |
| pgraner | rtg_: I can give you access to this one if you want to poke around | 17:44 |
| rtg_ | pgraner, oh hell no. do I _look_ like I wanna debug ACPI stuff? Thats cking's specialty | 17:45 |
| cking | ick | 17:46 |
| rtg_ | pgraner, ah, needs CONFIG_ACPI_DEBUG in order to get any output. | 17:46 |
| rtg_ | mjg59, any suggestion on how to approach a presumed ACPI problem for 2.6.28 and higher ? CONFIG_ACPI_DEBU is not defined, the machine boots with pci=noacpi. Its an Inspiron w/Celeron that wedges on boot. | 17:49 |
| * cking is only really clued up on hardy kernels | 17:51 | |
| rtg_ | pgraner, 32 bit kernel? | 17:51 |
| rtg_ | IIRC Celeron cannot do 64 | 17:51 |
| mjg59 | rtg_: Where does it wedge? | 17:52 |
| rtg_ | mjg59, pgraner had a picture of it awhile ago. Pete? | 17:53 |
| pgraner | rtg_: 32 bit | 17:53 |
| pgraner | rtg_: http://people.ubuntu.com/~pgraner/IMG00160-20090715-1115.jpg | 17:53 |
| pgraner | mjg59: ^^^^ | 17:53 |
| mjg59 | Heh, ok | 17:53 |
| mjg59 | So everything later than .28 wedges there, and earlier stuff boots? | 17:54 |
| rtg_ | .28 and later (inclusive) | 17:54 |
| rtg_ | well, he's only tried .28 and .31-rc3 | 17:54 |
| mjg59 | Nothing obvious springs to mind | 17:56 |
| rtg_ | mjg59, ok, I'm gonna build a kernel with ACPI_DEBUG and see if it sheds any light | 17:56 |
| pgraner | rtg_, mjg59: I filed a bug on that issue LP 399844 | 18:06 |
| rtg_ | pgraner, http://kernel.ubuntu.com/~rtg/linux-image-2.6.31-3-generic_2.6.31-3.19_i386.deb, use 'acpi.debug_layer=0x2 acpi.debug_level=0xffffffff' and see how far it gets. | 18:16 |
| pgraner | rtg_: ok, so I used your kernel with the kernel params.... Hung, the only difference is there is one additional line on the console: Clocksource tsc unstable (delta = -121312902 ns) | 19:07 |
| rtg_ | pgraner, ok, boot with 'hpet=disable' | 19:08 |
| pgraner | rtg_: keeping the debug? | 19:09 |
| rtg_ | pgraner, I doubt if it makes a diff. try with and without. | 19:10 |
| pgraner | rtg_: hung at the same spot with hpet=disable | 19:10 |
| pgraner | rtg_: booting with hpet=disable acpi.debug_layer=0x2 acpi.debug_level=0xffffffff removes the Clocksource tsc unstable line. Other than that it hangs at the same spot | 19:13 |
| rtg_ | pgraner, hmm, try different clock sources. perhaps clocksource=hpet or clocksource=pit | 19:13 |
| pgraner | rtg_: ack | 19:13 |
| pgraner | rtg_: no difference all hung in the same spot | 19:15 |
| rtg_ | pgraner, lemme research ACPI debug a bit more. | 19:18 |
| rtg_ | pgraner, try turning on all ACPI debug by using 'acpi.debug_layer=0xffffffff acpi.debug_level=0xffffffff' | 20:01 |
| pgraner | rtg_: it looks like its stuck in a loop, does all that get written to dmesg? | 20:08 |
| rtg_ | pgraner, depends on if the root fs is mounted. otherwise it just goes to the console | 20:09 |
| pgraner | rtg_: looks like its to the console | 20:10 |
| pgraner | rtg_: you want a picture? It scrolls with the exact same message the only thing changing is the time stamp | 20:11 |
| rtg_ | spewing the same stuff constantly? | 20:11 |
| pgraner | rtg_: yep | 20:12 |
| rtg_ | I guess see if you can get a phot | 20:13 |
| rtg_ | photo, even | 20:13 |
| rtg_ | Keybuk, you still around? | 20:29 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
