Re: Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?

On 19 Sep 2012, Chris Murphy outgrape: On Sep 19, 2012, at 12:52 PM, Nix wrote: So I have this x86-64 server running Linux 3.5.1 with a SATA-on-PCIe Areca 1210 hardware RAID-5 controller Did you find this? Same controller family. Weird that this just shows up now, but perhaps instead

Re: Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?

On 19 Sep 2012, Stan Hoeppner stated: > On 9/19/2012 1:52 PM, Nix wrote: >> So I have this x86-64 server running Linux 3.5.1 > > When did you install 3.5.1 on this machine? Forty days ago. > If fairly recently, does it > run

Re: Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?

On 19 Sep 2012, Stan Hoeppner stated: On 9/19/2012 1:52 PM, Nix wrote: So I have this x86-64 server running Linux 3.5.1 When did you install 3.5.1 on this machine? Forty days ago. If fairly recently, does it run without these errors when

Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?

So I have this x86-64 server running Linux 3.5.1 with a SATA-on-PCIe Areca 1210 hardware RAID-5 controller driven by libata which has been humming along happily for years -- but suddenly, today, the entire machine froze for a couple of minutes (or at least fs access froze), followed by this in the

Areca hardware RAID / first-ever SCSI bus reset: am I about to lose this disk controller?

So I have this x86-64 server running Linux 3.5.1 with a SATA-on-PCIe Areca 1210 hardware RAID-5 controller driven by libata which has been humming along happily for years -- but suddenly, today, the entire machine froze for a couple of minutes (or at least fs access froze), followed by this in the

Re: [3.5 regression] DRM: Massive (EDID-probing?) X startup delay on ATI Radeon RV770 (HD4870)

On 6 Aug 2012, Alex Deucher verbalised: > On Sat, Aug 4, 2012 at 12:13 PM, Nix wrote: >> Possibly-relevant info: >> >> - Two DVI monitors, identical specs, one dual-head graphics card >>(so no VGA switcheroo or awesome-yet-terrifying PRIME madness needed) &

Re: [3.5 regression] DRM: Massive (EDID-probing?) X startup delay on ATI Radeon RV770 (HD4870)

On 6 Aug 2012, Alex Deucher verbalised: On Sat, Aug 4, 2012 at 12:13 PM, Nix n...@esperi.org.uk wrote: Possibly-relevant info: - Two DVI monitors, identical specs, one dual-head graphics card (so no VGA switcheroo or awesome-yet-terrifying PRIME madness needed) - KMS, Xserver 1.12.3

Re: [3.5 regression] DRM: Massive (EDID-probing?) X startup delay on ATI Radeon RV770 (HD4870)

On 6 Aug 2012, Alex Deucher outgrape: > On Sat, Aug 4, 2012 at 12:13 PM, Nix wrote: >> Something appears to be wrong, but I have no idea what. I've not changed >> anything other than the kernel since my last non-huge-delayed startup >> earlier this week, and both th

Re: [3.5 regression] DRM: Massive (EDID-probing?) X startup delay on ATI Radeon RV770 (HD4870)

On 6 Aug 2012, Alex Deucher outgrape: On Sat, Aug 4, 2012 at 12:13 PM, Nix n...@esperi.org.uk wrote: Something appears to be wrong, but I have no idea what. I've not changed anything other than the kernel since my last non-huge-delayed startup earlier this week, and both the monitors still

[3.5 regression] DRM: Massive (EDID-probing?) X startup delay on ATI Radeon RV770 (HD4870)

Possibly-relevant info: - Two DVI monitors, identical specs, one dual-head graphics card (so no VGA switcheroo or awesome-yet-terrifying PRIME madness needed) - KMS, Xserver 1.12.3, driver 6.14.6-28 (trunk current as of today), Mesa 8.0.4, libdrm 2.4.37 As of kernel 3.5 EDID probing of

[3.5 regression] DRM: Massive (EDID-probing?) X startup delay on ATI Radeon RV770 (HD4870)

Possibly-relevant info: - Two DVI monitors, identical specs, one dual-head graphics card (so no VGA switcheroo or awesome-yet-terrifying PRIME madness needed) - KMS, Xserver 1.12.3, driver 6.14.6-28 (trunk current as of today), Mesa 8.0.4, libdrm 2.4.37 As of kernel 3.5 EDID probing of

Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?

On 24 Feb 2008, Peter Osterlund told this: > Nix <[EMAIL PROTECTED]> writes: >> But while I'd normally blame pktcdvd there's only one pktcdvd function >> in these tracebacks (pkt_open) and it's not got a significant stack >> footprint. > > Did you verify th

Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?

On 24 Feb 2008, [EMAIL PROTECTED] outgrape: > A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device) > sees a stack overflow in four or five tries. Doing the same thing with > the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash. > (This may or may not be

Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount - stack overflow: ide-cd related? dm-related?

On 24 Feb 2008, [EMAIL PROTECTED] outgrape: A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device) sees a stack overflow in four or five tries. Doing the same thing with the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash. (This may or may not be

Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount - stack overflow: ide-cd related? dm-related?

On 24 Feb 2008, Peter Osterlund told this: Nix [EMAIL PROTECTED] writes: But while I'd normally blame pktcdvd there's only one pktcdvd function in these tracebacks (pkt_open) and it's not got a significant stack footprint. Did you verify that with make checkstack or just by looking

2.6.24.2: 4KSTACKS + PCA403CD IDE CD + pcdrw + mount + PREEMPT -> stack overflow

A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device) sees a stack overflow in four or five tries. Doing the same thing with the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash. Here's a couple of oopses. config follows. (There are a wide variety. Some I

2.6.24.2: 4KSTACKS + PCA403CD IDE CD + pcdrw + mount + PREEMPT - stack overflow

A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device) sees a stack overflow in four or five tries. Doing the same thing with the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash. Here's a couple of oopses. config follows. (There are a wide variety. Some I

Re: Upgrade to 2.6.24 breaks NFS service

On 13 Feb 2008, Jeff Layton told this: > If upgrading nfs-utils doesn't help, on this box, could you run: > > # rpcinfo -p localhost > > send the output? statd expects that lockd will always be listening on a > UDP socket and some changes recently made it so that when there are > only TCP mounts

Upgrade to 2.6.24 breaks NFS service

I upgraded from 2.6.23.10 to 2.6.24.2 yesterday, and found NFS service failing. To be specific, all locks were blocking forever, with an endless flood of Feb 12 22:53:10 loki notice: kernel: statd: server localhost not responding, timed out Feb 12 22:53:10 loki notice: kernel: lockd: cannot

Re: Upgrade to 2.6.24 breaks NFS service

On 13 Feb 2008, Jeff Layton told this: If upgrading nfs-utils doesn't help, on this box, could you run: # rpcinfo -p localhost send the output? statd expects that lockd will always be listening on a UDP socket and some changes recently made it so that when there are only TCP mounts that it

Re: Kernel 2.6.23.9 + mdadm 2.6.2-2 + Auto rebuild RAID1?

On 6 Dec 2007, Jan Engelhardt verbalised: > On Dec 5 2007 19:29, Nix wrote: >>> >>> On Dec 1 2007 06:19, Justin Piszcz wrote: >>> >>>> RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if >>>> you use 1.x superblocks with

Re: Kernel 2.6.23.9 + mdadm 2.6.2-2 + Auto rebuild RAID1?

On 6 Dec 2007, Jan Engelhardt verbalised: On Dec 5 2007 19:29, Nix wrote: On Dec 1 2007 06:19, Justin Piszcz wrote: RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if you use 1.x superblocks with LILO you can't boot) Says who? (Don't use LILO ;-) Well, your kernels must

Re: Kernel 2.6.23.9 + mdadm 2.6.2-2 + Auto rebuild RAID1?

On 1 Dec 2007, Jan Engelhardt uttered the following: > > On Dec 1 2007 06:19, Justin Piszcz wrote: > >> RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if >> you use 1.x superblocks with LILO you can't boot) > > Says who? (Don't use LILO ;-) Well, your kernels must be on a

Re: Kernel 2.6.23.9 + mdadm 2.6.2-2 + Auto rebuild RAID1?

On 1 Dec 2007, Jan Engelhardt uttered the following: On Dec 1 2007 06:19, Justin Piszcz wrote: RAID1, 0.90.03 superblocks (in order to be compatible with LILO, if you use 1.x superblocks with LILO you can't boot) Says who? (Don't use LILO ;-) Well, your kernels must be on a

sym53c8xx2: incredible sloth after parity error / SCSI bus reset

About once a year I get a SCSI parity error on one of my systems (the only one with SCSI). I presume the cabling is substandard, but given my coordination deficits and the rarity of the errors I'd do far more damage replacing it than leaving it be. I had one of these today. The system (2.6.23.9)

sym53c8xx2: incredible sloth after parity error / SCSI bus reset

About once a year I get a SCSI parity error on one of my systems (the only one with SCSI). I presume the cabling is substandard, but given my coordination deficits and the rarity of the errors I'd do far more damage replacing it than leaving it be. I had one of these today. The system (2.6.23.9)

Re: Is there any word about this bug in gcc ?

On 20 Nov 2007, H. Peter Anvin outgrape: > This one is definitely messy. There is absolutely no way to know what > gcc has miscompiled. Actually, since this only affects abs() calls containing multiplications or divisions by negative constants, you can at least make a pretty good guess as to its

Re: Is there any word about this bug in gcc ?

On 20 Nov 2007, H. Peter Anvin outgrape: This one is definitely messy. There is absolutely no way to know what gcc has miscompiled. Actually, since this only affects abs() calls containing multiplications or divisions by negative constants, you can at least make a pretty good guess as to its

Re: Exporting a lot of data to other processes?

On 25 Oct 2007, Ph. Marek told this: > -) use some ramfs/shmfs or similar, and overwrite the data occasionally >- not current data >- runtime overhead (processor load) This is roughly what the nscd implementation in glibc does: the client can work over a socket, but prefers to ask the

Re: Exporting a lot of data to other processes?

On 25 Oct 2007, Ph. Marek told this: -) use some ramfs/shmfs or similar, and overwrite the data occasionally - not current data - runtime overhead (processor load) This is roughly what the nscd implementation in glibc does: the client can work over a socket, but prefers to ask the daemon

Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.

On 22 Oct 2007, WANG Cong uttered the following: > I build UML for non-SMP x86. But I don't know about UML_NET_VDE. ;( > > Errors threw out by gcc (too many) are put here: > http://wangcong.org/down/errors.txt It's hard to tell without LOCALE=C, but those are the sorts of results I'd expect

Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.

On 22 Oct 2007, WANG Cong uttered the following: I build UML for non-SMP x86. But I don't know about UML_NET_VDE. ;( Errors threw out by gcc (too many) are put here: http://wangcong.org/down/errors.txt It's hard to tell without LOCALE=C, but those are the sorts of results I'd expect if

Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.

On 20 Oct 2007, Paolo Giarrusso told this: > Guess most people are not using SMP right now, and that the error disappears > without that setting It doesn't. It fails with non-SMP as well. Rob, your patch works for me. (Not that the reboot into 2.6.23.1 was problem-free: iproute2-071016 fails to

Re: [uml-devel] User Mode Linux still doesn't build in 2.6.23-final.

On 20 Oct 2007, Paolo Giarrusso told this: Guess most people are not using SMP right now, and that the error disappears without that setting It doesn't. It fails with non-SMP as well. Rob, your patch works for me. (Not that the reboot into 2.6.23.1 was problem-free: iproute2-071016 fails to

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 18 Sep 2007, J. Bruce Fields told this: > Also I suppose we should check which version of nfs-utils that fix is in > and make sure distributions are getting the fixed nfs-utils before they > get the new libc, or we're going to see this bug a lot Further info. This behaviour, although it is

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 18 Sep 2007, J. Bruce Fields told this: Also I suppose we should check which version of nfs-utils that fix is in and make sure distributions are getting the fixed nfs-utils before they get the new libc, or we're going to see this bug a lot Further info. This behaviour, although it is

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 18 Sep 2007, J. Bruce Fields stated: > On Tue, Sep 18, 2007 at 12:54:07AM +0100, Nix wrote: >> The code which calls new_do_write() looks like this: >> >> ,[ libio/fileops.c:_IO_new_file_xsputn() ] >> | if (do_write) >> |{ >> |

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 18 Sep 2007, J. Bruce Fields stated: On Tue, Sep 18, 2007 at 12:54:07AM +0100, Nix wrote: The code which calls new_do_write() looks like this: ,[ libio/fileops.c:_IO_new_file_xsputn() ] | if (do_write) |{ | count = new_do_write (f, s, do_write); | to_do -= count

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 17 Sep 2007, J. Bruce Fields stated: > On Mon, Sep 17, 2007 at 11:23:46PM +0100, Nix wrote: >> A while later we start seeing runs of malloc failures, which I think >> correlated with the unexplained pauses in NFS response: > > Actually, they're nothing to do with malloc

[2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

Back in early 2006 I reported persistent hangs on the NFS server, whereby all of a sudden about ten minutes after boot my primary NFS server would cease responding to NFS requests until it was rebooted. That time, the problem

[2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

Back in early 2006 I reported persistent hangs on the NFS server, whereby all of a sudden about ten minutes after boot my primary NFS server would cease responding to NFS requests until it was rebooted. http://www.ussg.iu.edu/hypermail/linux/kernel/0601.3/1631.html That time, the problem vanished

Re: [2.6.22.6] nfsd: fh_verify() `malloc failure' with lots of free memory leads to NFS hang

On 17 Sep 2007, J. Bruce Fields stated: On Mon, Sep 17, 2007 at 11:23:46PM +0100, Nix wrote: A while later we start seeing runs of malloc failures, which I think correlated with the unexplained pauses in NFS response: Actually, they're nothing to do with malloc failures--the message printed

Re: Thinking outside the box on file systems

On 20 Aug 2007, Helge Hafting stated: > Shooting down bad ideas saves tremendous amounts of work, > killing an idea at the discussion stage means the idea never > got to the much more labor-intensive implementation stage. > > This don't mean that all new ideas are killed, only the bad ones. Even

Re: Thinking outside the box on file systems

[Lurker delurking here: I've seen Marc pull this sort of trick on multiple mailing lists now and I've had enough. Coming up with wild ideas, thinking they must be ideas nobody else has ever considered, and never thinking them through for five minutes is sort of Marc's hallmark, I'm afraid.]

Re: Thinking outside the box on file systems

[Lurker delurking here: I've seen Marc pull this sort of trick on multiple mailing lists now and I've had enough. Coming up with wild ideas, thinking they must be ideas nobody else has ever considered, and never thinking them through for five minutes is sort of Marc's hallmark, I'm afraid.]

Re: Thinking outside the box on file systems

On 20 Aug 2007, Helge Hafting stated: Shooting down bad ideas saves tremendous amounts of work, killing an idea at the discussion stage means the idea never got to the much more labor-intensive implementation stage. This don't mean that all new ideas are killed, only the bad ones. Even the

Re: [PATCH 2/3] UML - Limit request size on COWed devices

On 13 Jul 2007, Jeff Dike uttered the following: > COWed devices can't handle more than 32 (64 on x86_64) sectors in one > request due to the size of the bitmap being carried around in the > io_thread_req. This feels like a -stable candidate to me. - To unsubscribe from this list: send the line

Re: [PATCH 2/3] UML - Limit request size on COWed devices

On 13 Jul 2007, Jeff Dike uttered the following: COWed devices can't handle more than 32 (64 on x86_64) sectors in one request due to the size of the bitmap being carried around in the io_thread_req. This feels like a -stable candidate to me. - To unsubscribe from this list: send the line

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 6 Jul 2007, Mike Frysinger spake thusly: > On Friday 06 July 2007, Nix wrote: >> On 5 Jul 2007, Bernhard Walle stated: >> >While cmake itself isn't the problem, >> > often, it also depends on the version of cmake that is installed. Th

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, Bernhard Walle stated: > * Nix <[EMAIL PROTECTED]> [2007-07-05 22:42]: >> >> My only real grouch with cmake is that the authors have invented a >> language with so bloody many capital letters in it. > > The real problem I see with cmake is that y

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, Bernhard Walle stated: * Nix [EMAIL PROTECTED] [2007-07-05 22:42]: My only real grouch with cmake is that the authors have invented a language with so bloody many capital letters in it. The real problem I see with cmake is that you need to have cmake installed on the build

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 6 Jul 2007, Mike Frysinger spake thusly: On Friday 06 July 2007, Nix wrote: On 5 Jul 2007, Bernhard Walle stated: While cmake itself isn't the problem, often, it also depends on the version of cmake that is installed. The good idea about auto* tools

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, Mike Frysinger outgrape: > On Thursday 05 July 2007, Bodo Eggert wrote: >> The Makefiles generated by autotools is a huge mess, if autotools got it >> wrong (again!), fixing them requires editing a lot of files. > > this looks like a no brainer to me: dont edit generated files

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, DervishD spake thusly: > * Bodo Eggert <[EMAIL PROTECTED]> dixit: >> Standardisation is good, but autotools (as they are used) usurally isn't. > > Usually, by picking other's project configure.in and tweak blindly. You'd think they'd never heard of autoscan... > My

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, Bodo Eggert outgrape: > I'm really really happy if I read 'edit Makefile.conf and run make...'. autobuild scripts find it a hell of a lot more annoying to edit a different makefile for every project than to run one unchanging config.site... It's hardly a killer, but it would be a

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 4 Jul 2007, DervishD stated: > Anyway, if you don't like mobs or you just don't want to try it, > that's fine, but please don't use autotools, it doesn't make much sense > for a linux only project, since you will be using only the "directory > choosing" part of autotools. Maybe a hand made

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 4 Jul 2007, DervishD stated: Anyway, if you don't like mobs or you just don't want to try it, that's fine, but please don't use autotools, it doesn't make much sense for a linux only project, since you will be using only the directory choosing part of autotools. Maybe a hand made script

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, Bodo Eggert outgrape: I'm really really happy if I read 'edit Makefile.conf and run make...'. autobuild scripts find it a hell of a lot more annoying to edit a different makefile for every project than to run one unchanging config.site... It's hardly a killer, but it would be a

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, DervishD spake thusly: * Bodo Eggert [EMAIL PROTECTED] dixit: Standardisation is good, but autotools (as they are used) usurally isn't. Usually, by picking other's project configure.in and tweak blindly. You'd think they'd never heard of autoscan... My favourite is

Re: [ANNOUNCE] util-linux-ng 2.13-rc1

On 5 Jul 2007, Mike Frysinger outgrape: On Thursday 05 July 2007, Bodo Eggert wrote: The Makefiles generated by autotools is a huge mess, if autotools got it wrong (again!), fixing them requires editing a lot of files. this looks like a no brainer to me: dont edit generated files There is a

Re: Is it time for remove (crap) ALSA from kernel tree ?

On 28 Jun 2007, Adrian Bunk outgrape: > Linux software not supporting ALSA has becoming quite esoteric. Indeed. This is why I haven't moaned much (or at all): aoss is ugly, sure, but you only need it for those rare apps which run for a long time or while other sounds are playing, on

Re: Is it time for remove (crap) ALSA from kernel tree ?

On 25 Jun 2007, Adrian Bunk stated: > If people often run into this problem it might make sense to deprecate > the in-kernel OSS emulation and point people to the userspace emulation > instead? So now people need to know internal implementation details like if a program uses ALSA or OSS

Re: Is it time for remove (crap) ALSA from kernel tree ?

On 25 Jun 2007, Adrian Bunk stated: If people often run into this problem it might make sense to deprecate the in-kernel OSS emulation and point people to the userspace emulation instead? So now people need to know internal implementation details like if a program uses ALSA or OSS interfaces

Re: Is it time for remove (crap) ALSA from kernel tree ?

On 28 Jun 2007, Adrian Bunk outgrape: Linux software not supporting ALSA has becoming quite esoteric. Indeed. This is why I haven't moaned much (or at all): aoss is ugly, sure, but you only need it for those rare apps which run for a long time or while other sounds are playing, on

Re: limits on raid

On 21 Jun 2007, Neil Brown stated: > I have that - apparently naive - idea that drives use strong checksum, > and will never return bad data, only good data or an error. If this > isn't right, then it would really help to understand what the cause of > other failures are before working out how to

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On 21 Jun 2007, Miklos Szeredi said: > I'm working on this actually. See this (and related patches) in -mm: > > > http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/unprivileged-mounts-add-user-mounts-to-the-kernel.patch > > This solves the

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On 21 Jun 2007, Miklos Szeredi said: I'm working on this actually. See this (and related patches) in -mm: http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.22-rc4/2.6.22-rc4-mm2/broken-out/unprivileged-mounts-add-user-mounts-to-the-kernel.patch This solves the user=

Re: limits on raid

On 21 Jun 2007, Neil Brown stated: I have that - apparently naive - idea that drives use strong checksum, and will never return bad data, only good data or an error. If this isn't right, then it would really help to understand what the cause of other failures are before working out how to

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On 20 Jun 2007, H. Peter Anvin verbalised: > Right now it is actually impossible to conclusively determine a > filesystem-relative path in the presence of bind (and possibly move) > mounts. This is highly desirable to be able to do in contexts that > involve non-Linux (or

Re: Adding subroot information to /proc/mounts, or obtaining that through other means

On 20 Jun 2007, H. Peter Anvin verbalised: Right now it is actually impossible to conclusively determine a filesystem-relative path in the presence of bind (and possibly move) mounts. This is highly desirable to be able to do in contexts that involve non-Linux (or

Re: Patch related with Fork Bombing Atack

On 1 Jun 2007, Jens Axboe told this: > I think Anand is assuming that because syslog may coalesce identical > messages into "repeated foo times" in the messages file, that it's not a > dos. That is of course wrong. Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.) -- `On a

Re: Patch related with Fork Bombing Atack

On 1 Jun 2007, Jens Axboe told this: I think Anand is assuming that because syslog may coalesce identical messages into repeated foo times in the messages file, that it's not a dos. That is of course wrong. Not all syslog daemons do that, anyway. (syslog-ng doesn't, for one.) -- `On a scale

Re: CONFIG_PREEMPT -> crash under load in 2.6.20?

On 4 Mar 2007, Corey Hickey told this: > Nix wrote: >> I can't tell if magic sysrq dies, because as far as I know there's no >> way to get magic sysrq to do much visible when you're in X, and I can't >> get anything to go over the network kernel syslog because the networ

Re: CONFIG_PREEMPT - crash under load in 2.6.20?

On 4 Mar 2007, Corey Hickey told this: Nix wrote: I can't tell if magic sysrq dies, because as far as I know there's no way to get magic sysrq to do much visible when you're in X, and I can't get anything to go over the network kernel syslog because the network is dead. You should still

CONFIG_PREEMPT -> crash under load in 2.6.20?

Since upgrading to 2.6.20, my Athlon 4 has been locking up on a very-roughly-daily basis, generally in periods of some load (I've never seen it lock up when idle, but have seen it lock up with a load average of 0.5). I'm fairly sure this didn't happen with 2.6.19 and am certain that it didn't with

CONFIG_PREEMPT - crash under load in 2.6.20?

Since upgrading to 2.6.20, my Athlon 4 has been locking up on a very-roughly-daily basis, generally in periods of some load (I've never seen it lock up when idle, but have seen it lock up with a load average of 0.5). I'm fairly sure this didn't happen with 2.6.19 and am certain that it didn't with

Re: kernel 2.6.13 - space not freed to kernel

On 2 Sep 2005, [EMAIL PROTECTED] murmured woefully: > The usual malloc() never resets the break address or remaps memory > because it is an expensive operation. This means that when new > data space needs to be allocated, malloc() doesn't have to get > anything from the kernel because it already

Re: kernel 2.6.13 - space not freed to kernel

On 2 Sep 2005, [EMAIL PROTECTED] murmured woefully: The usual malloc() never resets the break address or remaps memory because it is an expensive operation. This means that when new data space needs to be allocated, malloc() doesn't have to get anything from the kernel because it already has,

Re: [PATCH] 2.6.13: Filesystem capabilities 0.16

On 1 Sep 2005, Olaf Dietsche murmured woefully: > This patch implements filesystem capabilities. It allows to run > privileged executables without the need for suid root. Is there some reason why this doesn't keep its capability data in xattrs? -- `... published last year in a limited

Re: [PATCH] 2.6.13: Filesystem capabilities 0.16

On 1 Sep 2005, Olaf Dietsche murmured woefully: This patch implements filesystem capabilities. It allows to run privileged executables without the need for suid root. Is there some reason why this doesn't keep its capability data in xattrs? -- `... published last year in a limited edition...

Re: Broke nice range for RLIMIT NICE

On Fri, 29 Jul 2005, Michael Kerrisk uttered the following: >> On 29 Jul 2005, Michael Kerrisk stated: >> > Yes, as noted in my earlier message -- at the moment RLIMIT_NICE >> > still isn't in the current glibc snapshot... >> >> According to traffic on libc-hacker, Ulrich committed it on Jun 20

Re: Broke nice range for RLIMIT NICE

On 29 Jul 2005, Michael Kerrisk stated: > Yes, as noted in my earlier message -- at the moment RLIMIT_NICE > still isn't in the current glibc snapshot... According to traffic on libc-hacker, Ulrich committed it on Jun 20 (along with RLIMIT_RTPRIO support). -- `Tor employs several thousand

Re: Broke nice range for RLIMIT NICE

On 29 Jul 2005, Michael Kerrisk stated: Yes, as noted in my earlier message -- at the moment RLIMIT_NICE still isn't in the current glibc snapshot... According to traffic on libc-hacker, Ulrich committed it on Jun 20 (along with RLIMIT_RTPRIO support). -- `Tor employs several thousand

Re: Broke nice range for RLIMIT NICE

On Fri, 29 Jul 2005, Michael Kerrisk uttered the following: On 29 Jul 2005, Michael Kerrisk stated: Yes, as noted in my earlier message -- at the moment RLIMIT_NICE still isn't in the current glibc snapshot... According to traffic on libc-hacker, Ulrich committed it on Jun 20 (along with

Re: kernel page size explanation

On Mon, 25 Jul 2005, VASM wrote: > i had one question > does the linux kernel support only one default page size even if the > processor on which it is working supports multiple ? No. Some architectures have compile-time support for multiple different page sizes (e.g. Itanium, SPARC64); many

Re: kernel page size explanation

On 22 Jul 2005, Jesper Juhl suggested tentatively: > You can > A) look in the .config file for your current kernel (if your arch > supports different page sizes at all). > B) You can use the getpagesize(2) syscall at runtime. getpagesize() > returns the nr of bytes in a page - man getpagesize -

Re: kernel page size explanation

On 22 Jul 2005, Jesper Juhl suggested tentatively: You can A) look in the .config file for your current kernel (if your arch supports different page sizes at all). B) You can use the getpagesize(2) syscall at runtime. getpagesize() returns the nr of bytes in a page - man getpagesize - I'm

Re: kernel page size explanation

On Mon, 25 Jul 2005, VASM wrote: i had one question does the linux kernel support only one default page size even if the processor on which it is working supports multiple ? No. Some architectures have compile-time support for multiple different page sizes (e.g. Itanium, SPARC64); many have

Re: pktcddvd -> immediate crash

On 5 Apr 2005, Soeren Sonnenburg whispered secretively: > I wonder whether anyone could use the pktcddvd device without killing > random jobs (due to sudden out of memory or better memory leaks in > pktcddvd) and finally a complete freeze of the machine ? I'm using it without difficulty. > To

Re: pktcddvd - immediate crash

On 5 Apr 2005, Soeren Sonnenburg whispered secretively: I wonder whether anyone could use the pktcddvd device without killing random jobs (due to sudden out of memory or better memory leaks in pktcddvd) and finally a complete freeze of the machine ? I'm using it without difficulty. To

Re: a problem with linux 2.6.11 and sa

On Wed, 09 Mar 2005, Paul Jarc uttered the following: > "George Georgalis" <[EMAIL PROTECTED]> wrote: >> It (Gerrit Pape's technique) very defiantly stopped working a few revs >> back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and >> mplayer with 2.6.10, now too. > > The /proc/kmsg

Re: a problem with linux 2.6.11 and sa

On Tue, 8 Mar 2005, George Georgalis announced authoritatively: > Here's what I'm doing that is broken. I use tcpserver (functionally > similar to inetd) to receive an incoming smtp connection. While the > smtp session is still open, the message is piped to a temp file which > is then scanned for

Re: a problem with linux 2.6.11 and sa

On Tue, 8 Mar 2005, George Georgalis announced authoritatively: Here's what I'm doing that is broken. I use tcpserver (functionally similar to inetd) to receive an incoming smtp connection. While the smtp session is still open, the message is piped to a temp file which is then scanned for

Re: a problem with linux 2.6.11 and sa

On Wed, 09 Mar 2005, Paul Jarc uttered the following: George Georgalis [EMAIL PROTECTED] wrote: It (Gerrit Pape's technique) very defiantly stopped working a few revs back (2.6.7?). I'm seeing a similar failed read from /dev/rtc and mplayer with 2.6.10, now too. The /proc/kmsg problem

[PATCH] linux-libc-headers-2.6.10.0: if_tunnel.h relies on byteorder.h having been included

In iproute2, ip/iptunnel.c says: #include #include #include #include Now the original Linux kernel includes byteorder.h as a side-effect of including netdevice.h, which it does inside a __KERNEL__ ifdef when if_arp.h is included. I think it makes more sense to include it in those headers

[PATCH] linux-libc-headers-2.6.10.0: if_tunnel.h relies on byteorder.h having been included

In iproute2, ip/iptunnel.c says: #include linux/if.h #include linux/if_arp.h #include linux/ip.h #include linux/if_tunnel.h Now the original Linux kernel includes byteorder.h as a side-effect of including netdevice.h, which it does inside a __KERNEL__ ifdef when if_arp.h is included. I think it

Re: 2.6.10: SPARC64 mapped figure goes unsignedly negative...

On Mon, 31 Jan 2005, Hugh Dickins uttered the following: > On Mon, 31 Jan 2005, Nix wrote: >> Filename TypeSizeUsedPriority >> /dev/sda2 partition523016 0 1 >> /dev/sda4

Re: 2.6.10: SPARC64 mapped figure goes unsignedly negative...

On Mon, 31 Jan 2005, Hugh Dickins said: > On Mon, 31 Jan 2005, Nix wrote: >> (2.6.10 seems to *run* perfectly well on that box, for what it's worth; >> unless this is a symptom of some underlying dark and terrible failure, >> it looks like a not-very-important cosmetic bug.) &

Re: 2.6.10: SPARC64 mapped figure goes unsignedly negative...

On Mon, 31 Jan 2005, Hugh Dickins suggested tentatively: > On Sun, 30 Jan 2005, Nix wrote: >> /proc/meminfo on my UltraSPARC IIi: >> Mapped: 18446744073687883208 kB >> >> (This kernel is compiled with GCC-3.4.3, which might be relevant.) > > Indeed: s

2.6.10: SPARC64 mapped figure goes unsignedly negative...

/proc/meminfo on my UltraSPARC IIi: MemTotal: 512816 kB MemFree: 14208 kB Buffers: 51328 kB Cached: 163056 kB SwapCached: 0 kB Active: 142160 kB Inactive: 304712 kB HighTotal: 0 kB HighFree:0 kB LowTotal: 512816 kB

<    1   2   3   4   >