[uml-devel] UML freezes at hdd-intensive processes

2005-03-03 Thread Oliver Baltz
Hi @all, my UML hangs while intensive processes that use the HDD. For example: rgrep, upgrade,... UML-Hostsystem: 2.4.27-1-386, Intel ICH5 SATA 150-Controller UML: 2.4.26-3um-1 Any ideas? --- SF email is sponsored by - The IT Product Gui

[uml-devel] UML freezes at hdd-intensive processes

2005-03-03 Thread Oliver Baltz
Hi @all, my UML hangs while intensive processes that use the HDD. For example: rgrep, upgrade,... UML-Hostsystem: 2.4.27-1-386, Intel ICH5 SATA 150-Controller UML: 2.4.26-3um-1 Any ideas? --- SF email is sponsored by - The IT Product

[uml-devel] Re: uml_switch security fixing

2005-03-03 Thread Nuutti Kotivuori
[EMAIL PROTECTED] wrote: > Suggestions? FWIW, we have gone off using switch daemon entirely. We are using simply preallocated tap devices, connected to bridges via normal Linux bridging controls. Works cleaner and faster, more places to dump the traffic from and it allows normal linux traffic queu

Re: [uml-devel] UML freezes at hdd-intensive processes

2005-03-03 Thread Rob Landley
On Thursday 03 March 2005 05:41 am, Oliver Baltz wrote: > Hi @all, > > my UML hangs while intensive processes that use the HDD. For example: > rgrep, upgrade,... > > UML-Hostsystem: 2.4.27-1-386, Intel ICH5 SATA 150-Controller > UML: 2.4.26-3um-1 > > Any ideas? I haven't seen this on 2.6, but I th

Re: [uml-devel] Triage on the pending patches

2005-03-03 Thread Jeff Dike
[EMAIL PROTECTED] said: > Well, just in case your job was too easy, here's one more. Using the > "quiet" option shows a couple of lines being printed out by printf > that should be printed out by printk (so they'll _shut_up_ when you > ask it to). Those are printfs for a reason. Early boot mesa

Re: [uml-devel] Triage on the pending patches

2005-03-03 Thread Rob Landley
On Thursday 03 March 2005 01:43 pm, Jeff Dike wrote: > [EMAIL PROTECTED] said: > > Well, just in case your job was too easy, here's one more. Using the > > "quiet" option shows a couple of lines being printed out by printf > > that should be printed out by printk (so they'll _shut_up_ when you > >