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