On 14/01/15 22:07, Greg KH wrote:
For networking patches, can you cc: netdev and get an ack from the
networking maintainer for me to be able to apply them?
Done, and sorry for the sta...@kernel.org bounce.
Mike.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing
these errors:
Jan 14 17:47:16 lxc2 kernel: [ 10.704890] WARNING: CPU: 0 PID: 3209 at
fs/sys
fs/dir.c:52 sysfs_warn_dup+0x8c/0xb0()
Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create
duplicate filename
When running 'lxc' on the latest -stable kernel, 3.14.28, I'm seeing
these errors:
Jan 14 17:47:16 lxc2 kernel: [ 10.704890] WARNING: CPU: 0 PID: 3209 at
fs/sys
fs/dir.c:52 sysfs_warn_dup+0x8c/0xb0()
Jan 14 17:47:16 lxc2 kernel: [ 10.704892] sysfs: cannot create
duplicate filename
On 14/01/15 22:07, Greg KH wrote:
For networking patches, can you cc: netdev and get an ack from the
networking maintainer for me to be able to apply them?
Done, and sorry for the sta...@kernel.org bounce.
Mike.
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the
In article
you
write:
>When the init process is created on system startup, does it have any
>open file descriptors? If so, where do they point?
0, 1 and 2, which are connected to the console. Boot a kernel with
"init=/bin/bash" and see for yourself.
Mike.
--
To unsubscribe from this list:
In article
xs4all.cammfjbpkgd28070a0jvmyl02juyw5tuwnmvwrj-1gfzknhc...@mail.gmail.com you
write:
When the init process is created on system startup, does it have any
open file descriptors? If so, where do they point?
0, 1 and 2, which are connected to the console. Boot a kernel with
On 08/20/2012 01:34 AM, Stan Hoeppner wrote:
I'm glad you jumped in David. You made a critical statement of fact
below which clears some things up. If you had stated it early on,
before Miquel stole the thread and moved it to LKML proper, it would
have short circuited a lot of this discussion.
On 08/20/2012 01:34 AM, Stan Hoeppner wrote:
I'm glad you jumped in David. You made a critical statement of fact
below which clears some things up. If you had stated it early on,
before Miquel stole the thread and moved it to LKML proper, it would
have short circuited a lot of this discussion.
On 08/17/2012 09:31 AM, Stan Hoeppner wrote:
On 8/16/2012 4:50 PM, Miquel van Smoorenburg wrote:
I did a simple test:
* created a 1G partition on 3 seperate disks
* created a md raid5 array with 512K chunksize:
mdadm -C /dev/md0 -l 5 -c $((1024*512)) -n 3 /dev/sdb1 /dev/sdc1
/dev/sdd1
* ran
On 08/17/2012 09:31 AM, Stan Hoeppner wrote:
On 8/16/2012 4:50 PM, Miquel van Smoorenburg wrote:
I did a simple test:
* created a 1G partition on 3 seperate disks
* created a md raid5 array with 512K chunksize:
mdadm -C /dev/md0 -l 5 -c $((1024*512)) -n 3 /dev/sdb1 /dev/sdc1
/dev/sdd1
* ran
On 16-08-12 1:05 PM, Stan Hoeppner wrote:
On 8/15/2012 6:07 PM, Miquel van Smoorenburg wrote:
Ehrm no. If you modify, say, a 4K block on a RAID5 array, you just have
to read that 4K block, and the corresponding 4K block on the
parity drive, recalculate parity, and write back 4K of data and 4K
On 16-08-12 1:05 PM, Stan Hoeppner wrote:
On 8/15/2012 6:07 PM, Miquel van Smoorenburg wrote:
Ehrm no. If you modify, say, a 4K block on a RAID5 array, you just have
to read that 4K block, and the corresponding 4K block on the
parity drive, recalculate parity, and write back 4K of data and 4K
In article you write:
>It's time to blow away the array and start over. You're already
>misaligned, and a 512KB chunk is insanely unsuitable for parity RAID,
>but for a handful of niche all streaming workloads with little/no
>rewrite, such as video surveillance or DVR workloads.
>
>Yes, 512KB is
In article xs4all.502c1c01.1040...@hardwarefreak.com you write:
It's time to blow away the array and start over. You're already
misaligned, and a 512KB chunk is insanely unsuitable for parity RAID,
but for a handful of niche all streaming workloads with little/no
rewrite, such as video
In article <[EMAIL PROTECTED]>,
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
>On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
>>
>>hi !
>>
>>i was wondering how to make kernel messages appear on /dev/ttyS0
>without a reboot, i.e. kernelparam "console=ttyS0"
>
>The solution is simple... the following
In article [EMAIL PROTECTED],
Jan Engelhardt [EMAIL PROTECTED] wrote:
On Jan 3 2008 13:43, [EMAIL PROTECTED] wrote:
hi !
i was wondering how to make kernel messages appear on /dev/ttyS0
without a reboot, i.e. kernelparam console=ttyS0
The solution is simple... the following piece of code is
it set pci_set_dma_mask(pDev, DMA_64BIT_MASK) .
Signed-off-by: Miquel van Smoorenburg <[EMAIL PROTECTED]>
diff -ruN linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c
linux-2.6.23.9/drivers/scsi/dpt_i2o.c
--- linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c 2007-11-26 18:51:43.0
+0100
+++ linux-2.6.23.9/
(pDev, DMA_64BIT_MASK) .
Signed-off-by: Miquel van Smoorenburg [EMAIL PROTECTED]
diff -ruN linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c
linux-2.6.23.9/drivers/scsi/dpt_i2o.c
--- linux-2.6.23.9.orig/drivers/scsi/dpt_i2o.c 2007-11-26 18:51:43.0
+0100
+++ linux-2.6.23.9/drivers/scsi
On Wed, 2007-12-12 at 03:38 -0800, Andrew Morton wrote:
> On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke <[EMAIL PROTECTED]> wrote:
>
> > Hi,
> >
> > I'd like to let you now that my boxes are running a 32-bit kernel, so
> > the 64-bit-uncleanliness shouldn't apply to my boxes; however,
> >
> >
On Wed, 2007-12-12 at 03:38 -0800, Andrew Morton wrote:
On Wed, 12 Dec 2007 11:58:41 +0100 Anders Henke [EMAIL PROTECTED] wrote:
Hi,
I'd like to let you now that my boxes are running a 32-bit kernel, so
the 64-bit-uncleanliness shouldn't apply to my boxes; however,
On Tue, 2007-12-11 at 15:40 +0100, Miquel van Smoorenburg wrote:
> I just noticed the same bug when I tried to update a 2.6.18 server to
> 2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init
> segfaults, or can't be found .. anyway, driver/fs errors.
>
> In th
On Fri, 2007-11-30 at 11:34 +0100, Anders Henke wrote:
> Am 30.11.2007 schrieb FUJITA Tomonori:
> > > > > According to the 2.6.23-rc1 short-form changelog, there is
> > > > > one major edit on the dpt_i2o driver:
> > > > >
> > > > > FUJITA Tomonori
> > > > >
> > > > > [SCSI] dpt_i2o:
On Fri, 2007-11-30 at 11:34 +0100, Anders Henke wrote:
Am 30.11.2007 schrieb FUJITA Tomonori:
According to the 2.6.23-rc1 short-form changelog, there is
one major edit on the dpt_i2o driver:
FUJITA Tomonori
[SCSI] dpt_i2o: convert to use the data buffer
On Tue, 2007-12-11 at 15:40 +0100, Miquel van Smoorenburg wrote:
I just noticed the same bug when I tried to update a 2.6.18 server to
2.6.23.9 .. also tried 2.6.24-rc4. The symptom I'm seeing is that init
segfaults, or can't be found .. anyway, driver/fs errors.
In the kernel config, under
In article <[EMAIL PROTECTED]>,
Denys Vlasenko <[EMAIL PROTECTED]> wrote:
>Hi Ulrich,
>
>On Friday 28 September 2007 18:34, Ulrich Drepper wrote:
>> One more small change to extend the availability of creation of
>> file descriptors with FD_CLOEXEC set. Adding a new command to
>> fcntl()
In article [EMAIL PROTECTED],
Denys Vlasenko [EMAIL PROTECTED] wrote:
Hi Ulrich,
On Friday 28 September 2007 18:34, Ulrich Drepper wrote:
One more small change to extend the availability of creation of
file descriptors with FD_CLOEXEC set. Adding a new command to
fcntl() requires no new
In article <[EMAIL PROTECTED]> you write:
>Hello Damien, people...
>
>Damien Wyart wrote:
>> Hello,
>>
>> After trying 2.6.22-rc2, I noticed the warning message from libata about
>> upgrading shutdown(8). First, I have two SATA disks, and get the warning for
>> only one of them. Second, I
In article [EMAIL PROTECTED] you write:
Hello Damien, people...
Damien Wyart wrote:
Hello,
After trying 2.6.22-rc2, I noticed the warning message from libata about
upgrading shutdown(8). First, I have two SATA disks, and get the warning for
only one of them. Second, I double-checked the
In article <[EMAIL PROTECTED]> you write:
>Its a Juniper M7i
>It comes default with a 5400 rpm laptop 2.5" harddrive but now we
>bought a more robust "server" 2.5" harddrive. It still barfs on the OS
>install, so the linux is doing all the job now. Will get a juniper guy
>to come and fix :)
>
>As
In article [EMAIL PROTECTED] you write:
Its a Juniper M7i
It comes default with a 5400 rpm laptop 2.5 harddrive but now we
bought a more robust server 2.5 harddrive. It still barfs on the OS
install, so the linux is doing all the job now. Will get a juniper guy
to come and fix :)
As a side note,
In article <[EMAIL PROTECTED]> you write:
>On May 02, 2007 18:23 +0530, Amit K. Arora wrote:
>> On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:
>> > On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:
>> >
>> > > For FA_ALLOCATE, it's supposed to change the file size
In article [EMAIL PROTECTED] you write:
On May 02, 2007 18:23 +0530, Amit K. Arora wrote:
On Sun, Apr 29, 2007 at 10:25:59PM -0700, Chris Wedgwood wrote:
On Mon, Apr 30, 2007 at 10:47:02AM +1000, David Chinner wrote:
For FA_ALLOCATE, it's supposed to change the file size if we
In article <[EMAIL PROTECTED]> you write:
>I was actually _really_ hoping that somebody would come along and tell
>everybody that this whole journal-logging is stupid, and that it's just
>better to not ever re-write blocks on disk, but instead write to new
>blocks with version numbers (and not
In article [EMAIL PROTECTED] you write:
I was actually _really_ hoping that somebody would come along and tell
everybody that this whole journal-logging is stupid, and that it's just
better to not ever re-write blocks on disk, but instead write to new
blocks with version numbers (and not re-use
In article <[EMAIL PROTECTED]>,
Jeff Chua <[EMAIL PROTECTED]> wrote:
>On 12 Feb 2007 10:02:28 +0100, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
>> > stat() returns time in seconds,
>>
>> Not correct (at least for glibc stat). It supports nanoseconds these days,
>> although not all file systems
In article [EMAIL PROTECTED],
Jeff Chua [EMAIL PROTECTED] wrote:
On 12 Feb 2007 10:02:28 +0100, Andi Kleen [EMAIL PROTECTED] wrote:
stat() returns time in seconds,
Not correct (at least for glibc stat). It supports nanoseconds these days,
although not all file systems (including ext3) do
In article <[EMAIL PROTECTED]>,
Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
>Miquel van Smoorenburg wrote on Wednesday, December 13, 2006 1:57 AM
>> Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
>> >This rawio test plows through sequential I/O and modulo each sma
In article <[EMAIL PROTECTED]>,
Chen, Kenneth W <[EMAIL PROTECTED]> wrote:
>This rawio test plows through sequential I/O and modulo each small record
>over number of threads. So each thread appears to be non-contiguous within
>its own process context, overall request hitting the device are
In article [EMAIL PROTECTED],
Chen, Kenneth W [EMAIL PROTECTED] wrote:
This rawio test plows through sequential I/O and modulo each small record
over number of threads. So each thread appears to be non-contiguous within
its own process context, overall request hitting the device are sequential.
I
In article [EMAIL PROTECTED],
Chen, Kenneth W [EMAIL PROTECTED] wrote:
Miquel van Smoorenburg wrote on Wednesday, December 13, 2006 1:57 AM
Chen, Kenneth W [EMAIL PROTECTED] wrote:
This rawio test plows through sequential I/O and modulo each small record
over number of threads. So each thread
In article <[EMAIL PROTECTED]>,
Oleg Verych <[EMAIL PROTECTED]> wrote:
>On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
>> > > > I found that sometimes processes disappear on some heavily used system
>> > > > of mine without any logging. So I've written a patch against
In article [EMAIL PROTECTED],
Oleg Verych [EMAIL PROTECTED] wrote:
On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote:
I found that sometimes processes disappear on some heavily used system
of mine without any logging. So I've written a patch against 2.6.18.2
which
In article <[EMAIL PROTECTED]>,
Xie, Bill <[EMAIL PROTECTED]> wrote:
>All,
>
>I am testing the multi-threaded IO performance on Opteron servers.
>
>I use dd as the test tools. The single dd can reach 60MBps for single disk.
>
>on 2.6.5 kernel, If dd numbers exceed the CPU numbers, vmstat bi
In article [EMAIL PROTECTED],
Xie, Bill [EMAIL PROTECTED] wrote:
All,
I am testing the multi-threaded IO performance on Opteron servers.
I use dd as the test tools. The single dd can reach 60MBps for single disk.
on 2.6.5 kernel, If dd numbers exceed the CPU numbers, vmstat bi reduced
to
In article <[EMAIL PROTECTED]>,
Erik Mouw <[EMAIL PROTECTED]> wrote:
>On Wed, Jul 20, 2005 at 02:16:36PM +0200, Bastiaan Naber wrote:
>> I have a 15 GB file which I want to place in memory via tmpfs. I want to do
>> this because I need to have this data accessible with a very low seek time.
>
In article [EMAIL PROTECTED],
Erik Mouw [EMAIL PROTECTED] wrote:
On Wed, Jul 20, 2005 at 02:16:36PM +0200, Bastiaan Naber wrote:
I have a 15 GB file which I want to place in memory via tmpfs. I want to do
this because I need to have this data accessible with a very low seek time.
That should
In article <[EMAIL PROTECTED]>,
Adnan Khaleel <[EMAIL PROTECTED]> wrote:
>Thanks for your suggestions. I have been working with Simics, SimNow and
>Bochs. I've had mixed luck with all of them. Although Simics should be
>the most promising, I've really had
>an uphill struggle with it especially
In article [EMAIL PROTECTED],
Adnan Khaleel [EMAIL PROTECTED] wrote:
Thanks for your suggestions. I have been working with Simics, SimNow and
Bochs. I've had mixed luck with all of them. Although Simics should be
the most promising, I've really had
an uphill struggle with it especially when it
In article <[EMAIL PROTECTED]>,
David Masover <[EMAIL PROTECTED]> wrote:
>Markus Törnqvist wrote:
>> Anyway, I don't really like the metafs thing.
>>
>> To access the data, you still need to refactor userspace,
>> so that's not a real advantage. Doing lookups from /meta
>> all the time, instead
In article [EMAIL PROTECTED],
David Masover [EMAIL PROTECTED] wrote:
Markus Törnqvist wrote:
Anyway, I don't really like the metafs thing.
To access the data, you still need to refactor userspace,
so that's not a real advantage. Doing lookups from /meta
all the time, instead of in the
In article <[EMAIL PROTECTED]>,
Takashi Ikebe <[EMAIL PROTECTED]> wrote:
>Chris Wedgwood wrote:
>> On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:>
>>
>>>To takeover the application status, connection type
>>>communications(SOCK_STREAM) are need to be disconnected by close().
In article [EMAIL PROTECTED],
Takashi Ikebe [EMAIL PROTECTED] wrote:
Chris Wedgwood wrote:
On Wed, Apr 20, 2005 at 04:35:07PM +0900, Takashi Ikebe wrote:
To takeover the application status, connection type
communications(SOCK_STREAM) are need to be disconnected by close().
Same network port
On Fri, 2005-04-15 at 15:52 +0100, Alan Cox wrote:
> On Mer, 2005-04-13 at 17:03, Miquel van Smoorenburg wrote:
> > I have a supermicro dual xeon em64t system, X6DH8-XG2 motherboard,
> > 4 GB RAM, with an Adaptec zero raid 2010S i2o controller. In 32
> > bits mo
On Fri, 2005-04-15 at 15:52 +0100, Alan Cox wrote:
On Mer, 2005-04-13 at 17:03, Miquel van Smoorenburg wrote:
I have a supermicro dual xeon em64t system, X6DH8-XG2 motherboard,
4 GB RAM, with an Adaptec zero raid 2010S i2o controller. In 32
bits mode it runs fine, both with the dpt_i2o
I have a supermicro dual xeon em64t system, X6DH8-XG2 motherboard,
4 GB RAM, with an Adaptec zero raid 2010S i2o controller. In 32
bits mode it runs fine, both with the dpt_i2o driver and the
generic i2o_block driver using kernel 2.6.11.6.
In 64 bits mode however the dpt_i2o driver isn't
I have a supermicro dual xeon em64t system, X6DH8-XG2 motherboard,
4 GB RAM, with an Adaptec zero raid 2010S i2o controller. In 32
bits mode it runs fine, both with the dpt_i2o driver and the
generic i2o_block driver using kernel 2.6.11.6.
In 64 bits mode however the dpt_i2o driver isn't
In article <[EMAIL PROTECTED]>,
Andrew Morton <[EMAIL PROTECTED]> wrote:
>Greg Edwards <[EMAIL PROTECTED]> wrote:
>>
>> According to include/linux/console.h, CON_CONSDEV flag should be set on
>> the last console specified on the boot command line:
>>
>> 86 #define CON_PRINTBUFFER (1)
>>
In article [EMAIL PROTECTED],
Andrew Morton [EMAIL PROTECTED] wrote:
Greg Edwards [EMAIL PROTECTED] wrote:
According to include/linux/console.h, CON_CONSDEV flag should be set on
the last console specified on the boot command line:
86 #define CON_PRINTBUFFER (1)
87 #define
References:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103392
http://lkml.org/lkml/2004/12/21/208
http://lkml.org/lkml/2004/11/2/17
At Tue, 21 Dec 2004 16:39:43 -0800 (PST) Chris Stromsoe wrote:
> I'm still seeing this problem. It repeats every week or week and a half,
> usually
References:
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=103392
http://lkml.org/lkml/2004/12/21/208
http://lkml.org/lkml/2004/11/2/17
At Tue, 21 Dec 2004 16:39:43 -0800 (PST) Chris Stromsoe wrote:
I'm still seeing this problem. It repeats every week or week and a half,
usually
On Mon, 21 Mar 2005 23:09:42, Andrew Morton wrote:
> "Miquel van Smoorenburg" <[EMAIL PROTECTED]> wrote:
> >
> > I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
> > use "iostat -k -x 2" to see live how busy the disks are. But
> >
On Mon, 21 Mar 2005 23:09:42, Andrew Morton wrote:
Miquel van Smoorenburg [EMAIL PROTECTED] wrote:
I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
use iostat -k -x 2 to see live how busy the disks are. But
I don't believe that Linux optimizes things so much that a disk
In article <[EMAIL PROTECTED]>,
Berkley Shands <[EMAIL PROTECTED]> wrote:
>I have not found any documentation of efforts to overcome the 2TB
>partition limit,
config LBD
bool "Support for Large Block Devices"
depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH
In article [EMAIL PROTECTED],
Berkley Shands [EMAIL PROTECTED] wrote:
I have not found any documentation of efforts to overcome the 2TB
partition limit,
config LBD
bool Support for Large Block Devices
depends on X86 || MIPS32 || PPC32 || ARCH_S390_31 || SUPERH
help
In article <[EMAIL PROTECTED]>,
Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>In article <[EMAIL PROTECTED]>,
>Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>>I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
>>use "iostat -k -x
In article [EMAIL PROTECTED],
Miquel van Smoorenburg [EMAIL PROTECTED] wrote:
In article [EMAIL PROTECTED],
Miquel van Smoorenburg [EMAIL PROTECTED] wrote:
I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
use iostat -k -x 2 to see live how busy the disks are. But
I don't believe
In article <[EMAIL PROTECTED]>,
Rick Lindsley <[EMAIL PROTECTED]> wrote:
>Mike -- where did you get your iostat from? There's a couple of different
>flavors out there and it may not make a difference but just in case ...
Debian, sysstat+5.0.6-4
I know about the iostat problems - there were
In article <[EMAIL PROTECTED]>,
Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
>use "iostat -k -x 2" to see live how busy the disks are. But
>I don't believe that Linux optimizes things so much th
I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
use "iostat -k -x 2" to see live how busy the disks are. But
I don't believe that Linux optimizes things so much that a disk
can be 1849.55% busy :)
(you'll have to stretch out your xterm to be able to read this):
Device:rrqm/s
I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
use iostat -k -x 2 to see live how busy the disks are. But
I don't believe that Linux optimizes things so much that a disk
can be 1849.55% busy :)
(you'll have to stretch out your xterm to be able to read this):
Device:rrqm/s
In article [EMAIL PROTECTED],
Miquel van Smoorenburg [EMAIL PROTECTED] wrote:
I just upgrades one of our newsservers from 2.6.9 to 2.6.11. I
use iostat -k -x 2 to see live how busy the disks are. But
I don't believe that Linux optimizes things so much that a disk
can be 1849.55% busy
In article [EMAIL PROTECTED],
Rick Lindsley [EMAIL PROTECTED] wrote:
Mike -- where did you get your iostat from? There's a couple of different
flavors out there and it may not make a difference but just in case ...
Debian, sysstat+5.0.6-4
I know about the iostat problems - there were 32/64 bit
In article <[EMAIL PROTECTED]>,
Lee Revell <[EMAIL PROTECTED]> wrote:
>On Tue, 2005-03-01 at 12:20 -0800, Ben Greear wrote:
>> What happens if you just don't muck with the NIC and let it auto-negotiate
>> on it's own?
>
>This can be asking for trouble too (auto negotiation is often buggy).
>What
In article [EMAIL PROTECTED],
Lee Revell [EMAIL PROTECTED] wrote:
On Tue, 2005-03-01 at 12:20 -0800, Ben Greear wrote:
What happens if you just don't muck with the NIC and let it auto-negotiate
on it's own?
This can be asking for trouble too (auto negotiation is often buggy).
What if you hard
In article <[EMAIL PROTECTED]>,
Helge Hafting <[EMAIL PROTECTED]> wrote:
>Bernd Petrovitsch wrote:
>>This would be a win (especially if the numbers are tweked to tune this)
>>with a relatively small effort.
>>However for real dependencies and parallelism you want the info similar
>>to creat a
In article [EMAIL PROTECTED],
Helge Hafting [EMAIL PROTECTED] wrote:
Bernd Petrovitsch wrote:
This would be a win (especially if the numbers are tweked to tune this)
with a relatively small effort.
However for real dependencies and parallelism you want the info similar
to creat a Makefile from it
In article <[EMAIL PROTECTED]>,
Oded Shimon <[EMAIL PROTECTED]> wrote:
>I have implemented this, but it has a major disadvantage - every 'write()'
>only write 4k at a time, never more, because of how non-blocking pipes are
>done. at 20,000 context switches a second, this method reaches barely
In article <[EMAIL PROTECTED]>,
Linus Torvalds <[EMAIL PROTECTED]> wrote:
>
>On Sat, 15 Jan 2005, Alan Cox wrote:
>>
>> Alan Cox (the other Alan Cox not me)
>
>Oh no! You guys are multiplying!
http://www.imdb.com/name/nm0184893/
Mike.
-
To unsubscribe from this list: send the line
In article [EMAIL PROTECTED],
Linus Torvalds [EMAIL PROTECTED] wrote:
On Sat, 15 Jan 2005, Alan Cox wrote:
Alan Cox (the other Alan Cox not me)
Oh no! You guys are multiplying!
http://www.imdb.com/name/nm0184893/
Mike.
-
To unsubscribe from this list: send the line unsubscribe
In article <[EMAIL PROTECTED]>,
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
>Hi,
>
>On Wed, Jul 04, 2001 at 06:27:13PM +, Miquel van Smoorenburg wrote:
>>
>> Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL))
>
>What for?
In article <[EMAIL PROTECTED]>,
Stephen C. Tweedie <[EMAIL PROTECTED]> wrote:
>For these reasons, buffered IO is often faster than O_DIRECT for pure
>sequential access. The downside it its greater CPU cost and the fact
>that it pollutes the cache (which, in turn, causes even _more_ CPU
>overhead
In article [EMAIL PROTECTED],
Stephen C. Tweedie [EMAIL PROTECTED] wrote:
For these reasons, buffered IO is often faster than O_DIRECT for pure
sequential access. The downside it its greater CPU cost and the fact
that it pollutes the cache (which, in turn, causes even _more_ CPU
overhead when
In article [EMAIL PROTECTED],
Stephen C. Tweedie [EMAIL PROTECTED] wrote:
Hi,
On Wed, Jul 04, 2001 at 06:27:13PM +, Miquel van Smoorenburg wrote:
Any chance of something like O_SEQUENTIAL (like madvise(MADV_SEQUENTIAL))
What for? The kernel already optimises readahead and writebehind
In article <[EMAIL PROTECTED]>,
Tommy Reynolds <[EMAIL PROTECTED]> wrote:
>Linus Torvalds <[EMAIL PROTECTED]> was pleased to say:
>
>> If they are shut off, then where's the drumming? Because if people start
>> making copyright printk's normal, I will make "quiet" the default.
>
>Amen. This is
In article [EMAIL PROTECTED],
Tommy Reynolds [EMAIL PROTECTED] wrote:
Linus Torvalds [EMAIL PROTECTED] was pleased to say:
If they are shut off, then where's the drumming? Because if people start
making copyright printk's normal, I will make quiet the default.
Amen. This is like editing a
In article <[EMAIL PROTECTED]>,
Helge Hafting <[EMAIL PROTECTED]> wrote:
>richard offer wrote:
>>
>> In arch/i386/kernel/ptrace.c there is the following code ...
>>
>> ret = -EPERM;
>> if (pid == 1) /* you may not mess with init */
>> goto out_tsk;
>>
In article [EMAIL PROTECTED],
Helge Hafting [EMAIL PROTECTED] wrote:
richard offer wrote:
In arch/i386/kernel/ptrace.c there is the following code ...
ret = -EPERM;
if (pid == 1) /* you may not mess with init */
goto out_tsk;
What is the
In article <[EMAIL PROTECTED]>,
Narayan Desai <[EMAIL PROTECTED]> wrote:
>>>>>> "Mike" == Miquel van Smoorenburg <[EMAIL PROTECTED]> writes:
>
>Mike> In article <[EMAIL PROTECTED]>,
>Mike> Narayan Desai <[EMAIL PROTECTED]>
In article <[EMAIL PROTECTED]>,
Narayan Desai <[EMAIL PROTECTED]> wrote:
>Hi. I have started having serial console problems in the last bunch of
>kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels (up
>to and including 2.4.5-ac4) and the problem has persisted. The problem
>is
In article [EMAIL PROTECTED],
Narayan Desai [EMAIL PROTECTED] wrote:
Hi. I have started having serial console problems in the last bunch of
kernel releases. I have tried various 2.4.4 and 2.4.5 ac kernels (up
to and including 2.4.5-ac4) and the problem has persisted. The problem
is basically that
In article [EMAIL PROTECTED],
Narayan Desai [EMAIL PROTECTED] wrote:
Mike == Miquel van Smoorenburg [EMAIL PROTECTED] writes:
Mike In article [EMAIL PROTECTED],
Mike Narayan Desai [EMAIL PROTECTED] wrote:
Hi. I have started having serial console problems in the last bunch
of kernel releases
In article <00c701c0e6d8$2b28ea40$4aa6b3d0@Toshiba>,
Jaswinder Singh <[EMAIL PROTECTED]> wrote:
>I am not able to understand why Linux read and/or write harddisk after some
>time (after few hours ) , harddisk read/write leds keep on glowing for few
>minutes , even though nobody working on it and
In article 00c701c0e6d8$2b28ea40$4aa6b3d0@Toshiba,
Jaswinder Singh [EMAIL PROTECTED] wrote:
I am not able to understand why Linux read and/or write harddisk after some
time (after few hours ) , harddisk read/write leds keep on glowing for few
minutes , even though nobody working on it and machine
According to Kurt Roeckx:
> On Tue, Apr 10, 2001 at 11:20:24PM +0000, Miquel van Smoorenburg wrote:
> > The "-1" means
> > "all processes except me". That means init will get hit with
> > SIGTERM occasionally during shutdown, and that might cause
In article <9b04fo$9od$[EMAIL PROTECTED]>,
Miquel van Smoorenburg <[EMAIL PROTECTED]> wrote:
>SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
>good reason; on some (many?) systems, the shutdown scripts
>include "kill -15 -1; sleep 2; kill -9 -1".
In article <[EMAIL PROTECTED]>,
Pavel Machek <[EMAIL PROTECTED]> wrote:
>Hi!
>
>Init should get to know that user pressed power button (so it can do
>shutdown and poweroff). Plus, it is nice to let user know that we can
>read such event. [I hunted bug for few hours, thinking that kernel
>does
In article [EMAIL PROTECTED],
Pavel Machek [EMAIL PROTECTED] wrote:
Hi!
Init should get to know that user pressed power button (so it can do
shutdown and poweroff). Plus, it is nice to let user know that we can
read such event. [I hunted bug for few hours, thinking that kernel
does not get the
In article 9b04fo$9od$[EMAIL PROTECTED],
Miquel van Smoorenburg [EMAIL PROTECTED] wrote:
SIGTERM is a bad choise. Right now, init ignores SIGTERM. For
good reason; on some (many?) systems, the shutdown scripts
include "kill -15 -1; sleep 2; kill -9 -1". The "-1" means
&quo
According to Kurt Roeckx:
On Tue, Apr 10, 2001 at 11:20:24PM +, Miquel van Smoorenburg wrote:
The "-1" means
"all processes except me". That means init will get hit with
SIGTERM occasionally during shutdown, and that might cause
weird things to happen.
-1 mean
In article <[EMAIL PROTECTED]>,
Jamie Lokier <[EMAIL PROTECTED]> wrote:
>Miquel van Smoorenburg wrote:
>> .. but there should be a cleaner way to get at the CFLAGS used
>> to compile the kernel.
>
>There is a way though I'd not call it clean. Here is an extract
1 - 100 of 203 matches
Mail list logo
