/srv/irclogs.ubuntu.com/2014/09/25/#ubuntu-kernel.txt

=== 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
MoPacHello. 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
ubot5Launchpad bug 1365378 in linux (Ubuntu Trusty) "[Regression] realtek pci-e card readers don't recognize mmc cards" [High,Fix committed]13:44
apwjodh, hey ... you are clearly using vbox ... how do i type C-A-F1 to switch terminals15:28
jodhapw: no, I'm using kvm15:29
jodhapw: the problem is recreatable with kvm.15:29
jodhapw: but I think you need to RIGHT-CONTROL + Fn to switch vt.15:30
apwjodh, "a" problem is reproducible, with similar symptoms, but is it the same15:30
apwjodh, ok i have it in this state, slangasek implied we are crashing plymouthd ... how do we know that15:31
jodhapw: look for SEGV in syslog / dmesg15:31
slangasekoh, ok, let's use this channel instead15: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 volumes15:37
apwargle15:38
apwslangasek, here /15:38
slangasekapw: ?15:38
apwjodh, slangasek, ok here then15:38
apwjodh, slangasek, so my log shows plymouth-upstart-bridge exploding before plymouth coredumps, could that be causual15:38
slangasekplymouth-upstart-bridge likes to explode15:39
slangasekalmost certainly unrelated15:39
apwslangasek, sooo will i have anything else from plymouthd than that line in dmesg15:40
apwthat i should be looking at15:40
apwto see why it is all in plain15:40
apwpain15:40
slangasekif there was any output, once the rootfs is rw the logs should be written to /var/log/upstart/plymouth.log15:42
slangasekbut chances are there won't be anything15:42
apwi do not have any of that15:42
slangasekif it's reproducible with setting plymouth:debug on kernel commandline, maybe15:42
apwthe ordering of things looks nice and safe, it is using vesafb which is nice and early15:43
apwand builtin, ok will try that15:43
apwslangasek, 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
slangasekapw: 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/stdout15:49
jodhapw: --tty=/dev/foo I think should work too. See https://wiki.ubuntu.com/Plymouth15:49
slangasekor maybe just something on /dev or /run15:49
* apw tries that15:49
slangasekbut if you pass --tty you're changing the behavior of plymouth too, not just redirecting its logging15:50
jodhslangasek: maybe that'll fix it :)15:50
slangasekFSVO "fix" :)15:52
jodhapw, 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
jodhapw, slangasek: so we may have 2 problems, but both possibly with the same root cause - kernel graphics issues?15:56
apwjodh, why did you pick kernel graphics issues there15:57
apwfor me when i ask lightdm to start it does, so the graphics are working just fine15:57
slangasekI'm not going to speculate; we should figure out why plymouthd is crashing15:57
slangasekalso, the purple-or-not may just depend on what state grub has left the console in at boot15:58
slangasekso may not indicate any difference in this bug15:58
jodhslangasek: ok, but see comment #27 for the behaviour jibel is seeing.15:59
apwall the kernel graphics issues we have seen recently and we see a lot, kill the ability to switch VTs which is working in these cases15:59
apwslangasek, ok the last thing it says is16:00
apw(it == plymouthd) add_picel_displays:Adding displays for 1 heads16:00
apwall spelling errors mine16:00
slangasekjodh: "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
apwas it wouldn't respond wether it was tagged or not, being as it has died16:01
slangasekjodh: 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-ready16:02
slangasekapw: can you get us a bit more context before that?16:03
apwslangasek, http://paste.ubuntu.com/8426429/16:05
slangasekapw: 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
jodhslangasek: yes, having noted the SEGV I think I dived down the wrong rathole :)16:07
apwslangasek, i don't think so, vesafb is very early and /proc/fb is 0 VESA VGA at the end16:09
slangasekjodh: 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
apwthough vesf16:09
jodhslangasek: jibel did not have any graphics devices tagged, nor vesafb loaded apparently.16:09
slangasekwhich implies that for this case, /etc/init/plymouth-splash.conf has triggered16:09
slangasekok16:09
apwthough vesafb seems to be builtin ... which is supprising16:09
slangasekah, no, so in the new plymouth, it's probing for seats before show-splash is ever called16:10
slangasekjodh: so similar plymouth:debug output from jibel's system would be useful for comparison16:11
apwslangasek, so one oddity is vesafb is builtin, which may mean we have lost the vesafb =m support again16:11
slangasekat any rate, this segfault is definitely happening before plymouth show-splash16:11
apwthat said on this platform i don't think we have other options, so that wouldn't account for this16:12
slangasekapw: I don't remember the details on how vesafb was supposed to be handled16:12
apwwe wait for drm framebuffers, and if udev settle finishes without getting one we attempt to modprobe vesafb16:12
apwwhich of course won't work right with it builtin16:12
apwbut i am not convinced that would trigger this issue, we should just get vesa sooner16:12
apwas that is the one we expect and want16:13
apwslangasek, 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 it16:14
slangasekk16:14
slangasekapw: 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 driver16:16
apwslangasek, stuff which will be bad if plymouthd starts before the framebuffers are done swapping about in the kerenl16:19
apwnot that we do that in this case, but ... in most of the otehrs16:19
slangasekright16:19
slangasekwell, really it should only be bad if plymouthd tries to /use/ those framebuffers before they're done swapping about16:20
slangasekwhich is 'plymouth show-splash'16:20
slangasekit'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 on16:21
slangasekbut maybe that's not what's implemented :P16:21
apwslangasek, fingers crossed :)16:24
apwslangasek, so ironically it is blowing up adding the text display not the pixel one16:40
slangasekgood show16:40
apwslangasek, 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 reliably17:40
apwslangasek, not 100% convinced this is correct but it is a step17:41
apwslangasek, i have pushed a debdif to the bug, and shoved it into a PPA, also listed in the bug17:41
slangasekis this code that we currently diverge from upstream on?17:42
apwslangasek, doesn't look to be, but we might elsewhere leading to the condition i guess17:43
apwslangasek, i will say that other code seems to think it is entirely possible for a seat to be pixel and not text17:45
apw  return ply_list_get_length (seat->pixel_displays) > 0 ||17:45
apw         ply_list_get_length (seat->text_displays) > 0;17:45
apwbut the instantiation code will _always_ make a text_display here, so that ought to be "return 1;" with the code in its core-dumping configuration17:45
slangasekok17:47
apwslangasek, 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't18:00
slangasekapw: 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 anyway18:36
slangaseksegfaults notwithstanding, there must be a bug elsewhere to trigger it18:37
apwslangasek, yeah these are all x86 vms i believe, and you may well be right18:37
slangasekapw: seen the latest followup with an upstream pointer?18:43
apwslangasek, so half of that is basically what my patch does just inside add_text_terminal18:48
apwslangasek, but i say apply the upstream fix indeed18:48
MoPacHello; 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
ubot5Launchpad bug 1365378 in linux (Ubuntu Trusty) "[Regression] realtek pci-e card readers don't recognize mmc cards" [High,Fix committed]18:55
MoPacI've also tried the procedure at http://askubuntu.com/questions/492476/internal-sd-card-reader-not-mounted-detected-hp-realtek-rts5227 but to no avail18: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!