-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>>You need to consider that in the end I'd need PT_GNU_STACK to do
>>everything PaX wants
>
>
> why?
> Why not have independent flags for independent things?
> That way you have both cleanness of design and you don't break a
Andrew Morton wrote:
Jeff Garzik <[EMAIL PROTECTED]> wrote:
> Was cc'ed to linux-net last Thursday, but it looks like the messages was
> too large and the vger server munched it.
This also brings up a larger question... why was a completely unreviewed
net driver merged?
Because nobody noticed that
On Mon, Mar 28, 2005 at 11:08:30PM -0800, Andrew Morton wrote:
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > Linux Kernel Mailing List wrote:
> > > ChangeSet 1.2231.1.122, 2005/03/28 19:50:29-08:00, [EMAIL PROTECTED]
> > >
> > > [PATCH] s390: claw network device driver
> > >
> > > Add
On Mon, Mar 28, 2005 at 11:08:30PM -0800, Andrew Morton wrote:
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> > Linux Kernel Mailing List wrote:
> > > ChangeSet 1.2231.1.122, 2005/03/28 19:50:29-08:00, [EMAIL PROTECTED]
> > >
> > > [PATCH] s390: claw network device driver
> > >
> > > Add
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Linux Kernel Mailing List wrote:
> > ChangeSet 1.2231.1.8, 2005/03/28 19:18:25-08:00, [EMAIL PROTECTED]
> >
> > [PATCH] slab: kfree(null) is unlikely
> >
> > - mark kfree(NULL) as being unlikely
>
> This is just a wild guess, right?
More li
On 2005-03-29, at 05:36, Lee Revell wrote:
On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
It seems that Apple's driver has an in-kernel framework for doing
volume
control, mixing, and other horrors right in the kernel, in temporary
buffers, just before they get DMA'ed (gack !)
I
Linux Kernel Mailing List wrote:
ChangeSet 1.2231.1.8, 2005/03/28 19:18:25-08:00, [EMAIL PROTECTED]
[PATCH] slab: kfree(null) is unlikely
- mark kfree(NULL) as being unlikely
This is just a wild guess, right?
Seems to me, it depends on the code.
Jeff
-
To unsubscrib
On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote:
> Guillaume wrote:
> > The lmbench shows that the overhead (the construction and the sending
> > of the message) in the fork() routine is around 7%.
>
> Thanks for including the numbers. The 7% seems a bit costly, for a bit
> more accountin
Hi,
Jan Engelhardt writes:
"[...]In general, you should prefer to use actual profile feedback for this
(`-fprofile-arcs'), as programmers are NOTORIOUSLY BAD AT PREDICTING how
their programs actually perform." --gcc info pages.
Indeed.
I wrote:
> The optimization does not help if you are rele
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> > Was cc'ed to linux-net last Thursday, but it looks like the messages was
> >> > too large and the vger server munched it.
> >>
> >> This also brings up a larger question... why was
Sorry to resume an old thread, but...
On Sat, Mar 19, 2005 at 10:52:39PM +0100, Romano Giannetti wrote:
>
> http://bugme.osdl.org/show_bug.cgi?id=4124
>
During Easter I had time to test a bit more the patch and I found a very bad
issue between acpi keys, preempt and suspend. It's a lot of data;
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Arjan van de Ven wrote:
>>You need to consider that in the end I'd need PT_GNU_STACK to do
>>everything PaX wants
>
>
> why?
> Why not have independent flags for independent things?
> That way you have both cleanness of design and you don't break a
> > dmix has been around for a while but softvol plugin is very new, you
> > will need ALSA CVS or the upcoming 1.0.9 release.
>
> Instead of the lame claims on how ugly it is to do hardware mixing in
> kernel space the ALSA fans should ask them self the following questions:
Well, we are claiming
Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
> > Was cc'ed to linux-net last Thursday, but it looks like the messages was
> > too large and the vger server munched it.
>
> This also brings up a larger question... why was a completely unreviewed
> net driver merged?
Because nobody noticed that it
On Mon, 2005-03-28 at 23:02 -0800, Greg KH wrote:
> On Tue, Mar 29, 2005 at 11:04:16AM +0400, Evgeniy Polyakov wrote:
> > On Mon, 2005-03-28 at 13:42 -0800, Paul Jackson wrote:
> > > I don't see it in my copies of *-mm or recent Linus bk trees. Am I
> > > missing something?
> >
> > It was dropped
Vivek, perhaps a little more context about the background of the
changes would have helped here. Not everyone has been following
the details of fastboot/kdump discussion for the last few months.
Let me give this a try - Eric/Vivek please pitch in and correct me,
where I go wrong since even I hav
On Mon, Mar 28 2005, Chen, Kenneth W wrote:
> On Mon, Mar 28, 2005 at 06:38:23PM -0800, Chen, Kenneth W wrote:
> > We have measured that the following patch give measurable performance gain
> > for industry standard db benchmark. Comments?
>
> Dave Jones wrote on Monday, March 28, 2005 7:00 PM
>
On Mon, Mar 28 2005, Chen, Kenneth W wrote:
> The noop elevator is still too fat for db transaction processing
> workload. Since the db application already merged all blocks before
> sending it down, the I/O presented to the elevator are actually not
> merge-able anymore. Since I/O are also random
Hi Andrew,
This patch adds the mem=X boot command line option for PPC64.
On iSeries the user's mem=X value is aligned to PAGE_SIZE, on
pSeries we align to 16 MB which is the size of a large page.
The iSeries implementation is fairly straight forward, we declare mem=X
as an early_param() and then
On Tue, 2005-03-29 at 02:53 -0500, John Richard Moser wrote:
> Right now, my rough sketch is:
>
> MF_PAX_PAGEEXEC
> ON: ET_EXEC enforced. Stack NX. Heap NX. Code PROT_EXEC.
> OFF: Stack and heap default to +X
> The PAGEEXEC flag will basically mandate the automated non-executable
>
On Mon, Mar 28 2005, Chen, Kenneth W wrote:
> This patch was posted last year and if I remember correctly, Jens said
> he is OK with the patch. In function __generic_unplug_deivce(), kernel
> can use a cheaper function elv_queue_empty() instead of more expensive
> elv_next_request to find whether
* Sven Dietrich <[EMAIL PROTECTED]> wrote:
> Ingo,
>
> this patch turns off the preemptable BKL when
> either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected.
thanks, added it to my tree.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a mes
* Yang Yi <[EMAIL PROTECTED]> wrote:
> Hi ,Ingo
>
> this patch fixes e1000 driver disable interrupt bug when enabling
> "Complete Preemption (Realtime)".
thanks - applied it to the 41-12 tree.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body o
On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote:
> The problem is that the mouse really does reports all the double-button
> stuff and autorepeat, and horizontal wheel together with button press on
> wheel tilt.
Okay, I'm playing with this under 2.6.11.4 some more, and it really
seems out
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
John Richard Moser wrote:
>
>
> Arjan van de Ven wrote:
>
[...]
Three more notes, then I'll sleep. These notes won't include the two
paragraph long explaination of falling back to PT_GNU_STACK if
PT_PAX_FLAGS isn't there; compatibility has been
* Eugeny S. Mints <[EMAIL PROTECTED]> wrote:
> please consider the following scenario for full RT kernel.
>
> Task A is running then an irq is occured which in turn wakes up irq
> related thread (B) of a higher priority than A.
>
> my current understanding that actual context switch between A
Evgeniy wrote:
> There is no overhead at all using CBUS.
This is unlikely. Very unlikely.
Please understand that I am not trying to critique CBUS or connector in
isolation, but rather trying to determine what mechanism is best suited
for getting this accounting data written to disk, which is whe
On Mon, Mar 21, 2005 at 04:09:54PM +0100, Norbert Preining wrote:
> On Mon, 21 Mär 2005, Alan Cox wrote:
> > I pushed the tested one as a starting point. May have been the wrong
> > decision but it's my fault if so
>
> Ah ok. I checked the differences between the versions but there are too
> many
* Mark Gross <[EMAIL PROTECTED]> wrote:
> > As I mentioned earlier, what would it take to be able to group
> > softirq threads that should not preempt each other, but still keep
> > preemption available for other threads?
>
> It would only take the creationt of multiple softIRQd threads per CPU.
On Tue, 2005-03-29 at 03:29 -0500, John Richard Moser wrote:
> >>MF_PAX_PAGEEXEC
> >> ON: ET_EXEC enforced. Stack NX. Heap NX. Code PROT_EXEC.
> >> OFF: Stack and heap default to +X
> >> The PAGEEXEC flag will basically mandate the automated non-executable
> >> setting for the stack and
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> I've created a tracing tool several years ago for my master's thesis
> against the 2.2 kernel and onto the 2.4 kernel. I'm currently using
> this in the 2.6 kernel to debug some customizations against Ingo's RT
> kernel.
neat. It seems there's som
On Mon, 28 Mar 2005, Chris Friesen wrote:
> Date: Mon, 28 Mar 2005 23:07:14 -0600
> From: Chris Friesen <[EMAIL PROTECTED]>
> To: krishna <[EMAIL PROTECTED]>
> Cc: Linux Kernel
> Subject: Re: How to measure time accurately.
>
> krishna wrote:
> > Hi All,
> >
> > Can any one tell me how to measu
"Chen, Kenneth W" <[EMAIL PROTECTED]> wrote:
>
> On Mon, Mar 28, 2005 at 06:38:23PM -0800, Chen, Kenneth W wrote:
> > We have measured that the following patch give measurable performance gain
> > for industry standard db benchmark. Comments?
>
> Dave Jones wrote on Monday, March 28, 2005 7:00
On Tue, 2005-03-29 at 00:49 -0800, Paul Jackson wrote:
> This
> amortizes the cost of almost all the handling, and of all the disk i/o,
> over many data collection events. Correct me if I'm wrong, but
> fork_connector doesn't do this merging of events into a consolidated
> data buffer, so is at
Nick Piggin wrote:
I haven't used a big disk array (or tried any simulation), but I'll
attach the patch if you're looking into that area.
Oh, and this one removes a memory barrier. I think we (Jens and I)
agreed this is valid. Whether or not you'll notice a difference is
another story ;)
This mem
Jens Axboe wrote:
On Mon, Mar 28 2005, Chen, Kenneth W wrote:
This patch was posted last year and if I remember correctly, Jens said
he is OK with the patch. In function __generic_unplug_deivce(), kernel
can use a cheaper function elv_queue_empty() instead of more expensive
elv_next_request to fin
Jeff Garzik napsal(a):
Merged recent upstream changes into libata-dev queue. No new patches
have found their way into libata-dev since last email.
BK URL, Patch URL, and changelog attached.
Note that the patch is diff'd against 2.6.11-bk6, which won't exist
until four hours after this email is
>In some cases you can simply count jiffies - depending on how accurate you
>need to time things I'd say that often something like this is adequate :
These "some cases" exclude this one:
If interrupts are disabled, a jiffy might be missed. Take care.
If you are on UP and want to measure within
On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
Well, we are claiming _and_ obviously proposing a solution ;)
I beg to differ.
1. Where do you have true "real-time" under linux? Kernel or user
space?
That's bullshit.
Wait a moment...
you don't need "true" real time for the mixing/volume
pro
On Tue, Mar 29 2005, Nick Piggin wrote:
> Jens Axboe wrote:
> >On Mon, Mar 28 2005, Chen, Kenneth W wrote:
> >
> >>This patch was posted last year and if I remember correctly, Jens said
> >>he is OK with the patch. In function __generic_unplug_deivce(), kernel
> >>can use a cheaper function elv_qu
Jens Axboe wrote:
Looks good, I've been toying with something very similar for a long time
myself.
The unplug change is a no-brainer.
Yep - I may have even stolen it from you (or someone) from a patch
which had been forgotten. I can't remember for sure, but it is trivial
enough that anyone could co
Hi,
There is a problem on my box (Asus L5D, x86-64 kernel) with the ACPI battery
driver in the 2.6.12-rc1-mm[1-3] kernels. Namely, the battery monitor that
I use (the kpowersave applet from SUSE 9.2) is no longer able to report the
battery status (ie how much % it is loaded). It can only check i
At Mon, 28 Mar 2005 22:36:09 -0500,
Lee Revell wrote:
>
> On Mon, 2005-03-28 at 09:42 +1000, Benjamin Herrenschmidt wrote:
> > It seems that Apple's driver has an in-kernel framework for doing volume
> > control, mixing, and other horrors right in the kernel, in temporary
> > buffers, just before
Jens Axboe wrote:
Looks good, I've been toying with something very similar for a long time
myself.
Here is another thing I just noticed that should further reduce the
locking by at least 1, sometimes 2 lock/unlock pairs per request.
At the cost of uglifying the code somewhat. Although it is pretty
On Tue, 29 Mar 2005, Rusty Russell wrote:
> On Sun, 2005-03-27 at 14:57 +0200, Bert Wesarg wrote:
> > Hello,
> >
> > there seems to be a bug, at least for me, in kernel/param.c for arrays
> > with .num == NULL. If .num == NULL, the function param_array_set() uses
> > &.max for the call to param_
On Tue, 2005-03-29 at 19:19 +1000, Nick Piggin wrote:
> - removes the relock/retry merge mechanism in __make_request if we
>aren't able to get the GFP_ATOMIC allocation. Just fall through
>and assume the chances of getting a merge will be small (is this
>a valid assumption? Should measu
Hello Linus,
you can either use "bk receive" to patch with this mail,
or you can
Pull from: bk://krusty.dt.e-technik.uni-dortmund.de/BK-kernel-tools
or in cases of dire need, you can apply the patch below.
BK parent: http://bktools.bkbits.net/bktools
Patch description:
[EMAIL PROTECTED], 2005-03
Hi!
> >>See the earlier discussion, when data validation was -removed- from the
> >>original Intel RNG driver, and moved to userspace.
> >
> >I'm not arguing against userspace validation, but if data produced
> >_is_ cryptographically strong, why revalidate it again?
>
> You cannot prove this w
On Tue, Mar 29 2005, Arjan van de Ven wrote:
> On Tue, 2005-03-29 at 19:19 +1000, Nick Piggin wrote:
> > - removes the relock/retry merge mechanism in __make_request if we
> >aren't able to get the GFP_ATOMIC allocation. Just fall through
> >and assume the chances of getting a merge will be
Arjan van de Ven wrote:
On Tue, 2005-03-29 at 19:19 +1000, Nick Piggin wrote:
- removes the relock/retry merge mechanism in __make_request if we
aren't able to get the GFP_ATOMIC allocation. Just fall through
and assume the chances of getting a merge will be small (is this
a valid assumption?
At Tue, 29 Mar 2005 11:22:07 +0200,
Marcin Dalecki wrote:
>
>
> On 2005-03-29, at 10:18, Benjamin Herrenschmidt wrote:
> >
> > Well, we are claiming _and_ obviously proposing a solution ;)
>
> I beg to differ.
>
> >> 1. Where do you have true "real-time" under linux? Kernel or user
> >> space?
Hi!
On Pá 25-03-05 18:25:31, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 10:19:55AM +0300, Evgeniy Polyakov wrote:
> >
> > Noone will complain on Linux if NIC is broken and produces wrong
> > checksum
> > and HW checksum offloading is enabled using ethtools.
>
> This is completely different. Th
On Tue, 2005-03-29 at 00:49 -0800, Paul Jackson wrote:
> Evgeniy wrote:
> > There is no overhead at all using CBUS.
>
> This is unlikely. Very unlikely.
>
> Please understand that I am not trying to critique CBUS or connector in
> isolation, but rather trying to determine what mechanism is best
On Tue, Mar 29, 2005 at 12:18:16PM +0200, Pavel Machek wrote:
>
> I do not think paranoia about random generators is neccessary. If
> vendor provides you with random generator, it should be ok to just use
> it. [Did anyone see failing hw random generator, *at all*?] I can
> provide you with plenty
On Tue, Mar 29, 2005 at 12:21:04PM +0200, Pavel Machek wrote:
>
> What catastrophic consequences? Noone is likely to even *notice*, and
> it does not help practical attack at all. Unless hardware RNGs are
> *very* flakey (like, more flakey than harddrives), this is not a problem.
The reason some
Hi,
On Monday, 28 of March 2005 03:22, Li Shaohua wrote:
> On Sun, 2005-03-27 at 02:23, Rafael J. Wysocki wrote:
]--snip--[
> Could you please file a bug in bugzilla? I don't want to lose the
> context of thread. And please attach your acpidmp output in the bug.
The bug report is at:
http://bug
Hi Artem:
On Mon, Mar 28, 2005 at 05:22:36PM +, Artem B. Bityuckiy wrote:
>
> The first patch is the implementation of the deflate_pcompress()
Thanks for the patch. I'll comment on the second patch later.
Are you sure that 12 bytes is enough for all cases? It would seem
to be safer to use
On Pá 25-03-05 17:13:11, Herbert Xu wrote:
> On Fri, Mar 25, 2005 at 09:16:01AM +0300, Evgeniy Polyakov wrote:
> > On Fri, 2005-03-25 at 00:58 -0500, Jeff Garzik wrote:
> >
> > > If its disabled by default, then you and 2-3 other people will use this
> > > feature. Not enough justification for a
Hi!
> > What catastrophic consequences? Noone is likely to even *notice*, and
> > it does not help practical attack at all. Unless hardware RNGs are
> > *very* flakey (like, more flakey than harddrives), this is not a problem.
>
> The reason some people use hardware RNGs in the first place is bec
On Tue, 2005-03-29 at 20:30 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 12:21:04PM +0200, Pavel Machek wrote:
> >
> > What catastrophic consequences? Noone is likely to even *notice*, and
> > it does not help practical attack at all. Unless hardware RNGs are
> > *very* flakey (like, more fl
On Tue, Mar 29, 2005 at 12:38:01PM +0200, Pavel Machek wrote:
>
> It seems to me that people wanting this level of assurance should do
> their own FIPS (or whatever) tests.
That's exactly what the current scheme of driver + rngd allows you
to do. For those that require high assurance, they can l
On Tue, Mar 29, 2005 at 02:50:28PM +0400, Evgeniy Polyakov wrote:
>
> Without ability speed this up in kernel, we completely [ok, almost]
> loose all RNG advantages.
Well if you can demonstrate that you're getting a higher rate of
throughput from your RNG by doing this in kernel space vs. doing
i
Hi Andrew, all,
> > Think about it. If the pointer could be NULL, then it's unlikely that
> > the bug would have gone unnoticed so far (unless the code is very
> > recent). Coverity found 3 such bugs in one i2c driver [1], and the
> > correct solution was to NOT check for NULL because it just
Hello!
> We trust hardware, anyway. Like your disk *could* accidentaly turn on
> setuid bit on /bin/bash, and we do not insist on userspace
> disk-validator.
But there is a very important difference: the most likely (both in theory
and practice) failure of a disk is clearly visible, while failure
Wij hebben geheel nieuw in ons aanbod edel horloges opgenomen.
Wij hebben bijna alle fantastische modelle voor u, die u zich maar wensen
kunt.
Alles van Bulgari, Cartier tot Chopard en Omega en Gucci uurwerken is te
verkrijgen.
Gesorteerd naar mannen en vrouwen uurwerken, of als geschenkbox is er o
Hi all,
swsusp is not working for me with 2.6.12rc1. I compiled the kernel
preempt, I am compiling now without preempt to test it. -mm3 has a
similar behaviour.
All the configuration, dmesg, lsmod etc is here:
http://www.dea.icai.upco.es/romano/linux/config-2.6.12-rc1/laptop-c
> Yes.
>
> > dmix has been around for a while but softvol plugin is very new, you
> > will need ALSA CVS or the upcoming 1.0.9 release.
>
> dmix currently doesn't work on PPC well but I'll fix it soon later.
> If it's confirmed to work, we can set dmix/softvol plugins for default
> of snd-powerm
Hello list,
how can I found out the size of the underlying block device when I am in
somefs_fill_super()?
Jan Engelhardt
--
No TOFU for me, please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at h
Christoph Lameter wrote:
>
> On Sat, 26 Mar 2005, Chen, Kenneth W wrote:
>
> > I changed schedule_timeout() to call the new del_timer_sync instead of
> > currently del_singleshot_timer_sync in attempt to stress these set of
> > patches a bit more and I just observed a kernel hang.
> >
> > The sympt
Andrew Morton wrote:
>
> Oleg Nesterov <[EMAIL PROTECTED]> wrote:
> >
> > This is the last one, I promise.
> > On top of "[PATCH rc1-mm3] timers: kill timer_list->lock", see
> > http://marc.theaimsgroup.com/?l=linux-kernel&m=93319932543
>
> I thought that earlier patch was a bit weird
A bit
Christoph Lameter wrote:
>
> Ok. Testing with your latest and greatest patches.
Many thanks.
> Is there any clarity about what caused the hangs?
No, I still hope these hangs are unrelated to these patches.
I am trying to find the bug, but I can't. May be it is because
I do not want to believe th
On Sun, Mar 27, 2005 at 11:27:00AM +0200, Alpt after a spiritual call wrote :
~> Bridge hub_enabled patch:
~> this patch adds the hub_enabled option for bridge.
~>
~> By default the hub_enabled flag is set to 1. In this case nothing changes,
the
~> bridge, as usually, acts as a hub and flood_for
Hi all,
In the kernels 2.6.12-rc1 and 2.6.12-rc1-mm3 my ALPS touchpad is not
recognized by the Xorg driver. The strange thing is that in dmesg ALPS is
detected, but then the Xorg driver tell strange things...
In dmesg:
[4294673.596000] Enabling hardware tapping
[4294673.6
On Sun, Mar 27 2005, Chris Rankin wrote:
> [gcc-3.4.3, Linux-2.6.11-SMP, Dual P4 Xeon with HT enabled]
>
> Hi,
>
> My Linux 2.6.11 box oopsed when I tried to logout. I have switched to using
> the anticipatory
> scheduler instead.
>
> Cheers,
> Chris
>
> NMI Watchdog detected LOCKUP on CPU1, e
On Tue, 2005-03-29 at 08:03 +0200, Jan Engelhardt wrote:
> >> > I am trying to set the SCHED_FIFO policy for my process.I am using
> >> > sched_setscheduler() function to do this.
> >>
> >> Attached is a little program that I use to set the priority of tasks.
> >
> >Why not just use chrt from sc
On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 02:50:28PM +0400, Evgeniy Polyakov wrote:
> >
> > Without ability speed this up in kernel, we completely [ok, almost]
> > loose all RNG advantages.
>
> Well if you can demonstrate that you're getting a higher rate of
>
Hi!
> Hello Pavel, I can now suspend to disk on the laptop with 2.6.12-rc1. There
> is
> no failures anymore. It resumes perfectly.
No video hacks needed? Good.
Pavel
--
People were complaining that M$ turns users into bet
>OK, I'm a little embarrassed. I never saw this tool. I use debian
You don't need to be. Before I got to know of this tool, I also wrote my own.
Look for "schedutils".
>unstable, but didn't have the package loaded. I did a apropos on
>sched_setscheduler, and it didn't come up with any tools, so
On Tue, Mar 29, 2005 at 03:42:05PM +0400, Evgeniy Polyakov wrote:
> On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
> > Well if you can demonstrate that you're getting a higher rate of
> > throughput from your RNG by doing this in kernel space vs. doing
> > it in user space please let me know
On Tue, 2005-03-29 at 08:03 +0200, Jan Engelhardt wrote:
> >> > I am trying to set the SCHED_FIFO policy for my process.I am using
> >> > sched_setscheduler() function to do this.
> >>
> >> Attached is a little program that I use to set the priority of tasks.
> >
> >Why not just use chrt from sc
>FC2 has this. Even FC1 had it, and I'd not be surprised if even RHL9 had
>this. I'd be very susprised if SuSE 9.1 doesn't have it either.
It was introduced with SUSE Linux 9.1. But, as usually, I usually do not care
for new packages when updating, and schedutils was not a dependency, so it
lost
On Thu, Mar 24, 2005 at 03:02:28AM +0100, Blaisorblade wrote:
> In this moment I need to clean up the missing symbol. If anyone wants to
> remove the code using this, then he might post a patch explictly removing it,
> and getting it refused probably.
>
> Or at least CC uml-devel when discussin
Hi,
When the kernel gets a particular syscall, is there a way to get it to
trigger another program?
Or send it a signal?
Thanks,
The Nomad.
_
Don't just search. Find. Check out the new MSN Search!
http://search.msn.click-url.com/go/on
Hi list,
I have a Dell Poweredge 1600SC with kernel 2.6.11 running and using the ext3
FS + quota v2.
After a while the quota system was running out of sync. This shouldn't be a
problem, so I decided to turn off quota for a while and rescan my files...
When running the quotaoff utility, it sudde
Is there a way to simulate a keystroke to a program, ie. have a program send
it something so that as far as it's concerned, say, the "P" key has been
pressed?
Thanks,
The Nomad.
_
Express yourself instantly with MSN Messenger! Down
On Tue, 2005-03-29 at 11:07 +0200, Ingo Molnar wrote:
> * Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> > I've created a tracing tool several years ago for my master's thesis
> > against the 2.2 kernel and onto the 2.4 kernel. I'm currently using
> > this in the 2.6 kernel to debug some customiz
I have one IDE hard disc, but I was using a USB memory stick at one point.
(Notice the usb-storage
and vfat modules in my list.) Could that be the troublesome SCSI device?
--- Jens Axboe <[EMAIL PROTECTED]> wrote:
> On Sun, Mar 27 2005, Chris Rankin wrote:
> > [gcc-3.4.3, Linux-2.6.11-SMP, Dual P
> Are you sure that 12 bytes is enough for all cases? It would seem
> to be safer to use the formula in deflateBound/compressBound from
> later versions (> 1.2) of zlib to calculate the reserve.
>
I'm not sure. David Woodhouse (the author) said that this is probably
enough in any case but a lot of
* Steven Rostedt <[EMAIL PROTECTED]> wrote:
> Also, I'm almost done adding the pending owner work against .41-11. I
> see you now have 41-13, and if you already implemented it, let me
> know. [...]
nope, i havent touched that area of code, knowing that you are working
on it.
> [...] I've bee
On Tue, Mar 29 2005, Chris Rankin wrote:
(please don't top post)
> --- Jens Axboe <[EMAIL PROTECTED]> wrote:
> > On Sun, Mar 27 2005, Chris Rankin wrote:
> > > [gcc-3.4.3, Linux-2.6.11-SMP, Dual P4 Xeon with HT enabled]
> > >
> > > Hi,
> > >
> > > My Linux 2.6.11 box oopsed when I tried to logo
>When running the quotaoff utility, it suddenly segfaulted and my /home was
>'dead'.
>I also noticed that the load of my box was rising very high. After a few
>minutes
>the whole server was 'dead'.
>
>If anyone has seen the same problem or has any idea howto solve this problem,
>or howto get mo
On Tue, 2005-03-29 at 21:39 +1000, Herbert Xu wrote:
> On Tue, Mar 29, 2005 at 03:42:05PM +0400, Evgeniy Polyakov wrote:
> > On Tue, 2005-03-29 at 20:46 +1000, Herbert Xu wrote:
>
> > > Well if you can demonstrate that you're getting a higher rate of
> > > throughput from your RNG by doing this in
On Tue, 2005-03-29 at 13:56 +0200, Ingo Molnar wrote:
> > To have a task take back the ownership, I had the stealer call
> > task_blocks_on_lock on the task that it stole it from. To get this to
> > work, when a task is given the pending ownership, it doesn't NULL the
> > blocked_on at that poi
At Tue, 29 Mar 2005 21:04:50 +1000,
Benjamin Herrenschmidt wrote:
>
>
> > Yes.
> >
> > > dmix has been around for a while but softvol plugin is very new, you
> > > will need ALSA CVS or the upcoming 1.0.9 release.
> >
> > dmix currently doesn't work on PPC well but I'll fix it soon later.
> > I
Hi!
> > > > Well if you can demonstrate that you're getting a higher rate of
> > > > throughput from your RNG by doing this in kernel space vs. doing
> > > > it in user space please let me know.
> > >
> > > While raw bits reading from hw_random on the fastest
> > > VIA boards can exceed 55mbits
On Mon, 28 Mar 2005, Steven Rostedt wrote:
On Mon, 2005-03-28 at 19:56 -0500, Kyle Moffett wrote:
On Mar 28, 2005, at 19:21, Steven Rostedt wrote:
So you are saying that a stand alone section of code, that needs
wrappers to work with Linux is a derived work of Linux? If there's
some functionality,
As a response to myself, I've found it:
superblock->s_bdev->bd_inode->i_size
:)
Jan Engelhardt
--
No TOFU for me, please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.or
At Sat, 26 Mar 2005 11:19:45 +0100,
Jean Delvare wrote:
>
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc1/2.6.12-rc1-mm3/
> > (...)
> > bk-alsa.patch
>
> This one made /proc/asound/card0/id change from "Live" to "Unknown" on
> one of my systems, preventing alsatcl fr
On Mon, 2005-03-28 at 19:28 +0200, Matthieu Castet wrote:
> > The memory limits aren't good enough either: if you set them low
> > enough that memory-forkbombs are unperilous for
> > RLIMIT_NPROC*RLIMIT_DATA, it's probably too low for serious
> > applications.
>
> yes, if you want to run applicati
On Tue, March 29, 2005 7:15 am, linux-os said:
> In the United States there is something called "restraint of trade".
> Suppose there was a long-time facility or API that got replaced
> with one that was highly restrictive. To use the new facility, one
> would have to buy a license or kiss somebod
1 - 100 of 384 matches
Mail list logo
