| === ben_r_ is now known as ben_r | ||
| ejat | apw: i've updated to 4.8.0-17-generic , but still no luck for the ntfs rw | 02:30 |
|---|---|---|
| apw | ejat, reviewing configs, i cannot see when we had that turned on ... it looks like writability of ntfs was actually done via a fuse filesystem, which is unrelated to the kernel, so that is confusing | 07:14 |
| ricotz | hi, regarding https://wiki.ubuntu.com/Kernel/FAQ#Kernel.2FFAQ.2FGeneralUbuntuDelta.What_differentiates_the_Ubuntu_Kernel_from_the_upstream_Linux_Kernel.3F | 07:23 |
| ricotz | it seems wrong to included commits and tags like https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/?id=1d074db69c46d62ce82b331c2080e2fcb710bf4a | 07:23 |
| ricotz | and using a "ckt" suffix would be more appropriate to reflect the nature of the kernel in its version string | 07:24 |
| ricotz | wrong commit, I meant this one https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/xenial/commit/?h=master-next&id=b536d9ae195f9daa32cf2446df2a35787142cacb | 07:24 |
| apw | ricotz, that is really a matter of taste to a large degree, that kernel has the vast majority of the stable 4.4.21 and its predecessors applied | 07:29 |
| apw | ricotz, so is it wrong for its internal version strings to include that information | 07:29 |
| apw | ricotz, it exposes its version in uname more like 4.4.0-36-generic #19-Ubuntu so you can tell it is an ubuntu build and track it back | 07:31 |
| ricotz | apw, imho, it is wrong while it suggests it is based on the full 4.4.x stable release | 07:31 |
| ricotz | this stable release version is exposed in logs though | 07:31 |
| apw | ricotz, well the vast majority are applied so ... its pretty close, and it it was literally rebased on that and we reverted the delta it would be fine to call it that ? | 07:32 |
| ricotz | apw, imo, yes | 07:32 |
| apw | ricotz, as i say, i think you can make arguement either way, and indeed we have internally, but we feel that calling a kernel which has all of 4.4.21 applied 4.4.0 would be more inaccurate | 07:32 |
| apw | ricotz, well i'd argue as those bits on disk would be identicle it is wrong to say one way of making it can be called 4.4.21 and the other not | 07:33 |
| ricotz | what I am saying if someone it hit by a bug which an unapplied patch is triggering, it would be more painful to find out | 07:33 |
| ricotz | s/triggering/fixing/ | 07:34 |
| apw | ricotz, i can't deny that if we have dropped any there is a very slight possibility of people making assumptions rather thna actually checking what is applied | 07:35 |
| apw | i actually do not think we have in 4.4 so far, we tend to drop them because they are already applied "early" rather than anything else | 07:35 |
| ricotz | right, so using the ckt suffix to some extent would be it a bit more clear | 07:35 |
| apw | the kernel advertises itself as -Ubuntu pretty strongly in the only real place we emit "loose dumps" of data, which is oops output | 07:36 |
| apw | most any other collection of data is attached to system information | 07:37 |
| ricotz | (I for myself assumed it would get all stable-release patches until now) | 07:37 |
| apw | and that is the plan, aim and normally the execution | 07:37 |
| apw | i have i think twice in recent memory seen a patch dropped for being already applied, and oobviously we have reverted a couple of actually broken patches | 07:38 |
| apw | before they got fixed in -stable, but that seems like a positive | 07:38 |
| ricotz | it might not hurt so much for non-lts kernels, but for the 4.4 lts with 5 year support those dropped patches might pile up | 07:38 |
| apw | you know ubuntu is not a pure upstream kernel, no distro kernle is, there is always delta | 07:39 |
| apw | having the 4.4.21 information tells you at least waht it is closest to in mainline terms, not including that just | 07:39 |
| apw | means you have even less idea what it is similar to | 07:39 |
| ricotz | I am aware of that, I am just arguing about the advertised base-kernel | 07:39 |
| ricotz | I see | 07:40 |
| apw | and you are arguing it should be 4.4.0 | 07:40 |
| ricotz | no, I am not ;) | 07:40 |
| apw | ok then you need to be clearer in what you are arguing :) | 07:40 |
| ricotz | I mentioned to add some "ckt" suffix | 07:40 |
| apw | and where do you want that, given we have a -Ubuntu suffix in the primary output userspace can ask for | 07:41 |
| apw | and do keep in mind that we cannot completley arbitrarily mangle the version format | 07:42 |
| apw | because _stupid_ userspace tools assume it is at least 3 dotted numbers, _and_ others assume they can just | 07:42 |
| ricotz | like https://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux/+git/trusty/commit/?id=a4e4e7cac5f9fcf4368ad5d22ac96285290562fc | 07:42 |
| apw | use the string as a directory name in the filesystem | 07:42 |
| apw | extraversion does not make it into the names exposed in the packaging, that is set in some of the older kernels | 07:43 |
| apw | and you won't see it, because htat is where the abi number is | 07:43 |
| apw | i guess we could put -ckt in the Makefile itself, but you'd never see it anywhere else | 07:43 |
| ricotz | I know the kernel package name doesnt reflect the micro version | 07:45 |
| ricotz | ok, I guess I will have to live with it ;) | 07:46 |
| apw | ricotz, i'd like to remove the .0 there and expose the real micro in the binary packages, but that keeps slipping | 07:46 |
| ricotz | apw, I see, that makes sense | 07:52 |
| apw | we got into this .0 mess because userspace tooling is broken in the format assumptions so like ps would vomit if you made the built in version shorter | 07:52 |
| ricotz | apw, oh, I assumed it was made that way to cope with "real" ABI breaks regarding dkms modules | 08:00 |
| apw | the name of the abi directory isn't so critical as long as it changes when the abi changes | 08:01 |
| apw | (and only ...) | 08:01 |
| ejat | apw: so its conclude not coming from Kernel issue/problem? | 08:15 |
| ejat | any suggestion how can i debug or get logs from ? | 08:16 |
| apw | ejat, right now i believe that if it is a kernel issue it is not what i would have thought, as that fucnionality is marked dangerous and turned off | 08:16 |
| apw | ejat, in all releases. it was pointed out to me that we used a fuse job to access ntfs r/w | 08:17 |
| apw | not quite sure how that triggers | 08:17 |
| ejat | apw: i think i found some clues .. http://paste.ubuntu.com/23240235/ | 08:22 |
| ejat | i have suspected windows partition .. but i already full shutdown n restart | 08:23 |
| ejat | n off the fast restart | 08:23 |
| apw | oh a good point, i wonder if with new never shutting down windows you can ever mount it r/w safely from outside | 08:24 |
| ejat | or maybe some updates/patches for Windows 10 Fast Ring Insider | 08:24 |
| ejat | but its work previous in LTS :( | 08:25 |
| apw | it does not seem possible we could modify the filessytem is windows is hibernated | 08:26 |
| apw | as it could have any of that data cached in memory and changing it would be fatal to the filesystme | 08:26 |
| ejat | but i've tried to disable the Fast Startup | 08:27 |
| ejat | maybe the cache is not cleaned yet ... | 08:28 |
| apw | probabaly windows has reneabled it because you would be daft to not use it (in its mind) :) | 08:36 |
| ejat | lol ... u got a point .. im clearing off the cache in the disk n will try again shortly | 09:03 |
| ejat | apw: sorry to bothering u this few days ... finally rw work again after i clear the partition cache and disable the fast startup + shutdown | 09:34 |
| apw | ejat, awsome that it is now working | 09:34 |
| ejat | but its kinda weird that i doesnt have to do that way previously as i can just reboot when ever i want to choose etiher ubuntu or windows | 09:35 |
| ejat | i doesn't need to disable the fast startup in 16.04 lts ... n its work flawlessly without proper shutdown (just only reboot will do the job to switch between OS) | 09:36 |
| apw | that can only be broken to my mind, if windows is hibernated what is on disk cannot be changed safely ever | 09:36 |
| apw | so something else must have changed, and i am willing to believe that windows changed something to be "faster" | 09:37 |
| ejat | :) | 09:39 |
| ejat | btw, thanks again .. im also thinking that there is "something" changed in windows ... as i use the fast insider ring | 09:40 |
| === maxb_ is now known as maxb | ||
| manjo | rtg, EDAC_MM_EDAC=m therefore EDAC_GHES is not selected, EDAC_GHES is needed on arm64 v8.0+ for firmware first error handling of memory and CPU errors .. would you consider a patch to enable that for Y ? | 13:43 |
| manjo | apw, ^ | 13:43 |
| rtg | manjo, file away... | 13:43 |
| manjo | rtg, thanks | 13:43 |
| apw | manjo, we're close enough to freeze now that we should have a bug for that and send the patch to the list, as it will likely need two acks etc as if it were an sru | 13:50 |
| manjo | apw, will open a bug and send it to ukml | 13:50 |
| manjo | apw, bug against package "linux" ? | 13:54 |
| manjo | apw, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1628111 | 13:56 |
| ubot5 | Ubuntu bug 1628111 in linux (Ubuntu) "[Yakkety] enable EDAC_GHES in kernel config" [Undecided,New] | 13:56 |
| apw | manjo, yes, and i assume you referenced that in the patch | 14:02 |
| manjo | apw, yes . just letting you know I have the bug ☺ | 14:02 |
| apw | oh don't worry i have wiped all knowledge of it | 14:02 |
| manjo | apw, config.common.ubuntu:CONFIG_HAVE_ACPI_APEI=y but when I do edit configs for arm64 it is not selected .. why is that ? | 14:37 |
| manjo | apw, it is depend is ACPI=y which is true | 14:37 |
| manjo | apw, nm I see why | 14:43 |
| apw | configs are fenicety is normally the reason | 14:43 |
| === PaulW2U_ is now known as PaulW2U | ||
| _ami_ | any pointers on why i get this warning messages sometimes when i send urbs for IN/OUT endpoint? | 15:13 |
| _ami_ | WARNING: CPU: 1 PID: 2866 at /build/linux-a2WvEb/linux-4.4.0/drivers/usb/core/urb.c | 15:13 |
| _ami_ | :338 usb_submit_urb+0x51/0x70() | 15:13 |
| _ami_ | [ +0.000002] URB ffff8801fd3ef780 submitted while active | 15:13 |
| _ami_ | i send interrupt IN & OUT whenever a sysfs file value is changed | 15:14 |
| apw | _ami_, as that is a WARN_ON i assume it has some hints at that line to say what it thinks you are doing wrong | 15:14 |
| _ami_ | apw: it seems like i am resubmitting a urb which is yet to be used.. | 15:16 |
| apw | reusing the same buffer perhaps ? | 15:16 |
| _ami_ | apw: indeed, it was the case. | 15:17 |
| _ami_ | just fixed :) | 15:17 |
| _ami_ | i was doing submitting interrupt in urb on _probe() too. just removed that code. now doing Interrupt in/out on device attribute setter function. :) | 15:18 |
| rtg | manjo, is that CONFIG_EDAC_MM_EDAC patch for Xenial or Yakkety ? | 15:23 |
| manjo | rtg, for Y | 15:23 |
| manjo | rtg, oops did I miss that | 15:23 |
| manjo | rtg, the bug report says Y .. | 15:23 |
| rtg | manjo, 'cause I set it | 15:24 |
| manjo | rtg, ok thanks .. sorry about that my patch should have said Y as well | 15:24 |
| _ami_ | apw: which is FASTER? creating and reusing control/bulk/interrupt urbs to send/recv data? or helper functions like usb_control/bulk/interrupt_msg()? i tend to believe that reusing same urb everytime is FASTER. just wonder why people use helper functions quite often? | 15:35 |
| _ami_ | people are LAZY or its just does not matter much? | 15:36 |
| apw | reusing it is only safe if you can be sure it will never get queued etd | 15:36 |
| apw | etc | 15:36 |
| === daniel1 is now known as Odd_Bloke | ||
| apw | helpers tend to stop you making mistakes like reusing them too early | 15:36 |
| _ami_ | aha, sync vs async dilemma | 15:37 |
| apw | right, async is normally better when you have lots of data | 15:37 |
| apw | and knowin when the urb has gone is error prone | 15:37 |
| _ami_ | got it., thanks, noted down. | 15:38 |
| rtg | manjo, I responded to your patch with an alternate. I'm not too keen on munging Kconfigs | 15:39 |
| manjo | rtg, trying your patch as we speak.. | 15:40 |
| rtg | manjo, thanks | 15:41 |
| manjo | rtg, it does not select EDAC_GHES | 15:41 |
| manjo | rtg, for that you also need to satisfy select HAVE_ACPI_APEI if ACPI in Kconfig. | 15:42 |
| rtg | manthen you really need 2 patches, a SAUCE patch to fix the Kconfig, and a patch to update the config settings. | 15:43 |
| rtg | manjo, ^^ | 15:43 |
| manjo | rtg, ok will resend | 15:43 |
| rtg | manjo, I expect that you'll want to upstream the Kconfig patch | 15:44 |
| manjo | rtg, right that is next | 15:44 |
| manjo | rtg, ah that patch for APIE in kconfig went upstream in Jul | 15:53 |
| manjo | rtg, https://lkml.org/lkml/2016/7/27/427 | 15:53 |
| manjo | rtg, wonder why it is missing in Ubuntu | 15:53 |
| rtg | manI assume you are basing this off of Yakkety master-next ? It has been rebased against 4.8-rc8 | 15:54 |
| rtg | manjo, ^^ damn tab completion | 15:54 |
| manjo | rtg, let me reclone my tree.. it is a cf right now | 16:08 |
| rtg | manjo, you shouldn't have to reclone. 'git fetch origin master-next;git reset --hard FETCH_HEAD" | 16:08 |
| manjo | rtg, that is what I did and it blew up on my face | 16:09 |
| manjo | rtg, recloning as we speak | 16:09 |
| rtg | manjo, how did it blow up ? | 16:09 |
| apw | git fetch origin master-next doenst make sense those are all remote names | 16:09 |
| manjo | apw, git fetch master-next; git rebase master-next ? | 16:12 |
| apw | git fetch origin; then maybe a rebase yes | 16:13 |
| apw | but if the upstream is rebasing which it is you need to be more careful | 16:13 |
| apw | and use --onto | 16:13 |
| === daniel is now known as Guest11181 | ||
| === Guest11181 is now known as Odd_Bloke | ||
| === Elimin8r is now known as Elimin8er | ||
| === Serge is now known as Guest37289 | ||
| === xnox_ is now known as xnox | ||
| === leftyfb_ is now known as leftyfb | ||
| === sforshee` is now known as sforshee | ||
| === Elimin8r is now known as Elimin8er | ||
| === Guest37289 is now known as hallyn | ||
| === ben_r_ is now known as ben_r | ||
| === eichiro_ is now known as eichiro | ||
| === kees_ is now known as kees | ||
| === spossiba_ is now known as spossiba | ||
| === sforshee` is now known as sforshee | ||
| === ghostcube_ is now known as ghostcube | ||
| === mamarley is now known as Guest12142 | ||
| === mamarley_ is now known as mamarley | ||
| === sts is now known as Guest67929 | ||
| === PaulW2U is now known as Guest66500 | ||
| === PaulW2U_ is now known as PaulW2U | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!