[04:20] <John> Here it goes. Please excuse me if I offend you. It is not my intent.
[04:21] <John> For a long time kernel devs have been ignoring users.
[04:21] <John> I believe they simply don't care. If for a year there
[04:21] <John> has been an OPEN SOURCE drivers for the LARGEST laptop
[04:21] <John> manufacturer with millions of computers sold with this
[04:21] <John> particular hardware and at least 20 versions of kernel
[04:21] <John> since, where does that leave us?
[04:21] <John> Here it goes:
[04:21] <John> Here are the OS drivers that are available:
[04:21] <John> http://www.ralinktech.com/en/04_support/support.php?sn=501
[04:21] <John> The drivers I mean are:
[04:21] <John> RT539x PCIe 	09/26/2011 	2.5.0.3
[04:21] <John> Our lspci -k:
[04:21] <John> Network controller: Ralink corp. RT5390 [802.11 b/g/n 1T1R G-band PCI Express Single Chip]
[04:21] <John> Kernel driver in use: rt2800pci
[04:21] <John> Kernel modules: rt2800pci
[04:21] <John> These ARE NOT GOOD. They work, but are designed for other Ralink hardware.
[04:21] <John> They have bugs.
[04:21] <John> For the above module it should be the OS drivers from the above website.
[04:21] <John> They are OPEN SOURCE and AVAILABLE!
[04:21] <John> The RT5390 PCI is in shit loads of HPs laptops. Shit loads of!
[04:21] <John> And the hardware is great! The drivers for Windows are awesome!
[04:21] <ohsix> uh, no
[04:21] <John> And the drivers for Linux have been available for a long long time!
[04:21] <John> And yet WE ARE IGNORED for shit load of kernel versions, shit loads
[04:21] <John> of versions! WTF?!
[04:21] <John> PS. You have to probably blacklist some other shitty drivers like:
[04:21] <John> gksudo leafpad /etc/modprobe.d/blacklist.conf
[04:21] <John> # Blacklist conflicting RaLink driver modules:
[04:21] <John> blacklist rt2800pci
[04:21] <John> blacklist rt2800lib
[04:21] <John> blacklist rt2x00usb
[04:21] <John> blacklist rt2x00pci
[04:21] <John> blacklist rt2x00lib
[04:21] <John> blacklist rt2860sta
[04:22] <John> oh, no?
[04:22] <ohsix> this isn't even the right place for that, if there was a place to flood a screed
[04:22] <ohsix> do you think the linux wireless people don't know of, or have a real reason to not include those drivers?
[04:22] <John> oh yeah not the place, just another FU user! You are nice as those kernel devs who care more about google and android than users!
[04:23] <ohsix> you don't know what you are talking about
[04:23] <ohsix> if you presume to put yourself in the place of a person who can make that decision, decide to use the driver yourself and forget about the actual people who are
[04:24] <John> there has been at least 20 versions and they ignored us. I don't simply understand why android is more important than us.
[04:25] <John> They always cry that there are no drivers, but there are and even Open Source. In a moth there will be a YEAR!
[04:26] <ohsix> if you post that every time, i'm not surprised you are ignored; you are not ignored
[04:26] <ohsix> you aren't even asking the right people, in this case
[04:26] <John> ?
[04:26] <ohsix> further, you assume the people who decide these things have no other reason to not do it, besides ignoring you
[04:27] <John> I only care about resaults. The resault is NO DRIVER.
[04:27] <ohsix> if you only care about results then you can't factually say that you have been ignored, as you have made no obvious attempt at actually meeting your goals
[06:48] <ppisati> moin
[07:47] <smb> morning
[07:48] <ppisati> brb
[07:48] <ppisati> moin Stefan :)
[07:50] <smb> ppisati, Morning Paolo. Right back within one second. Not bad. :)
[10:08]  * ppisati goes out for a bit
[10:24] <oumpa> hello, on my samsung laptop, xubuntu 12.04 the screen-brightnes-control with fn keys was working with kernel 3.2.0-23 and after update to 3.2.0-27 there is only low light and bright, nothing in-between and the notification (with the sun) doesnt appear anymore
[10:24] <oumpa> what can i do?
[10:24] <oumpa> to fix this?
[10:29] <oumpa> the grub entries are the same, just the kernel changed, semms to be a bug of 3.2.0-27
[12:41] <apw> oumpa, if you were still here i would suggest fileing a bug and testing the kernels in between from launchpad to see which broke it
[13:29]  * rtg delivers vehicle for maintenance
[14:46]  * ogasawara back in 20
[15:51] <jeremiah> I'd love to have the AF_BUS patch added to the kernel for the i.MX53 QSB. 
[15:51] <jeremiah> Should I submit that to Linaro? Or is there somewhere in Ubuntu I should ask?
[15:52] <ogra_> linaro ... 
[15:52] <jeremiah> Okay, thanks
[15:52] <ogra_> since the kernel package for mx5 is maintained by them
[16:18] <ogra_> ogasawara, thx for the update !
[16:19] <ogasawara> ogra_: np 
[16:45] <rtg> kees, finally! http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=800179c9b8a1e796e441674776d11cd4c05d61d7
[16:56]  * ppisati takes a break...
[17:07] <rtg> tyhicks, re 3.6-rc1 'The write-through cache changes are being reverted due to bugs...' - should we be backporting those patches ?
[17:10] <tyhicks> rtg: Probably so
[17:10] <tyhicks> rtg: I didn't feel comfortable marking them for the stable kernel just yet because I haven't had a chance to look at the backport
[17:10] <rtg> tyhicks, ack
[17:11] <tyhicks> rtg: I was going to speak with cking about it because he is mostly familiar with the bugs caused by the reverted code
[17:11] <rtg> tyhicks, I think he's on vacation for a couple of weeks
[17:11] <tyhicks> (he wrote a test case for one of them)
[17:11] <tyhicks> oh
[17:12] <rtg> tyhicks, prolly for the empty files case ?
[17:13] <tyhicks> rtg: Nope. The biggest problem is that ENOSPC can't be detected at the correct time to return from write().
[17:13] <rtg> ah
[17:14] <tyhicks> rtg: So userspace thinks everything is fine and may keep writing but eCryptfs can't detect a full lower filesystem until the page writeback is performed.
[17:15] <rtg> tyhicks, wouldn't an unlayered FS have the same problem ?
[17:15] <tyhicks> rtg: No, because they are able to do internal tracking of available space
[17:33]  * smb -> EOD
[17:42]  * rtg -> lunch
[18:00]  * ppisati goes out for some chinese food
[19:36] <rtg> ogasawara, pushed quantal master-next to fix 'II: Checking modules for generic...
[19:36] <rtg>    reading new modules...read 3474 modules.
[19:36] <rtg>    reading old modules...
[19:36] <rtg>       MISS: aufs
[19:36] <rtg>       read 3475 modules : new(0)  missing(1)
[19:36] <rtg> EE: Missing modules (start begging for mercy)
[19:36] <rtg> ma'
[19:36] <ogasawara> rtg: ah, thanks
[19:37] <rtg> ogasawara, am working through recent ecryptfs updates to see what might be SRU worthy.
[19:37] <ogasawara> rtg: ack
[19:40] <tyhicks> rtg: Sorry, I'm now seeing that I forgot to set the "Cc: stable@..." tag on any of the patches in my last pull request
[19:40] <tyhicks> rtg: Let me get you a list of what I think is SRU-worthy
[19:40] <rtg> tyhicks, that would be great, thanks.
[19:40] <tyhicks> 821f749 eCryptfs: Revert to a writethrough cache model
[19:40] <tyhicks> e3ccaa9 eCryptfs: Initialize empty lower files when opening them
[19:41] <tyhicks> 8bc2d3c eCryptfs: Unlink lower inode when ecryptfs_create() fails
[19:41] <tyhicks> 069ddcd eCryptfs: Copy up POSIX ACL and read-only flags from lower mount
[19:41] <tyhicks> rtg: ^ I see that you've already got the ball rolling on that last one
[19:41] <rtg> tyhicks, yep, it looked like a good one
[19:42] <tyhicks> rtg: The empty lower files fixes should solve one of the most nagging usability problems
[19:43] <rtg> tyhicks, I'm also looking at 2.6.32.y to see if it would benefit from a backport of 069ddcd. All the other kernel versions are a clean cherry-pick
[19:43] <rtg> tyhicks, agreed about lower files fixes...
[19:49] <tyhicks> rtg: re 2.6.32.y> I would say so
[19:49] <rtg> tyhicks, k, I'll look into it
[19:50] <tyhicks> rtg: I see the if "(... !IS_POSIXACL(inode)) { mode &= ~current_umask(); }" pattern several places in fs/namei.c
[19:51] <herton> tyhicks, I saw we had on precise/oneiric commit 4a26620 "eCryptfs: Improve statfs reporting" and forwarded to stable. It seemed worth to have on stables, cking was in favour too. But by Ben's response, not sure he will pick.
[19:51] <tyhicks> herton: Yeah, I was about to respond to that. I think Ben is right. :/
[19:52] <tyhicks> herton: I hadn't considered his use case
[21:00]  * rtg -> EOD
[22:55] <xmltok> i'm running ubuntu 12.04 LTS in a KVM VM on Ubuntu 12.04 LTS, if I bidirection iperf my VM from the host node the NIC will lock up requiring if up/down after a few hours
[22:56] <xmltok> i've tried to reproduce this with centos5 VM on the same host (its the only other readily available template right now) and I was unable to reproduce the bug. I'm currently testing 10.04 but it will be a few hours until I know if its working
[22:56] <xmltok> has anyone seen this kind of issue before?