| === ivan\_ is now known as ivan\ | ||
| === henrix- is now known as henrix | ||
| === hughhalf is now known as hugh_afk | ||
| === hugh_afk is now known as hughhalf | ||
| MoPac | Hello. I'm a bit confused about whether a kernel fix should be present in my Utopic version (3.16.0-17) or not. My OS does not recognize SD cards from my RTS 5227. I've seen this commit https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365378 , but I'm not sure if my kernel doesn't have it yet or if it's just not working for me. | 13:44 |
|---|---|---|
| ubot5 | Launchpad bug 1365378 in linux (Ubuntu Trusty) "[Regression] realtek pci-e card readers don't recognize mmc cards" [High,Fix committed] | 13:44 |
| apw | jodh, hey ... you are clearly using vbox ... how do i type C-A-F1 to switch terminals | 15:28 |
| jodh | apw: no, I'm using kvm | 15:29 |
| jodh | apw: the problem is recreatable with kvm. | 15:29 |
| jodh | apw: but I think you need to RIGHT-CONTROL + Fn to switch vt. | 15:30 |
| apw | jodh, "a" problem is reproducible, with similar symptoms, but is it the same | 15:30 |
| apw | jodh, ok i have it in this state, slangasek implied we are crashing plymouthd ... how do we know that | 15:31 |
| jodh | apw: look for SEGV in syslog / dmesg | 15:31 |
| slangasek | oh, ok, let's use this channel instead | 15:34 |
| JayJ_ | Anybody have any pointers on how to slipstream a driver into Ubuntu PXE server? My server need a RAID driver to see the volumes | 15:37 |
| apw | argle | 15:38 |
| apw | slangasek, here / | 15:38 |
| slangasek | apw: ? | 15:38 |
| apw | jodh, slangasek, ok here then | 15:38 |
| apw | jodh, slangasek, so my log shows plymouth-upstart-bridge exploding before plymouth coredumps, could that be causual | 15:38 |
| slangasek | plymouth-upstart-bridge likes to explode | 15:39 |
| slangasek | almost certainly unrelated | 15:39 |
| apw | slangasek, sooo will i have anything else from plymouthd than that line in dmesg | 15:40 |
| apw | that i should be looking at | 15:40 |
| apw | to see why it is all in plain | 15:40 |
| apw | pain | 15:40 |
| slangasek | if there was any output, once the rootfs is rw the logs should be written to /var/log/upstart/plymouth.log | 15:42 |
| slangasek | but chances are there won't be anything | 15:42 |
| apw | i do not have any of that | 15:42 |
| slangasek | if it's reproducible with setting plymouth:debug on kernel commandline, maybe | 15:42 |
| apw | the ordering of things looks nice and safe, it is using vesafb which is nice and early | 15:43 |
| apw | and builtin, ok will try that | 15:43 |
| apw | slangasek, ok that is still reproducible, and logs a lot but all to tty7, anyway to tell it to use stdout so it goes to upstart ? | 15:48 |
| slangasek | apw: there's a --debug-file= option which you can get by passing plymouth:debug=file:<path>; not sure if that would work to use /dev/stdout | 15:49 |
| jodh | apw: --tty=/dev/foo I think should work too. See https://wiki.ubuntu.com/Plymouth | 15:49 |
| slangasek | or maybe just something on /dev or /run | 15:49 |
| * apw tries that | 15:49 | |
| slangasek | but if you pass --tty you're changing the behavior of plymouth too, not just redirecting its logging | 15:50 |
| jodh | slangasek: maybe that'll fix it :) | 15:50 |
| slangasek | FSVO "fix" :) | 15:52 |
| jodh | apw, slangasek: I've recreated "a" problem where we still get the purple screen but no lightdm. This is the same issue as seen by jibel but possibly not the same as originally reported (as the user sees the tty). On my system, there is no plymouth crash, but emitting plymouth-ready makes lightdm start. This is with "quiet splash". Removing those options and I cannot force this behaviour. | 15:55 |
| jodh | apw, slangasek: so we may have 2 problems, but both possibly with the same root cause - kernel graphics issues? | 15:56 |
| apw | jodh, why did you pick kernel graphics issues there | 15:57 |
| apw | for me when i ask lightdm to start it does, so the graphics are working just fine | 15:57 |
| slangasek | I'm not going to speculate; we should figure out why plymouthd is crashing | 15:57 |
| slangasek | also, the purple-or-not may just depend on what state grub has left the console in at boot | 15:58 |
| slangasek | so may not indicate any difference in this bug | 15:58 |
| jodh | slangasek: ok, but see comment #27 for the behaviour jibel is seeing. | 15:59 |
| apw | all the kernel graphics issues we have seen recently and we see a lot, kill the ability to switch VTs which is working in these cases | 15:59 |
| apw | slangasek, ok the last thing it says is | 16:00 |
| apw | (it == plymouthd) add_picel_displays:Adding displays for 1 heads | 16:00 |
| apw | all spelling errors mine | 16:00 |
| slangasek | jodh: "as discussed on IRC"> this is hearsay; how did you get from "plymouth-ready not emitted" to "graphics device was not being tagged PRIMARY_DEVICE_FOR_DISPLAY"? | 16:01 |
| apw | as it wouldn't respond wether it was tagged or not, being as it has died | 16:01 |
| slangasek | jodh: plymouth-splash's start depends on two events, only one of which is PRIMARY_DEVICE_FOR_DISPLAY=1; the other is 'started plymouth' - if plymouth is segfaulting before it forks, then that would also stop you from getting plymouth-ready | 16:02 |
| slangasek | apw: can you get us a bit more context before that? | 16:03 |
| apw | slangasek, http://paste.ubuntu.com/8426429/ | 16:05 |
| slangasek | apw: right. So it's trying to run against the vesa framebuffer; is the vesa fb being subsequently ripped out from under plymouth? | 16:07 |
| slangasek | (what does /proc/fb say at the end of boot?) | 16:07 |
| jodh | slangasek: yes, having noted the SEGV I think I dived down the wrong rathole :) | 16:07 |
| apw | slangasek, i don't think so, vesafb is very early and /proc/fb is 0 VESA VGA at the end | 16:09 |
| slangasek | jodh: maybe, maybe not... I'm still not sure at all what's happening here - from apw's output, I would expect this to all be happening only once 'plymouth show-splash' is executed (i.e., why would it try to configure a renderer before that) | 16:09 |
| apw | though vesf | 16:09 |
| jodh | slangasek: jibel did not have any graphics devices tagged, nor vesafb loaded apparently. | 16:09 |
| slangasek | which implies that for this case, /etc/init/plymouth-splash.conf has triggered | 16:09 |
| slangasek | ok | 16:09 |
| apw | though vesafb seems to be builtin ... which is supprising | 16:09 |
| slangasek | ah, no, so in the new plymouth, it's probing for seats before show-splash is ever called | 16:10 |
| slangasek | jodh: so similar plymouth:debug output from jibel's system would be useful for comparison | 16:11 |
| apw | slangasek, so one oddity is vesafb is builtin, which may mean we have lost the vesafb =m support again | 16:11 |
| slangasek | at any rate, this segfault is definitely happening before plymouth show-splash | 16:11 |
| apw | that said on this platform i don't think we have other options, so that wouldn't account for this | 16:12 |
| slangasek | apw: I don't remember the details on how vesafb was supposed to be handled | 16:12 |
| apw | we wait for drm framebuffers, and if udev settle finishes without getting one we attempt to modprobe vesafb | 16:12 |
| apw | which of course won't work right with it builtin | 16:12 |
| apw | but i am not convinced that would trigger this issue, we should just get vesa sooner | 16:12 |
| apw | as that is the one we expect and want | 16:13 |
| apw | slangasek, as i have it 100% reproducible here, i guess i can try and work out why plymoth is pooping, adding debug and changing timeing hasn't gotten rid of it | 16:14 |
| slangasek | k | 16:14 |
| slangasek | apw: note that in any case, your log shows that plymouth itself is doing a lot of udev interaction that it wasn't at the time those upstart jobs were written. Could be adverse interactions there, though in any event what we're seeing here is plymouth just plain crashing after loading the frame-buffer driver | 16:16 |
| apw | slangasek, stuff which will be bad if plymouthd starts before the framebuffers are done swapping about in the kerenl | 16:19 |
| apw | not that we do that in this case, but ... in most of the otehrs | 16:19 |
| slangasek | right | 16:19 |
| slangasek | well, really it should only be bad if plymouthd tries to /use/ those framebuffers before they're done swapping about | 16:20 |
| slangasek | which is 'plymouth show-splash' | 16:20 |
| slangasek | it's fine if it detects them via udev, configures internal state, etc., and also knows to remove those again if the devices change instead of blindly stumbling on | 16:21 |
| slangasek | but maybe that's not what's implemented :P | 16:21 |
| apw | slangasek, fingers crossed :) | 16:24 |
| apw | slangasek, so ironically it is blowing up adding the text display not the pixel one | 16:40 |
| slangasek | good show | 16:40 |
| apw | slangasek, ok it seems that seat->terminal is null in this case, and various other bits of code handle this, but add_text_terminal does not, making that short-circuit in this case seems to get us to lightdm reliably | 17:40 |
| apw | slangasek, not 100% convinced this is correct but it is a step | 17:41 |
| apw | slangasek, i have pushed a debdif to the bug, and shoved it into a PPA, also listed in the bug | 17:41 |
| slangasek | is this code that we currently diverge from upstream on? | 17:42 |
| apw | slangasek, doesn't look to be, but we might elsewhere leading to the condition i guess | 17:43 |
| apw | slangasek, i will say that other code seems to think it is entirely possible for a seat to be pixel and not text | 17:45 |
| apw | return ply_list_get_length (seat->pixel_displays) > 0 || | 17:45 |
| apw | ply_list_get_length (seat->text_displays) > 0; | 17:45 |
| apw | but the instantiation code will _always_ make a text_display here, so that ought to be "return 1;" with the code in its core-dumping configuration | 17:45 |
| slangasek | ok | 17:47 |
| apw | slangasek, though i am sure we shold be talking to upstream and saying wtf, is it reasonable for this to be null, like this half of the code thinks and this bit doessn't | 18:00 |
| slangasek | apw: so one thing... these are all on x86 systems, right? we always have VTs, and I'm pretty sure it is a bug to have 0 text_displays anyway | 18:36 |
| slangasek | segfaults notwithstanding, there must be a bug elsewhere to trigger it | 18:37 |
| apw | slangasek, yeah these are all x86 vms i believe, and you may well be right | 18:37 |
| slangasek | apw: seen the latest followup with an upstream pointer? | 18:43 |
| apw | slangasek, so half of that is basically what my patch does just inside add_text_terminal | 18:48 |
| apw | slangasek, but i say apply the upstream fix indeed | 18:48 |
| MoPac | Hello; I'm really hoping for some information about https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1365378 . I'm on 3.16.0-17 , but my RTS5227 SD Card reader is not recognized and throws a -110 error on startup. | 18:55 |
| ubot5 | Launchpad bug 1365378 in linux (Ubuntu Trusty) "[Regression] realtek pci-e card readers don't recognize mmc cards" [High,Fix committed] | 18:55 |
| MoPac | I've also tried the procedure at http://askubuntu.com/questions/492476/internal-sd-card-reader-not-mounted-detected-hp-realtek-rts5227 but to no avail | 18:56 |
| === hughhalf is now known as hugh_afk | ||
| === hugh_afk is now known as hughhalf | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!