[09:11] <kraut> moin
[07:22] <xivulon> mjg59: any luck with wubi?
[07:23] <mjg59> xivulon: The kernel is stupid
[07:23] <mjg59> Not convinced we can fix it for gutsy, but I'll see
[07:23] <xivulon> ?
[07:23] <mjg59> The process freezer is used for suspend to RAM, but syslog is still trying to write when fuse is frozen
[07:23] <mjg59> So the writing never completes
[07:23] <mjg59> And suspend fails
[07:24] <xivulon> I see
[07:24] <xivulon> what about stopping syslog beforhand?
[07:24] <mjg59> Syslog is just what fails in the trivial case
[07:24] <mjg59> It could be any application
[07:24] <xivulon> I understand
[07:25] <xivulon> Note that in hibernation there is an added problem
[07:25] <xivulon> Swap is inside a mounted fs
[07:26] <mjg59> Yes, hibernation is impossible
[07:26] <xivulon> So for instance we have lubi (the wubi version working on linux/ext3) where suspend works (since there is no fuse involved) but hibernation does not (I assume because the swap is not in a dedicated partition)
[07:28] <xivulon> mjg59 what would be an elegant way to turn off suspend/hibernation for the time being?
[07:29] <mjg59> For gnome, there's a couple of gconf keys that you can set
[07:30] <Mithrandir> look at what casper does.
[07:30] <xivulon> The issue that wubi is not really gnome specific
[07:31] <xivulon> Also suspend might work in some cases (non-fuse host fs)
[07:31] <mjg59> Policy is managed by individual applications
[07:32] <xivulon> Do they read "capabilities" from somewhere?
[07:32] <mjg59> No
[07:32] <xivulon> What about acpi=off? 
[07:33] <mjg59> Ouch. No.
[07:33] <mjg59> acpi is much more than power management
[07:33] <xivulon> I was expecting the ouch
[07:33] <mjg59> (And it'll do nothing to influence hibernation)
[07:36] <xivulon> What about having a script in suspend.d that kills sleep.sh
[07:36] <xivulon> That will not take care of disabling the suspend/download buttons though...
[07:37] <xivulon> mjg59 as a side question. Any chance of having ntfs-3g as a kernel module? That would solve lots of issues
[07:37] <mjg59> No
[07:38] <xivulon> I asked szaka (ntfs-3g) and he was not so inclined either...
[07:38] <mjg59> It's not easy to port a fuse application to the kernel
[07:39] <xivulon> Last question (other than the suspend.d hack above):
[07:39] <xivulon> Users do tend to hard reboot quite a lot
[07:39] <xivulon> Because often they come from windows and do not know what to do when they get stacked
[07:40] <xivulon> A nested fs is not the best environment for that
[07:40] <xivulon> What can be done to minimize damage?
[07:40] <mjg59> Nothing
[07:40] <xivulon> I changed /etc/sysctl.conf on szaka suggestion
[07:42] <xivulon> vm.dirty_background_ratio=0 , vm.dirty_ratio=0 , vm.dirty_expire_centisecs=1  , vm.dirty_writeback_centisecs=1  
[07:43] <mjg59> What sort of corruption are you actually seeing?
[07:43] <xivulon> Sometimes the hosted fs (ext3) might become unrecoverable, since data loss in the hosting fs might compromise the journal
[07:44] <xivulon> Alos hosting fs corruption has been reported (but chckfs normally can fix that)
[07:44] <xivulon> Using the above things seem to have improved
[07:44] <xivulon> Based on bug reports
[07:45] <mjg59> Right. ext3 makes the assumption that writes to the journal actually end up in the journal
[07:45] <mjg59> I'm not sure there's a good way around that
[07:46] <xivulon> According to szaka the sysctl parameters above should improve things but to be honest I have not looked up what they do exactly
[07:47] <xivulon> mjg59 any reason not to use the sysctl parameters above?
[07:48] <mjg59> xivulon: Reduced performance, but I guess you'll have to take that hit
[07:48] <xivulon> so far it does not look to bad, so I guess I'll leave them there
[07:48] <xivulon> mjg59 last thing: is the idea of using a suspend.d script that makes sleep.sh exit so bad?
[07:49] <mjg59> Yes
[07:49] <xivulon> ok 
[07:49] <xivulon> That's all I had to ask, thank you very much for all your help
[07:49] <xivulon> very useful
[07:57] <johanbr> Is there are reason /dev/input/eventX would not be available immediately on resume? Sometimes my touchpad dies when I resume, and I think it's related to log entries like
[07:57] <johanbr> :0.log.4:Synaptics Touchpad no synaptics event device found (checked 17 nodes)
[07:57] <johanbr> :0.log.4:(EE) xf86OpenSerial: Cannot open device /dev/input/event3
[07:58] <mjg59> Yeah, synaptics seems a bit dumb.
[07:59] <johanbr> So it's the fault of the synaptics driver rather than the kernel?
[08:01] <mjg59> Yes
[08:04] <johanbr> Alright. Well, you seem to be aware of the problem, so I'll just hope for a fix at some point in the future. :) Thank you.