patch: 2.4.0/2.5.0: nanoseconds time resolution

ve a /proc/sys/kernel/time directory, I'd also suggest to accept the patch for /usr/src/linux/include/sysctl.h for the standard kernel. Currently I have allocated "50" for the "time" entry. I'd like to have a stable number for the

Re: patch: 2.4.0/2.5.0: nanoseconds time resolution

On 22 Jan 2001, at 22:55, Albert D. Cahalan wrote: Therefore I put together a simple "hacking document" (see attachment) to guide you when trying to port the code. More text can be found in Documentation/kernel-time.txt after the patch, or in the distribution for Linux 2.2

2.2.18: severe performance problem (high load, low mem, idle CPU)

Hello, we experienced a severe performance problem on a PentiumPro 200 MHz, 64MB RAM, 128MB swap: Due to many processes being started in a short time, the system load went up to 53, and the 9GB SCSI disk was working heavily. At that time I suspected no severe problem, and I was busy doing

(Fwd) about timer in linux kernel.

, 18 May 2001 16:58:55 -0700 Hi! Mr. Ulrich Windl, I want to know how timer works in kernel. When we call add_timer(), it will call add_timer_internal to add it to its list. Now I am confused how the system checks if it is expired or not? In run_timer_list(), Why it uses tv1.vec + tv1.index

2.2.16: OOPS 2 VFS panic

Hello, I had a kernel panic with 2.2.16 yesterday. Because of this rare occasion, I immediately checked my RAM (memtest86), but the RAM is OK, there was no thunderstorm, no handy (mobile phone) nearby, the CPU and RAM not overclocked, all chipsets Genuine Intel. I only have two memory chips

Compiling 2.2 on Pentium

Hi, I noticed that when compiling with gcc-2.95.2 for a Pentium the flag "- m486" ist still passed to gcc. However gcc-2.95.2 generates different code if "-m586" is used (older versions ended at -m486). Is the makefile intentionally not updated, or was it just forgotten? Regards, Ulrich - To

2.2.17: CPU features bug for AMD?

Browsing patch-2.2.17.gz I found this: linux/arch/i386/kernel/setup.c: Isn't here an "else" or "break" missing? Otherwise ``x86_cap_flags[16] = "pat"'' is always the case, and extended AMD features are always present. @@ -1029,17 +1130,22 @@ case X86_VENDOR_AMD:

2.2.16: Verify mounting of /

Hello, I have some trouble with an initrd configuration where it seems the wrong partition is mounted as root (/), even though it seems fine in /etc/fstab, and mount and df all display that it's fine. I realized that the kernel messages are not as helpful as possible: 4VFS: Mounted root

2.2.18: static rtc_lock in nvram.c

Hi, browsing the sources for some problem I wondered why nvram.c uses a static spinlock named rtc_lock, hiding the global one. Regards, Ulrich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at

2.2.18/ext2: special file corruption?

Hi, I had an interesting effect: Due to NVdriver I had a lot of system freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the message that one specific "Special (device/socket/fifo) inode .. has non-zero size. FIXED." Interestingly I got the message for every reboot. So either

Re: 2.2.18: static rtc_lock in nvram.c

On 26 Feb 2001, at 9:33, Alan Cox wrote: browsing the sources for some problem I wondered why nvram.c uses a static spinlock named rtc_lock, hiding the global one. It only does that for the atari, where the driver isnt used by other things Hmm.. are there different nvram.c drivers? I

Re: 2.2.18/ext2: special file corruption?

On 26 Feb 2001, at 10:48, Andreas Dilger wrote: Ulrich Windl writes: I had an interesting effect: Due to NVdriver I had a lot of system freezes, and I had to reboot. Using e2fsck 1.19a (SuSE 7.1) I got the message that one specific "Special (device/socket/fifo) inode .. has non

FYI: [comp.protocols.time.ntp] announce: Linux PPS support for Kernel 2.4.2

FYI, a copy... --- Start of forwarded message --- From: Ulrich Windl [EMAIL PROTECTED] Newsgroups: comp.protocols.time.ntp Subject: announce: Linux PPS support for Kernel 2.4.2 Date: 13 Mar 2001 08:04:56 +0100 Organization: University of Regensburg, Germany Message-ID: [EMAIL PROTECTED

2.4.2: kernel patch for asm-i386/delay.h, nanosleep

Hello, originally intended for my PPSkit patch I found out that the "normal" kernel might like this patch as well: nanosleep() currently uses "udelay()" from asm/delay.h as there is no "ndelay()". I implemented "ndelay()" for i386 and adjusted the other macros. During that I found that some

2.2.18: e100.c (SuSE 7.1): udelay() used in a wrong way?

From the source code of drivers/net/e100.c: / * Name: Phy82562EHDelayMilliseconds * * Description: Stalls execution for a specified number of milliseconds. * * Arguments: Time - milliseconds to delay

2.2.16: How to freeze the kernel

Hello, this is for your interest, amusement, and for "what not to do": I managed to freeze the kernel (2.2.16 from SuSE Linux 7.0) in a way that I could not even switch virtual consoles. Completely silent eberything... It all started when Windows/95 ruined another CD-R while trying to write

2.4.0test11: some issues and a possible show stopper

Reading the article in the German computer magazine c't that Linux 2-4 is scheduled for release in December, and that Linux complained people do not want to test the new kernel, I decided to test it. The Hardware was: Spacewalker/Shuttle AV11 (VIA Apollo Pro chipset), Intel Celeron-500

poll: nanoseconds in 2.5?

Hello, maybe some of you know that I patched an early 2.2 kernel (2.1.131 or so) to provide nanoseconds to the customers, i.e. xtime has tv_nsec. The patch is available throughout 2.2 (including 2.2.17). I merged the patch into 2.4test11, it compiles and boots so far. Now I wonder if there's

2.4.0test11: nanoseconds patch (prerelease) available

Hi, related to my question about having nanoseconds in xtime for Linux 2.5, two (or three) people were interested, or at least managed to route their message to me. As promised I have made an early release patch against 2.4.0test11 available at

i386: gcc asm(): wrong constraint for mull

Hello, I noticed (with some inspiration from Andy Kleen) that some asm() instructions for the ia32 use the "g" constraint for "mull", where my Intel 386 Assembly Language Manual suggests the "MUL" instruction needs an r/m operand. So I guess the correct constraint is "rm" in gcc, and not

Re: i386: gcc asm(): wrong constraint for mull

On 29 Dec 2000, at 5:17, Jakub Jelinek wrote: On Fri, Dec 29, 2000 at 10:54:38AM +0100, Ulrich Windl wrote: Hello, I noticed (with some inspiration from Andy Kleen) that some asm() instructions for the ia32 use the "g" constraint for "mull", where my Intel 3

2.4.0test12: problems timing events

Hi, I tried to time events inside the kernel in 2.4.0test12: Basically the same code works fine in 2.2.18 with about 1us jitter. However in 2.4.0test12 the jitter is around 600ms! What I did is this: I modified the interrupt routine of the serial driver to get a precision time-stamp via

suggest: diff-2.4.0-test12_to_2.4.0

I thought I'd find a diff between 2.4.0test12 (last test release) to the final 2.4.0 release, but did not. Wouldn't it be (have been) a good idea? Regards, Ulrich - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please

Re: suggest: diff-2.4.0-test12_to_2.4.0

On 8 Jan 2001, at 14:16, Andreas Jaeger wrote: Ulrich Windl writes: I thought I'd find a diff between 2.4.0test12 (last test release) to the final 2.4.0 release, but did not. Wouldn't it be (have been) a good idea? Apply: patch-2.4.0-prerelease.bz2 and then prerelease

2.4: header file confusion (interrupts)

Inspecting some code I found out that in 2.4.0test12 request_irq() is declared in sched.h, and not in interrupt.h, SA_SHIRQ is declared in asm/signal.h, and not in interrupt.h Isn't that a bit confusing? Maybe for 2.5 let's re-sort some things to clean up dependencies... Regards, Ulrich -

some issues for 2.4.0

Hello, I have some issues on Linux-2.4.0: During boot the (slightly modified, see later) kernel says: 4Linux version 2.4.0-NANO (root@elf) (gcc version 2.95.2 19991024 (release)) #1 Mon Jan 8 22:04:48 MET 2001 [...] 4PCI: PCI BIOS revision 2.10 entry at 0xfb280, last bus=1 4PCI: Using

2.2.18: writing an R/O floppy

Hi, I don't know if it's possible to make fd a read-only device if the inserted media is write-protected, but I had a strange problem: I had inserted a write protected floppy and accessed it via autofs as vfat in 2.2.18. It worked. Some time later it had expired (and I'm not sure whether I

kernel: eepro100: wait_for_cmd_done timeout!

Hello, I'm seeing the message periodically: Nov 8 09:52:59 kgate last message repeated 5 times Nov 8 11:26:54 kgate kernel: eepro100: wait_for_cmd_done timeout! Nov 8 11:56:12 kgate kernel: eepro100: wait_for_cmd_done timeout! Nov 8 14:38:45 kgate kernel: eepro100: wait_for_cmd_done

Re: No 100 HZ timer!

IMHO the POSIX is doable to comply with POSIX. Probably not what many of the RT freaks expect, but doable. I'm tuning the nanoseconds for a while now... Ulrich On 17 Apr 2001, at 11:53, george anzinger wrote: I was thinking that it might be good to remove the POSIX API for the kernel and

patch-proposal: extended adjtime()

Hello, someone found out that in Linux adjtime()'s correction is limited to something like 2000s (signed 32bit microseconds for i386). This is not a true problem, but for those who desperately need/want it, I have a patch proposal (incomplete, but essential) to implement the full range

RFD(time): squeezing and stretching the tick

For i386 with TSC, the kernel calibrates how much CPU cycles will fit between two timer interrupts. That value corresponds to 1 microseconds. Ideally. In practice however the timer interrupts do not happen exactly every 1 us (for hardware reasons). When interpolating time between

having a hard time with 2.4.x

Hello, I have some news on the topic of timekeeping in Linux-2.4: As Alan Cox pointed out the ACPI changes between 2.4.0 and 2.4.1 created a extremely slow console output (if not more). Configuring away ACPI support solved that problem. However there is still a problem that I cannot explain.

pthreads gdb: zombie threads?

Hello, I'm having a strange problem debugging a pthreads application in 2.2.18 (as per SuSE 7.1): gdb says the program terminated normally after having started two or three LWPs. I can exit gdb then, and I find (ps -ax) one zombie thread and two or three other threads. Is it more likely a

Re: announce: PPSkit patch for Linux 2.4.2 (pre6)

Hi, Cycle Counters, Linux currently tries to synchronize TSCs for consistent time in SMP systems. One would not believe what combinations of hardware are tried, especially for precision timing. Here's a short answer to my asking- back about a complaint (the kernel is reporting negative time

2.2.19: config help text about TCO timer

Hi, I know I'm late, but Configure.help in 2.2.19 says: ..."The TCO (Total Cost of Ownership) timer is a watchdog"... I know TCO meaning that, but I can't believe it for a mainboard component. Should the user then throw the PC away, or what? Or is it more safe to reboot frequently. What has

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]

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

Socket-related problem in x86_64 Kernel (2.6.16.53-0.8-smp)?

Hi, since upgrading from SLES9 SP3 to SLES10 SP1 I see kernel segfaults which seem network-related: Most notably slapd does not run any more, and my sendmail-milter based virus scanner terminates now and then with kernel segfault. Current kernel form SLES10 SP1 is: # cat /proc/version Linux

Re: Socket-related problem in x86_64 Kernel (2.6.16.53-0.8-smp)?

On 11 Sep 2007 at 15:01, Eric Dumazet wrote: [...] Also note that the i586 (32-bit, non-SMP) kernel does not have that problem. Linux version 2.6.16.53-0.8-default ([EMAIL PROTECTED]) (gcc version 4.1.2 20070115 (prerelease) (SUSE Linux)) #1 Fri Aug 31 13:07:27 UTC 2007 Are you sure

Re: Socket-related problem in x86_64 Kernel (2.6.16.53-0.8-smp)?

On 11 Sep 2007 at 15:01, Eric Dumazet wrote: On Tue, 11 Sep 2007 11:30:38 +0200 Ulrich Windl [EMAIL PROTECTED] wrote: Hi, since upgrading from SLES9 SP3 to SLES10 SP1 I see kernel segfaults which seem network-related: Most notably slapd does not run any more, and my sendmail

Re: Socket-related problem in x86_64 Kernel (2.6.16.53-0.8-smp)?

On 11 Sep 2007 at 17:04, Al Viro wrote: On Tue, Sep 11, 2007 at 05:54:38PM +0200, Ulrich Windl wrote: If not, any clues on debugging/tracing? There's a /usr/src/linux/Documentation/oops-tracing.txt, but no segfault-tracing. That would be because it has fsck-all to do with the kernel

Q: PCI-X @ 266MHz on HP rx6600 (Qlogic 4Gb FC HBA)

to my address as I'm not subscribed to the kernel list. Regards, Ulrich Windl - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http

Re: Q: PCI-X @ 266MHz on HP rx6600 (Qlogic 4Gb FC HBA)

On 27 Jul 2007 at 9:46, Andrew Patterson wrote: On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote: On Thu, 26 Jul 2007, Andrew Patterson wrote: On Thu, 2007-07-26 at 15:36 +0200, Ulrich Windl wrote: Hi, I have a question: The Qlogic ISP2422 chip is said to handle PCI-X

Re: Q: PCI-X @ 266MHz on HP rx6600 (Qlogic 4Gb FC HBA)

On 31 Jul 2007 at 9:50, Andrew Vasquez wrote: On Fri, 27 Jul 2007, Andrew Patterson wrote: On Thu, 2007-07-26 at 23:23 -0700, Andrew Vasquez wrote: The 33/66/100/133 values refer to the bus-clock speed at which the card is operating. As is seen here (although a bit truncated

throttling kernel messages: KERNEL: assertion (flags MSG_PEEK) failed at net/ipv4/tcp.c (1282)

Hi, I'm affected by the (in)famous bug: Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679 Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags MSG_PEEK) failed at net/ipv4/tcp.c (1282) Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679 Apr

Re: [RFC][PATCH] new timeofday core subsystem (v. A3)

On 15 Mar 2005 at 10:25, john stultz wrote: On Mon, 2005-03-14 at 21:37 -0800, Christoph Lameter wrote: Note that similarities exist between the posix clock and the time sources. Will all time sources be exportable as posix clocks? At this point I'm not familiar enough with the posix

Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

On 24 Jan 2005 at 15:24, Christoph Lameter wrote: On Mon, 24 Jan 2005, john stultz wrote: +/* __monotonic_clock(): + * private function, must hold system_time_lock lock when being + * called. Returns the monotonically increasing number of + * nanoseconds

Re: [RFC][PATCH] new timeofday core subsystem (v. A2)

On 24 Jan 2005 at 17:54, Christoph Lameter wrote: On Mon, 24 Jan 2005, john stultz wrote: We talked about this last time. I do intend to re-work ntp_scale() so its not a function call, much as you describe above. hopelessly endeavoring, hehe But seriously: The easiest approach

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

Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

On 10 Aug 2005 at 22:32, Lee Revell wrote: On Wed, 2005-08-10 at 19:13 -0700, john stultz wrote: All, Here's the next rev in my rework of the current timekeeping subsystem. No major changes, only some cleanups and further splitting the larger patches into smaller ones. Last I

Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

On 16 Aug 2005 at 11:25, Christoph Lameter wrote: You mentioned that the NTP code has some issues with time interpolation at the KS. This is due to the NTP layer not being aware of actual time differences between timer interrupts that the interpolator knows about. If the NTP layer would be

Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

On 16 Aug 2005 at 18:17, john stultz wrote: [...] Maybe to focus this productively, I'll try to step back and outline the goals at a high level and you can address those. My Assumptions: 1. adjtimex() sets/gets NTP state values One of the greatest mistakes in the past which still affects

Re: [RFC - 0/9] Generic timekeeping subsystem (v. B5)

On 24 Aug 2005 at 1:54, Roman Zippel wrote: [...] error) shift. The difference between system time and reference time is really important. gettimeofday() returns the system time, NTP controls the reference time and these two are synchronized regularly. [...] Roman, I'm having a problem

2.6.19: slight performance optimization for lib/string.c's strstrip()

Hi, my apologies for disobeying all the rules for submitting patches, but I'll suggest a performance optimization for strstrip() in lib/string.c: Original routine: char *strstrip(char *s) { size_t size; char *end; size = strlen(s); if (!size) return

TCP checksum change in RPC replies within XEN, NFS lockup (SLES10)

Hello, my apologies for not being sure whom to tell this problem, but it is very strange. Let me tell the story: I'm using XEN (3.0.2) with SLES10 (x86_64, SunFire X4100). On one machine I have three virtual machines (DomU) that are very identically configured (SLES10 x86_64 also). There is

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 from an

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

Ryan Mallon rmal...@gmail.com 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 root): test -r $file cat $file emitting

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

...@gmail.com 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 rmal...@gmail.com 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

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).

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

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

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

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

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

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

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:

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

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

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: 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

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

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

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/

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

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

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.

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

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

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

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

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.

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?)

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

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: 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

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."

). 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."

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 &

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: 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

>>> 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: 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.

  1   2   3   >