[03:02] <qwer> anyone here know a crapload about linux drivers?
[03:02] <qwer> I'm fairly knowledgeable, but I've a problem that no on in any other channel has been able to help me solve for about 2 weeks
[03:02] <qwer> anyway, I'll just tell the story, mysteriously ubuntu 10.04 detects the sata_mv driver properly - as well as an old slackware install cd - I've tried about a dozen recent and current distros though - and even after mod probing sata_mv -> no block devices found.......I've no idea how to continue troubleshooting - I've messed with udevadm, modprobe, etc
[03:13] <qwer> this has taken many hours out of my life, so I'd be happy to paypal anyone money if they help me fix it
[03:14] <jk-> so 10.4 does work?
[03:15] <jk-> (and what sata controller(s) do you have?)
[03:19] <qwer> this is the hercules II by Marvell, supposedly great linux support, uses sata_mv kernel module
[03:19] <jk-> so you have the module loaded, but no block devices?
[03:20] <jk-> (and could you paste the output of: lspci -n | grep 11ab
[03:21] <qwer> okay let me boot and try again
[03:23] <qwer> you want me to do this with one that is working, or the huge majority that arent?
[03:23] <jk-> well, what are you trying to do? :)
[03:24] <jk-> (get 9.10 working? or something else?)
[03:24] <qwer> 43:01.0 0100: 11ab:6081 (rev 09)
[03:24] <qwer> I'm just trying to install, but none of the distros that will install recognize my hardware/show block devices/modprobe sata_mv, etc
[03:25] <qwer> 42:01* sorry
[03:25] <jk-> so you're not keen just to install 10.4 ?
[03:25] <qwer> it barely works
[03:25] <qwer> and I'm not going to be using on the server anyway
[03:25] <jk-> ok
[03:25] <qwer> I just have no idea why it works
[03:25] <qwer> I'd love to figure that out, as I've been trying to get this computer (a box that needs this controller to see disksS) to work for weeks
[03:26] <jk-> so what are you planning to install on this?
[03:26] <qwer> arch
[03:26] <qwer> does it matter?
[03:27] <qwer> you have any ideas?
[03:27] <qwer> I'll install whatever you want if you can get something to install
[03:28] <lifeless> qwer: install 10.4 then :) it works 
[03:28] <qwer> not really, too beta, lots of other problems, this is a server, I don't know WHY it works, same could be said for the fairly old slack disks that for some reason sees/configures the sata properly too
[03:29] <jk-> looks like that device has been supported for quite a while; most recent distros should have it
[03:29] <qwer> indeed, I've read all about that - supposedly awesome linux support - that is why I paid another 100 dollars for a sata controller after the first had terrible support
[03:30] <qwer> I've done a crap load of troubleshooting, maybe if you can aide me with a bit more, I can find out why it isnt
[03:30] <jk-> so maybe boot 9.10, wait 'till it drops to the initramfs shell and we can do some digging
[03:30] <qwer> I've been digging for weeks, im stuck
[03:30] <RAOF> You could also pass “break=mount” to the kernel command line.
[03:30] <qwer> did that lspci give you any ideas?
[03:30] <RAOF> If it works in Lucid, does it work in all new kernels?
[03:30] <jk-> it just tells me which device you have
[03:31] <qwer> is that the same as hercules II sata controller?
[03:31] <jk-> no idea about the names
[03:31] <qwer> oh, what is 11ab then?
[03:31] <jk-> marvell's vendor ID
[03:31] <qwer> oh
[03:31] <qwer> well give me some other stuff you want readouts on, maybe it will give you some ideas
[03:32] <jk-> would be good to get it booted to a shell on a broken system
[03:33] <qwer> i am
[03:33] <qwer> thats how i got that readout, heh
[03:34] <jk-> so `ls /sys/block/` gives nothing?
[03:52] <qwer> omfg, it might have started to work for no reason at all, maybe the hardware is flakey - I'm checking a few things (amazing since I've been messing with this for weeks)
[03:57] <qwer> k, I rebooted and tried the 64bit kernel, now there's no 11ab, hopefully it wasn't a fluke and the 32 sees it again
[03:58] <qwer> bam, the 32bit kernel works - wow
[04:48] <qwer> okay, hdparm says buffered disk reads are 2.5mb/sec?!
[04:48] <qwer> jk-, I seem to have got it working though - and it seems to be a 64bit kernel bug, since only the 32bit works 
[04:49] <qwer> i think i was mostly trying 64bit kernels at first
[04:49] <qwer> and those two that works miraculously were 32bit
[05:02] <twb> When booting lucid kernels, vga16fb is loaded by default.  How do I stop this?  None of video=vga16:off, video=vga16fb:off, vga=normal and nofb worked.
[05:02] <twb> I can't reproduce this issue on sid.
[10:03] <qwer> Wholy fucking shit - a bios update fixed EVERYTHING! And I've been using this hardware for 4 years...
[10:05] <twb> "Holy"
[10:07] <qwer> dude, this occasion calls for a serious misspelling
[10:07] <qwer> I am flabbergasted
[10:07] <twb> As you will
[10:07] <qwer> As you are, sir
[10:07] <qwer> I've been using this system for 4 years, and this mysteriousness took days out of my life
[10:07] <qwer> little did I know could this be tracked back to a bios update
[10:09] <twb> AHS
[10:09] <qwer> always have sex?
[10:09] <twb> All Hardware Sucks
[10:09] <qwer> ahhh
[10:09] <qwer> makes a bit more sense
[10:10] <qwer> where is that from, and what do they say about softare?
[10:10] <qwer> software*
[10:10] <twb> ASS
[10:10] <twb> It's from the monastery
[10:20] <matti> :]
[10:25] <twb> DNA is their third mantra.
[10:29] <qwer> I wish I got your joke
[10:29] <twb> Down, not across.
[10:30] <qwer> because I'm in a great mood now
[10:30] <qwer> lol
[10:30] <matti> qwer: ;]
[10:30] <twb> http://www.faqs.org/faqs/sysadmin-recovery/
[10:33] <twb> I was reading the ITS tourist policy today, and I ran across "Use the :LUSER command to tell other users that you need help" or so.  It was a nostalgic moment, I can tell you.
[14:49] <lool> apw: is there time for another linux upload before A3?
[14:50] <lool> apw: (It would be great to have working initrd support with versatile in A3; currently it's busted)
[14:54] <lool> I'm tentatively milestoning this as "Low" importance for A3; it's not dramatic if we miss the target  ;)
[15:01] <apw> lool, i suspect i won't get a linux upload in, as i have so many arm ones pending which have key bugs in
[15:07] <lool> apw: I understand, thanks either way
[16:15] <apw> smb, this trigger-happy patch set ... whats the gen there, is this already in karmic or something?
[16:16] <smb> apw, No, its not even upstream. (see cherry-picked from linux-next)
[16:16] <smb> I just happen to be sort of involved in the development and we got testing
[16:19] <apw> ahh so this is fixing a real bug ... for a real user of ours ... ok
[16:20] <smb> apw, Yeah, hard to say how many. But there seem to be people out there capable to operate joysticks with more than 15 buttons
[16:20] <smb> You could consider it as a regression even
[16:20] <apw> i don't normally play games which require me to take off my socks
[16:20] <persia> Good day.  I notice that all the kernel uploads get reported to the ubuntu-mobile mailing list.  I wondered why there, and not to ubuntu-devel.  I would think it would be of more general interest.
[16:20] <smb> As we fixed something else which broke it
[16:20] <persia> smb: I have at least four joysticks that have > 15 buttons if you need to test something.
[16:21] <apw> persia, they get reported to the teams which  have asked for specific reports
[16:21] <persia> apw: Would it improve your workflow to only have to report to the one team (ubuntu-devel@) ?
[16:21] <apw> i'd actually expect most people who really cared to get the email via the lucid-changes list ... crtainly i do
[16:21]  * persia suspects it would improve other workflows
[16:21] <apw> ubuntu-devel is pretty noisy ... i suspect the installer would want it sent to them specifically regardless
[16:21] <smb> persia, Only if beyond 30 or so. (Saitek X52) 
[16:22] <persia> I have one of those :)
[16:22] <persia> My first patch ever to Ubuntu was to make it work with vegastrike, even :)
[16:22] <smb> persia, Then in should have stopped being detected since Karmic (as a joystick) ;-)
[16:22] <persia> I don't have the X52 Pro though (it has 2 more buttons)
[16:23] <persia> smb: It worked in Karmic, at least for some of the buttons.  I used it for some testing with input-utils for a user.
[16:23] <persia> But I didn't try *all* the buttons.
[16:23] <persia> Can we make it work again?
[16:23] <apw> now i know you have one, never :)
[16:23] <persia> There are some keyboards that are implemented as joysticks internally, and have >60 buttons.
[16:23] <smb> Thats two patchs I was proposing for Lucid
[16:24] <persia> smb: Please subscribe me to the bugs if you like, and I'll confirm behavioural changes.
[16:25] <persia> For Saitek, I have the X52 and Strategic Commander, which both exhibit fairly odd characteristics for "joysticks".
[16:25] <persia> But most of my joysticks/controllers are more pedestrian.
[16:25] <smb> The bug was/is bug 492056
[16:25] <ubot3> Malone bug 492056 in linux "Saitek X52 Joystick does not work" [Medium,Triaged] https://launchpad.net/bugs/492056
[16:26] <smb> There is a test kernel linked. Though I probably have a hard time keeping up with newer Lucid kernels
[16:27] <persia> smb: So you need a retest for each kernel release?
[16:29] <smb> persia, I believe the one test is enough. If you had the same problem, the joystick would not have been detected as a joystick (joydev) as the number of buttons made it include BTN_DIGI and digitizers were blacklisted not to be joysticks
[16:29] <persia> And presumably you need testing with all classes of unusual device (so left-hand gamepad keyboards, super joysticks, etc.)
[16:30]  * persia laughs at repeated BTN_TRIGGER_HAPPY
[16:30] <smb> It makes the people with many triggers happy :)
[16:30] <persia> So, won't this break for stuff like keyboards with integrated joysticks that require both mappings?
[16:31] <persia> Or like the Nostromo n52Pro which is a joystick and a mouse and a keyboard?
[16:32] <smb> persia, Would those not have the normal keys as keys and only joystick buttons as buttons. Well, if you got time you are welcome to try that test kernel with all your odd devices
[16:32] <smb> As far as I understand the code, the additional mapping is only done for class joystick buttons and that seems to be part of the hid descriptor
[16:33] <persia> smb: Depends on the device.  The Saitek Strategic Commander is special in that it implements them all as joystick buttons in hardware.
[16:34] <persia> I don't have a Microsoft Sidewinder Commander though, which would probably be the ultimate test for this.  It had enough buttons (implemented as joystick buttons) that people used it as a typing input device.
[16:34] <persia> smb: Is there a lucid test kernel available?  I'm only seeing karmic listed in the bug.
[16:35] <smb> Doh, never underestimate hw developers crazieness. The test kernel is actually lucid
[16:35] <smb> Looks for the link to my people page
[16:35] <persia> Found it.
[16:35] <persia> I just saw comments about it being karmic.
[16:35] <persia> I'll give that a test tomorrow.
[16:35] <smb> Cool, thanks.
[16:36] <persia> And please feel free to poke me if you need any sort of joystick testing.  I have a collection, and care about them working (although I don't use them as much as I'd like to have time to do)
[16:37] <smb> Sure, now that I know. Atm, its the only problem I am aware of
[16:38] <persia> Well, there's also an issue with how we're mapping joysticks with /dev/jsN and /dev/eventN, but that's a userspace bug (which I hope to find time to fix before lucid release).
[16:39] <persia> And there's an issue with the joystick X input driver that certain devices get reversed axes.
[16:39] <persia> And ...
[16:39] <persia> (but it's all userspace)
[17:00] <ricotz> hello, anyone here willing to answer a question?
[17:02] <ricotz> i have a clean updated lucid install, and the cpu fan working normal on cold boot, when rebooting the fan spins up but doesnt spin down while lucid booting up, this is no temperature problem
[17:02] <ricotz> so i think this should be a kernel problem
[17:03] <ricotz> it is a hp 2510p notebook
[17:30] <crimsun> apw: RE: hda_beep.c patch proposed for lucid, I concur that it appears (according to the git trees on zinc) that enabled = 1, but that means that the changelog entry for 2.6.28-13.44 is actually incorrect.
[17:30] <crimsun> apw: and indeed, I can find no actual git history of the patch being applied to sound/pci/hda/hda_beep.c in smb's jaunty or the ubuntu-jaunty trees.
[17:31] <crimsun> which probably would explain why it was never applied to karmic
[17:32] <apw> crimsun, so the odd thing is that karmic doesn't have beep = 0 and yet the beep was not in karmic and appears in lucid so somethign else has changed... what i don't  know
[17:32] <crimsun> apw: there was that whole libgnome mess in karmic to disable the system beep, but that's just one very small part
[17:33] <crimsun> but the root of this particular issue is that the patch seems to never have been applied
[17:46] <apw> ok so i'll get with smb to try and find out what the heck happened there
[17:47] <smb> apw, Hmmm...
[17:55] <apw> crimsun, what are you seeing in the 13.44 changelog?  i see no mention of diabling beep
[17:57] <crimsun> [ Luke Yelavich ]
[17:57] <crimsun>   * disable CONFIG_SND_HDA_INPUT_BEEP on amd64 and i386
[17:57] <crimsun>     - LP: #331589
[17:58] <apw> hrm
[17:58] <apw> ahh thats -12.43
[17:59] <apw> crimsun, so that is a config change, not a code change
[18:00]  * apw goes find out why the config change is undone
[18:00] <crimsun> ah, thanks
[18:00] <apw> it seemed to be undone in karmic ... and we didn't seem to have the whining there we have in lucid ... hrm
[18:02] <crimsun> perhaps beep was unmuted somehow and simply got saved as part of the state
[18:02] <apw> well we tend to unmute everything under the sun on installing a new kernel
[18:02] <apw> at least thats my experience ... i have always assumed that was userspace doing that
[18:04] <crimsun> I'll chase up the alsa-utils end; we don't use alsactl init 
[18:04] <apw> ok cool ...
[18:05] <crimsun> eventually all this cruft in /sbin/alsa-utils needs to be converted over to /usr/share/alsa/init/*
[18:09] <apw> crimsun/smb, i have this vague memory of turning it off in jaunty, then we put it back in karmic cause something in userspace was making sure Pc Beep was muted, and i think themuso was involved in that ... buts its a long time ago
[18:10] <smb> Maybe that was when it was muted by something else and replaced by another sound. At least I don't seem to have that beep. Or maybe it needs a boot to textmode without gnome
[18:16] <apw> smb, good thought ... there it is on VT-1
[18:16] <apw> hit backspace on the shell and BZZZT
[18:20] <crimsun> heh. If you have a 'Beep' mixer element, see amixer get 'Beep'
[18:21] <crimsun> ( ->  amixer set 'Beep' 0% mute )
[18:21] <apw> crimsun, yeah this is actually a different bug ... the vile beep i have here is changing volume when the mixer goes up and down
[18:21] <apw> previously it would change frequency from vile deepness to ear splitting high
[18:21] <smb> Strange- Seems I got one that does a beep but is not silent on 0...
[18:22] <apw> so i think we have a new bug ... pc beep really makes a nasty fart noise
[18:22] <apw> and i think this is relativly new
[18:22] <smb> Here hda(alc268) it seems to work
[18:24] <apw> yeah and mine is hda(Intel GM45 something something)
[18:24] <apw> and is not well
[18:27] <crimsun> ick, we're missing the beep consolidation that's in 2.6.33
[18:32] <crimsun> namely, http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=123c07aeddd71fbb295842a8c19866e780b9a100 and its follow-on fixes 13dab08, 5f81669, 411fe85, 54f7190)
[18:34] <smb> Looks "slightly" invasive
[18:36] <crimsun> yeah, I don't think it's really all that useful for the release kernel given that there are cod alsa-driver builds for people really wanting it
[18:39] <crimsun> apw: / smb: anyhoo, thanks for looking closer
[18:40] <apw> crimsun, np.  i think we want to get whoever had the original issue to file a bug so we get the alsainfo off them
[18:40] <apw> then we can try and find the codec which is affected, i suspect its the intel own codecs currently
[19:00] <philsf> crimsun, I had a disconnection yesterday before getting your answer on my USB problem ( http://pastebin.com/f489fcdd0 ). you said something about driver or hw, and I think it's not hw. how can I test if if it's a driver issue?
=== Hedge|Hog is now known as Hedgehog
=== Hedgehog is now known as Guest42436
=== KB1JWQ is now known as PancakeStaffer
=== PancakeStaffer is now known as KB1JWQ
[20:09] <TheMuso> apw: It was turned off in jaunty, then a configs/packaging metadata shuffle re-enabled it again.
[20:24] <tgardner> apw, lbm_nouveau appears to be working on my Dell w/nVidia, but I was a bit surprised to get an LBM package without selecting it.
[20:47] <lifeless> tgardner: 
[20:47] <lifeless> CONFIG_TASK_DELAY_ACCT not enabled in kernel - do you know anything about this? 
[20:47] <lifeless> it was on in karmic, but is off in lucid