Antw: [EXT] [systemd-devel] [SPECIFICATION RFC] The firmware and bootloader log specification

o or what defines t == 0? ... Regards, Ulrich Windl

FYI: PoC: Running 100000 processes in 5.3.18 (SLES15 SP2)

Hi! Just in case someone is interested: As a Proof-of-Concept I started 100 thousand processes on a big machine (72 cores). It worked! However starting those too more than 30 minutes, and top needs more than 30 minutes to refresh ist display. Still, interactive input via SSH works nice, but

heads up: clock_gettime(CLOCK_MONOTONIC, ...) is not monotonic with Xen PVM

n is 0.%09ld\n", res.tv_nsec); return(result); } - it is intentional that the program aborts on error Output from a newer machine: get_res: resolution is 0.1 get_res: smallest delta is 0.00030 get_res: largest delta is 0.00050 resolution is 0.00030 Regards, Ulrich Windl (Keep me on CC if I should read your replies)

Q: Getting consistent CPU status rates from /proc/stat

If so it makes it hard to be used by a univarsal utility like my monitoring plugin that can read _any_ value from procfs. For reference, here's the consistency check script I was using: #!/usr/bin/perl # Check consistency of CPU states in /proc/stat # written for SLES12 SP5 and PERL 5.18 by Ulr

Issue with reading sysfs files

Hi! I wrote a simple tool to browse sysfs. However I noticed that there are some files having "r" (read) permission, but when you actually try to read from those, I get an I/O error. So I wonder whether the actual read was forgotten to implement, or the read permission should be gone actually.

leap seconds and 61st second in minute

Hi! I was currently following some discussion on the topic of leap seconds, and due to the basic role of time in the kernel, I'd like to send a "heads up" ("food for thought") with some proposal (not to start some useless discussion): The UNIX timescale running in UTC had (I suppose) the idea

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Jeffrey Walton schrieb am 17.06.2017 um 16:23 in >>> Nachricht : [...] > But its not clear to me how to ensure uniqueness when its based on > randomness from the generators. Even with a perfect random

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Jeffrey Walton schrieb am 17.06.2017 um 16:23 in >>> Nachricht : [...] > But its not clear to me how to ensure uniqueness when its based on > randomness from the generators. Even with a perfect random generator non-unique values are possible (that's why it's random). It's unlikely, but it

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Stephan Müller schrieb am 26.06.2017 um 19:38 in Nachricht <1678474.gnybdsl...@tauon.chronox.de>: > Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger: > > Hi Nicholas, > >> Hi Stephan, Lee & Jason, >> >> (Adding target-devel CC') >> >> Apologies

Antw: Re: [kernel-hardening] Re: [PATCH v4 06/13] iscsi: ensure RNG is seeded before use

>>> Stephan Müller schrieb am 26.06.2017 um 19:38 in Nachricht <1678474.gnybdsl...@tauon.chronox.de>: > Am Montag, 26. Juni 2017, 03:23:09 CEST schrieb Nicholas A. Bellinger: > > Hi Nicholas, > >> Hi Stephan, Lee & Jason, >> >> (Adding target-devel CC') >> >> Apologies for coming late to the

Antw: Q: si_code for SIGBUS caused by mmap() write error

I'm sorry for using that address as sender in my previous message; it was an oversight! The CC: address was correct, however. You can drop above address from your replies.

Antw: Q: si_code for SIGBUS caused by mmap() write error

I'm sorry for using that address as sender in my previous message; it was an oversight! The CC: address was correct, however. You can drop above address from your replies.

Kernel lockup with Intel Iris graphics

Hi folks, maybe someone has a idea on this: https://bugzilla.opensuse.org/show_bug.cgi?id=1032832 Regards, Ulrich

Kernel lockup with Intel Iris graphics

Hi folks, maybe someone has a idea on this: https://bugzilla.opensuse.org/show_bug.cgi?id=1032832 Regards, Ulrich

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

83809.595235] [<7fb04560dba0>] 0x7fb04560db9f >>> Ulrich Windl schrieb am 07.12.2016 um 13:23 in Nachricht <5847FF5E.7E4 : >>> 161 : 60728>: > Hi again! > > An addition: Processes doing such I/O seem to be unkillable, and I also > cannot change the queue param

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

83809.595235] [<7fb04560dba0>] 0x7fb04560db9f >>> Ulrich Windl schrieb am 07.12.2016 um 13:23 in Nachricht <5847FF5E.7E4 : >>> 161 : 60728>: > Hi again! > > An addition: Processes doing such I/O seem to be unkillable, and I also > cannot change the queue param

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

nonvoluntary_ctxt_switches: 1 Best regards, Ulrich >>> Ulrich Windl schrieb am 07.12.2016 um 13:19 in Nachricht <5847FE66.7E4 : >>> 161 : 60728>: > Hi again! > > Maybe someone can confirm this: > If you have a device (e.g. multipath map) that limits max_sectors_kb to &

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

nonvoluntary_ctxt_switches: 1 Best regards, Ulrich >>> Ulrich Windl schrieb am 07.12.2016 um 13:19 in Nachricht <5847FE66.7E4 : >>> 161 : 60728>: > Hi again! > > Maybe someone can confirm this: > If you have a device (e.g. multipath map) that limits max_sectors_kb to &

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

). Last seen with this kernel (SLES11 SP4 on x86_64): Linux version 3.0.101-88-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Nov 4 22:07:35 UTC 2016 (b45f205) Regards, Ulrich >>> Ulrich Windl schrieb am 23.08.2016 um 17:03 in

Antw: 3.0.101: "blk_rq_check_limits: over max size limit."

). Last seen with this kernel (SLES11 SP4 on x86_64): Linux version 3.0.101-88-default (geeko@buildhost) (gcc version 4.3.4 [gcc-4_3-branch revision 152973] (SUSE Linux) ) #1 SMP Fri Nov 4 22:07:35 UTC 2016 (b45f205) Regards, Ulrich >>> Ulrich Windl schrieb am 23.08.2016 um 17:03 in

Antw: Re: MBR partitions slow?

>>> Mark D Rustad <mrus...@gmail.com> schrieb am 31.08.2016 um 17:32 in >>> Nachricht <e2d72371-913b-4460-a370-c141835ad...@gmail.com>: > Ulrich Windl <ulrich.wi...@rz.uni-regensburg.de> wrote: > >> So without partition the throughput is

Antw: Re: MBR partitions slow?

>>> Mark D Rustad schrieb am 31.08.2016 um 17:32 in >>> Nachricht : > Ulrich Windl wrote: > >> So without partition the throughput is about twice as high! Why? > > My first thought is that by starting at block 0 the accesses were aligned >

Antw: MBR partitions slow?

at 0x7fe18823e000: 0.038380s time to close /dev/disk/by-id/dm-name-FirstTest-32_part2: 0.265687s So the correctly aligned partition is two to three times faster than the badly aligned partition (write-only case), and it's about the performance of an unpartitioned disk. Regards, Ulrich >>&g

Antw: MBR partitions slow?

at 0x7fe18823e000: 0.038380s time to close /dev/disk/by-id/dm-name-FirstTest-32_part2: 0.265687s So the correctly aligned partition is two to three times faster than the badly aligned partition (write-only case), and it's about the performance of an unpartitioned disk. Regards, Ulrich >>&g

MBR partitions slow?

Hello! (I'm not subscribed to this list, but I'm hoping to get a reply anyway) While testing some SAN storage system, I needed a utility to erase disks quickly. I wrote my own one that mmap()s the block device, memset()s the area, then msync()s the changes, and finally close()s the file

MBR partitions slow?

Hello! (I'm not subscribed to this list, but I'm hoping to get a reply anyway) While testing some SAN storage system, I needed a utility to erase disks quickly. I wrote my own one that mmap()s the block device, memset()s the area, then msync()s the changes, and finally close()s the file

3.0.101: "blk_rq_check_limits: over max size limit."

Hello! While performance-testing a 3PARdata StorServ 8400 with SLES11SP4, I noticed that I/Os dropped, until everything stood still more or less. Looking into the syslog I found that multipath's TUR-checker considered the paths (FC, BTW) as dead. Amazingly I did not have this problem when I

3.0.101: "blk_rq_check_limits: over max size limit."

Hello! While performance-testing a 3PARdata StorServ 8400 with SLES11SP4, I noticed that I/Os dropped, until everything stood still more or less. Looking into the syslog I found that multipath's TUR-checker considered the paths (FC, BTW) as dead. Amazingly I did not have this problem when I

and NTP incompatibility (MOD_NANO)

Hi folks! I'd wish ntp_loopfilter.c would compile without problems. The mess is (I had fixed it about 15 years ago (keyword "PPSkit")) that Linux uses ADJ_* flags to do traditional adjtime() things, as well as NTP kernel-related things (That's why the Linux syscall is named adjtimex()). NTP

and NTP incompatibility (MOD_NANO)

Hi folks! I'd wish ntp_loopfilter.c would compile without problems. The mess is (I had fixed it about 15 years ago (keyword "PPSkit")) that Linux uses ADJ_* flags to do traditional adjtime() things, as well as NTP kernel-related things (That's why the Linux syscall is named adjtimex()). NTP

Suggestion for improving documentation (/usr/src/linux/Documentation/sysctl/vm.txt)

Hi! I just read the documentation for the "swappiness" sysctl parameter, and I realized that 1) the documentation does not talk about the valid range of the parameter (0-100?) 2) the documentation does not talk about the units the parameter uses (Percent?)

Suggestion for improving documentation (/usr/src/linux/Documentation/sysctl/vm.txt)

Hi! I just read the documentation for the "swappiness" sysctl parameter, and I realized that 1) the documentation does not talk about the valid range of the parameter (0-100?) 2) the documentation does not talk about the units the parameter uses (Percent?)

ioprio_set() & IOPRIO_WHO_PROCESS: Rename?

Hi! I noticed that older Manual pages for ioprio_set(2) say IOPRIO_WHO_PROCESS modified the process, while I think it should be per thread. Newer manual pages say it's per thread, but shouldn't IOPRIO_WHO_PROCESS be declared obsolete then and be replaced with a new IOPRIO_WHO_THREAD? (i.e.

ioprio_set() IOPRIO_WHO_PROCESS: Rename?

Hi! I noticed that older Manual pages for ioprio_set(2) say IOPRIO_WHO_PROCESS modified the process, while I think it should be per thread. Newer manual pages say it's per thread, but shouldn't IOPRIO_WHO_PROCESS be declared obsolete then and be replaced with a new IOPRIO_WHO_THREAD? (i.e.

Antw: Re: Lower bound 0.05 on 15-Minute load?

>>> Martin Steigerwald schrieb am 02.07.2015 um 11:26 in Nachricht <1479160.a5Vb4cJSSF@merkaba>: > On Thursday 02 July 2015 10:50:13 Ulrich Windl wrote: >> Hi! > > Hi Ulrich, > >> I'm not subscribed, so plese CC: me for your replies. >> >>

Antw: Re: Lower bound 0.05 on 15-Minute load?

Martin Steigerwald mar...@lichtvoll.de schrieb am 02.07.2015 um 11:26 in Nachricht 1479160.a5Vb4cJSSF@merkaba: On Thursday 02 July 2015 10:50:13 Ulrich Windl wrote: Hi! Hi Ulrich, I'm not subscribed, so plese CC: me for your replies. When graphing the CPU load, I noticed that the 15

Lower bound 0.05 on 15-Minute load?

Hi! I'm not subscribed, so plese CC: me for your replies. When graphing the CPU load, I noticed that the 15-minute average never drops below 0.05, while the 5-minute load and the 1-minute load does (Kernel 3.0.101-0.47.52-xen of SLES11 on x86_64). Ist that a known bug? Interactive call of

Lower bound 0.05 on 15-Minute load?

Hi! I'm not subscribed, so plese CC: me for your replies. When graphing the CPU load, I noticed that the 15-minute average never drops below 0.05, while the 5-minute load and the 1-minute load does (Kernel 3.0.101-0.47.52-xen of SLES11 on x86_64). Ist that a known bug? Interactive call of

Formatting of /proc/meminfo

rmat (%-16s%8lu kB\n) in a constant also, allowing a change at one point to affect every item... Probably gcc will optimize the code anyway, so there won't be much difference regarding performance. Regards, Ulrich Windl -- To unsubscribe from this list: send the line "unsubscribe linux-k

Formatting of /proc/meminfo

to affect every item... Probably gcc will optimize the code anyway, so there won't be much difference regarding performance. Regards, Ulrich Windl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info

Xen. How an error message should not look like

Hi! This is a somewhat generic subject, so please forgive me. We are having some very strange Xen problem in SLES11 SP3 (kernel 3.0.101-0.46-xen). Eventually I found out that the message kernel: [615432.648108] vbd vbd-7-51888: 2 creating vbd structure is not a "progress" message (some vbd

Xen. How an error message should not look like

Hi! This is a somewhat generic subject, so please forgive me. We are having some very strange Xen problem in SLES11 SP3 (kernel 3.0.101-0.46-xen). Eventually I found out that the message kernel: [615432.648108] vbd vbd-7-51888: 2 creating vbd structure is not a progress message (some vbd

RFE: kernel message "rport-2:0-10: blocked FC remote port time out: removing rport"

ro message if possible. Regards, Ulrich Windl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

RFE: kernel message rport-2:0-10: blocked FC remote port time out: removing rport

if possible. Regards, Ulrich Windl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/

FYI: unclean Intel RAID reported as "clean"

Hi! I detected a problem with an Intel (imsm, ICH) RAID1 reported as "clean" by Linux, while the BIOS and Windows claimed the RAID is in state "rebuild". This was for an older kernel, and the bug had been reported to openSUSE bugzilla as bug #902000. Anyone interested can find the details

FYI: unclean Intel RAID reported as clean

Hi! I detected a problem with an Intel (imsm, ICH) RAID1 reported as clean by Linux, while the BIOS and Windows claimed the RAID is in state rebuild. This was for an older kernel, and the bug had been reported to openSUSE bugzilla as bug #902000. Anyone interested can find the details there. I

3.16.3: misdetected nsc-ircc version 01 in VMware?

Hello, a short note: Using the release candidate of openSUSE 13.2 (GNOME live medium), I see this when booting the kernel in VMware: Oct 15 12:07:00 linux kernel: nsc-ircc, Found chip at base=0x02e Oct 15 12:07:00 linux kernel: nsc-ircc, Wrong chip version 01 I doubt the VMware has an infrared

3.16.3: misdetected nsc-ircc version 01 in VMware?

Hello, a short note: Using the release candidate of openSUSE 13.2 (GNOME live medium), I see this when booting the kernel in VMware: Oct 15 12:07:00 linux kernel: nsc-ircc, Found chip at base=0x02e Oct 15 12:07:00 linux kernel: nsc-ircc, Wrong chip version 01 I doubt the VMware has an infrared

Q: EDAC/kprintf/Xen issue (long logs inline)

Hi! I have a somewhat strange isse on a Xen host running SLES11 SP3 on a HP DL380 G7 server (two 5-core Xeon 5650 CPUs): At some time the system had RAM problems, and in one case the messages seemed to overwrite each other as seen in syslog. I wonder whether the locking of kprintf() is broken.

Q: EDAC/kprintf/Xen issue (long logs inline)

Hi! I have a somewhat strange isse on a Xen host running SLES11 SP3 on a HP DL380 G7 server (two 5-core Xeon 5650 CPUs): At some time the system had RAM problems, and in one case the messages seemed to overwrite each other as seen in syslog. I wonder whether the locking of kprintf() is broken.

Re: Antw: Re: Some problems with HP DL380 G8 BIOS and SLES11 SP3

>>> Don Zickus schrieb am 18.08.2014 um 14:44 in Nachricht <20140818124404.gl49...@redhat.com>: > On Mon, Aug 18, 2014 at 08:12:44AM +0200, Ulrich Windl wrote: >> >>> Don Zickus schrieb am 14.08.2014 um 19:46 in >> >>> Nachricht >> <2014

Antw: Re: Some problems with HP DL380 G8 BIOS and SLES11 SP3

>>> Don Zickus schrieb am 14.08.2014 um 19:46 in Nachricht <20140814174658.gv49...@redhat.com>: > On Wed, Aug 13, 2014 at 05:22:17PM +0200, Ulrich Windl wrote: >> Hello! >> >> Running the current SLES11 SP3 kernel on a HP DL380 G8 server, there are > s

Antw: Re: Some problems with HP DL380 G8 BIOS and SLES11 SP3

Don Zickus dzic...@redhat.com schrieb am 14.08.2014 um 19:46 in Nachricht 20140814174658.gv49...@redhat.com: On Wed, Aug 13, 2014 at 05:22:17PM +0200, Ulrich Windl wrote: Hello! Running the current SLES11 SP3 kernel on a HP DL380 G8 server, there are some kernel messages that indicate

Re: Antw: Re: Some problems with HP DL380 G8 BIOS and SLES11 SP3

Don Zickus dzic...@redhat.com schrieb am 18.08.2014 um 14:44 in Nachricht 20140818124404.gl49...@redhat.com: On Mon, Aug 18, 2014 at 08:12:44AM +0200, Ulrich Windl wrote: Don Zickus dzic...@redhat.com schrieb am 14.08.2014 um 19:46 in Nachricht 20140814174658.gv49...@redhat.com: On Wed

Some problems with HP DL380 G8 BIOS and SLES11 SP3

Hello! Running the current SLES11 SP3 kernel on a HP DL380 G8 server, there are some kernel messages that indicate a bug either in the kernel or in the HP BIOS. Maybe someone can explain, so I can try to get it fixed whatever party broke it... Linux kernel is "3.0.101-0.35-default

Some problems with HP DL380 G8 BIOS and SLES11 SP3

Hello! Running the current SLES11 SP3 kernel on a HP DL380 G8 server, there are some kernel messages that indicate a bug either in the kernel or in the HP BIOS. Maybe someone can explain, so I can try to get it fixed whatever party broke it... Linux kernel is 3.0.101-0.35-default

Q: setting the process name for ps

uot;proc %d", getpid()); printf("look: process title\n"); delay(); return 0; } --- As I'm not subscribed to LKML, please keep me CC'd on you replies! Thanks & regards, Ulrich Windl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel"

Q: setting the process name for ps

(look: process title\n); delay(); return 0; } --- As I'm not subscribed to LKML, please keep me CC'd on you replies! Thanks regards, Ulrich Windl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo

Q: uniqueness of pthread_t

Hi! I'm programming a little bit with pthreads in Linux. As I understand pthread_t is an opaque type (a pointer address?) that cannot be mapped to the kernel's TID easily. Anyway: Is it expected that when one thread terminates and another thread is created (in fact the same thread again), that

Q: uniqueness of pthread_t

Hi! I'm programming a little bit with pthreads in Linux. As I understand pthread_t is an opaque type (a pointer address?) that cannot be mapped to the kernel's TID easily. Anyway: Is it expected that when one thread terminates and another thread is created (in fact the same thread again), that

Q on ioctl BLKGETSIZE

Hi! I'm wondering (on a x86_64 SLES11 system): "man 4 sd" says: --- BLKGETSIZE Returns the device size in sectors. The ioctl(2) parameter should be a pointer to a long. --- /usr/src/linux/block/ioctl.c (3.0.101-0.15) reads: --- case BLKGETSIZE:

Q on ioctl BLKGETSIZE

Hi! I'm wondering (on a x86_64 SLES11 system): man 4 sd says: --- BLKGETSIZE Returns the device size in sectors. The ioctl(2) parameter should be a pointer to a long. --- /usr/src/linux/block/ioctl.c (3.0.101-0.15) reads: --- case BLKGETSIZE:

Antw: read stalls with large RAM: transparent huges pages, dirty buffers, or I/O (block) scheduler?

I forgot to mention: CPU power is not the problem: We have 2 * 6 Cores (2 Threads each), making 24 logical CPUs... >>> Ulrich Windl schrieb am 10.10.2013 um >>> 10:15 in Nachricht <52566237.478 : 161 : 60728>: > Hi! > > We are running some x86_64 ser

read stalls with large RAM: transparent huges pages, dirty buffers, or I/O (block) scheduler?

Hi! We are running some x86_64 servers with large RAM (128GB). Just to imagine: With a memory speed of a little more than 9GB/s it takes > 10 seconds to read all RAM... In the past and recently we had problems with read() stalls when the kernel was writing back big amounts (like 80GB) of

read stalls with large RAM: transparent huges pages, dirty buffers, or I/O (block) scheduler?

Hi! We are running some x86_64 servers with large RAM (128GB). Just to imagine: With a memory speed of a little more than 9GB/s it takes 10 seconds to read all RAM... In the past and recently we had problems with read() stalls when the kernel was writing back big amounts (like 80GB) of dirty

Antw: read stalls with large RAM: transparent huges pages, dirty buffers, or I/O (block) scheduler?

I forgot to mention: CPU power is not the problem: We have 2 * 6 Cores (2 Threads each), making 24 logical CPUs... Ulrich Windl ulrich.wi...@rz.uni-regensburg.de schrieb am 10.10.2013 um 10:15 in Nachricht 52566237.478 : 161 : 60728: Hi! We are running some x86_64 servers with large RAM

Wtrlt: Q: NFS: directory XX/YYY contains a readdir loop.Please contact your server vendor.

Re-sent due to "5.7.1 Content-Policy reject msg: The capital Triple-X in subject is way too often associated with junk email, please rephrase. ": >>> "Ulrich Windl" schrieb am 16.08.2013 um 10:29 in Nachricht <520e15ef.ed38.00a...@rz.uni-regensburg.de>: >

Wtrlt: Q: NFS: directory XX/YYY contains a readdir loop.Please contact your server vendor.

Re-sent due to 5.7.1 Content-Policy reject msg: The capital Triple-X in subject is way too often associated with junk email, please rephrase. : Ulrich Windl ulrich.wi...@rz.uni-regensburg.de schrieb am 16.08.2013 um 10:29 in Nachricht 520e15ef.ed38.00a...@rz.uni-regensburg.de: Hi, recently

message (3.0.80) "kernel: [440682.559851] blk_rq_check_limits: over max size limit."

Hi! I just did some block device tuning according to some expert's advice which resulted in multipath failures. I'm not going to discuss this as I'll have to investigate further, but I'd like to point out that the messages like "[440682.559851] blk_rq_check_limits: over max size limit." lack

message (3.0.80) kernel: [440682.559851] blk_rq_check_limits: over max size limit.

Hi! I just did some block device tuning according to some expert's advice which resulted in multipath failures. I'm not going to discuss this as I'll have to investigate further, but I'd like to point out that the messages like [440682.559851] blk_rq_check_limits: over max size limit. lack the

Antw: Re: Possible mmap() write() problem in SLES11 SP2 kernel

>>> Hugh Dickins schrieb am 04.08.2013 um 00:37 in Nachricht : > On Thu, 1 Aug 2013, Ulrich Windl wrote: >> Hi folks! >> >> I think I'd let you know (maybe I'm wrong, and the kernel is right): >> >> I write a C-program that maps a file into an priva

Antw: Re: Possible mmap() write() problem in SLES11 SP2 kernel

Hugh Dickins hu...@google.com schrieb am 04.08.2013 um 00:37 in Nachricht alpine.LNX.2.00.1308031516010.11134@eggly.anvils: On Thu, 1 Aug 2013, Ulrich Windl wrote: Hi folks! I think I'd let you know (maybe I'm wrong, and the kernel is right): I write a C-program that maps a file

Possible mmap() write() problem in SLES11 SP2 kernel

Hi folks! I think I'd let you know (maybe I'm wrong, and the kernel is right): I write a C-program that maps a file into an private writable map. Then I modify the area a bit and use one write to write that area back to a file. This worked fine in SLES11 kernel 3.0.74-0.6.10. However with

Possible mmap() write() problem in SLES11 SP2 kernel

Hi folks! I think I'd let you know (maybe I'm wrong, and the kernel is right): I write a C-program that maps a file into an private writable map. Then I modify the area a bit and use one write to write that area back to a file. This worked fine in SLES11 kernel 3.0.74-0.6.10. However with

chown: s-Bits: to clear or not to clear

know this is the wrong list for discussing utils). Regards, Ulrich Windl -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FA

chown: s-Bits: to clear or not to clear

know this is the wrong list for discussing utils). Regards, Ulrich Windl -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

"floppy0: floppy timeout called", https://bugzilla.novell.com/show_bug.cgi?id=799559

Hi! maybe someone wants to have a look at kernel messages that look like debug dumps from the floppy driver. These messages fill up syslog unnecessarily. You can find the kernel messages in https://bugzilla.novell.com/show_bug.cgi?id=799559. Last seen in kernel-default-3.7.10-1.11.1.i586 of

floppy0: floppy timeout called, https://bugzilla.novell.com/show_bug.cgi?id=799559

Hi! maybe someone wants to have a look at kernel messages that look like debug dumps from the floppy driver. These messages fill up syslog unnecessarily. You can find the kernel messages in https://bugzilla.novell.com/show_bug.cgi?id=799559. Last seen in kernel-default-3.7.10-1.11.1.i586 of

bad time after boot (read from absent hardware?): "Time: 165:165:165 Date: 165/165/65"

Hi! Some time ago I discovered strange output in boot messages, just as if the kernel trusts junk from hardware that is not present, like the RTC in a paravirtualized Xen guest (the guest has no /dev/rtc*). The message says: <6>[0.123524] Time: 165:165:165 Date: 165/165/65 Obviously, if

bad time after boot (read from absent hardware?): Time: 165:165:165 Date: 165/165/65

Hi! Some time ago I discovered strange output in boot messages, just as if the kernel trusts junk from hardware that is not present, like the RTC in a paravirtualized Xen guest (the guest has no /dev/rtc*). The message says: 6[0.123524] Time: 165:165:165 Date: 165/165/65 Obviously, if

Suggestion for improving kernel messages on ext3-mount for consistency

Hi! I have a kind of trivial suggestion for improving the kernel messages for ext3-fs mounts to be more consistent and useful: Most messages for ext3-mounting include the device, like: kernel: [ 823.233892] EXT3-fs (dm-7): using internal journal kernel: [ 823.233899] EXT3-fs (dm-7): mounted

Suggestion for improving kernel messages on ext3-mount for consistency

Hi! I have a kind of trivial suggestion for improving the kernel messages for ext3-fs mounts to be more consistent and useful: Most messages for ext3-mounting include the device, like: kernel: [ 823.233892] EXT3-fs (dm-7): using internal journal kernel: [ 823.233899] EXT3-fs (dm-7): mounted

Antw: [PATCH 0/5] kfifo cleanup and log based kfifo API

>>> Yuanhan Liu schrieb am 08.01.2013 um 15:57 in Nachricht <1357657073-27352-1-git-send-email-yuanhan@linux.intel.com>: [...] > My proposal is to replace kfifo_init with kfifo_alloc, where it > allocate buffer and maintain fifo size inside kfifo. Then we can > remove buggy kfifo_init. [...]

Antw: [PATCH 0/5] kfifo cleanup and log based kfifo API

Yuanhan Liu yuanhan@linux.intel.com schrieb am 08.01.2013 um 15:57 in Nachricht 1357657073-27352-1-git-send-email-yuanhan@linux.intel.com: [...] My proposal is to replace kfifo_init with kfifo_alloc, where it allocate buffer and maintain fifo size inside kfifo. Then we can remove

ext3 corruption in 3.0 kernel (SLES11 SP2 x86_64 (AMD Opteron))

Hi! I thought I'd let you know of two ext3 corruptions found on an ADM Opteron server running SLES11 SP2 (kernel-xen-3.0.42-0.7.3). Corruptions occurred at different times in different files on different machines: Too much to be ignored. The older one looked like this: [75548.267404] EXT3-fs

ext3 corruption in 3.0 kernel (SLES11 SP2 x86_64 (AMD Opteron))

Hi! I thought I'd let you know of two ext3 corruptions found on an ADM Opteron server running SLES11 SP2 (kernel-xen-3.0.42-0.7.3). Corruptions occurred at different times in different files on different machines: Too much to be ignored. The older one looked like this: [75548.267404] EXT3-fs

3.0: blk-cgroup.c: allow '*' for device selection for "throttle.read_bps_device" and alike

Hi! I have a wish for Linux 3.x and blkio cgroup subsystem: Allow to specify any device like: blkio.throttle.read_bps_device = "*:* 41943040" Why: With multipathing being effective, you can't predict the device number your device will have in advance (I'm talking about "/etc/cgconfig.conf").

3.0: blk-cgroup.c: allow '*' for device selection for throttle.read_bps_device and alike

Hi! I have a wish for Linux 3.x and blkio cgroup subsystem: Allow to specify any device like: blkio.throttle.read_bps_device = *:* 41943040 Why: With multipathing being effective, you can't predict the device number your device will have in advance (I'm talking about /etc/cgconfig.conf).

Q: using cgroups in real life

Hi! I have a question on cgroups (as of Linux 3.0): The concept is to mount a filesystem, and configure cgroups through it. This implies that all the files belong to root (or maybe some other fixed user). AFAIK, you can chmod() and chown() files, but these bits are only kept in the i-node

Q: using cgroups in real life

Hi! I have a question on cgroups (as of Linux 3.0): The concept is to mount a filesystem, and configure cgroups through it. This implies that all the files belong to root (or maybe some other fixed user). AFAIK, you can chmod() and chown() files, but these bits are only kept in the i-node

3.0.38: strange boot message: "Time: 165:165:165 Date: 165/165/65" with Xen

Hi! I just discovered a strange "<6>[0.123867] Time: 165:165:165 Date: 165/165/65" boot message in a Xen DomU VM for SLES11 SP2 on AMD Opteron (x86_64). The context is: ... <6>[0.080197] Initializing cgroup subsys net_cls <6>[0.080199] Initializing cgroup subsys blkio <6>[

3.0.38: strange boot message: Time: 165:165:165 Date: 165/165/65 with Xen

Hi! I just discovered a strange 6[0.123867] Time: 165:165:165 Date: 165/165/65 boot message in a Xen DomU VM for SLES11 SP2 on AMD Opteron (x86_64). The context is: ... 6[0.080197] Initializing cgroup subsys net_cls 6[0.080199] Initializing cgroup subsys blkio 6[0.080204]

Antw: Re: Q: Seeing the microcode revision in /proc/cpuinfo

t; On Tue, Aug 14, 2012 at 02:35:40PM +0200, Ulrich Windl wrote: > > Hi! > > > > After several reboots due to memory errors after excellent power-saving of > Linux on a HP DL380G7 with Intel Xeon 5650 processors (all in on memory > bank), I found out the errate "BD1

Q: Seeing the microcode revision in /proc/cpuinfo

Hi! After several reboots due to memory errors after excellent power-saving of Linux on a HP DL380G7 with Intel Xeon 5650 processors (all in on memory bank), I found out the errate "BD104" and "BD123". The former should be fixed in a microcode revision "15H". Now I wonder what microcode

Q: Seeing the microcode revision in /proc/cpuinfo

Hi! After several reboots due to memory errors after excellent power-saving of Linux on a HP DL380G7 with Intel Xeon 5650 processors (all in on memory bank), I found out the errate BD104 and BD123. The former should be fixed in a microcode revision 15H. Now I wonder what microcode revision my

Antw: Re: Q: Seeing the microcode revision in /proc/cpuinfo

:35:40PM +0200, Ulrich Windl wrote: Hi! After several reboots due to memory errors after excellent power-saving of Linux on a HP DL380G7 with Intel Xeon 5650 processors (all in on memory bank), I found out the errate BD104 and BD123. The former should be fixed in a microcode revision 15H

Q: diskstats for MD-RAID

Hello! I have a question based on the SLES11 SP1 kernel (2.6.32.59-0.3-default): In /proc/diskstats the last four values seem to be zero for md-Devices. So "%util", "await", and "svctm" from "sar" are always reported as zero. Ist this a bug or a feature? I'm tracing a fairness problem resulting

Q: diskstats for MD-RAID

Hello! I have a question based on the SLES11 SP1 kernel (2.6.32.59-0.3-default): In /proc/diskstats the last four values seem to be zero for md-Devices. So %util, await, and svctm from sar are always reported as zero. Ist this a bug or a feature? I'm tracing a fairness problem resulting from an

Re: Antw: Re: /sys and access(2): Correctly implemented?

issue here. Regards, Ulrich >>> Ryan Mallon schrieb am 09.07.2012 um 09:22 in Nachricht <4ffa86c5.7090...@gmail.com>: > On 09/07/12 16:23, Ulrich Windl wrote: >>>>> Ryan Mallon schrieb am 09.07.2012 um 01:24 in >>>>> Nachricht

Antw: Re: /sys and access(2): Correctly implemented?

>>> Ryan Mallon schrieb am 09.07.2012 um 01:24 in Nachricht <4ffa16b6.9050...@gmail.com>: > On 06/07/12 16:27, Ulrich Windl wrote: > > Hi! > > > > Recently I found a problem with the command (kernel 3.0.34-0.7-default from > SLES 11 SP2, run as r

  1   2   3   >