=== gerald is now known as Guest89273 [07:12] creepy: http://heartbleed.com/ [07:53] Hi everyone, i come from ubuntu-fr with a pb that we didnt resolve yet [07:54] on my dell 7010, with xubuntu 12.04.3 64 bits, reboot blocks [07:54] i have 30 computers, same problem [07:54] i had the same problem before, with 32 bits image, but i found a solution [07:54] i had to add "acpi=force reboot=bios" options in /etc/default/grub [07:55] but it doesn't work on 64bits image [07:55] i tried every "reboot" parameter without success [07:55] (see http://linux.koolsolutions.com/2009/08/04/howto-fix-linux-hangfreeze-during-reboots-and-restarts/) [07:55] has anyone have an idea ? [07:56] eolien, not anything i have heard of, is there a bug filed for this specifici issue on 64bit [07:57] didn't find it [07:57] i'm searching for [07:58] then i would suggest filing one againt the apckage "linux" === ikonia_ is now known as ikonia [07:58] sorry, dont know how to do it [07:58] can you help me ? [07:59] i need to do it on launchpad ? [07:59] run "ubuntu-bug linux" in a terminal window [08:07] done [08:07] thx [08:30] eolien, might be worth letting us know the number here, as we get a heck of a lot of bugs [08:35] 1304246 [08:35] bug #1304246 [08:35] Launchpad bug 1304246 in linux (Ubuntu) "Reboot hangs with Dell computers on 64 bits" [Undecided,Confirmed] https://launchpad.net/bugs/1304246 [08:44] eolien, i am confused, the data in this bug implies this is running on KVM or similar ? [08:44] bios.vendor: Bochs [08:50] ppisati, seen lp #1303657 ? [08:50] Launchpad bug 1303657 in linux (Ubuntu) "Cannot boot trusty kernel on qemu-system-arm" [High,Confirmed] https://launchpad.net/bugs/1303657 [08:52] apw: watches [08:53] u-boot [08:53] uhm [08:57] ppisati, if you are able to boot an image with qemu we are good regardless i am sure [08:57] ppisati, if that is osmething we are able to do normally :) [08:57] apw: yes we normally do [08:57] apw: testing now [09:11] ppisati, thanks indeed [09:18] ppisati: If I had to guess, I'd assume it's because of the mandatory fdt requirement in 3.13, and he's neither appending an fdt to his kernel, nor loading a (correct) one from u-boot. [09:19] infinity: we were appending fdt since 3.11 iirc [09:19] ppisati: It wasn't required in 3.11 [09:20] infinity: and if he used flash-kernel (as it seems since it's using a flash-partition), thr fdt should be there [09:20] ppisati: Anyhow, when he's booting raw, I guarantee he's not appending one (he certainly doesn't mention it), and I suspect there isn't one in play when he's booting with u-boot. [09:21] wait [09:21] ppisati: Does flash-kernel actually deal with qemu machines properly? [09:21] he is using it [09:21] fatload mmc 0:1 0x62008000 board.dtb [09:21] ppisati: That doesn't mean it's the *right* one. [09:21] infinity: neither it says it's the correct kernel, one has to trust the bug reporter and hope that he updated kernel/initrd/dtb in accordance [09:22] ppisati: Well, I see exactly zero entries in flash-kernel that match his cpuingo. [09:22] cpuinfo, even. [09:22] So, how would the right dtb ever get there? :P [09:23] infinity: forget about the attached dtb, he is explicitly passing one [09:23] ppisati: Yes. And? [09:23] ppisati: Where is that coming from? [09:23] infinity: i don't know i'm not the bug reporter [09:24] :P === Guest60091 is now known as wmp === gerald is now known as Guest19181 [12:29] apw, have you noticed bug #1301496 ? [12:29] Launchpad bug 1301496 in linux (Ubuntu) "kernel crash: Unable to handle kernel paging request for data" [High,Confirmed] https://launchpad.net/bugs/1301496 [12:36] rtg, looking [12:39] rtg, yeah i have seen this one ... i think the logical change is to do the same test on 4K kernel, as it seems pretty reproducible [12:40] apw, guest or host or both ? [12:41] for me, guest, the host we do not supply the kernels there [12:41] rtg, i've added a note, and i'll go and look at dpkg as well [12:57] slangasek, this dpkg thing, is dpkg the only thing affected or are other things unhappy ? [12:58] apw, cking: are you familiar with "dpm_run_callback(): pnp_bus_resume+0x0/0xa0 returns -19". I think it's what's preventing the system from resuming correctly in LP: #1300568 [12:59] tseliot, not familiar no [12:59] bug #1300568 [13:00] ou [13:00] me neither, wonder why it is returning No such device [13:00] dead bot [13:00] oi ubotu where are you [13:00] and could someone fix the "diable touchpad while typing" so oh i don't know, it disables the touchpad when typing [13:01] apw, just quit dragging those huge thumbs around [13:01] you've seen my thumbs, i'd need like helium balloons attached to each [13:01] https://bugs.launchpad.net/kittyhawk/+bug/1300568 [13:01] tseliot: Error: launchpad bug 1300568 not found [13:02] apw, cking ^ [13:03] BTW the disable touchpad when typing sounds like a problem with palm detection in the driver [13:04] isn't that PNP device a keyboard? [13:05] cking, it is the id for the i8042, i wonder if it even has one [13:05] maybe it popped offline, EC error etc [13:06] or maybe it just has none at all, i didn't think most new kit did [13:07] i8042: PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 [13:07] in the kern log at boot [13:07] oh just the keyboard at that [13:09] i wonder if i8042.nopnp may show different behaviour [13:12] I can ask the engineer to try that [13:12] cking, yeah ... [13:12] maybe the bios folk in HWE will have some ideas too [13:12] wrt EC foobars [13:14] yeah [13:15] cking, seems there is a quirk table for that option if it is that [13:16] yup, but if this is a EC bug in new kit I guess we can get it fixed in the firmware before worrying about that [13:16] yep that [13:18] in the firmware? [13:22] in the EC firmware [13:27] ok [13:27] rtg, did you get anywhere bisecting your kernel for the nvidia issue? [13:27] bjf, I power cycled the jumbotron and then it started working [13:27] huh [13:28] same kernel, now no problems [13:28] that's special [13:28] with I'd have thought of that 3 1/2 hours earlier [13:29] it has a life of its own [13:35] rtg, makes no sense to me but .. i was unable to get anything but low-res and only 1 monitor recognized. i shutdown the system and power-cycled the monitors and now the system recogizes them both and i'm back to hi-res [13:36] bjf, I guess these monitors have buggy firmware too [13:37] rtg, i've never had this problem until this new HEDT [13:39] bjf, do you have the same monitors as tim ? [13:39] apw, no [13:39] apw, mine is a 27" dell [13:39] i don't think i want to work out how that can be that you both are affected by the same issue on the same day with different h/w [13:39] bjf, nor have I, which is why it took me so long to try a simple power cycle. [13:40] apw, but we both are using an intel HEDT with the same nvidia card (i believe) [13:42] yeah, but the issue was that the machine somehow made the monitors cry, but only once, it makes my head hurt [13:50] bjf, this wasn't happening on an HEDT. Its a generic Gigabyte MB with a GeForce GTX650 display adapter. [13:50] wierd [13:50] rtg, ok, that's even more odd === hatch__ is now known as hatch [15:09] ** [15:09] ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting [15:09] ** [15:14] apw: I imagine other things are unhappy, but it's really easy to notice with dpkg because one bit flip per page causes a segfault on startup [15:16] slangasek, ok, yeah i vaguely wondered if the zero page could have stopped being all zero, and if we could detect that elsewhere [15:17] slangasek, as the dpkg init there is pretty simple and it finds the "static variable" non-zero [15:20] slangasek, i guess i would like to see one of these in the flesh when it is unhappy === gerald is now known as Guest34012 === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues April 15th, 2014 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! === tinoco is now known as tinoco-away