[00:08] <JanC> maybe we could set up a distributed test farm of machines spread all over the world, but then a lot of care should be taken that it is done in a very secure way (we don't want it to be taken over by a spammer or DDoS network or such!)   ;)
[00:09] <bjf> bug 640033
[00:09] <ubot2> Launchpad bug 640033 in grub-installer (Ubuntu) "maverick daily server iso (Sept. 15, 2010) fails to install grub on raided drive set (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/640033
[00:54] <melkor> I have been using the maverick backports lts kernel and today on an update it wouldn't fully install.
[08:42] <apw> melkor, that probabally means it has not been fully built in terms of linux, lbm, and meta, should sort itself shortly
[10:26] <lag> diwic: Hi
[10:27] <diwic> hi lag
[10:28] <lag> I need your help? 
[10:28] <lag> What's it like to be wanted? :)
[10:29] <diwic> lag, I like to help people :-)
[10:29] <lag> Have you heard of an sdp4430?
[10:30] <diwic> nope
[10:30] <lag> What about a twl6040?
[10:31] <diwic> nope
[10:31] <lag> sound/soc/omap/sdp4430.c
[10:32] <lag> sound/soc/codecs/twl6040.c
[10:32] <lag> The sdp4430 is an audio chip
[10:32] <lag> The twl6040 is a companion CODEC
[10:32] <lag> They are connected together on the Panda
[10:33] <lag> They used to be connected together on the Blaze
[10:33] <diwic> I haven't looked into the soc stuff at all, but there is a first time for everything, I suppose.
[10:33] <lag> Sound works on the Blaze, but not on the Panda
[10:33] <lag> I would like to know how to debug
[10:34] <apw> jjohansen, smb, i just became input only on mumble ... i can hear you but my machine X has hung ... ARGS
[10:35] <diwic> so no audio at all, right?
[10:35] <lag> Right
[10:36] <diwic> is the card detected? see /proc/asound/cardX and "aplay -l"
[10:37] <lag> I have two versions of the image
[10:37] <lag> One contains a few hacks - I'll send you the email
[10:38] <lag> Sent
[10:38] <diwic> lag, so you could either read my triaging class I had on IRC last Saturday
[10:39] <lag> Was that logged anywhere?
[10:39] <diwic> lag, or you could upload an alsa-info to canonical's pastebin and let me do it for you
[10:39] <lag> How do I do that?
[10:40] <lag> It is just a command line thing?
[10:40] <diwic> https://wiki.ubuntu.com/Audio/AlsaInfo
[10:41] <diwic> Triaging classes: http://irclogs.ubuntu.com/2010/09/11/%23ubuntu-classroom.html
[10:46] <lag> Okay
[10:46] <lag> Did you see those files I sent you?
[10:47] <lag> I'm not entirely sure what they set up
[10:47] <lag> Once applied to the image alsa-info provides this: http://paste.ubuntu.com/494653/
[10:47] <lag> I'll also run alsa-info on a system where the hacks aren't applied 
[10:47] <lag> diwic: --^
[10:47] <diwic> so regardless of hack or not, sound is not working?
[10:48] <lag> Correct
[10:48] <lag> For me at least
[10:48] <lag> I know someone with the same board that sound is working
[10:48] <lag> I'll ask him to send me his kernel, but he's not up until this afternoon
[10:50] <diwic> so the files there sets the mixer in specific ways
[10:52] <lag> Without them my Sound Preferences applet says "Dummy Output"
[10:52] <lag> With them it says SDP4430
[10:52] <diwic> that's probably the default.pa doing that, which opens the chip in a specific way
[10:52] <lag> Again, without them my volume icon in the panel is greyed out
[10:52] <lag> Okay
[10:55] <lag> This is how it looks without the files included: http://paste.ubuntu.com/494657/
[10:57] <diwic> I don't know much of those chips unfortunately
[10:58] <diwic> but you could try "speaker-test -c2 -Dhw:0,0" and see what happens
[10:59] <lag> Playback open error: -22,Invalid argument
[10:59] <lag> Oh, let me try the other image
[11:00] <diwic>  "speaker-test -c2 -Dhw:0,0 -F S32_LE -f 48000" ?
[11:00] <diwic> sorry
[11:00] <diwic>  "speaker-test -c2 -Dhw:0,0 -F S32_LE -r 48000" 
[11:01] <lag> Just booting
[11:01] <lag> Is there any way to ask the system which port it's playing the sound out of?
[11:02] <diwic> If you run "aplay -l", it should give you a list
[11:02] <diwic> is that the list you're looking for?
[11:03] <lag> I don't hear any sound from speaker test
[11:04] <diwic> so then there's probably something on the chip, e g routing-wise or mixer-wise that needs fixing
[11:05] <lag> The thing I don't understand is that the same configuration was used with the board's predecessor
[11:06] <lag> So aplay -l gives me a list of devices
[11:06] <lag> But the kernel must know which device/port it's attempting to play sound out of?
[11:06] <lag> On board speaker, headphone jack, aux, etc
[11:06] <diwic> and you can select which one in your call to speaker-test (-Dhw:0,x) where x is the number
[11:07] <lag> Each device is card0 - subdevices 1/1 - subdevice #1
[11:07] <lag> How do I differentiate? 
[11:07] <diwic> card 0: SDP4430 [SDP4430], device 3: Tone Playback null-codec-dai-3 [] 
[11:08] <lag> Oh card0 device0
[11:08] <diwic> = hw:0,3
[11:08] <lag> 0:3?
[11:08] <lag> Got it 
[11:08] <lag> Let me try
[11:09] <diwic> but it might also be that the outputs are controlled by either the mixer or some other magic in the driver
[11:09] <diwic> with "alsamixer -Dhw:0" you can fiddle around with the mixer settings
[11:12] <lag> Okay, leave it with me
[11:12] <diwic> okay, I'll go and have some lunch now
[11:47] <lag> diwic_lunch: speaker-test doesn't work on my desktop either?
[13:04] <diwic_lunch> lag: for speaker_test, try "plughw" instead of "hw"
[13:08] <lag> What does: "Sample format not available for playback: Invalid argument" mean?
[13:09] <lag> Setting of hwparams failed: Invalid argument
[13:39] <diwic> lag, so, your hardware only supports one or a few samplerates and sample formats (e g 16 bit signed, little-endian). If you use "hw" in your argument to speaker-test (or in default.pa, btw), it will use the format you specify and only that. If you use "plughw", there will be a plug layer added that converts the sample-rate and sample format for you
[13:40] <diwic> lag, so "Sample format not available for playback" means you tried to use a sample format the hardware does not support.
[13:41] <lag> With plughw:0,0 I get: Playback open error: -22,Invalid argument
[13:42] <lag> With plughw:0,8 it looks like it works, but it's actually silent and gets stuck on "0 - Front left"
[13:42] <diwic> lag, is that on the omap or on your desktop?
[13:42] <lag> omap
[13:42] <lag> When I use hw or plughw with 0,6 I get sound from HDMI
[13:43] <diwic> so if HDMI works, you're actually getting some kind of sound, that's good news I suppose
[13:48] <apw> that hdmi is on and nothing else is the inverse of most of our normal issues
[13:49] <diwic> apw, :-) 
[13:50] <apw> lag, on my lappy to get hdmi i have to switch 'hardware' on sound preferences
[13:50] <apw> r
[13:51] <apw> the profile on the hardware tab
[13:51] <diwic> apw, that's on the gnome/pulseaudio level. We're doing things at the ALSA level currently. But you have a point. lag, is PulseAudio running? 
[13:51] <diwic> lag, perhaps that's interfering with our tests.
[13:52] <lag> apw: There is nothing in the HW tab
[13:53] <lag> diwic: Yes it is
[13:53] <lag> As is gconf-helper
[13:53] <diwic> lag, try stopping it and see what that does for the tests ( https://wiki.ubuntu.com/Audio/StopPulseaudio )
[13:57] <lag> Still nothing
[13:58] <lag> [ 1361.951721] asoc: no valid backend routes for PCM: SDP4430 Media 
[13:58] <lag> I'm assuming that's bad
[14:00] <diwic> lag, I'm assuming likewise...
[14:01] <diwic> lag, I grepped the kernel tree for "backend routes" but couldn't find anything
[14:03] <lag> sound/soc/soc-core.c
[14:03] <lag> Near line 505
[14:03] <ogra> diwic, lag is talking about omap4, not omap ;)
[14:03] <ogra> (different tree)
[14:04] <diwic> okay, I was just checking sound-2.6.git
[14:05] <jdstrand> smb: hi. I haven't read my email yet but I wanted to mention that I'm here now to shuffle the security kernel along until kees comes online
[14:05] <jdstrand> smb: whenever you're ready
[14:07] <smb> jdstrand, The src package are all on chinstrap now, up to now I did only a regression test on lucid-amd64 and hardy-xen. More test kernels are either building or pending upload
[14:08] <smb> As the changes modify only compat stuff probably amd64 only test might be ok
[14:08] <smb> But maybe better do some i386 as well
[14:29] <tjaalton> jdstrand: you got one ready?
[14:29] <jdstrand> smb: so are these something I should upload to the security ppa?
[14:30] <jdstrand> tjaalton: no, smb is preparing them
[14:30] <tjaalton> jdstrand: ok
[14:30] <smb> jdstrand, If we want to speed up things we can upload them and should anything come up throw them away
[14:31] <jdstrand> smb: I think that would be a good idea. I had a glance at some of the upstream commits and they didn't seem too intrusive
[14:31]  * jdstrand goes to upload them
[14:32] <smb> tjaalton, I currently have them only on chinstrap. jdstrand would it be ok to place kernel packages somehwere open?
[14:32] <smb> jdstrand, Beside of breaking the build when backporting they seem to be ok. :-P
[14:33] <jdstrand> we can build them in the ubuntu-security-proposed
[14:33] <apw> ogasawara, about ?
[14:33] <jdstrand> smb: it's just the too issues that came up yesterday, right?
[14:33] <jdstrand> s/too/two/
[14:33] <smb> jdstrand, yes only those two
[14:33] <jdstrand> k
[14:33] <tjaalton> smb: do you have them for jaunty as well?
[14:33] <smb> tjaalton, yes
[14:34] <tjaalton> smb: excellent
[14:34] <jdstrand> give me a few minutes and I'll let you know they are uploaded
[14:34] <smb> jdstrand, issue #1 seems to affect all, issue #2 only jaunty-maverick
[14:36] <smb> jdstrand, Do you have an exploit for compat1?
[14:37] <jdstrand> I think mdeslaur came across one this morning
[14:37] <jdstrand> mdeslaur: did you play with it any yet?
[14:37] <jdstrand> mdeslaur: ^
[14:37] <apw> i suspec that is best discussed in private
[14:37] <jdstrand> apw: it is public
[14:37] <jdstrand> but we can go somewhere else
[14:37] <apw> heh but pointing people to the exploit just makes it even easier 
[14:38] <apw> the rest of the discussion is fine, just that one titbit
[14:38] <jdstrand> sure (though it was pointed out to us in another public channel), but I take your point
[14:38] <mdeslaur> smb: the exploit we have only works for RH, it would need to get all the ubuntu offsets added to it
[14:39] <jdstrand> mdeslaur: can you discuss in #security
[14:39] <mjg59> Everyone hates us :(
[14:39] <mdeslaur> haha
[14:39] <tjaalton> mdeslaur: the one "rh specific" exploit works fine on jaunty as well
[14:39] <tjaalton> confirmed here
[14:40] <mdeslaur> tjaalton: the one for issue #1?
[14:40] <tjaalton> mdeslaur: compat1, yes
[14:40] <smb> So they hate us too. :)
[14:40] <mdeslaur> tjaalton: oh, I need to try it then
[14:40] <mdeslaur> tjaalton: thanks
[14:41] <tjaalton> the patch didn't look ksplice'able.. :/
[14:41] <tjaalton> at least not trivially
[14:46] <jdstrand> smb: I'm guessing ogasawara is taking care of maverick?
[14:46] <smb> jdstrand, ack
[14:46] <smb> jdstrand, She already has uploaded
[14:50] <jdstrand> smb: can you respin 2.6.31-22? it has lucid-security for the distribution name
[14:50] <smb> jdstrand, doh
[14:50] <smb> jdstrand, yes
[14:50] <jdstrand> smb: thanks
[14:52] <jdstrand> smb: will there be new kernels for lucid arm?
[14:53] <smb> jdstrand, I believe kees agreed that we don't do them as this is 64bit only
[14:53] <jdstrand> smb: ok cool
[14:58] <tjaalton> smb: do you have an ETA for the debs?
[14:59] <smb> tjaalton, If they should come from sec-proposed jdstrand may have
[15:00] <tjaalton> smb: ok, thanks
[15:02] <jdstrand> smb: can you respin dapper? the upload was rejected: "The source linux-source-2.6.15 - 2.6.15-55.87 is already accepted in ubuntu/dapper and you cannot upload the same version within the same distribution. You have to modify the source version and re-upload."
[15:03] <smb> jdstrand, wtf, *sigh* yes 
[15:05] <jdstrand> hardy, jaunty and lucid are now in https://edge.launchpad.net/~ubuntu-security-proposed/+archive/ppa/+packages
[15:06] <jdstrand> smb: I think you meant to do this, but I want to be sure. 2.6.32-25.43 is in lucid-proposed, but we just uploaded 2.6.32-24.43 to lucid-security
[15:06] <smoser> apw, thanks for your help yesterday. bug 606373 is now fixed.
[15:06] <ubot2> Launchpad bug 606373 in plymouth (Ubuntu Maverick) (and 5 other projects) "cloud-init output does not get to console when booted with pv-grub and ramdisk (affects: 1) (heat: 10)" [Undecided,New] https://launchpad.net/bugs/606373
[15:06] <smb> jdstrand, Yes this one of all is intentional
[15:06] <jdstrand> hehe, cool
[15:06] <smb> jdstrand, I'll do a re-upload there asap
[15:07] <jdstrand> tjaalton: ^ sources are uploaded and building presently
[15:07] <tjaalton> jdstrand: yeah, getting them now, thanks :)
[15:08] <tjaalton> i've got 8 cores to build it on
[15:10] <apw> smoser, most excellent i like bugs that end 'fixed'
[15:10] <smoser> me too, especially *before* a freeze :)
[15:11] <apw> smoser, heh there is that, what was at fault in the end?
[15:11] <smoser> you can read the final 2 comments.  but basically i ended up adding 'console=hvc0' to the kernel command line.
[15:11] <smoser> that way plymouth repeats the data it stole to hvc0
[15:12] <smoser> if you dont have console= it doesn't repeat it for you.  there is no way i could see to tell it "please repeat it to /dev/console"
[15:13] <apw> smoser, i don't think it can repeat to /dev/console as it is stealing the output to there via an ioctl magic
[15:13] <apw> so it would self recurse to itsself if it pushed it into there
[15:13] <smoser> well, it unsteals it on exit
[15:13] <smoser> so it could buffer, unsteal, write
[15:13] <apw> smoser, ahh i see, yes it could do that 
[15:14] <smoser> but i guess that would generally be broken for its purposes of prompting and such
[15:15] <smoser> or, i guess, it could just not steal (I've read "You shall not steal." somewhere before)
[15:28] <jdstrand> smb: ok, dapper and karmic uploaded
[15:29] <ogasawara> apw: did you need something earlier
[15:29] <jdstrand> smb: now that they are building, I am going to let you and kees finish the testing/publication since I have a stack of mozilla updates I need to get out today. if you need me, holler
[15:29] <smb> jdstrand, ok sure
[15:29] <smb> jdstrand, Thanks for getting them building
[15:30] <apw> ogasawara, wondered if you remembered dropping some nouveau noaccel patches in maverick
[15:30] <ogasawara> apw: it's not ringing a bell
[15:31] <ogasawara> apw: but if they were there and are not now, then it likely happened
[15:33] <jdstrand> smb: sure, np :) I went ahead and updated the cve tracker marking maverick as released, dapper and hardy not affected by CVE-2010-3301, and everything else 'pending'
[15:33] <ubot2> jdstrand: ** RESERVED ** This candidate has been reserved by an organization or individual that will use it when announcing a new security problem.  When the candidate has been publicized, the details for this candidate will be provided. (http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2010-3301)
[15:35] <smb> jdstrand, most of it should have been in our branch of it. beside the maverick things
[15:35] <smb> jdstrand, at some point it might be good to merge them back
[15:36] <jdstrand> smb: ack
[15:47] <apw> ogasawara, ack will let you know the outcome of the patch testing
[15:48] <ogasawara> apw: looks like the archive will officially freeze at 1700 UTC
[15:48] <apw> ogasawara, hrm 
[15:48] <apw> i presume they ahve been waiting for the mesa/untity fixes
[15:49] <tgardner> ogasawara, so I still have time to upload ti-omap4 ?
[15:49] <diwic> so if I want to get a fix into libffado + udev within the next two hours, who should I bug about that? :-)
[15:49] <bjf> diwic: talk to the hand
[15:50] <diwic> bjf, the hand? If you mean myself, I'm not a MOTU.
[15:50] <apw> didn't think that was going to translate
[15:50] <tgardner> ogasawara, nm, mpoirier's patch is for maverick master
[15:50] <bjf> diwic: http://en.wikipedia.org/wiki/Talk_to_the_hand
[15:50] <ogasawara> apw: not sure, but it sounded like Daviey would appreciate a few extra mins to get a quick fix.
[15:50] <ogasawara> apw: so robbie said he'd hold off till 1700
[15:51] <ogra> nah,. robbie was bribed with a kettle full of beer it seems
[15:51] <apw> i can't see us wanting to spin master at this point either way
[15:51] <ogasawara> yah, I'd like to avoid a respin of master if we can help it
[15:52] <apw> the bug here is that macpros need noveau.noaccel to boot on the live CDs with this kernel, seems we dropped the fixes from lucid (likely resonably)
[15:52] <apw> so its release notable anyhow
[15:52] <apw> and i don't have confirmation that putting the patches back helps yet, so i can't even suggest we put it in
[15:53] <ogasawara> apw: doesn't cooloney or cnd have a macpro?
[15:53] <diwic> bjf, aha :-) Just like I thank my editor for "keeping tabs" instead of converting them to spaces...
[15:57] <apw> ogasawara, yeah ... strange neither of them has mentioned it
[16:05] <bjf> apw, are you sure they are dogfooding?
[16:06] <apw> bjf, likely not
[16:06] <tgardner> apw, I blasted HEAD on ubuntu-maverick-meta ti-omap4
[16:10] <apw> tgardner, ack
[16:12] <apw> tgardner, what did i do, push the tag and not the branch or something silly?
[16:13] <tgardner> apw, I homogenized the commit log entry and redid the tag
[17:07] <tgardner> JFo, bug chat?
[17:07] <JFo> ooh, yes
[17:07] <JFo> sorry was distracted
[19:01]  * tgardner lunches
[20:08]  * jjohansen -> lunch
[20:25]  * ogasawara lunch
[21:15] <vanhoof> does anyone know off hand the max memory ubuntu will support?
[21:15] <vanhoof> 10.10. specifically, i386+pae and amd64
[21:17] <tgardner> vanhoof, I don't think there is a practical upper limit, though PAE will incur some overhead.
[21:19] <vanhoof> tgardner: gotcha ... looking at a machine that can scale up to 192gb :)
[21:20] <tgardner> vanhoof, I have some amd64 servers with 132GB
[21:22] <jcrigby> tgardner, is there a way to override module checking for just one modules?
[21:22] <vanhoof> tgardner: cool, this would typically call for i386, which has me fearful 
[21:22] <achiang> vanhoof: unlike cpus, there's no hard coded limit in .config for memory
[21:23] <vanhoof> achiang: well im wondering max vs supported, along w/ factoring in this might require i386
[21:23] <vanhoof> i386 seems like a bad idea here
[21:23] <achiang> yes, i386 would be bad
[21:23] <tgardner> jcrigby, yep, lemme check.
[21:25] <tgardner> vanhoof, i386 is definitely a bad idea
[21:27] <tgardner> jcrigby, perhaps not. I was thinking perm-blacklist, but excludes symbols from the ABI check. Maybe you could just hack out the module name from the ABI module file?
[21:27] <tgardner> that excludes*
[21:28] <jcrigby> tgardner, the hack will work.  I had to move a driver from m to y
[21:28] <tgardner> jcrigby, you can always add an ignore.modules file
[21:29] <jcrigby> tgardner, maybe I'll just do that
[21:29] <tgardner> but that ignores the whole module check
[21:29] <jcrigby> tgardner, while I have you here I'll mention that I have a new kernel coming.  Just a sync with last ubuntu
[21:30] <jcrigby> I know the freeze is on so I'll let the important people figure out how to get it through
[21:30] <tgardner> jcrigby, ok.
[21:41] <ogasawara> jcrigby: https://wiki.ubuntu.com/KernelTeam/KernelMaintenance#Overriding module check failures
[21:42] <ogasawara> jcrigby: so I think if you create a modules.ignore file and add the name of the module to that file it should ignore it in the checks
[21:43] <jcrigby> ogasawara, thanks
[21:43] <jcrigby> ogasawara, ok dumb question do I put it in the new or old abi directory?
[21:44] <jcrigby> ogasawara, its got to be old right since new is generated
[21:44] <tgardner> jcryour new abi directory doesn't exisat until prepare time
[21:44] <lag> Has anyone else been taken into #ubuntu-unregged?
[21:44] <ogasawara> jcrigby: add it to the old
[21:44] <jcrigby> tgardner, ogasawara: ok thanks
[21:45] <smoser> anyone have thoughts : http://paste.ubuntu.com/494924/ (bug 567334)
[21:45] <ubot2> Launchpad bug 567334 in linux (Ubuntu) (and 1 other project) "blocked tasks delay cloud-init for 240 seconds (affects: 2) (heat: 31)" [Medium,Triaged] https://launchpad.net/bugs/567334
[21:46] <smoser> what could cause the "blocked for more than 120 seconds." messages ?
[21:47] <tgardner> smoser, a really high load average, or the host has an incorrect concept of time.
[21:47] <smoser> hm.. well, it isn't time being bad like skipping 120 seconds. its not htat bad.
[21:48] <tgardner> smoser, a really high load average?
[21:48] <smoser> i've seen it at boot on ec2, this is someone seeing it long after boot.  by design boot should be as high load average as possible, but doesn't normally last 120 seconds.
[21:49] <tgardner> smoser, if the hypervisor is over subscribed it might happen
[21:49] <smoser> well, yeah, i thought you might say that.
[21:49] <smoser> and of course a.) it *is* oversubscribed, and b.) theres nothing i can do about it.
[21:50] <smoser> but i just can't imagein its that over subscribeed, to where performance was unable to boot in 120 seconds or something.
[21:50] <tgardner> smoser, I assume your instance came up eventually and stopped puking in the log?
[21:50] <smoser> the times i've waited, yeah, ssh server eventually does come up
[21:51] <tgardner> smoser, have you reproduced this since your plymouth hack?
[21:51] <tgardner> console hack, I mean
[21:51] <smoser> personally no.
[21:51] <smoser> let me see if the person who just did today was using an image from today
[21:52] <tgardner> smoser, when these tasks recover its always been load related
[21:52] <tgardner> smoser, I can reproduce it on bare metal using 'stress'
[21:52] <smoser> hm..
[21:53] <smoser> so, the person reported it just now was running apache, ~ 30 minutes after boot, but not with console=hvc0 on cmdline
[21:54] <tgardner> smoser, thats more likely to have an impact at boot time.
[22:18] <ogasawara> tgardner: your lts backports kernel blueprint... can I postpone the "interlock with QA to set support levels" and the "investigate MIR" work items?
[22:19] <ogasawara> bah, I just missed him
[22:35] <kees> ogasawara: did maverick get smb's fixes for mlock + the new stack guard page?
[22:37] <ogasawara> kees: I believe so, http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-maverick.git;a=commit;h=1ccc5359a8f055b153a2e0cfec02a594a8443360
[22:37] <ogasawara> kees: ^^ that commit correct?
[22:37] <kees> looks like it, yeah
[22:37] <kees> weird. which build did that make it into?
[22:38] <kees> I'm running Ubuntu 2.6.35-20.29-generic 2.6.35.4
[22:38] <kees> and it seems to be failing
[22:39] <ogasawara> kees: I think it just got into the most recent, 2.6.35-22.32
[22:39] <kees> ah-ha! I will go reboot again
[22:39] <ogasawara> kees: as I recall he mentioned he had a last minute patch for me before freeze
[22:40] <kees> ogasawara: excellent.
[23:35] <undriedsea> Hey everyone, I am having trouble calling set_pages_rw (from <asm/cacheflush.h>) in my kernel module (I get Unknown symbol set_pages_rw). Does the kernel not export this function? Is there a way to find out what the kernel version of a kernel is exporting?
[23:37] <undriedsea> Should I just read the address for the function from System.mapxxx?
[23:49] <achiang> undriedsea: it sounds like you're writing an out-of-tree module?
[23:49] <undriedsea> yes
[23:49] <achiang> undriedsea: anyway, it also sounds like you shouldn't be using that API anyway, based on comments in the header file
[23:49] <achiang> and reading the address from System.map is a *really* bad idea
[23:49] <undriedsea> why is that?
[23:51] <achiang> undriedsea: in general, the kernel is specific about what it exports. if it's not exporting a symbol, there's usually a good reason for it, such as proper encapsulation, not wanting out-of-tree modules to become dependent on it, etc.
[23:51] <achiang> undriedsea: in any case, what's wrong with using set_memory_rw ?
[23:51] <achiang> that symbol is exported GPL
[23:52] <undriedsea> I am working on a project that requires my kernel module to modify the system call table. Since it is no longer exported, I was using System.map to find it and I was setting it to writable so I can make my modifications 
[23:52] <undriedsea> is it, let me double check something
[23:52] <mjg59> undriedsea: If you're working on something that wants to modify the system call table then you can implement it in any way you want - upstream is never going to approve
[23:52] <mjg59> There's no "correct" way to do it
[23:53] <achiang> right. i was thinking about how to say that... ;)
[23:53] <undriedsea> I have no intent of it getting accepted, I only want my end users to be able to load it
[23:54] <mjg59> You have no guarantee that any method you use will continue working with even minor kernel updates
[23:54] <mjg59> So just ship your end users a modified kernel
[23:54] <mjg59> It's the only way to be sure
[23:55] <undriedsea> really-- :( thanks
[23:55] <undriedsea> If I forgot to put MODULE_LICENSE ("GPL"); in my mod, would that by why  set_pages_rw was not working?
[23:55] <achiang> yeah, i guess just EXPORT_SYMBOL(set_pages_rw)
[23:56] <undriedsea> why is reading from the System.map a bad idea?