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 any

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

res; get_res(&res); printf("resolution 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

), '#7=.sirq' (software IRQs), '#8=.st' (stolen) Is "idle" the only field that is in USER_HZ? 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

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 t

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 for coming late to the d

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

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 paramete

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

nyway). 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:0

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

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

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 descript

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 did

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 how

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. #def

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. >> &g

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

Formatting of /proc/meminfo

t (%-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 li

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 struct

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

the erro 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/

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

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.

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

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 (geeko@build

Q: setting the process name for ps

tf(argv[0], "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

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:

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 server

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

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

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 th

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

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 kerne

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

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

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 th

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 fi

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. [...]

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 e

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

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 cache

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

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

amd.com>: > 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 e

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 revisi

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

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

the 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 >>>>> Nachr

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

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

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

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

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

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

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

ilities: [64] Message Signalled Interrupts: Mask- 64bit+ Queue=0/3 Enable- Capabilities: [74] Vital Product Data Please CC: any replies 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-ke

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 i

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 probl

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 affe

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

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

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 1

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 posi

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

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 > > + * nanosecond

(Fwd) about timer in linux kernel.

inux kernel. Date sent: Fri, 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

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 som

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 tick

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 (maybe

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

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 t

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 wa

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 ker

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.4.2: kernel patch for , 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 as there is no "ndelay()". I implemented "ndelay()" for i386 and adjusted the other macros. During that I found that some files have o

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

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

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?

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

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

2.4 kernel & gcc code generation: a bug?

Trying to find out what got broken in kernel 2.4, I was so clueless as to compare assembly output for 2.2.18 with 2.4.1. However the assembler is quite different, as 2.4 uses the more advanced optimizations of gcc- 2.95.2. Anyway: 1) spinlocks look strange in 2.2(!): .globl rtc_lock .t

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.

2.4.x: spinlock problem

Hello, I had reported this before: In 2.4.0 getting exact system time from interrupt handlers seems inaccurate (in 2.2.18 it works fine). I have applied the same modifications to the 2.4 code base as to 2.2. With 2.4.1 the kernel is incredibly slow, so you can watch the individual lines of ke

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 (PP

patch: 2.4.0/2.5.0: nanoseconds time resolution

not to have 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 sta

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 ha

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: <4>Linux version 2.4.0-NANO (root@elf) (gcc version 2.95.2 19991024 (release)) #1 Mon Jan 8 22:04:48 MET 2001 [...] <4>PCI: PCI BIOS revision 2.10 entry at 0xfb280, last bus=1 <4>PCI: Using c

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

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?

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 read

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 do_ge

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 &qu

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

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 ftp.kernel.org:/pub/linux/daemons/ntp/PPS/pps-2.

  1   2   >