[00:00] <Specialist> there must be something i am mising. everything is set up as per the tutorials i read, but still the last kernel message that ends up on the serial console is:
[00:00] <Specialist> [   27.571317] EXT4-fs (dm-2): mounted filesystem without journal. Opts: (null)
[00:01] <Specialist> then follows silence until i reboot, which is again indicated on the console: [ 1762.680197] Restarting system.
[00:03] <BenC> Specialist: are you sure there are actually kernel messages to be printed?
[00:03] <Specialist> yes, i can see them using dmesg
[00:03] <BenC> Perhaps the console level for kernel messages is set to mask them being sent to the console?
[00:03] <BenC> Is "quiet" on the kernel command line?
[00:04] <Specialist> BenC: no, quiet is not on the command line
[00:04] <BenC> Check printk level for console output then
[00:05] <BenC> Read and edit /etc/sysctl.d/10-console-messages.conf
[00:13] <Specialist> BenC: it's 4 4 1 7 - what would i need to specify if i wanted to see all messages (googling did not help to figure this out - most hits just list the defaults)
[00:14] <BenC> Specialist: http://www.makelinux.net/ldd3/chp-4-sect-2.shtml
[00:14] <BenC> Section 4.2.2 and the line above it where you "echo 8 > ..."
[00:15] <BenC> Specialist: So changing the values to 8 should do it
[00:15] <Specialist> thanks!
[00:15]  * BenC found that with google
[00:16] <Specialist> BenC: just out of curiosity: what were your search terms?
[00:16] <BenC> linux kernel printk console level
[01:32] <ogasawara> skaet: alpha3 to beta1 blurb added for the kernel section in the TechnicalOverview wiki, will add the more substantial Maverick to Natty blub in a bit.
[01:32] <skaet> ogasawara, awesome.  thanks!
[01:42] <beata|lemur> Howdy hi. Encryption question: How do I tell if pcrypt is actually being used? I don't seem to see it in ps, and the module use count is 0.
[07:40] <fairuz> hi morning
[07:42] <fairuz> hi, is it a problem if i got a compiled kernel with -dirty behind it's name? I already did make clean but no luck, still it adds -dirty.
[07:42] <ohsix> it just means you changed it
[07:44] <fairuz> ohsix: what do you mean by changed? afaik, if you do make clean, the dirty will go away
[07:55] <jjohansen> fairuz: do you have uncommitted changes?  That can cause the dirty tag to be applied
[07:55] <fairuz> jjohansen: of course! why i dont think of that before
[07:57] <fairuz> jjohansen: what is the command to reset again (i tend to forget everything). something like git reset --hard master?
[07:57] <jjohansen> fairuz: to reset the head git reset --hard origin/master (if on the master branch)
[07:57] <jjohansen> fairuz: git checkout -f will throw away uncommitted changes
[07:58] <fairuz> jjohansen: cool, ty
[08:15] <fairuz> jjohansen: still bug hunting?
[08:15] <jjohansen> fairuz: not at the moment, but I do have several queued up
[08:17] <fairuz> jjohansen: i suppose it's very time consuming? Seen that you and DrDetroit did test a lot of kernels
[08:17] <jjohansen> fairuz: yeah it can be, it just depends on the bug
[08:19] <DrDetroit> hehe i should turn off my sound when I am napping
[08:19] <DrDetroit> or mark myself away i guess
[08:32] <fairuz> DrDetroit: oh sorry :D
[08:33] <DrDetroit> fairuz: don't worry about it, you did nothing to apologize for
[11:30] <jjohansen> rebooting
[12:25] <ppisati> how long does it take to move from master-next to master?
[14:10] <Specialist> hi there, my struggle to figure out what is breaking s2ram for my machine on 2.6.38 continues. i got a serial console working. unfortunately, during suspend the serial console output changes to garbage (with no_console_suspend enabled) rather early during the suspend phase so that i cannot read the most interesting information. is this to be expected?
[14:22] <jjohansen> Specialist: it can happen, some further ideas might be found at
[14:22] <jjohansen> https://wiki.ubuntu.com/DebuggingKernelSuspend
[14:22] <jjohansen> https://wiki.ubuntu.com/DebuggingKernelSuspendHibernateResume
[14:26] <Specialist> jjohansen: thanks! i have to say that i have read those documents already a couple of times ;-) the only untested hypothesis that remains is the possibility of a kernel panic during suspend. i guess a usb keyboard will not indicate that event by flashing the keyboard led as usb will probably already be down, right?
[14:27] <jjohansen> Specialist: ugh, yeah usb keyboard making the flashing led trick less than useful
[14:27] <jjohansen> or less useful
[14:28] <Specialist> well, then it's time to resurrect my ps/2 keyboard ;-)
[14:49] <Specialist> yesterday someone also mentioned storing debug information in the cmos using the rtc. instead of using the current time (causing the information to decay) wouldn't it make sense to set a (disabled) alarm with the intended payload instead? that data should not decay...
[14:50] <ohsix> Specialist: theres actually in practice lots of places to store that information, but the rtc is the lowest common denominator
[14:51] <Specialist> ohsix: are you aware of any code sample that i may re-use?
[14:55] <ohsix> Specialist: don't know what you're doing, i just saw the rtc comment and something about debugging suspend
[14:57] <Specialist> ohsix: i am trying to figure out why my system sporadically freezes during s2ram. i alreadt tried serial console, but that becomes corrupted during suspend. so i thought that i'd modify the rtc state using a bitmask to record certain checkpoint information during the suspend phase
[14:59] <sconklin> ppisati: thanks for verifying your bug!
[15:00] <ohsix> Specialist: i used netconsole
[15:02] <Specialist> ohsix: the thing is that for me the suspend fails so low-level that the rtc may be the only device that will still work reliably at that time
[15:02] <diwic> Specialist, I think the kernel uses the upper bits only and you have a few minutes only to read the information out of the rtc when you boot up again
[15:04] <Specialist> ohsix: well, that's ok for me. i just spotted the implementation in drivers/base/power/trace.c, which seems like a good starting point for my debug code
[15:12] <fairuz> Hi, when compiling a external module, can I specify the output folder for *.ko file? I use this right now to compile : make ARCH=$(ARCH) CROSS_COMPILE=$(CROSS_COMPILE) -C $(KERNEL_SRC) M=$(PWD) modules
[15:16] <jjohansen> fairuz: O=
[15:16] <jjohansen> but its not just the output folder for the .ko its all object files
[15:18] <sforshee> fairuz, have you tried using using MOD_INSTALL_PATH with make modules_install ?
[15:19] <sforshee> e.g. 'MOD_INSTALL_PATH=/foo make modules_install'
[15:19] <fairuz> sforshee: I'm compiling __a__ module
[15:19] <fairuz> an external one
[15:20] <sforshee> fairuz, yes, but what does it do if you run that from your module's source dir? I don't know, but might be worth trying
[15:21] <fairuz> sforshee: it will install the modules from the source tree not my module :D
[15:21] <fairuz> jjohansen: already tried that before but no luck
[15:22] <sforshee> fairuz, that's too bad
[15:22] <jjohansen> fairuz: hrmm, it should work I know I have used it with external modules, mind you that was years ago
[15:26]  * ogasawara back in 20min
[15:28] <fairuz> jjohansen: that's why..i wonder myself whhy it didn't work.
[15:31] <sforshee> fairuz, I just tried it and it did work
[15:31] <fairuz> sforshee: what did you try?
[15:32] <sforshee> make -C /path/to/kernel M=$(pwd) INSTALL_MOD_PATH=/path/to/modules modules_install
[15:32] <sforshee> fairuz, that installed my module to /path/to/modules
[15:33] <fairuz> sforshee: it will install just the external module? and not the other kernel modules?
[15:33] <sforshee> fairuz, yes
[15:34] <sforshee> fairuz, note that if you use a relative path it will be relative to the kernel source directory, not your module source dir
[15:36] <fairuz> sforshee: it will just move the files or it will compile and move the files
[15:37] <jjohansen> fairuz: it should set the compiler to write the files to the target location
[15:37]  * jjohansen has used it in the past for source trees that were read only
[15:40] <fairuz> I use this -> make ARCH=arm CROSS_COMPILE=arm-none-linux-gnueabi- -C /home/x0152532/kernel-src M=/home/x0152532/remote-x0152532/tools/caches/pl310 INSTALL_MOD_PATH=/home/x0152532/remote-x0152532/tools/caches/pl310/bin modules_install
[15:40] <sforshee> jjohansen, fairuz, just using the modules_install target didn't build for me, I had to do the modules target as well
[15:40] <fairuz> and it installs lib/modules directory in my target folder
[15:40] <fairuz> and no sign of my own modules
[15:41] <sforshee> fairuz, see my comment above, you'll have to do a 'make modules' first
[15:41] <sforshee> in my testing anyway
[15:41] <sforshee> and that will build to your local directory
[15:41] <sforshee> unless you use O=...
[15:41] <fairuz> sforshee: done that
[15:43] <sforshee> fairuz, don't know what to say, it installs my module
[15:43] <fairuz> sforshee: in your case, it did not install /lib/modules/kernel-name in your target folder?
[15:44] <sforshee> fairuz, no, it does create lib/modules/..., and installs the module there
[15:44] <fairuz> sforshee: ah ok i got what you mean
[15:44] <sforshee> fairuz, if you want something different I guess you could make a custom target in your local makefile
[15:45] <fairuz> sforshee: it puts the module in /lib/modules/kernel-name/extra/*
[15:45] <sforshee> fairuz, yes
[15:46] <fairuz> sforshee: hmm not really what i want actually.. 
[15:46] <fairuz> I'm searching something like target-folder/mymodule.ko
[15:47] <sforshee> fairuz, that may be the only thing the kernel makefile provides
[15:47] <bjf> ##
[15:47] <bjf> ## Ubuntu Kernel Team Meeting - Today @ 17:00 UTC - #ubuntu-meeting
[15:47] <bjf> ##      agenda: https://wiki.ubuntu.com/KernelTeam/Meeting
[15:47] <fairuz> sforshee: there's O= too but unfortunately, it didn't work for me..will dig it out later
[15:48] <fairuz> sforshee: jjohansen: btw, thanks for helping
[15:48] <sforshee> fairuz, iirc O= puts all the build targets in that dir, which probably isn't what you want anyway
[15:48] <sforshee> fairuz, np
[15:49] <fairuz> sforshee: that's ok for be. As long as the source folder is clean :)
[15:49] <fairuz> *me
[15:56] <fairuz> jjohansen: if we make a package, it will create headers, image, and src package automatically ? 
[15:56] <fairuz> or there is some work to do by hand
[16:02] <jjohansen> fairuz: make a package how?
[16:02] <fairuz> *.deb files
[16:03] <fairuz> jjohansen: something like this https://launchpad.net/ubuntu/+source/linux-ti-omap4/2.6.38-1204.5/+buildjob/2313441
[16:03] <jjohansen> fairuz: hrmm, I'm sure what you are doing to build, a package can create each of those
[16:04]  * jj-afk steps away for 20
[16:04] <fairuz> jjohansen: (i'm not really want to create packages, but just to fill my curiousity =))
[16:17] <tgardner> ogasawara, do you remember if bug #630748 was on skaet's radar last week?
[16:17] <ubot2> Launchpad bug 630748 in linux-firmware "iwlagn degrades quickly during normal wifi session" [High,Confirmed] https://launchpad.net/bugs/630748
[16:17] <ogasawara> tgardner: it was
[16:18] <tgardner> ogasawara, great, thanks.
[16:19] <sforshee> tgardner, for the eeepc-wmi backports, is it best to base the branch for the pull request off of master-next ?
[16:19] <tgardner> sforshee, that works, but its not critical.
[16:20] <sforshee> tgardner, yeah, there probably aren't any differences between master and master-next for that file, I was just wondering
[16:21] <sforshee> thanks
[16:21] <tgardner> sforshee, the advantage of using master is that it gives you a stable merge point, whereas master-next often gets rebased. however, small pull requests aren't that hard to figure out.
[17:03] <ppisati> sconklin: you are welcome :)
[17:30] <bjf> ##
[17:30] <bjf> ## Kernel team meeting in 30 minutes
[17:30] <bjf> ##
[18:13] <maks_> dudes your meeting is finished before one has time to follow it
[18:14] <maks_> wanted to raise debian drm tree sync
[18:14] <maks_> :P
[18:14] <maks_> 2.6.32.y-drm33.z.git misses some of our stuff.
[18:15] <ogasawara> smb: ^^
[18:16] <smb> maks_, Ah yes
[18:16] <smb> I think it was mentioned that you had some drm things. Do you have a git tree I can pull from?
[18:17] <maks_> yes mirror didn't change
[18:18] <maks_> http://git.debian.org/?p=kernel/linux-2.6.git;a=summary
[18:18] <bjf> maks_, you can always request to get something on the meeting agenda
[18:18] <maks_> I was just to slow and got distracted in middle of the meeting, thanks bjf 
[18:18] <smb> maks_, Thanks, I was about to ask cause I tend to forget
[18:18] <bjf> maks_, if you blink, we are gone
[18:26] <maks_> ok cool.
[18:56] <bjf> ogasawara, the April 14 freeze date, is that when you'll upload or the last day we put changes into the repo ?
[18:57] <ogasawara> bjf: ideally, we'll make no changes to the kernel past that date, which means we'd have to upload ~2days prior for the builds to finish by the 14th
[18:57] <ogasawara> bjf: we can still apply changes, they'll just be subject to SRU
[18:57] <ogasawara> bjf:  but there's no guarantee that those changes will warrant another upload
[18:58] <bjf> ogasawara, right, i'm just thinking that one way of thinking is that the code is actually frozen on the 12th
[18:58] <ogasawara> bjf: yep
[19:33] <JFo> headset died
[19:45] <JFo> thanks pgraner :)
[19:47] <JFo> <-need food
[20:49]  * jjohansen -> lunch
[21:16] <tgardner> kees, sconklin, I think we're OK to release Hardy. HPPA LBM hasn't built since 2.6.24-19.17 (2008-10-27). Clearly nobody cares.
[21:16] <sconklin> tgardner: bwahahaha ok
[21:16] <sconklin> why haven't we seen  the fails indicated in the PPA builds?
[21:17] <tgardner> sconklin, this should _never_ have taken me so long to figure out. maybe I need ritalin.
[21:17] <tgardner> sconklin, https://launchpad.net/ubuntu/+source/linux-backports-modules-2.6.24/+publishinghistory
[21:18] <sconklin> well, now we know whether anyone cares
[21:19] <tgardner> sconklin, as it turns out, compat-wireless has never built on HPPA. dunno why we didn't notice it in c-k-t PPA. I'll upload a new package here in a bit.
[21:19] <tgardner> my test build on wongi seems to be completing
[21:35] <tgardner> sconklin, [PPA canonical-kernel-team] [ubuntu/hardy]	linux-backports-modules-2.6.24 2.6.24-29.41 (Accepted)
[21:36] <sconklin> ok, lbm builds fast, so we should know soon
[21:36] <tgardner> sconklin, I'll check back in a couple hours.
[21:36] <sconklin> no hurry I think
[21:55]  * ogasawara back on later
[22:12] <beata|lemur> Oh hey guys. I don't suppose there's a way from the user side to tell if pcrypt is doing its job? Or, does it need to be loaded *before*?