| snadge | latest saucy kernel wont do dual display on whatever ivy bridge intel chip is in this mac mini | 03:25 |
|---|---|---|
| snadge | latest mainline drm-intel-next .. does work | 03:26 |
| apw | snadge, what happens when you try to do that, and what is the bug # | 07:38 |
| * apw yawns | 07:42 | |
| snadge | apw: i didn't look for a bug number | 07:52 |
| snadge | which means if i did look for one.. and there wasn't one, i'd feel obligated to report the issue / look into it further | 07:54 |
| apw | snadge, with a bug of this nature (likely h/w related) it is best to file one yourself so we have that h/w info and let it be dupped to another bug if it is truly the same | 07:54 |
| snadge | its an ivy bridge cpu, i5.. mac mini late 2012 model | 07:55 |
| snadge | so its not anything special or unique.. hd4000 (i think).. im not at work to beable to confirm it | 07:55 |
| snadge | i went straight for an intel-drm-next nightly.. so I have no real information as to what actually fixes it, and what the actual problem is | 07:56 |
| snadge | im more motivated to help fix this problem.. than I am to help figure out a known and reported issue in fedora, that remains unsolved | 07:58 |
| snadge | which prevented me from installing it alongside OS X | 07:58 |
| apw | snadge, heh if it is a mac it is unique, likely different from even other macs of the same h/w revision; that is apple's way | 08:27 |
| apw | snadge, so if you file a bug against linux (ubuntu-bug linux) and put in that the fact you have tried a speciifc kernel, i'll ask our defect analyst to look at it, he can help you bisect for the actual fix | 08:28 |
| apw | (a specific kernel where it is fixed) | 08:28 |
| apw | if you get me the bug# i'll get it to them | 08:28 |
| snadge | apw: thanks .. that makes it really easy, i'll do that now | 09:20 |
| snadge | actually, it will have to wait until im at work tomorrow morning, I forgot to enable remote access | 09:23 |
| ppisati | http://paste.ubuntu.com/6239978/ | 10:33 |
| ppisati | may i have your opinion on this? | 10:33 |
| apw | whos | 10:33 |
| ppisati | there two things that i don't understandL | 10:33 |
| ppisati | 1) why a driver should add a device file (/bus/platform/devices/ahci) - that's the dtb work, the driver shall just find it and attach | 10:34 |
| ppisati | 2) why the hell it's calling itself?? a recursive probe? | 10:34 |
| apw | thats not a dtb path that is a sysfs path | 10:34 |
| apw | i assume something else is using the directory ahci in there, probabally the module (buiultin?) called ahci | 10:35 |
| apw | who would have the right after all | 10:35 |
| apw | i think i would expect a cirtain amount of self reference, as if it is a bus driver | 10:36 |
| apw | then it would 'add itsself' as a new bus, which would cause the bus to be scanned, whcih if it is the host provider on the bus would cause it to be called to probe the bus members it just added | 10:37 |
| apw | as remmber a module probe is a 'late' thing | 10:37 |
| apw | so we have to ask everything which might be near it to try and be probed again | 10:37 |
| apw | to see if the new driver which just loaded would attach to them | 10:37 |
| apw | so its all very circular | 10:37 |
| apw | and it is possible it is self locking on the ahci directory if they haven't handled that right | 10:38 |
| apw | ppisati, which tree is this | 10:39 |
| ppisati | apw: saucy | 10:39 |
| apw | master-next ? | 10:39 |
| ppisati | apw: yep | 10:39 |
| apw | is the machine usable when this happens at all | 10:40 |
| ppisati | drivers/ata/ahci_imx.c::imx_ahci_probe() | 10:40 |
| ppisati | apw: yes | 10:40 |
| apw | ie can you look at /sys to see if there is an ahci and who it belongs to | 10:40 |
| apw | ls -l /sys/bus/platform/devices/ahci | 10:41 |
| apw | and see what it belongs to | 10:41 |
| ppisati | apw: i think it belongs to the imx_ahci driver | 10:42 |
| ppisati | because | 10:42 |
| ppisati | in imx_ahci_probe() | 10:42 |
| ppisati | there's this call | 10:42 |
| ppisati | ahci_pdev = platform_device_alloc("ahci", -1); | 10:42 |
| ppisati | and that's the one that triggers the add of ahci etcetc | 10:42 |
| ppisati | you say that someone else already added thatd evice before, ok | 10:42 |
| ppisati | possible | 10:42 |
| apw | well i suspect we'll find that it was imx_ahci, but do check | 10:43 |
| apw | if so then we know it is self adding and not telling itself it did | 10:43 |
| ppisati | flag@linaro-ubuntu-desktop:~$ ls -la /sys/bus/platform/devices/ahci/ | 10:43 |
| ppisati | total 0 | 10:43 |
| ppisati | drwxr-xr-x 3 root root 0 Jan 1 1970 . | 10:43 |
| ppisati | drwxr-xr-x 4 root root 0 Jan 1 1970 .. | 10:43 |
| ppisati | -r--r--r-- 1 root root 4096 Oct 15 10:41 modalias | 10:43 |
| ppisati | drwxr-xr-x 2 root root 0 Oct 15 10:41 power | 10:43 |
| ppisati | lrwxrwxrwx 1 root root 0 Jan 1 1970 subsystem -> ../../../../bus/platform | 10:43 |
| ppisati | -rw-r--r-- 1 root root 4096 Jan 1 1970 uevent | 10:43 |
| apw | cat that uevent | 10:43 |
| ppisati | flag@linaro-ubuntu-desktop:~$ cat /sys/bus/platform/devices/ahci/uevent | 10:44 |
| ppisati | OF_NAME=sata | 10:44 |
| ppisati | OF_FULLNAME=/soc/sata@02200000 | 10:44 |
| ppisati | OF_COMPATIBLE_0=fsl,imx6q-ahci | 10:44 |
| ppisati | OF_COMPATIBLE_N=1 | 10:44 |
| ppisati | MODALIAS=of:NsataT<NULL>Cfsl,imx6q-ahci | 10:44 |
| apw | and is that the right driver, the one which barfed | 10:44 |
| ppisati | right | 10:44 |
| apw | then we can suppose that the driver can add it more than once... which its not meant to, and would be a bug | 10:45 |
| ppisati | apw: let me test one thing | 10:45 |
| ppisati | two other kernels that i saw around, compile this as =y instead of =m as we do | 10:50 |
| ppisati | and indeed, compiling this as =y, avoid the problem | 10:50 |
| ppisati | i'll send an email upstream bot it | 10:50 |
| apw | ppisati, ack | 10:51 |
| ppisati | but IMO it's a bug | 10:51 |
| apw | its definatly a bug | 10:51 |
| ppisati | and another question at thsi point would be: why compiling it in doesn't make it happen? | 10:52 |
| ppisati | uhm | 10:52 |
| apw | ppisati, ordering is differnet | 10:52 |
| apw | and init is differnet, so we will init the modile much much earlier, so there are no devices to probe | 10:52 |
| apw | and do the probe 'later' | 10:52 |
| ppisati | right | 10:53 |
| * ppisati -> lunch | 11:46 | |
| === kentb-out is now known as kentb | ||
| tjaalton | apw: bah.. looks like I need some fixing to do :/ | 14:21 |
| tjaalton | need/have | 14:21 |
| apw | tjaalton, for ? | 14:23 |
| tjaalton | apw: build error due to the recent quantal pull | 14:23 |
| tjaalton | worked fine for raring, must have missed something (like, a build test..) | 14:24 |
| apw | tjaalton, *slap* | 14:27 |
| apw | that doesn't exactly inspire confidence it has even been tested | 14:28 |
| tjaalton | well, HAS_DDI was added to 3.8.13.1, quantal's ubuntu/i915 hasn't been updated past 3.8.13 | 14:29 |
| tjaalton | should I do that too? | 14:30 |
| tjaalton | eh, 57 changes | 14:31 |
| tjaalton | probably not | 14:31 |
| tjaalton | 56 | 14:31 |
| tjaalton | *commits | 14:31 |
| === psivaa is now known as psivaa-afk | ||
| apw | heh ... i think ot | 14:39 |
| apw | not | 14:39 |
| apw | tjaalton, so should i rip these off here again | 14:40 |
| tjaalton | apw: maybe so | 14:43 |
| * ppisati goes out for a bit | 14:44 | |
| tjaalton | or add 26c2b3a4e572263 from v3.8 stable | 14:44 |
| apw | tjaalton, sigh | 14:46 |
| tjaalton | though it's trivial to change the patch too | 14:46 |
| * apw rips the second fix | 14:47 | |
| apw | so you can get a pair to gether which have been tested | 14:47 |
| tjaalton | thanks | 14:47 |
| tjaalton | i'll sort it out tomorrow | 14:47 |
| tjaalton | but, in theory, shouldn't it be ok to sync it with the stable tree? | 14:48 |
| apw | yeah if it is in there we will get it without help when stable do their next syn | 14:49 |
| apw | sync | 14:49 |
| apw | but, i'll not step on their toes on that, so you can either wait on that or include it in your replacement | 14:50 |
| apw | its too near saucy release to keep too much state in my brain :) | 14:50 |
| tjaalton | heh, ok | 14:50 |
| tjaalton | noones syncing the quantal ubuntu/i915 though | 14:50 |
| apw | no indeed, we assume people will be getting new shiney from later kernels | 14:52 |
| rtg | apw, so we can ignore the raring pull request for i915_hsw also ? | 14:52 |
| apw | or that you will be sending us shiney new updates | 14:52 |
| apw | tjaalton, has that raring one been tested ? | 14:52 |
| tjaalton | rtg: that should work, though you can hold off on that too | 14:52 |
| tjaalton | apw: yeah, raring got that extra commit via stable already | 14:52 |
| tjaalton | i'll build test both tomorrow though to be sure.. | 14:53 |
| rtg | tjaalton, ok, I'm happy to ignore you in the mean time :) | 14:54 |
| * rtg goes back to firmware issues | 14:54 | |
| jsalisbury | ** | 14:59 |
| jsalisbury | ** Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting | 14:59 |
| jsalisbury | ** | 14:59 |
| === psivaa-afk is now known as psivaa | ||
| tjaalton | rtg: feel free :) | 15:24 |
| jsalisbury | ## | 16:55 |
| jsalisbury | ## Kernel team meeting in 5 minutes | 16:55 |
| jsalisbury | ## | 16:55 |
| === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 15th, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| jsalisbury | Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 22nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | 17:07 |
| === jsalisbury changed the topic of #ubuntu-kernel to: Home: https://wiki.ubuntu.com/Kernel/ || Ubuntu Kernel Team Meeting - Tues October 22nd, 2013 - 17:00 UTC || If you have a question just ask, and do wait around for an answer! | ||
| === fmasi is now known as fmasi_afk | ||
| rtg | apw, have you tried todays ISO on an EFI system ? am having some trouble getting it to reboot. It worked fine last week. | 18:38 |
| apw | rtg .... hmm not the iso, i have the current kernel on, well this ctual machine | 18:41 |
| apw | actual | 18:41 |
| rtg | it booted well enough, but its not really a good experience | 18:45 |
| rtg | hmm, must be lunch time | 18:45 |
| bjf | rtg, i'll try it on my macbook air | 18:50 |
| rtg | bjf, yeah, this is a gigabyte MB. it behaves odd sometimes. | 18:52 |
| infinity | We had a lubuntu tester claim that amd64+mac wouldn't reboot post-install for him too. | 19:07 |
| infinity | Could be the same thing. | 19:07 |
| infinity | Given that amd64+mac is EFI by definition. | 19:07 |
| bjf | infinity, will know shortly. installing right now | 19:07 |
| infinity | If it's kernel-related, we're pretty much too late to fix it anyway. | 19:08 |
| infinity | https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1238836 | 19:09 |
| ubot2 | Launchpad bug 1238836 in ubiquity (Ubuntu) "System does not reboot after installation" [Undecided,Confirmed] | 19:09 |
| infinity | Oh, then someone else piggybacks with a similar bug with i386. | 19:09 |
| infinity | Which wouldn't be EFI. | 19:09 |
| infinity | So, that's unhelpful. | 19:09 |
| rtg | mine reboots normally thereafter | 19:10 |
| bjf | infinity, mine install and boots just fine. couple minor issues: 1. indicator garbage during install (mouse over made it go away); 2. No "please remove your install media and hit return" message seen. (i just waited, hit return and it did the right thing); 3. Upon first bootup and log in i got a crash with indicator-datetime-service. | 19:13 |
| infinity | So, your number 2 could be what others see as a failure to reboot. | 19:14 |
| bjf | infinity, could be | 19:14 |
| rtg | I'm guessing thats right | 19:14 |
| infinity | If it's not actually a reboot failure but rather just the usual recurring "reboot message doesn't show because $reasons" bug, we might be able to find a fix for that. | 19:23 |
| infinity | Could one or both of you follow up to that bug with your experience(s)? | 19:23 |
| infinity | bjf: The two indicator bugs are pretty unlikely to be addressed for release. Hoping the crash gets SRUed, though. | 19:24 |
| bjf | infinity, bug comment added | 19:30 |
| infinity | bjf: Danke. | 19:30 |
| brendand | can anyone tell me why/when 'Extended CMOS Year' is printed? | 19:55 |
| brendand | is it on resume? | 19:57 |
| apw | brendand, is that the exact string, and what series | 20:08 |
| brendand | Extended CMOS year: 2000 | 20:11 |
| brendand | and i'm using saucy | 20:11 |
| apw | infinity, that not saying "please remove" thing, mostly in my experience is saying it on vt1 but not switching there | 20:11 |
| apw | bjf, when it happened did you still have graphics on the screen instead of VT1 | 20:11 |
| bjf | apw, no, i was on VT1 (i think) no graphics | 20:12 |
| snadge | yesterday I was asked to report a bug for the linux package.. im at work now on the affected machine | 23:47 |
| snadge | can i report the bug whilst using the mainline kernel that doesn't have the bug? .. or should i reboot into the affected kernel | 23:47 |
| snadge | which means i lose my second display .. i guess temporarily | 23:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!