[PATCH] Support UML and make O= when building Debian packages

[Ryan Anderson]

Support UML builds and make O= when building Debian packages.

Sam, I'm pretty sure I've sent this before, but it seems to have been
dropped. I've been using this for a while to build my personal kernels,
and haven't had any problems.  This is a combination of old patches.

Signed-Off-By: Ryan Anderson <[EMAIL PROTECTED]>


Index: linux-git/scripts/package/builddeb
===
--- linux-git.orig/scripts/package/builddeb 2005-07-16 01:35:52.0 
-0400
+++ linux-git/scripts/package/builddeb  2005-07-16 01:38:22.0 -0400
@@ -14,18 +14,37 @@ set -e
 # Some variables and settings used throughout the script
 version=$KERNELRELEASE
 tmpdir="$objtree/debian/tmp"
+packagename=linux-$version
+
+if [ "$ARCH" == "um" ] ; then
+   packagename=user-mode-linux-$version
+fi
 
 # Setup the directory structure
 rm -rf "$tmpdir"
 mkdir -p "$tmpdir/DEBIAN" "$tmpdir/lib" "$tmpdir/boot"
+if [ "$ARCH" == "um" ] ; then
+   mkdir -p "$tmpdir/usr/lib/uml/modules/$version" 
"$tmpdir/usr/share/doc/$packagename" "$tmpdir/usr/bin"
+fi
 
 # Build and install the kernel
-cp System.map "$tmpdir/boot/System.map-$version"
-cp .config "$tmpdir/boot/config-$version"
-cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
+if [ "$ARCH" == "um" ] ; then
+   cp System.map "$tmpdir/usr/lib/uml/modules/$version/System.map"
+   cp .config "$tmpdir/usr/share/doc/$packagename/config"
+   gzip "$tmpdir/usr/share/doc/$packagename/config"
+   cp $KBUILD_IMAGE "$tmpdir/usr/bin/linux-$version"
+else
+   cp System.map "$tmpdir/boot/System.map-$version"
+   cp .config "$tmpdir/boot/config-$version"
+   cp $KBUILD_IMAGE "$tmpdir/boot/vmlinuz-$version"
+fi
 
 if grep -q '^CONFIG_MODULES=y' .config ; then
-   INSTALL_MOD_PATH="$tmpdir" make modules_install
+   INSTALL_MOD_PATH="$tmpdir" make KBUILD_SRC= modules_install
+   if [ "$ARCH" == "um" ] ; then
+   mv "$tmpdir/lib/modules/$version"/* 
"$tmpdir/usr/lib/uml/modules/$version/"
+   rmdir "$tmpdir/lib/modules/$version"
+   fi
 fi
 
 # Install the maintainer scripts
@@ -53,6 +72,8 @@ linux ($version) unstable; urgency=low
 EOF
 
 # Generate a control file
+if [ "$ARCH" == "um" ]; then
+
 cat < debian/control
 Source: linux
 Section: base
@@ -60,12 +81,34 @@ Priority: optional
 Maintainer: $name
 Standards-Version: 3.6.1
 
-Package: linux-$version
+Package: $packagename
+Architecture: any
+Description: User Mode Linux kernel, version $version
+ User-mode Linux is a port of the Linux kernel to its own system call
+ interface.  It provides a kind of virtual machine, which runs Linux
+ as a user process under another Linux kernel.  This is useful for
+ kernel development, sandboxes, jails, experimentation, and
+ many other things.
+ .
+ This package contains the Linux kernel, modules and corresponding other
+ files version $version
+EOF
+
+else
+cat < debian/control
+Source: linux
+Section: base
+Priority: optional
+Maintainer: $name
+Standards-Version: 3.6.1
+
+Package: $packagename
 Architecture: any
 Description: Linux kernel, version $version
  This package contains the Linux kernel, modules and corresponding other
- files version $version.
+ files version $version
 EOF
+fi
 
 # Fix some ownership and permissions
 chown -R root:root "$tmpdir"
Index: linux-git/scripts/package/Makefile
===
--- linux-git.orig/scripts/package/Makefile 2005-07-16 01:35:52.0 
-0400
+++ linux-git/scripts/package/Makefile  2005-07-16 01:38:22.0 -0400
@@ -59,7 +59,7 @@ $(objtree)/binkernel.spec: $(MKSPEC) $(s
$(CONFIG_SHELL) $(MKSPEC) prebuilt > $@

 binrpm-pkg: $(objtree)/binkernel.spec
-   $(MAKE)
+   $(MAKE) KBUILD_SRC=
set -e; \
$(CONFIG_SHELL) $(srctree)/scripts/mkversion > $(objtree)/.tmp_version
set -e; \
@@ -74,7 +74,7 @@ clean-files += $(objtree)/binkernel.spec
 #
 .PHONY: deb-pkg
 deb-pkg:
-   $(MAKE)
+   $(MAKE) KBUILD_SRC=
$(CONFIG_SHELL) $(srctree)/scripts/package/builddeb
 
 clean-dirs += $(objtree)/debian/


-- 

Ryan Anderson
  sometimes Pug Majere
-
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://www.tux.org/lkml/

Re: [stable] Re: [11/11] x86_64: TASK_SIZE fixes for compatibility mode processes

[Chris Wright]

* Andi Kleen ([EMAIL PROTECTED]) wrote:
> On Fri, Jul 15, 2005 at 07:17:44PM -0700, Siddha, Suresh B wrote:
> > On Fri, Jul 15, 2005 at 10:53:33AM -0500, Justin M. Forbes wrote:
> > > That said, I will be testing this patch a bit further
> > 
> > Thanks. Let me know if you see any issues.
> > 
> > > myself, and because it does address a real memory leak issue, we should
> > > consider it or another fix for stable 2.6.12.4.
> > 
> > Appended patch will just fix the memory leak issue. Atleast, we should
> > apply this.
> 
> Looks good. Thanks, Suresh.

Queued for next -stable.

thanks,
-chris
-
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://www.tux.org/lkml/

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Eric St-Laurent]

On Fri, 2005-07-15 at 12:58 -0700, Stephen Pollei wrote:
> But If I understand Linus's points he wants jiffies to remain a memory
> fetch, and make sure it doesn't turn into a singing dancing christmas
> tree.

It seems it relatively easy to support dynamic tick, the ARM
architecture has it. But with the numerous users of jiffies through the
code, it seems to me that it's hard to ensure that everyone of them will
continue to work correctly if the jiffies_increment is changed during
runtime.

As Linus noted, the current tick code is flexible and powerful, but it
can be hard to get it right in all case. 

WinCE developers have similar problems/concerns:

http://blogs.msdn.com/ce_base/archive/2005/06/08/426762.aspx

With the previous cleanup like time_after()/time_before(), msleep() and
friends, unit conversion helpers, etc. it's a step in the right
direction.

I just wanted to point out that while it's good to preserve the current
efficient tick implementation, it may be worthwhile to add a relative
timeout API like Alan Cox proposed a year ago to better hide the
implementation details.


- Eric St-Laurent


-
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://www.tux.org/lkml/

oz6812, yenta_socket and madwifi

[Aristeu Sergio Rozanski Filho]

Hi,
for some time I was unable to use Atheros based cards on my
notebook (O2Micro oz6812 Cardbus controller) because of lots
of rx packets getting dropped by frame errors. running ping I got
this: (~1m from access point)

PING 192.168.67.1 (192.168.67.1): 56 data bytes
64 bytes from 192.168.67.1: icmp_seq=0 ttl=64 time=1.5 ms
wrong data byte #20 should be 0x14 but was 0x0
0 10 18 1 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29
2a 2b 2c 2d 2e 2f 30 31 32 33
34 35 36 37 0 0 0 0 84 dc 5 8 ff ff ff ff
64 bytes from 192.168.67.1: icmp_seq=4 ttl=64 time=1.3 ms
wrong data byte #20 should be 0x14 but was 0x0
0 10 18 1 18 19 1a 1b 1c 1d 1e 1f 20 21 22 23 24 25 26 27 28 29
2a 2b 2c 2d 2e 2f 30 31 32 33
34 35 36 37 0 0 0 0 84 dc 5 8 ff ff ff ff

after playing a bit with yenta_socket I came to this patch which
makes both cards work flawlessly:

--- 2.6.orig/drivers/pcmcia/o2micro.h   2005-07-15 23:43:42.556540296 -0400
+++ 2.6/drivers/pcmcia/o2micro.h2005-07-16 00:23:16.552638032 -0400
@@ -138,6 +138,8 @@
printk(KERN_INFO "Yenta O2: res at 0x94/0xD4: %02x/%02x\n", a, 
b);
 
switch (socket->dev->device) {
+   case PCI_DEVICE_ID_O2_6812:
+   config_writeb(socket, 0xD4, 0);
case PCI_DEVICE_ID_O2_6832:
printk(KERN_INFO "Yenta O2: old bridge, not enabling 
read prefetch / write burst\n");
break;

in oz6812 datasheet there's nothing about read prefetch and write burst
which o2micro_override() enables (and hey, if 6832 is an old bridge, I
guess 6812 is even older :).
while playing with the only control2 register bit described in datasheet
(14th, SCLK_ENABLE) I discovered that zeroing the first byte made the
driver work with both cards (the first 13 bits are described as reserved
for diagnostic test mode).

anyone (perhaps from O2Micro) knows what those bits are exactly or has a
better clue of what's going on here?

(if anyone finds useful, dmesg, ifconfig, /proc/interrupts, lspci -vvv
are attached)

--
Aristeu

Linux version 2.6.11.6-pinguim2 ([EMAIL PROTECTED]) (gcc version 3.3.5 (Debian 
1:3.3.5-8)) #6 Sun Apr 3 17:34:27 GMT+2 2005
BIOS-provided physical RAM map:
 BIOS-e820:  - 0009fc00 (usable)
 BIOS-e820: 0009fc00 - 000a (reserved)
 BIOS-e820: 000f - 0010 (reserved)
 BIOS-e820: 0010 - 0fff (usable)
 BIOS-e820: 0fff - 0fff8000 (ACPI data)
 BIOS-e820: 0fff8000 - 1000 (ACPI NVS)
 BIOS-e820:  - 0001 (reserved)
255MB LOWMEM available.
On node 0 totalpages: 65520
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 61424 pages, LIFO batch:14
  HighMem zone: 0 pages, LIFO batch:1
DMI 2.1 present.
ACPI: RSDP (v000 Acer  ) @ 0x000fe030
ACPI: RSDT (v001 Acer   AN3400x0001 Acer 0x) @ 0x0fff
ACPI: FADT (v001 Acer   AN3400x0001 Acer 0x) @ 0x0fff0054
ACPI: BOOT (v001 Acer   AN3400x0001 Acer 0x) @ 0x0fff002c
ACPI: DSDT (v001   Acer   AN340  0x1000 MSFT 0x010c) @ 0x
Allocating PCI resources starting at 1000 (gap: 1000:efff)
Built 1 zonelists
Kernel command line: root=/dev/hda2 ro vga=787 resume=/dev/hda3
__iounmap: bad address c00fffd9
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to d000 (01201000)
Initializing CPU#0
PID hash table entries: 1024 (order: 10, 16384 bytes)
Detected 499.589 MHz processor.
Using tsc for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 255172k/262080k available (2076k kernel code, 6336k reserved, 1159k 
data, 264k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay loop... 985.08 BogoMIPS (lpj=492544)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
CPU: After generic identify, caps: 0383f9ff     
 
CPU: After vendor identify, caps: 0383f9ff     
 
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU: After all inits, caps: 0383f9ff   0040  
 
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 03
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
ACPI: setting ELCR to 0200 (from 0620)
NET: Registered protocol family 16
EISA bus registered
PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20050211

Re: Linux 2.6.12.3

[Greg KH]

diff --git a/Makefile b/Makefile
--- a/Makefile
+++ b/Makefile
@@ -1,7 +1,7 @@
 VERSION = 2
 PATCHLEVEL = 6
 SUBLEVEL = 12
-EXTRAVERSION = .2
+EXTRAVERSION = .3
 NAME=Woozy Numbat
 
 # *DOCUMENTATION*
diff --git a/arch/ppc/kernel/time.c b/arch/ppc/kernel/time.c
--- a/arch/ppc/kernel/time.c
+++ b/arch/ppc/kernel/time.c
@@ -89,6 +89,9 @@ unsigned long tb_to_ns_scale;
 
 extern unsigned long wall_jiffies;
 
+/* used for timezone offset */
+static long timezone_offset;
+
 DEFINE_SPINLOCK(rtc_lock);
 
 EXPORT_SYMBOL(rtc_lock);
@@ -170,7 +173,7 @@ void timer_interrupt(struct pt_regs * re
 xtime.tv_sec - last_rtc_update >= 659 &&
 abs((xtime.tv_nsec / 1000) - (100-100/HZ)) < 
50/HZ &&
 jiffies - wall_jiffies == 1) {
-   if (ppc_md.set_rtc_time(xtime.tv_sec+1 + time_offset) 
== 0)
+   if (ppc_md.set_rtc_time(xtime.tv_sec+1 + 
timezone_offset) == 0)
last_rtc_update = xtime.tv_sec+1;
else
/* Try again one minute later */
@@ -286,7 +289,7 @@ void __init time_init(void)
unsigned old_stamp, stamp, elapsed;
 
 if (ppc_md.time_init != NULL)
-time_offset = ppc_md.time_init();
+timezone_offset = ppc_md.time_init();
 
if (__USE_RTC()) {
/* 601 processor: dec counts down by 128 every 128ns */
@@ -331,10 +334,10 @@ void __init time_init(void)
set_dec(tb_ticks_per_jiffy);
 
/* If platform provided a timezone (pmac), we correct the time */
-if (time_offset) {
-   sys_tz.tz_minuteswest = -time_offset / 60;
+if (timezone_offset) {
+   sys_tz.tz_minuteswest = -timezone_offset / 60;
sys_tz.tz_dsttime = 0;
-   xtime.tv_sec -= time_offset;
+   xtime.tv_sec -= timezone_offset;
 }
 set_normalized_timespec(_to_monotonic,
 -xtime.tv_sec, -xtime.tv_nsec);
diff --git a/arch/um/kernel/process.c b/arch/um/kernel/process.c
--- a/arch/um/kernel/process.c
+++ b/arch/um/kernel/process.c
@@ -130,7 +130,7 @@ int start_fork_tramp(void *thread_arg, u
return(arg.pid);
 }
 
-static int ptrace_child(void)
+static int ptrace_child(void *arg)
 {
int ret;
int pid = os_getpid(), ppid = getppid();
@@ -159,16 +159,20 @@ static int ptrace_child(void)
_exit(ret);
 }
 
-static int start_ptraced_child(void)
+static int start_ptraced_child(void **stack_out)
 {
+   void *stack;
+   unsigned long sp;
int pid, n, status;

-   pid = fork();
-   if(pid == 0)
-   ptrace_child();
-
+   stack = mmap(NULL, PAGE_SIZE, PROT_READ | PROT_WRITE | PROT_EXEC,
+MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
+   if(stack == MAP_FAILED)
+   panic("check_ptrace : mmap failed, errno = %d", errno);
+   sp = (unsigned long) stack + PAGE_SIZE - sizeof(void *);
+   pid = clone(ptrace_child, (void *) sp, SIGCHLD, NULL);
if(pid < 0)
-   panic("check_ptrace : fork failed, errno = %d", errno);
+   panic("check_ptrace : clone failed, errno = %d", errno);
CATCH_EINTR(n = waitpid(pid, , WUNTRACED));
if(n < 0)
panic("check_ptrace : wait failed, errno = %d", errno);
@@ -176,6 +180,7 @@ static int start_ptraced_child(void)
panic("check_ptrace : expected SIGSTOP, got status = %d",
  status);
 
+   *stack_out = stack;
return(pid);
 }
 
@@ -183,12 +188,12 @@ static int start_ptraced_child(void)
  * just avoid using sysemu, not panic, but only if SYSEMU features are broken.
  * So only for SYSEMU features we test mustpanic, while normal host features
  * must work anyway!*/
-static int stop_ptraced_child(int pid, int exitcode, int mustexit)
+static int stop_ptraced_child(int pid, void *stack, int exitcode, int 
mustpanic)
 {
int status, n, ret = 0;
 
if(ptrace(PTRACE_CONT, pid, 0, 0) < 0)
-   panic("stop_ptraced_child : ptrace failed, errno = %d", errno);
+   panic("check_ptrace : ptrace failed, errno = %d", errno);
CATCH_EINTR(n = waitpid(pid, , 0));
if(!WIFEXITED(status) || (WEXITSTATUS(status) != exitcode)) {
int exit_with = WEXITSTATUS(status);
@@ -199,13 +204,15 @@ static int stop_ptraced_child(int pid, i
printk("check_ptrace : child exited with exitcode %d, while "
  "expecting %d; status 0x%x", exit_with,
  exitcode, status);
-   if (mustexit)
+   if (mustpanic)
panic("\n");
else
printk("\n");
ret = -1;
}
 
+   if(munmap(stack, PAGE_SIZE) < 0)
+   panic("check_ptrace : munmap failed, errno = %d", errno);

Linux 2.6.12.3

[Greg KH]

We (the -stable team) are announcing the release of the 2.6.12.3 kernel.

The diffstat and short summary of the fixes are below.

I'll also be replying to this message with a copy of the patch between
2.6.12.2 and 2.6.12.3, as it is small enough to do so.

The updated 2.6.12.y git tree can be found at:

rsync://rsync.kernel.org/pub/scm/linux/kernel/git/gregkh/linux-2.6.12.y.git
and can be browsed at the normal kernel.org git web browser:
www.kernel.org/git/

thanks,

greg k-h

--

 Makefile |2 
 arch/ppc/kernel/time.c   |   13 ++--
 arch/um/kernel/process.c |   48 ++---
 drivers/acpi/pci_irq.c   |2 
 drivers/char/tpm/tpm.c   |   76 ---
 drivers/char/tpm/tpm.h   |2 
 drivers/char/tpm/tpm_atmel.c |   16 +++--
 drivers/char/tpm/tpm_nsc.c   |   16 +++--
 drivers/char/tty_ioctl.c |4 -
 drivers/media/video/cx88/cx88-video.c|2 
 drivers/net/hamradio/Kconfig |2 
 drivers/net/shaper.c |   40 +-
 fs/char_dev.c|2 
 include/linux/if_shaper.h|2 
 net/ipv4/ip_output.c |3 -
 net/ipv4/netfilter/ip_conntrack_standalone.c |7 ++
 net/packet/af_packet.c   |6 ++
 17 files changed, 93 insertions(+), 150 deletions(-)


Summary of changes from v2.6.12.2 to v2.6.12.3
==

Alexander Nyberg:
  If ACPI doesn't find an irq listed, don't accept 0 as a valid PCI irq.

David S. Miller:
  fix Shaper driver lossage in 2.6.12

Greg Kroah-Hartman:
  Linux 2.6.12.3

john stultz:
  ppc32: stop misusing ntps time_offset value

KAMBAROV, ZAUR:
  coverity: tty_ldisc_ref return null check

Kylene Jo Hall:
  tpm breaks 8139cp

Michael Krufky:
  v4l cx88 hue offset fix

Paolo 'Blaisorblade' Giarrusso:
  uml: fix TT mode by reverting "use fork instead of clone"

Patrick McHardy:
  revert nf_reset change

Ralf Baechle:
  SMP fix for 6pack driver

Wen-chien Jesse Sung:
  fix semaphore handling in __unregister_chrdev_region
-
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://www.tux.org/lkml/

Re: [11/11] x86_64: TASK_SIZE fixes for compatibility mode processes

[Andi Kleen]

On Fri, Jul 15, 2005 at 07:17:44PM -0700, Siddha, Suresh B wrote:
> On Fri, Jul 15, 2005 at 10:53:33AM -0500, Justin M. Forbes wrote:
> > That said, I will be testing this patch a bit further
> 
> Thanks. Let me know if you see any issues.
> 
> > myself, and because it does address a real memory leak issue, we should
> > consider it or another fix for stable 2.6.12.4.
> 
> Appended patch will just fix the memory leak issue. Atleast, we should
> apply this.

Looks good. Thanks, Suresh.

-Andi
-
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://www.tux.org/lkml/

Re: 2.6.12 vs. /sbin/cardmgr

[Bob Tracy]

Dominik Brodowski wrote:
> On Sun, Jul 10, 2005 at 03:37:22PM -0500, Bob Tracy wrote:
> > Dominik Brodowski wrote:
> > > On Sat, Jul 09, 2005 at 12:12:17AM -0500, Bob Tracy wrote:
> > > > (/sbin/cardmgr chewing up lots of CPU cycles with 2.6.12 kernel)
> > > 
> > > Please post the output of "lspci" and "lsmod" as I'd like to know which
> > > kind of PCMCIA bridge is in your notebook.
> 
> OK, it's a plain TI1225. Could you try whether the bug is still existent in
> 2.6.13-rc3, please?

2.6.13-rc3 works fine here.  The "cardmgr" process is no longer chewing
up lots of CPU time, and otherwise seems to be working correctly.  Thanks!

-- 
---
Bob Tracy   WTO + WIPO = DMCA? http://www.anti-dmca.org
[EMAIL PROTECTED]
---
-
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://www.tux.org/lkml/

Re: [PATCH] mb_cache_shrink() frees unexpected caches

[Akinobu Mita]

2005-07-16 (Sat) 03:44 +0200 Andreas Gruenbacher wrote:
> Removing the cache parameter from mb_cache_shrink would break when more than 
> one mb_cache is used per filesystem, correct. Leaving the parameter in and 
> adding your patch is more "future proof", so I'm fine with it. Are you 
> actually using more than one mb_cache, or is this theoretical?

This is just theorecal.

Now I agree with your two patches except for the name of
"mb_cache_shrink".  it should be renamed to imply that this function
shrinks all sort of mbcache on specified block device.





-
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://www.tux.org/lkml/

Re: [rfc patch 2/2] direct-io: remove address alignment check

[Tejun Heo]

Badari Pulavarty wrote:

On Fri, 2005-07-15 at 17:23 +0900, Tejun Heo wrote:


Badari Pulavarty wrote:


...

I don't know why you wanna relax the alignment requirement, but 
wouldn't it be easier to just write/use block-aligned allocator for 
such buffers?  It will even make the program more portable.




I can imagine a reason for relaxing the alignment. I keep getting asked
whether we can do "O_DIRECT mount option".  Database folks wants to
make sure all the access to files in a given filesystem are O_DIRECT
(whether they are accessing or some random program like ftp, scp, cp
are acessing them). This was mainly to ensure that buffered accesses to
the file doesn't polute the pagecache (while database is using O_DIRECT
access). Seems like a logical request, but not easy to do :(

Thanks,
Badari


 I don't know much about VM, but, if that's necessary, I think that 
limiting pagecache size per mounted fs (or by some other applicable 
category) is easier/more complete approach.  After all, you cannot mmap 
w/ O_DIRECT and many programs (gcc, ld come to mind) mmap large part of 
their memory usage.



I agree. I guess for mmap()ed access we can kick it back to buffered
mode.

I don't think limiting pagecache use per filesystem is an acceptable
option. In fact, database folks exactly want this -  to limit the
pagecache use by filesystems - but I don't think its right thing to do,
so I am trying to propose mount O_DIRECT as an alternative (if its
feasible).


 Just out of curiosity, can you tell me why you think limiting 
pagecache isn't the right thing to do (tm)?  O_DIRECT mount seems to me 
incomplete/complex solution (DMA alignment etc...).  Forgive me if this 
issue has been discussed to death already.


--
tejun
-
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://www.tux.org/lkml/

[RFC][PATCH 5/6] new timeofday i386 arch specific changes, part 4 (v. B4)

[john stultz]

All,
The conversion of i386 to use the new timeofday subsystem has been
split into 4 parts. This patch, the final of four, converts the i386
arch to use the new timeofday subsystem and removes the old
timers/timer_opts infrastructure. 

It applies on top of my timeofday-arch-i386-part3 patch. This patch is
the last in the the timeofday-arch-i386 patchset, so you should be able
to build and boot a kernel after it has been applied. 

Note that this patch does not provide any i386 timesources, so you will
only have the jiffies timesource. To get full replacements for the code
being removed here, the following timeofday-timesources-i386 patch will
need to be applied.

thanks
-john

linux-2.6.13-rc3_timeofday-arch-i386-part4_B4.patch

diff --git a/arch/i386/Kconfig b/arch/i386/Kconfig
--- a/arch/i386/Kconfig
+++ b/arch/i386/Kconfig
@@ -14,6 +14,10 @@ config X86
  486, 586, Pentiums, and various instruction-set-compatible chips by
  AMD, Cyrix, and others.
 
+config NEWTOD
+   bool
+   default y
+
 config MMU
bool
default y
diff --git a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -10,7 +10,6 @@ obj-y := process.o semaphore.o signal.o 
doublefault.o quirks.o tsc.o
 
 obj-y  += cpu/
-obj-y  += timers/
 obj-$(CONFIG_ACPI_BOOT)+= acpi/
 obj-$(CONFIG_X86_BIOS_REBOOT)  += reboot.o
 obj-$(CONFIG_MCA)  += mca.o
diff --git a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c
+++ b/arch/i386/kernel/time.c
@@ -46,7 +46,6 @@
 #include 
 #include 
 #include 
-#include 
 
 #include 
 #include 
@@ -57,6 +56,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "mach_time.h"
 
@@ -92,8 +92,6 @@ EXPORT_SYMBOL(rtc_lock);
 DEFINE_SPINLOCK(i8253_lock);
 EXPORT_SYMBOL(i8253_lock);
 
-struct timer_opts *cur_timer __read_mostly = _none;
-
 /*
  * This is a special lock that is owned by the CPU and holds the index
  * register we are working with.  It is required for NMI access to the
@@ -123,99 +121,19 @@ void rtc_cmos_write(unsigned char val, u
 }
 EXPORT_SYMBOL(rtc_cmos_write);
 
-/*
- * This version of gettimeofday has microsecond resolution
- * and better than microsecond precision on fast x86 machines with TSC.
- */
-void do_gettimeofday(struct timeval *tv)
-{
-   unsigned long seq;
-   unsigned long usec, sec;
-   unsigned long max_ntp_tick;
-
-   do {
-   unsigned long lost;
-
-   seq = read_seqbegin(_lock);
-
-   usec = cur_timer->get_offset();
-   lost = jiffies - wall_jiffies;
-
-   /*
-* If ntp_adjtime_offset is negative then NTP is slowing the 
clock
-* so make sure not to go into next possible interval.
-* Better to lose some accuracy than have time go backwards..
-*/
-   if (unlikely(ntp_adjtime_offset < 0)) {
-   max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
-   usec = min(usec, max_ntp_tick);
-
-   if (lost)
-   usec += lost * max_ntp_tick;
-   }
-   else if (unlikely(lost))
-   usec += lost * (USEC_PER_SEC / HZ);
-
-   sec = xtime.tv_sec;
-   usec += (xtime.tv_nsec / 1000);
-   } while (read_seqretry(_lock, seq));
-
-   while (usec >= 100) {
-   usec -= 100;
-   sec++;
-   }
-
-   tv->tv_sec = sec;
-   tv->tv_usec = usec;
-}
-
-EXPORT_SYMBOL(do_gettimeofday);
-
-int do_settimeofday(struct timespec *tv)
-{
-   time_t wtm_sec, sec = tv->tv_sec;
-   long wtm_nsec, nsec = tv->tv_nsec;
-
-   if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
-   return -EINVAL;
-
-   write_seqlock_irq(_lock);
-   /*
-* This is revolting. We need to set "xtime" correctly. However, the
-* value in this location is the value at the most recent update of
-* wall time.  Discover what correction gettimeofday() would have
-* made, and then undo it!
-*/
-   nsec -= cur_timer->get_offset() * NSEC_PER_USEC;
-   nsec -= (jiffies - wall_jiffies) * TICK_NSEC;
-
-   wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
-   wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
-
-   set_normalized_timespec(, sec, nsec);
-   set_normalized_timespec(_to_monotonic, wtm_sec, wtm_nsec);
-
-   ntp_clear();
-   write_sequnlock_irq(_lock);
-   clock_was_set();
-   return 0;
-}
-
-EXPORT_SYMBOL(do_settimeofday);
-
 static int set_rtc_mmss(unsigned long nowtime)
 {
int retval;
-
-   WARN_ON(irqs_disabled());
+   unsigned long flags;
 
/* gets recalled with irq locally 

[RFC][PATCH 4/6] new timeofday i386 arch specific changes, part 3 (v.B4)

[john stultz]

All,
The conversion of i386 to use the new timeofday subsystem has 
been
split into 4 parts. This patch, the third of four, reworks some of the
code in the new tsc.c file. Additionally it adds some new interfaces and
hooks to use these new interfaces appropriately. This patch also renames
some ACPI PM variables. 

It applies on top of my timeofday-arch-i386-part2 patch. This patch is
part the timeofday-arch-i386 patchset, so without the following parts it
is not expected to compile.

thanks
-john

linux-2.6.13-rc3_timeofday-arch-i386-part3_B4.patch

diff --git a/arch/i386/kernel/acpi/boot.c b/arch/i386/kernel/acpi/boot.c
--- a/arch/i386/kernel/acpi/boot.c
+++ b/arch/i386/kernel/acpi/boot.c
@@ -633,7 +633,8 @@ static int __init acpi_parse_hpet(unsign
 #endif
 
 #ifdef CONFIG_X86_PM_TIMER
-extern u32 pmtmr_ioport;
+u32 acpi_pmtmr_ioport;
+int acpi_pmtmr_buggy;
 #endif
 
 static int __init acpi_parse_fadt(unsigned long phys, unsigned long size)
@@ -664,13 +665,13 @@ static int __init acpi_parse_fadt(unsign
if (fadt->xpm_tmr_blk.address_space_id != 
ACPI_ADR_SPACE_SYSTEM_IO)
return 0;
 
-   pmtmr_ioport = fadt->xpm_tmr_blk.address;
+   acpi_pmtmr_ioport = fadt->xpm_tmr_blk.address;
} else {
/* FADT rev. 1 */
-   pmtmr_ioport = fadt->V1_pm_tmr_blk;
+   acpi_pmtmr_ioport = fadt->V1_pm_tmr_blk;
}
-   if (pmtmr_ioport)
-   printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x\n", 
pmtmr_ioport);
+   if (acpi_pmtmr_ioport)
+   printk(KERN_INFO PREFIX "PM-Timer IO Port: %#x\n", 
acpi_pmtmr_ioport);
 #endif
return 0;
 }
diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c
--- a/arch/i386/kernel/setup.c
+++ b/arch/i386/kernel/setup.c
@@ -1610,6 +1610,7 @@ void __init setup_arch(char **cmdline_p)
conswitchp = _con;
 #endif
 #endif
+   tsc_init();
 }
 
 #include "setup_arch_post.h"
diff --git a/arch/i386/kernel/tsc.c b/arch/i386/kernel/tsc.c
--- a/arch/i386/kernel/tsc.c
+++ b/arch/i386/kernel/tsc.c
@@ -5,11 +5,17 @@
  */
 
 #include 
-#include 
 #include 
+#include 
 #include 
 #include "mach_timer.h"
 
+/* On some systems the TSC frequency does not
+ * change with the cpu frequency. So we need
+ * an extra value to store the TSC freq
+ */
+unsigned int tsc_khz;
+
 int tsc_disable __initdata = 0;
 #ifndef CONFIG_X86_TSC
 /* disable flag for tsc.  Takes effect by clearing the TSC cpu flag
@@ -32,15 +38,42 @@ __setup("notsc", tsc_setup);
 
 int read_current_timer(unsigned long *timer_val)
 {
-   if (cur_timer->read_timer) {
-   *timer_val = cur_timer->read_timer();
+   if (!tsc_disable && cpu_khz) {
+   rdtscl(*timer_val);
return 0;
}
return -1;
 }
 
+/* Code to mark and check if the TSC is unstable
+ * due to cpufreq or due to unsynced TSCs
+ */
+static int tsc_unstable;
+int check_tsc_unstable(void)
+{
+   return tsc_unstable;
+}
+
+void mark_tsc_unstable(void)
+{
+   tsc_unstable = 1;
+}
+
+/* Code to compensate for C3 stalls */
+static u64 tsc_c3_offset;
+void tsc_c3_compensate(unsigned long usecs)
+{
+   u64 cycles = (usecs * tsc_khz)/1000;
+   tsc_c3_offset += cycles;
+}
+
+u64 tsc_read_c3_time(void)
+{
+   return tsc_c3_offset;
+}
 
-/* convert from cycles(64bits) => nanoseconds (64bits)
+/* Accellerators for sched_clock()
+ * convert from cycles(64bits) => nanoseconds (64bits)
  *  basic equation:
  * ns = cycles / (freq / ns_per_sec)
  * ns = cycles * (ns_per_sec / freq)
@@ -80,76 +113,54 @@ unsigned long long sched_clock(void)
 * synchronized across all CPUs.
 */
 #ifndef CONFIG_NUMA
-   if (!use_tsc)
+   if (!cpu_khz || check_tsc_unstable())
 #endif
/* no locking but a rare wrong value is not a big deal */
-   return jiffies_64 * (10 / HZ);
+   return (jiffies_64 - INITIAL_JIFFIES) * (10 / HZ);
 
/* Read the Time Stamp Counter */
rdtscll(this_offset);
+   this_offset += tsc_read_c3_time();
 
/* return the value in ns */
return cycles_2_ns(this_offset);
 }
 
-/* -- Calibrate the TSC ---
- * Return 2^32 * (1 / (TSC clocks per usec)) for do_fast_gettimeoffset().
- * Too much 64-bit arithmetic here to do this cleanly in C, and for
- * accuracy's sake we want to keep the overhead on the CTC speaker (channel 2)
- * output busy loop as low as possible. We avoid reading the CTC registers
- * directly because of the awkward 8-bit access mechanism of the 82C54
- * device.
- */
-
-#define CALIBRATE_TIME (5 * 120/HZ)
 
-unsigned long calibrate_tsc(void)
+static unsigned long calculate_cpu_khz(void)
 {
-   mach_prepare_counter();
-
-   {
-   unsigned long startlow, starthigh;
-   unsigned long endlow, endhigh;
- 

[RFC][PATCH 6/6] new timeofday i386 specific timesources

[john stultz]

All,
This patch implements the time sources shared between i386 acpi_pm,
cyclone, hpet, pit, tsc and tsc-interp). The patch should apply on top
of the timeofday-arch-i386-part4 patch.

The patch should be fairly straight forward, only adding the new
timesources.

thanks
-john

linux-2.6.13-rc3_timeofday-timesources-i386_B4.patch

diff --git a/drivers/timesource/Makefile b/drivers/timesource/Makefile
--- a/drivers/timesource/Makefile
+++ b/drivers/timesource/Makefile
@@ -1 +1,8 @@
 obj-y += jiffies.o
+
+obj-$(CONFIG_X86) += tsc.o
+obj-$(CONFIG_X86) += i386_pit.o
+obj-$(CONFIG_X86) += tsc-interp.o
+obj-$(CONFIG_X86_CYCLONE_TIMER) += cyclone.o
+obj-$(CONFIG_X86_PM_TIMER) += acpi_pm.o
+obj-$(CONFIG_HPET_TIMER) += hpet.o
diff --git a/drivers/timesource/acpi_pm.c b/drivers/timesource/acpi_pm.c
new file mode 100644
--- /dev/null
+++ b/drivers/timesource/acpi_pm.c
@@ -0,0 +1,152 @@
+/*
+ * linux/drivers/timesource/acpi_pm.c
+ *
+ * This file contains the ACPI PM based time source.
+ *
+ * This code was largely moved from the i386 timer_pm.c file
+ * which was (C) Dominik Brodowski <[EMAIL PROTECTED]> 2003
+ * and contained the following comments:
+ *
+ * Driver to use the Power Management Timer (PMTMR) available in some
+ * southbridges as primary timing source for the Linux kernel.
+ *
+ * Based on parts of linux/drivers/acpi/hardware/hwtimer.c, timer_pit.c,
+ * timer_hpet.c, and on Arjan van de Ven's implementation for 2.4.
+ *
+ * This file is licensed under the GPL v2.
+ */
+
+
+#include 
+#include 
+#include 
+#include 
+
+/* Number of PMTMR ticks expected during calibration run */
+#define PMTMR_TICKS_PER_SEC 3579545
+
+#if (CONFIG_X86 && (!CONFIG_X86_64))
+#include "mach_timer.h"
+#define PMTMR_EXPECTED_RATE ((PMTMR_TICKS_PER_SEC*CALIBRATE_TIME_MSEC)/1000)
+#endif
+
+/* The I/O port the PMTMR resides at.
+ * The location is detected during setup_arch(),
+ * in arch/i386/acpi/boot.c */
+extern u32 acpi_pmtmr_ioport;
+extern int acpi_pmtmr_buggy;
+
+#define ACPI_PM_MASK 0xFF /* limit it to 24 bits */
+
+
+static inline u32 read_pmtmr(void)
+{
+   /* mask the output to 24 bits */
+   return inl(acpi_pmtmr_ioport) & ACPI_PM_MASK;
+}
+
+static cycle_t acpi_pm_read_verified(void)
+{
+   u32 v1=0,v2=0,v3=0;
+   /* It has been reported that because of various broken
+* chipsets (ICH4, PIIX4 and PIIX4E) where the ACPI PM time
+* source is not latched, so you must read it multiple
+* times to insure a safe value is read.
+*/
+   do {
+   v1 = read_pmtmr();
+   v2 = read_pmtmr();
+   v3 = read_pmtmr();
+   } while ((v1 > v2 && v1 < v3) || (v2 > v3 && v2 < v1)
+   || (v3 > v1 && v3 < v2));
+
+   return (cycle_t)v2;
+}
+
+
+static cycle_t acpi_pm_read(void)
+{
+   return (cycle_t)read_pmtmr();
+}
+
+struct timesource_t timesource_acpi_pm = {
+   .name = "acpi_pm",
+   .priority = 200,
+   .type = TIMESOURCE_FUNCTION,
+   .read_fnct = acpi_pm_read,
+   .mask = (cycle_t)ACPI_PM_MASK,
+   .mult = 0, /*to be caluclated*/
+   .shift = 22,
+};
+
+#if (CONFIG_X86 && (!CONFIG_X86_64))
+/*
+ * Some boards have the PMTMR running way too fast. We check
+ * the PMTMR rate against PIT channel 2 to catch these cases.
+ */
+static int __init verify_pmtmr_rate(void)
+{
+   u32 value1, value2;
+   unsigned long count, delta;
+
+   mach_prepare_counter();
+   value1 = read_pmtmr();
+   mach_countup();
+   value2 = read_pmtmr();
+   delta = (value2 - value1) & ACPI_PM_MASK;
+
+   /* Check that the PMTMR delta is within 5% of what we expect */
+   if (delta < (PMTMR_EXPECTED_RATE * 19) / 20 ||
+   delta > (PMTMR_EXPECTED_RATE * 21) / 20) {
+   printk(KERN_INFO "PM-Timer running at invalid rate: %lu%% of 
normal - aborting.\n", 100UL * delta / PMTMR_EXPECTED_RATE);
+   return -1;
+   }
+
+   return 0;
+}
+#else
+#define verify_pmtmr_rate() (0)
+#endif
+
+static int __init init_acpi_pm_timesource(void)
+{
+   u32 value1, value2;
+   unsigned int i;
+
+   if (!acpi_pmtmr_ioport)
+   return -ENODEV;
+
+   timesource_acpi_pm.mult = timesource_hz2mult(PMTMR_TICKS_PER_SEC,
+   
timesource_acpi_pm.shift);
+
+   /* "verify" this timing source */
+   value1 = read_pmtmr();
+   for (i = 0; i < 1; i++) {
+   value2 = read_pmtmr();
+   if (value2 == value1)
+   continue;
+   if (value2 > value1)
+   goto pm_good;
+   if ((value2 < value1) && ((value2) < 0xFFF))
+   goto pm_good;
+   printk(KERN_INFO "PM-Timer had inconsistent results: 0x%#x, 
0x%#x - aborting.\n", value1, value2);
+   return -EINVAL;
+   }
+   

[RFC][PATCH 3/6] new timeofday i386 arch specific changes, part 2 (v. B4)

[john stultz]

All,
The conversion of i386 to use the new timeofday subsystem has been
split into 4 parts. This patch, the second of four, is a cleanup patch
for the i386 arch in preperation of moving the the new timeofday
infrastructure. It moves some code from timer_tsc.c to a new tsc.c file.

It applies on top of my timeofday-arch-i386-part1 patch. This patch is
part the timeofday-arch-i386 patchset, so without the following parts it
is not expected to compile.

thanks
-john

linux-2.6.13-rc3_timeofday-arch-i386-part2_B4.patch

diff --git a/arch/i386/kernel/Makefile b/arch/i386/kernel/Makefile
--- a/arch/i386/kernel/Makefile
+++ b/arch/i386/kernel/Makefile
@@ -7,7 +7,7 @@ extra-y := head.o init_task.o vmlinux.ld
 obj-y  := process.o semaphore.o signal.o entry.o traps.o irq.o vm86.o \
ptrace.o time.o ioport.o ldt.o setup.o i8259.o sys_i386.o \
pci-dma.o i386_ksyms.o i387.o dmi_scan.o bootflag.o \
-   doublefault.o quirks.o
+   doublefault.o quirks.o tsc.o
 
 obj-y  += cpu/
 obj-y  += timers/
diff --git a/arch/i386/kernel/timers/common.c b/arch/i386/kernel/timers/common.c
--- a/arch/i386/kernel/timers/common.c
+++ b/arch/i386/kernel/timers/common.c
@@ -14,66 +14,6 @@
 
 #include "mach_timer.h"
 
-/* -- Calibrate the TSC ---
- * Return 2^32 * (1 / (TSC clocks per usec)) for do_fast_gettimeoffset().
- * Too much 64-bit arithmetic here to do this cleanly in C, and for
- * accuracy's sake we want to keep the overhead on the CTC speaker (channel 2)
- * output busy loop as low as possible. We avoid reading the CTC registers
- * directly because of the awkward 8-bit access mechanism of the 82C54
- * device.
- */
-
-#define CALIBRATE_TIME (5 * 120/HZ)
-
-unsigned long calibrate_tsc(void)
-{
-   mach_prepare_counter();
-
-   {
-   unsigned long startlow, starthigh;
-   unsigned long endlow, endhigh;
-   unsigned long count;
-
-   rdtsc(startlow,starthigh);
-   mach_countup();
-   rdtsc(endlow,endhigh);
-
-
-   /* Error: ECTCNEVERSET */
-   if (count <= 1)
-   goto bad_ctc;
-
-   /* 64-bit subtract - gcc just messes up with long longs */
-   __asm__("subl %2,%0\n\t"
-   "sbbl %3,%1"
-   :"=a" (endlow), "=d" (endhigh)
-   :"g" (startlow), "g" (starthigh),
-"0" (endlow), "1" (endhigh));
-
-   /* Error: ECPUTOOFAST */
-   if (endhigh)
-   goto bad_ctc;
-
-   /* Error: ECPUTOOSLOW */
-   if (endlow <= CALIBRATE_TIME)
-   goto bad_ctc;
-
-   __asm__("divl %2"
-   :"=a" (endlow), "=d" (endhigh)
-   :"r" (endlow), "0" (0), "1" (CALIBRATE_TIME));
-
-   return endlow;
-   }
-
-   /*
-* The CTC wasn't reliable: we got a hit on the very first read,
-* or the CPU was so fast/slow that the quotient wouldn't fit in
-* 32 bits..
-*/
-bad_ctc:
-   return 0;
-}
-
 #ifdef CONFIG_HPET_TIMER
 /* -- Calibrate the TSC using HPET ---
  * Return 2^32 * (1 / (TSC clocks per usec)) for getting the CPU freq.
@@ -146,27 +86,3 @@ unsigned long read_timer_tsc(void)
rdtscl(retval);
return retval;
 }
-
-
-/* calculate cpu_khz */
-void init_cpu_khz(void)
-{
-   if (cpu_has_tsc) {
-   unsigned long tsc_quotient = calibrate_tsc();
-   if (tsc_quotient) {
-   /* report CPU clock rate in Hz.
-* The formula is (10^6 * 2^32) / (2^32 * 1 / 
(clocks/us)) =
-* clock/second. Our precision is about 100 ppm.
-*/
-   {   unsigned long eax=0, edx=1000;
-   __asm__("divl %2"
-   :"=a" (cpu_khz), "=d" (edx)
-   :"r" (tsc_quotient),
-   "0" (eax), "1" (edx));
-   printk("Detected %u.%03u MHz processor.\n",
-   cpu_khz / 1000, cpu_khz % 1000);
-   }
-   }
-   }
-}
-
diff --git a/arch/i386/kernel/timers/timer_tsc.c 
b/arch/i386/kernel/timers/timer_tsc.c
--- a/arch/i386/kernel/timers/timer_tsc.c
+++ b/arch/i386/kernel/timers/timer_tsc.c
@@ -32,10 +32,6 @@ static unsigned long hpet_last;
 static struct timer_opts timer_tsc;
 #endif
 
-static inline void cpufreq_delayed_get(void);
-
-int tsc_disable __devinitdata = 0;
-
 static int use_tsc;
 /* Number of usecs that the last interrupt was delayed */
 static int delay_at_last_interrupt;
@@ -45,34 +41,6 @@ static unsigned long last_tsc_high; /* m
 static unsigned long long 

Re: [PATCH 2/7] new timeofday i386 arch specific changes, part 1 (v. B4)

[john stultz]

Sorry about that, the subject should have been:

[RFC][PATCH 2/6] new timeofday i386 arch specific changes, part 1 (v. B4)

-
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://www.tux.org/lkml/

[RFC][PATCH 1/6] new timeofday core subsystem

[john stultz]

All,

I've been busy splitting out the NTP changes from the core timeofday
patch, in order to reduce the patch size and avoid any features vs
cleanups confusion. Hopefully this will lead to a more productive
discussion of the proposed changes.

However with OLS upon us, I figured I resend this out to just sync up
with others who have been testing my patches. Unfortunately it is still
a fairly large chunk of code, but I do intend to split this up more and
address the 64bit issues brought up the last time I sent this out. But
this will have to do for now since I'll unlikely be sending any patches
next week.

In the rush in preparing for OLS I really haven't had a chance to test
this beyond compiling it, so tread lightly. 

Now that that is out of the way, here is the patch:

With the goal to simplify, streamline and consolidate the time-of-day
infrastructure, I propose the following common implementation across all
arches. This will allow generic bugs to be fixed once, reduce code
duplication, and with many architectures sharing the same time source,
this allows drivers to be written once for multiple architectures.
Additionally it will better delineate the lines between the soft-timer
subsystem and the time-of-day subsystem, opening the door for more
flexible and better soft-timer management. 

Features of this design:


o Splits time of day management from timer interrupts
o Consolidates a large amount of code
o Generic algorithms which use time-source drivers chosen at runtime
o More consistent and readable code

For another description on the rework, see here:
http://lwn.net/Articles/120850/ (Many thanks to the LWN team for that
easy to understand writeup!)

This patch implements the architecture independent portion of the new
time of day subsystem. Included below is timeofday.c (which includes all
the time of day management and accessor functions), timesource.c (for
timesource specific management functions), interface definition .h
files, the example jiffies timesource (lowest common denominator time
source, mainly for use as example code) and minimal hooks into arch
independent code.

This patch applies ontop of my timeofday-ntp cleanup patchset.

The patch does nothing without at least minimal architecture specific
hooks (i386, x86-64 and other architecture examples to follow), and it
should be able to be applied to a tree without affecting the existing
code.

Finally I'd like to thank the following people who have contributed
ideas, criticism, testing and code that has helped shape this work:

George Anzinger, Nish Aravamudan, Max Asbock, Dominik Brodowski, Darren
Hart, Christoph Lameter, Matt Mackal, Keith Mannthey, Martin
Schwidefsky, Frank Sorenson, Ulrich Windl, Darrick Wong, Roman Zippel
and any others whom I've accidentally forgotten.


thanks
-john


linux-2.6.13-rc3_timeofday-core_B4.patch

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -52,6 +52,7 @@ restrictions referred to are that the re
MTD MTD support is enabled.
NET Appropriate network support is enabled.
NUMANUMA support is enabled.
+   NEW_TOD The new timeofday code is enabled.
NFS Appropriate NFS support is enabled.
OSS OSS sound support is enabled.
PARIDE  The ParIDE subsystem is enabled.
@@ -309,7 +310,7 @@ running once the system is up.
Default value is set via a kernel config option.
Value can be changed at runtime via 
/selinux/checkreqprot.
  
-   clock=  [BUGS=IA-32, HW] gettimeofday timesource override. 
+   clock=  [BUGS=IA-32, HW] gettimeofday timesource override. 
[Deprecated]
Forces specified timesource (if avaliable) to be used
when calculating gettimeofday(). If specicified 
timesource
is not avalible, it defaults to PIT. 
@@ -1442,6 +1443,10 @@ running once the system is up.
 
timeShow timing data prefixed to each printk message line
 
+   timesource= [NEW_TOD] Override the default timesource
+   Override the default timesource and use the timesource
+   with the name specified.
+
tipar.timeout=  [HW,PPT]
Set communications timeout in tenths of a second
(default 15).
diff --git a/drivers/Makefile b/drivers/Makefile
--- a/drivers/Makefile
+++ b/drivers/Makefile
@@ -65,3 +65,4 @@ obj-$(CONFIG_INFINIBAND)  += infiniband/
 obj-$(CONFIG_SGI_IOC4) += sn/
 obj-y  += firmware/
 obj-$(CONFIG_CRYPTO)   += crypto/
+obj-$(CONFIG_NEWTOD)   += timesource/
diff --git a/drivers/char/hangcheck-timer.c b/drivers/char/hangcheck-timer.c

[PATCH 2/7] new timeofday i386 arch specific changes, part 1 (v. B4)

[john stultz]

All,
The conversion of i386 to use the new timeofday subsystem has been
split into 4 parts. This patch, the first of four, is just a simple
cleanup for the i386 arch in preperation of moving the the new timeofday
infrastructure. It simply moves some code from timer_pit.c to i8259.c.

It applies on top of my timeofday-core patch. This patch is part the
timeofday-arch-i386 patchset, so without the following parts it is not
expected to compile (although just this one should).

thanks
-john

linux-2.6.13-rc3_timeofday-arch-i386-part1_B4.patch

diff --git a/arch/i386/kernel/i8259.c b/arch/i386/kernel/i8259.c
--- a/arch/i386/kernel/i8259.c
+++ b/arch/i386/kernel/i8259.c
@@ -24,6 +24,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 
@@ -399,6 +400,45 @@ void __init init_ISA_irqs (void)
}
 }
 
+void setup_pit_timer(void)
+{
+   unsigned long flags;
+
+   spin_lock_irqsave(_lock, flags);
+   outb_p(0x34,PIT_MODE);  /* binary, mode 2, LSB/MSB, ch 0 */
+   udelay(10);
+   outb_p(LATCH & 0xff , PIT_CH0); /* LSB */
+   udelay(10);
+   outb(LATCH >> 8 , PIT_CH0); /* MSB */
+   spin_unlock_irqrestore(_lock, flags);
+}
+
+static int timer_resume(struct sys_device *dev)
+{
+   setup_pit_timer();
+   return 0;
+}
+
+static struct sysdev_class timer_sysclass = {
+   set_kset_name("timer_pit"),
+   .resume = timer_resume,
+};
+
+static struct sys_device device_timer = {
+   .id = 0,
+   .cls= _sysclass,
+};
+
+static int __init init_timer_sysfs(void)
+{
+   int error = sysdev_class_register(_sysclass);
+   if (!error)
+   error = sysdev_register(_timer);
+   return error;
+}
+
+device_initcall(init_timer_sysfs);
+
 void __init init_IRQ(void)
 {
int i;
diff --git a/arch/i386/kernel/timers/timer_pit.c 
b/arch/i386/kernel/timers/timer_pit.c
--- a/arch/i386/kernel/timers/timer_pit.c
+++ b/arch/i386/kernel/timers/timer_pit.c
@@ -162,43 +162,3 @@ struct init_timer_opts __initdata timer_
.init = init_pit, 
.opts = _pit,
 };
-
-void setup_pit_timer(void)
-{
-   unsigned long flags;
-
-   spin_lock_irqsave(_lock, flags);
-   outb_p(0x34,PIT_MODE);  /* binary, mode 2, LSB/MSB, ch 0 */
-   udelay(10);
-   outb_p(LATCH & 0xff , PIT_CH0); /* LSB */
-   udelay(10);
-   outb(LATCH >> 8 , PIT_CH0); /* MSB */
-   spin_unlock_irqrestore(_lock, flags);
-}
-
-static int timer_resume(struct sys_device *dev)
-{
-   setup_pit_timer();
-   return 0;
-}
-
-static struct sysdev_class timer_sysclass = {
-   set_kset_name("timer_pit"),
-   .resume = timer_resume,
-};
-
-static struct sys_device device_timer = {
-   .id = 0,
-   .cls= _sysclass,
-};
-
-static int __init init_timer_sysfs(void)
-{
-   int error = sysdev_class_register(_sysclass);
-   if (!error)
-   error = sysdev_register(_timer);
-   return error;
-}
-
-device_initcall(init_timer_sysfs);
-


-
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://www.tux.org/lkml/

[RFC][PATCH - 12/12] NTP cleanup: use ppm instead of unit adj returned by ntp_advance

[john stultz]

All,
This patch stops ntp_advance() from returning unit adjustments (ie:
nanoseconds). Instead the update_wall_time() function uses the ppm
adjustment from get_ntp_adjustment() which is then converted into a
nanosecond adjustment value.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part12_B4.patch

diff --git a/include/linux/ntp.h b/include/linux/ntp.h
--- a/include/linux/ntp.h
+++ b/include/linux/ntp.h
@@ -9,8 +9,11 @@
 #include 
 #include 
 
+/* Required to safely shift negative values */
+#define shiftR(x,s) (x < 0) ? (-((-x) >> (s))) : ((x) >> (s))
+
 /* NTP state machine interfaces */
-int ntp_advance(unsigned long interval_nsec);
+void ntp_advance(unsigned long interval_nsec);
 int ntp_adjtimex(struct timex*);
 int ntp_leapsecond(struct timespec now);
 void ntp_clear(void);
diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -3,7 +3,9 @@
 *
 * NTP state machine and time scaling code.
 *
-* Code moved from kernel/time.c and kernel/timer.c
+* Copyright (C) 2004, 2005 IBM, John Stultz ([EMAIL PROTECTED])
+*
+* Code moved and rewritten from kernel/time.c and kernel/timer.c
 * Please see those files for original copyrights.
 *
 * This program is free software; you can redistribute it and/or modify
@@ -48,8 +50,6 @@
 
 /* Don't completely fail for HZ > 500.  */
 int tickadj = 500/HZ ? : 1;/* microsecs */
-static long time_phase; /* phase offset (scaled us) */
-static long time_adj;   /* tick adjust (scaled 1 / HZ) */
 
 /* Chapter 5: Kernel Variables [RFC 1589 pg. 28] */
 /* 5.1 Interface Variables */
@@ -82,13 +82,9 @@ static seqlock_t ntp_lock = SEQLOCK_UNLO
 #define MAX_SINGLESHOT_ADJ 500 /* (ppm) */
 #define SEC_PER_DAY 86400
 
-/* Required to safely shift negative values */
-#define shiftR(x,s) (x < 0) ? (-((-x) >> (s))) : ((x) >> (s))
-
-int ntp_advance(unsigned long interval_nsec)
+void ntp_advance(unsigned long interval_nsec)
 {
static unsigned long interval_sum = 0;
-   long time_adjust_step, delta_nsec;
unsigned long flags;
static long ss_adj = 0;
 
@@ -130,23 +126,6 @@ int ntp_advance(unsigned long interval_n
ntp_offset -= next_adj;
offset_adj = shiftR(next_adj, SHIFT_UPDATE); /* ppm */
 
-
-   time_adj = next_adj << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
-   time_adj += shiftR(ntp_freq, (SHIFT_USEC + SHIFT_HZ - 
SHIFT_SCALE));
-#if HZ == 100
-   /* Compensate for (HZ==100) != (1 << SHIFT_HZ).
-* Add 25% and 3.125% to get 128.125;
-* => only 0.125% error (p. 14)
-*/
-   time_adj += shiftR(time_adj,2) + shiftR(time_adj,5);
-#endif
-#if HZ == 1000
-   /* Compensate for (HZ==1000) != (1 << SHIFT_HZ).
-* Add 1.5625% and 0.78125% to get 1023.4375;
-* => only 0.05% error (p. 14)
-*/
-   time_adj += shiftR(time_adj,6) + shiftR(time_adj,7);
-#endif
/* Set ss_adj for the next second */
ss_adj = min_t(unsigned long, singleshot_adj, 
MAX_SINGLESHOT_ADJ);
singleshot_adj -= ss_adj;
@@ -158,42 +137,6 @@ int ntp_advance(unsigned long interval_n
shifted_ppm_sum += ntp_freq; /* already shifted by SHIFT_USEC */
shifted_ppm_sum += ss_adj << SHIFT_USEC;
 
-
-   if ( (time_adjust_step = ntp_adjtime_offset) != 0 ) {
-   /* We are doing an adjtime thing.
-*
-* Prepare time_adjust_step to be within bounds.
-* Note that a positive ntp_adjtime_offset means we want the clock
-* to run faster.
-*
-* Limit the amount of the step to be in the range
-* -tickadj .. +tickadj
-*/
-   if (ntp_adjtime_offset > tickadj)
-   time_adjust_step = tickadj;
-   else if (ntp_adjtime_offset < -tickadj)
-   time_adjust_step = -tickadj;
-
-   /* Reduce by this step the amount of time left  */
-   ntp_adjtime_offset -= time_adjust_step;
-   }
-   delta_nsec = time_adjust_step * 1000;
-
-   /*
-* Advance the phase, once it gets to one microsecond, then
-* advance the tick more.
-*/
-   time_phase += time_adj;
-   if (time_phase <= -FINENSEC) {
-   long ltemp = -time_phase >> (SHIFT_SCALE - 10);
-   time_phase += ltemp << (SHIFT_SCALE - 10);
-   delta_nsec -= ltemp;
-   } else if (time_phase >= FINENSEC) {
-   long ltemp = time_phase >> (SHIFT_SCALE - 10);
-   time_phase -= ltemp << (SHIFT_SCALE - 10);
-   delta_nsec += ltemp;
-   }
-
/* Changes by adjtime() do not take effect till next tick. */
if (ntp_next_adjtime_offset != 0) {
ntp_adjtime_offset = 

[RFC][PATCH - 5/12] NTP cleanup: Break out leapsecond processing

[john stultz]

All,
This patch breaks the leapsecond processing logic into its own
function. By making the NTP code avoid making any direct changes to
time, instead allowing the time code to use NTP to decide when to change
time, we better isolate the NTP subsystem.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part5_B4.patch

diff --git a/include/linux/ntp.h b/include/linux/ntp.h
--- a/include/linux/ntp.h
+++ b/include/linux/ntp.h
@@ -13,6 +13,7 @@
 int ntp_advance(void);
 int ntp_adjtimex(struct timex*);
 void second_overflow(void);
+int ntp_leapsecond(struct timespec now);
 void ntp_clear(void);
 int ntp_synced(void);
 
diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -40,12 +40,6 @@
 #include 
 #include 
 
-#ifdef CONFIG_TIME_INTERPOLATION
-void time_interpolator_update(long delta_nsec);
-#else
-#define time_interpolator_update(x)
-#endif
-
 /* Don't completely fail for HZ > 500.  */
 int tickadj = 500/HZ ? : 1;/* microsecs */
 
@@ -69,6 +63,8 @@ static long time_reftime;   
 long time_adjust;
 static long time_next_adjust;
 
+#define SEC_PER_DAY 86400
+
 /* Required to safely shift negative values */
 #define shiftR(x,s) (x < 0) ? (-((-x) >> (s))) : ((x) >> (s))
 
@@ -142,59 +138,6 @@ void second_overflow(void)
}
 
/*
-* Leap second processing. If in leap-insert state at
-* the end of the day, the system clock is set back one
-* second; if in leap-delete state, the system clock is
-* set ahead one second. The microtime() routine or
-* external clock driver will insure that reported time
-* is always monotonic. The ugly divides should be
-* replaced.
-*/
-   switch (time_state) {
-
-   case TIME_OK:
-   if (time_status & STA_INS)
-   time_state = TIME_INS;
-   else if (time_status & STA_DEL)
-   time_state = TIME_DEL;
-   break;
-
-   case TIME_INS:
-   if (xtime.tv_sec % 86400 == 0) {
-   xtime.tv_sec--;
-   wall_to_monotonic.tv_sec++;
-   /* The timer interpolator will make time change 
gradually instead
-* of an immediate jump by one second.
-*/
-   time_interpolator_update(-NSEC_PER_SEC);
-   time_state = TIME_OOP;
-   clock_was_set();
-   printk(KERN_NOTICE "Clock: inserting leap second 
23:59:60 UTC\n");
-   }
-   break;
-
-   case TIME_DEL:
-   if ((xtime.tv_sec + 1) % 86400 == 0) {
-   xtime.tv_sec++;
-   wall_to_monotonic.tv_sec--;
-   /* Use of time interpolator for a gradual change of 
time */
-   time_interpolator_update(NSEC_PER_SEC);
-   time_state = TIME_WAIT;
-   clock_was_set();
-   printk(KERN_NOTICE "Clock: deleting leap second 
23:59:59 UTC\n");
-   }
-   break;
-
-   case TIME_OOP:
-   time_state = TIME_WAIT;
-   break;
-
-   case TIME_WAIT:
-   if (!(time_status & (STA_INS | STA_DEL)))
-   time_state = TIME_OK;
-   }
-
-   /*
 * Compute the phase adjustment for the next second. In
 * PLL mode, the offset is reduced by a fixed factor
 * times the time constant. In FLL mode the offset is
@@ -438,6 +381,70 @@ leave:
return result;
 }
 
+
+/**
+ * ntp_leapsecond - NTP leapsecond processing code.
+ * now: the current time
+ *
+ * Returns the number of seconds (-1, 0, or 1) that
+ * should be added to the current time to properly
+ * adjust for leapseconds.
+ */
+int ntp_leapsecond(struct timespec now)
+{
+   /*
+* Leap second processing. If in leap-insert state at
+* the end of the day, the system clock is set back one
+* second; if in leap-delete state, the system clock is
+* set ahead one second.
+*/
+   static time_t leaptime = 0;
+
+   switch (time_state) {
+   case TIME_OK:
+   if (time_status & STA_INS)
+   time_state = TIME_INS;
+   else if (time_status & STA_DEL)
+   time_state = TIME_DEL;
+
+   /* calculate end of today (23:59:59)*/
+   leaptime = now.tv_sec + SEC_PER_DAY -
+   (now.tv_sec % SEC_PER_DAY) - 1;
+   break;
+
+   case TIME_INS:
+   /* Once we are at (or past) leaptime, insert the second */
+   if (now.tv_sec >= leaptime) {
+   time_state = TIME_OOP;
+   printk(KERN_NOTICE "Clock: inserting leap 

Re: [RFC][PATCH] Add PCI<->PCI bridge driver [4/9]

[Adam Belay]

On Fri, 2005-07-15 at 09:58 +0100, Russell King wrote:
> On Thu, Jul 14, 2005 at 04:55:19AM -0400, Adam Belay wrote:
> > This patch adds a basic PCI<->PCI bridge driver that utilizes the new
> > PCI bus class API.
> 
> Thanks.  I think this breaks Cardbus.
> 
> The whole point of the way PCI is _presently_ organised is that it allows
> busses to be configured and setup _before_ the devices are made available
> to drivers.  This breaks that completely:

Hi Russell,

I'm aware of this issue.  These changes are major and will need more
than one pass to be correct.  I'll be redoing most of the bus
configuration code in the next patch set.  I have a strategy for proper
device and bus configuration.  These are my current thoughts:

1.) When bound to its device PCI bridge drivers will add their current
devices to the bus device list, but will not register them with the
driver model.

2.) The bus class driver will initiate a procedure similar to
pci_bus_add_devices(), but only for host (root) bridges and hot-plugged
devices.

pci_register_bus_devices(struct pci_bus *bus)
{
- register all bios configured bridges
- call pci_register_bus_devices() for each previously registered bridge
- register remaining uninitialized bridges and call
pci_register_bus_devices() for each bridge as it's registered.
}

pci_register_devices(struct pci_bus *bus)
{
- register all remaining PCI devices, including those of child pci buses
}

* pci_register_bus_devices() will be called first followed by
pci_register_devices().

3.) Bridge windows will not be configured until a child device is
enabled.  In other words, resource configuration is lazy much like we
handle PCI IRQ routing.  We will, however, verify the validity of BIOS
assignments.  If the assignments are incorrect, the bridge will be
disabled and then reconfigured when needed.

Thanks,
Adam


-
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://www.tux.org/lkml/

[RFC][PATCH - 9/12] NTP cleanup: Improve NTP variable names

[john stultz]

All,

This patch changes the NTP variable names from time_* to ntp_* further
clarifying their use. 

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part9_B4.patch

diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c
--- a/arch/cris/kernel/time.c
+++ b/arch/cris/kernel/time.c
@@ -68,11 +68,11 @@ void do_gettimeofday(struct timeval *tv)
}
 
 /*
-* If time_adjust is negative then NTP is slowing the clock
+* If ntp_adjtime_offset is negative then NTP is slowing the clock
 * so make sure not to go into next possible interval.
 * Better to lose some accuracy than have time go backwards..
 */
-   if (unlikely(time_adjust < 0) && usec > tickadj)
+   if (unlikely(ntp_adjtime_offset < 0) && usec > tickadj)
usec = tickadj;
 
sec = xtime.tv_sec;
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -166,11 +166,11 @@ void do_gettimeofday(struct timeval *tv)
lost = jiffies - wall_jiffies;
 
/*
-* If time_adjust is negative then NTP is slowing the clock
+* If ntp_adjtime_offset is negative then NTP is slowing the 
clock
 * so make sure not to go into next possible interval.
 * Better to lose some accuracy than have time go backwards..
 */
-   if (unlikely(time_adjust < 0)) {
+   if (unlikely(ntp_adjtime_offset < 0)) {
max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
usec = min(usec, max_ntp_tick);
 
diff --git a/arch/i386/kernel/time.c b/arch/i386/kernel/time.c
--- a/arch/i386/kernel/time.c
+++ b/arch/i386/kernel/time.c
@@ -142,11 +142,11 @@ void do_gettimeofday(struct timeval *tv)
lost = jiffies - wall_jiffies;
 
/*
-* If time_adjust is negative then NTP is slowing the clock
+* If ntp_adjtime_offset is negative then NTP is slowing the 
clock
 * so make sure not to go into next possible interval.
 * Better to lose some accuracy than have time go backwards..
 */
-   if (unlikely(time_adjust < 0)) {
+   if (unlikely(ntp_adjtime_offset < 0)) {
max_ntp_tick = (USEC_PER_SEC / HZ) - tickadj;
usec = min(usec, max_ntp_tick);
 
diff --git a/arch/m32r/kernel/time.c b/arch/m32r/kernel/time.c
--- a/arch/m32r/kernel/time.c
+++ b/arch/m32r/kernel/time.c
@@ -122,11 +122,11 @@ void do_gettimeofday(struct timeval *tv)
lost = jiffies - wall_jiffies;
 
/*
-* If time_adjust is negative then NTP is slowing the clock
+* If ntp_adjtime_offset is negative then NTP is slowing the 
clock
 * so make sure not to go into next possible interval.
 * Better to lose some accuracy than have time go backwards..
 */
-   if (unlikely(time_adjust < 0)) {
+   if (unlikely(ntp_adjtime_offset < 0)) {
usec = min(usec, max_ntp_tick);
if (lost)
usec += lost * max_ntp_tick;
diff --git a/arch/mips/kernel/time.c b/arch/mips/kernel/time.c
--- a/arch/mips/kernel/time.c
+++ b/arch/mips/kernel/time.c
@@ -171,11 +171,11 @@ void do_gettimeofday(struct timeval *tv)
lost = jiffies - wall_jiffies;
 
/*
-* If time_adjust is negative then NTP is slowing the clock
+* If ntp_adjtime_offset is negative then NTP is slowing the 
clock
 * so make sure not to go into next possible interval.
 * Better to lose some accuracy than have time go backwards..
 */
-   if (unlikely(time_adjust < 0)) {
+   if (unlikely(ntp_adjtime_offset < 0)) {
usec = min(usec, max_ntp_tick);
 
if (lost)
diff --git a/arch/ppc64/kernel/time.c b/arch/ppc64/kernel/time.c
--- a/arch/ppc64/kernel/time.c
+++ b/arch/ppc64/kernel/time.c
@@ -355,7 +355,7 @@ int timer_interrupt(struct pt_regs * reg
timer_sync_xtime(lpaca->next_jiffy_update_tb);
timer_check_rtc();
write_sequnlock(_lock);
-   if ( adjusting_time && (time_adjust == 0) )
+   if ( adjusting_time && (ntp_adjtime_offset == 0) )
ppc_adjtimex();
}
lpaca->next_jiffy_update_tb += tb_ticks_per_jiffy;
@@ -582,7 +582,7 @@ void __init time_init(void)
systemcfg->stamp_xsec = xtime.tv_sec * XSEC_PER_SEC;
systemcfg->tb_to_xs = tb_to_xs;
 
-   time_freq = 0;
+ 

[RFC][PATCH - 11/12] NTP cleanup: Introduce PPM adjustment variables

[john stultz]

All,
This patch introduces variables to keep track of the different NTP
adjustment values in PPM units. It also introduces the
ntp_get_adjustment() interface which returns shifted PPM units. The
patch also changes the ppc64 ppc_adjtimex() function to use
ntp_get_adjustment(). 

This will likely need careful review from the ppc64 folks. There are
some subtle differences between what ntp_get_adjustment() returns and
what ppc_adjtimex() calculates.

Any comments or feedback would be greatly appreciated.

thanks
-john

linux-2.6.13-rc3_timeofday-ntp-part11_B4.patch

diff --git a/arch/ppc64/kernel/time.c b/arch/ppc64/kernel/time.c
--- a/arch/ppc64/kernel/time.c
+++ b/arch/ppc64/kernel/time.c
@@ -106,8 +106,6 @@ extern struct timezone sys_tz;
 
 void ppc_adjtimex(void);
 
-static unsigned adjusting_time = 0;
-
 unsigned long ppc_proc_freq;
 unsigned long ppc_tb_freq;
 
@@ -355,8 +353,7 @@ int timer_interrupt(struct pt_regs * reg
timer_sync_xtime(lpaca->next_jiffy_update_tb);
timer_check_rtc();
write_sequnlock(_lock);
-   if ( adjusting_time && (ntp_adjtime_offset == 0) )
-   ppc_adjtimex();
+   ppc_adjtimex();
}
lpaca->next_jiffy_update_tb += tb_ticks_per_jiffy;
}
@@ -582,7 +579,7 @@ void __init time_init(void)
systemcfg->stamp_xsec = xtime.tv_sec * XSEC_PER_SEC;
systemcfg->tb_to_xs = tb_to_xs;
 
-   ntp_freq = 0;
+   ntp_clear();
 
xtime.tv_nsec = 0;
last_rtc_update = xtime.tv_sec;
@@ -599,7 +596,7 @@ void __init time_init(void)
  * to microseconds to keep do_gettimeofday synchronized 
  * with ntpd.
  *
- * Use the ntp_adjtime_offset, ntp_freq and ntp_offset computed by adjtimex to 
+ * Use the ntp_get_adjustment computed by adjtimex to 
  * adjust the frequency.
  */
 
@@ -609,62 +606,14 @@ void ppc_adjtimex(void)
 {
unsigned long den, new_tb_ticks_per_sec, tb_ticks, old_xsec, 
new_tb_to_xs, new_xsec, new_stamp_xsec;
unsigned long tb_ticks_per_sec_delta;
-   long delta_freq, ltemp;
+   long delta_freq;
struct div_result divres; 
unsigned long flags;
struct gettimeofday_vars * temp_varp;
unsigned temp_idx;
-   long singleshot_ppm = 0;
 
-   /* Compute parts per million frequency adjustment to accomplish the 
time adjustment
-  implied by ntp_offset to be applied over the elapsed time indicated 
by ntp_constant.
-  Use SHIFT_USEC to get it into the same units as ntp_freq. */
-   if ( ntp_offset < 0 ) {
-   ltemp = -ntp_offset;
-   ltemp <<= SHIFT_USEC - SHIFT_UPDATE;
-   ltemp >>= SHIFT_KG + ntp_constant;
-   ltemp = -ltemp;
-   }
-   else {
-   ltemp = ntp_offset;
-   ltemp <<= SHIFT_USEC - SHIFT_UPDATE;
-   ltemp >>= SHIFT_KG + ntp_constant;
-   }
-   
-   /* If there is a single shot time adjustment in progress */
-   if ( ntp_adjtime_offset ) {
-#ifdef DEBUG_PPC_ADJTIMEX
-   printk("ppc_adjtimex: ");
-   if ( adjusting_time == 0 )
-   printk("starting ");
-   printk("single shot ntp_adjtime_offset = %ld\n", 
ntp_adjtime_offset);
-#endif 
-   
-   adjusting_time = 1;
-   
-   /* Compute parts per million frequency adjustment to match 
ntp_adjtime_offset */
-   singleshot_ppm = tickadj * HZ;  
-   /*
-* The adjustment should be tickadj*HZ to match the code in
-* linux/kernel/timer.c, but experiments show that this is too
-* large. 3/4 of tickadj*HZ seems about right
-*/
-   singleshot_ppm -= singleshot_ppm / 4;
-   /* Use SHIFT_USEC to get it into the same units as ntp_freq */  
-   singleshot_ppm <<= SHIFT_USEC;
-   if ( ntp_adjtime_offset < 0 )
-   singleshot_ppm = -singleshot_ppm;
-   }
-   else {
-#ifdef DEBUG_PPC_ADJTIMEX
-   if ( adjusting_time )
-   printk("ppc_adjtimex: ending single shot 
ntp_adjtime_offset\n");
-#endif
-   adjusting_time = 0;
-   }
-   
/* Add up all of the frequency adjustments */
-   delta_freq = ntp_freq + ltemp + singleshot_ppm;
+   delta_freq = ntp_get_adjustment();

/* Compute a new value for tb_ticks_per_sec based on the frequency 
adjustment */
den = 100 * (1 << (SHIFT_USEC - 8));
@@ -678,7 +627,7 @@ void ppc_adjtimex(void)
}

 #ifdef DEBUG_PPC_ADJTIMEX
-   printk("ppc_adjtimex: ltemp = %ld, ntp_freq = %ld, singleshot_ppm = 
%ld\n", ltemp, ntp_freq, singleshot_ppm);
+   printk("ppc_adjtimex: delta_freq = %ld\n", delta_freq);
  

[RFC][PATCH - 8/12] NTP cleanup: Integrate second_overflow() logic

[john stultz]

All,
This patch removes the second_overflow() logic integrating it into the
ntp_advance() function. This provides a single interface to advance the
internal NTP state machine.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part8_B4.patch

diff --git a/include/linux/ntp.h b/include/linux/ntp.h
--- a/include/linux/ntp.h
+++ b/include/linux/ntp.h
@@ -10,9 +10,8 @@
 #include 
 
 /* NTP state machine interfaces */
-int ntp_advance(void);
+int ntp_advance(unsigned long interval_nsec);
 int ntp_adjtimex(struct timex*);
-void second_overflow(void);
 int ntp_leapsecond(struct timespec now);
 void ntp_clear(void);
 int ntp_synced(void);
diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -30,6 +30,11 @@
 *  http://www.eecis.udel.edu/~mills/database/rfc/rfc1589.txt
 *  http://www.eecis.udel.edu/~mills/database/reports/kern/kernb.pdf
 *
+* The tricky bits of code to handle the accurate clock support
+* were provided by Dave Mills ([EMAIL PROTECTED]) of NTP fame.
+* They were originally developed for SUN and DEC kernels.
+* All the kudos should go to Dave for this stuff.
+*
 * NOTE:To simplify the code, we do not implement any of
 * the PPS code, as the code that uses it never was merged.
 * [EMAIL PROTECTED]
@@ -68,10 +73,69 @@ static long time_next_adjust;
 /* Required to safely shift negative values */
 #define shiftR(x,s) (x < 0) ? (-((-x) >> (s))) : ((x) >> (s))
 
-int ntp_advance(void)
+int ntp_advance(unsigned long interval_nsec)
 {
+   static unsigned long interval_sum = 0;
long time_adjust_step, delta_nsec;
 
+
+   /* Some components of the NTP state machine are advanced
+* in full second increments (this is a hold-over from
+* the old second_overflow() code)
+*
+* XXX - I'd prefer to smoothly apply this math at each
+* call to ntp_advance() rather then each second.
+*/
+   interval_sum += interval_nsec;
+   while (interval_sum > NSEC_PER_SEC) {
+   long next_adj;
+   interval_sum -= NSEC_PER_SEC;
+
+   /* Bump the maxerror field */
+   time_maxerror += time_tolerance >> SHIFT_USEC;
+   if ( time_maxerror > NTP_PHASE_LIMIT ) {
+   time_maxerror = NTP_PHASE_LIMIT;
+   time_status |= STA_UNSYNC;
+   }
+
+   /*
+* Compute the phase adjustment for the next second. In
+* PLL mode, the offset is reduced by a fixed factor
+* times the time constant. In FLL mode the offset is
+* used directly. In either mode, the maximum phase
+* adjustment for each second is clamped so as to spread
+* the adjustment over not more than the number of
+* seconds between updates.
+*/
+   next_adj = time_offset;
+   if (!(time_status & STA_FLL))
+   next_adj = shiftR(next_adj, SHIFT_KG + time_constant);
+   next_adj = min(next_adj, (MAXPHASE / MINSEC) << SHIFT_UPDATE);
+   next_adj = max(next_adj, -(MAXPHASE / MINSEC) << SHIFT_UPDATE);
+   time_offset -= next_adj;
+
+   time_adj = next_adj << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+
+   time_adj += shiftR(time_freq, (SHIFT_USEC + SHIFT_HZ - 
SHIFT_SCALE));
+
+#if HZ == 100
+   /* Compensate for (HZ==100) != (1 << SHIFT_HZ).
+* Add 25% and 3.125% to get 128.125;
+* => only 0.125% error (p. 14)
+*/
+   time_adj += shiftR(time_adj,2) + shiftR(time_adj,5);
+#endif
+#if HZ == 1000
+   /* Compensate for (HZ==1000) != (1 << SHIFT_HZ).
+* Add 1.5625% and 0.78125% to get 1023.4375;
+* => only 0.05% error (p. 14)
+*/
+   time_adj += shiftR(time_adj,6) + shiftR(time_adj,7);
+#endif
+
+   }
+
+
if ( (time_adjust_step = time_adjust) != 0 ) {
/* We are doing an adjtime thing.
 *
@@ -116,71 +180,6 @@ int ntp_advance(void)
return delta_nsec;
 }
 
-
-/*
- * this routine handles the overflow of the microsecond field
- *
- * The tricky bits of code to handle the accurate clock support
- * were provided by Dave Mills ([EMAIL PROTECTED]) of NTP fame.
- * They were originally developed for SUN and DEC kernels.
- * All the kudos should go to Dave for this stuff.
- *
- */
-void second_overflow(void)
-{
-   long ltemp;
-
-   /* Bump the maxerror field */
-   time_maxerror += time_tolerance >> SHIFT_USEC;
-   if ( time_maxerror > NTP_PHASE_LIMIT ) {
-   time_maxerror = NTP_PHASE_LIMIT;
-   time_status |= STA_UNSYNC;
-   }
-
-   /*
-* Compute the phase adjustment for the next second. In
-* PLL mode, the offset 

[RFC][PATCH - 10/12] NTP cleanup: Use ntp_lock instead of xtime_lock

[john stultz]

All,
This patch introduces the ntp_lock which replaces the xtime_lock for
serialization in the NTP subsystem. This further isolates the NTP
subsystem from the time subsystem.

Any comments or feedback would be greatly appreciated.

thanks
-john

linux-2.6.13-rc3_timeofday-ntp-part10_B4.patch

diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -69,6 +69,8 @@ static int ntp_state= TIME_OK;  
 long ntp_adjtime_offset;
 static long ntp_next_adjtime_offset;
 
+/* lock for the above variables */
+static seqlock_t ntp_lock = SEQLOCK_UNLOCKED;
 
 #define SEC_PER_DAY 86400
 
@@ -79,7 +81,9 @@ int ntp_advance(unsigned long interval_n
 {
static unsigned long interval_sum = 0;
long time_adjust_step, delta_nsec;
+   unsigned long flags;
 
+   write_seqlock_irqsave(_lock, flags);
 
/* Some components of the NTP state machine are advanced
 * in full second increments (this is a hold-over from
@@ -178,6 +182,7 @@ int ntp_advance(unsigned long interval_n
ntp_adjtime_offset = ntp_next_adjtime_offset;
ntp_next_adjtime_offset = 0;
}
+   write_sequnlock_irqrestore(_lock, flags);
 
return delta_nsec;
 }
@@ -187,13 +192,13 @@ int ntp_advance(unsigned long interval_n
  * offset: current offset
  * tv: timeval holding the current time
  *
- * Private function, called only by ntp_adjtimex
+ * Private function, called only by ntp_adjtimex while holding ntp_lock
  *
  * This function is called when an offset adjustment is requested.
  * It calculates the offset adjustment and manipulates the
  * frequency adjustement accordingly.
  */
-static int ntp_hardupdate(long offset, struct timespec tv)
+static int ntp_hardupdate(long offset, struct timeval tv)
 {
int ret;
long current_offset, interval;
@@ -256,6 +261,7 @@ int ntp_adjtimex(struct timex *txc)
 {
long save_adjust;
int result;
+   unsigned long flags;
 
/* Now we validate the data before disabling interrupts */
 
@@ -298,7 +304,8 @@ int ntp_adjtimex(struct timex *txc)
||(txc->tick > 1100/USER_HZ)))
return -EINVAL;
 
-   write_seqlock_irq(_lock);
+   write_seqlock_irqsave(_lock, flags);
+
result = ntp_state;   /* mostly `TIME_OK' */
 
/* Save for later - semantics of adjtime is to return old value */
@@ -327,7 +334,7 @@ int ntp_adjtimex(struct timex *txc)
/* adjtime() is independent from ntp_adjtime() */
if ((ntp_next_adjtime_offset = txc->offset) == 0)
ntp_adjtime_offset = 0;
-   } else if (ntp_hardupdate(txc->offset, xtime))
+   } else if (ntp_hardupdate(txc->offset, txc->time))
result = TIME_ERROR;
}
 
@@ -364,8 +371,8 @@ int ntp_adjtimex(struct timex *txc)
txc->errcnt = 0;
txc->stbcnt = 0;
 
-   write_sequnlock_irq(_lock);
-   do_gettimeofday(>time);
+   write_sequnlock_irqrestore(_lock, flags);
+
return result;
 }
 
@@ -387,6 +394,8 @@ int ntp_leapsecond(struct timespec now)
 * set ahead one second.
 */
static time_t leaptime = 0;
+   unsigned long flags;
+   write_seqlock_irqsave(_lock, flags);
 
switch (ntp_state) {
case TIME_OK:
@@ -429,6 +438,7 @@ int ntp_leapsecond(struct timespec now)
ntp_state = TIME_OK;
}
 
+   write_sequnlock_irqrestore(_lock, flags);
return 0;
 }
 
@@ -436,14 +446,18 @@ int ntp_leapsecond(struct timespec now)
 /**
  * ntp_clear - Clears the NTP state machine.
  *
- * Must be called while holding a write on the xtime_lock
  */
 void ntp_clear(void)
 {
+   unsigned long flags;
+   write_seqlock_irqsave(_lock, flags);
+
ntp_next_adjtime_offset = 0;/* stop active adjtime() */
ntp_status |= STA_UNSYNC;
ntp_maxerror = NTP_PHASE_LIMIT;
ntp_esterror = NTP_PHASE_LIMIT;
+
+   write_sequnlock_irqrestore(_lock, flags);
 }
 
 /**
diff --git a/kernel/time.c b/kernel/time.c
--- a/kernel/time.c
+++ b/kernel/time.c
@@ -222,6 +222,11 @@ int do_adjtimex(struct timex *txc)
if (txc->modes && !capable(CAP_SYS_TIME))
return -EPERM;

+   /* Note: We set tx->time first,
+* because ntp_adjtimex uses it
+*/
+   do_gettimeofday(>time);
+
result = ntp_adjtimex(txc);

notify_arch_cmos_timer();


-
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://www.tux.org/lkml/

[RFC][PATCH - 7/12] NTP cleanup: Cleanup signed shifting logic

[john stultz]

All,
Signed shifting must be done carefully, and the ntp code has quite a
number of conditionals to do the signed shifting. This patch makes use
of the local shiftR() macro introduced in a previous patch to simplify a
bit of logic.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part7_B4.patch

diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -165,28 +165,19 @@ void second_overflow(void)
}
 
ltemp = time_freq;
-   if (ltemp < 0)
-   time_adj -= -ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
-   else
-   time_adj += ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
+   time_adj += shiftR(ltemp, (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE));
 
 #if HZ == 100
 /* Compensate for (HZ==100) != (1 << SHIFT_HZ).
  * Add 25% and 3.125% to get 128.125; => only 0.125% error (p. 14)
  */
-   if (time_adj < 0)
-   time_adj -= (-time_adj >> 2) + (-time_adj >> 5);
-   else
-   time_adj += (time_adj >> 2) + (time_adj >> 5);
+   time_adj += shiftR(time_adj,2) + shiftR(time_adj,5);
 #endif
 #if HZ == 1000
 /* Compensate for (HZ==1000) != (1 << SHIFT_HZ).
  * Add 1.5625% and 0.78125% to get 1023.4375; => only 0.05% error (p. 14)
  */
-   if (time_adj < 0)
-   time_adj -= (-time_adj >> 6) + (-time_adj >> 7);
-   else
-   time_adj += (time_adj >> 6) + (time_adj >> 7);
+   time_adj += shiftR(time_adj,6) + shiftR(time_adj,7);
 #endif
 }
 
@@ -352,10 +343,7 @@ int ntp_adjtimex(struct timex *txc)
if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
txc->offset = save_adjust;
else {
-   if (time_offset < 0)
-   txc->offset = -(-time_offset >> SHIFT_UPDATE);
-   else
-   txc->offset = time_offset >> SHIFT_UPDATE;
+   txc->offset = shiftR(time_offset, SHIFT_UPDATE);
}
txc->freq = time_freq;
txc->maxerror = time_maxerror;


-
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://www.tux.org/lkml/

[RFC][PATCH - 6/12] NTP cleanup: Clean up ntp_adjtimex() arguement checking

[john stultz]

All,
Currently ntp_adjtimex() checks the validity of a few arguments values
then takes the xtime_lock then checks the validity of more arguments
while it parses them. This separates the logic so we check the validity
of all arguments before aquiring the xtime lock. This greatly improves
the readability of the code.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part6_B4.patch

diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -267,21 +267,44 @@ int ntp_adjtimex(struct timex *txc)
 
/* Now we validate the data before disabling interrupts */
 
-   if ((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
-   /* singleshot must not be used with any other mode bits */
-   if (txc->modes != ADJ_OFFSET_SINGLESHOT)
-   return -EINVAL;
-
-   if (txc->modes != ADJ_OFFSET_SINGLESHOT && (txc->modes & ADJ_OFFSET))
-   /* adjustment Offset limited to +- .512 seconds */
-   if (txc->offset <= - MAXPHASE || txc->offset >= MAXPHASE )
-   return -EINVAL;
-
-   /* if the quartz is off by more than 10% something is VERY wrong ! */
-   if (txc->modes & ADJ_TICK)
-   if (txc->tick <  90/USER_HZ ||
-   txc->tick > 110/USER_HZ)
-   return -EINVAL;
+   /* frequency adjustment limited to +/- MAXFREQ */
+   if ((txc->modes & ADJ_FREQUENCY)
+   && (abs(txc->freq) > MAXFREQ))
+   return -EINVAL;
+
+   /* maxerror adjustment limited to NTP_PHASE_LIMIT */
+   if ((txc->modes & ADJ_MAXERROR)
+   && (txc->maxerror < 0
+   || txc->maxerror >= NTP_PHASE_LIMIT))
+   return -EINVAL;
+
+   /* esterror adjustment limited to NTP_PHASE_LIMIT */
+   if ((txc->modes & ADJ_ESTERROR)
+   && (txc->esterror < 0
+   || txc->esterror >= NTP_PHASE_LIMIT))
+   return -EINVAL;
+
+   /* constant adjustment must be positive */
+   if ((txc->modes & ADJ_TIMECONST)
+   && (txc->constant < 0)) /* NTP v4 uses values > 6 */
+   return -EINVAL;
+
+   /* Single shot mode can only be used by itself */
+   if (((txc->modes & ADJ_OFFSET_SINGLESHOT) == ADJ_OFFSET_SINGLESHOT)
+   && (txc->modes != ADJ_OFFSET_SINGLESHOT))
+   return -EINVAL;
+
+   /* offset adjustment limited to +/- MAXPHASE */
+   if ((txc->modes != ADJ_OFFSET_SINGLESHOT)
+   && (txc->modes & ADJ_OFFSET)
+   && (abs(txc->offset)>= MAXPHASE))
+   return -EINVAL;
+
+   /* tick adjustment limited to 10% */
+   if ((txc->modes & ADJ_TICK)
+   && ((txc->tick < 90/USER_HZ)
+   ||(txc->tick > 1100/USER_HZ)))
+   return -EINVAL;
 
write_seqlock_irq(_lock);
result = time_state;   /* mostly `TIME_OK' */
@@ -290,65 +313,42 @@ int ntp_adjtimex(struct timex *txc)
save_adjust = time_next_adjust ? time_next_adjust : time_adjust;
 
/* If there are input parameters, then process them */
-   if (txc->modes) {
-   if (txc->modes & ADJ_STATUS)/* only set allowed bits */
-   time_status =  (txc->status & ~STA_RONLY) |
-   (time_status & STA_RONLY);
-
-   if (txc->modes & ADJ_FREQUENCY) {   /* p. 22 */
-   if (txc->freq > MAXFREQ || txc->freq < -MAXFREQ) {
-   result = -EINVAL;
-   goto leave;
-   }
-   time_freq = txc->freq;
-   }
-
-   if (txc->modes & ADJ_MAXERROR) {
-   if (txc->maxerror < 0
-   || txc->maxerror >= NTP_PHASE_LIMIT) {
-   result = -EINVAL;
-   goto leave;
-   }
-   time_maxerror = txc->maxerror;
-   }
-
-   if (txc->modes & ADJ_ESTERROR) {
-   if (txc->esterror < 0
-   || txc->esterror >= NTP_PHASE_LIMIT) {
-   result = -EINVAL;
-   goto leave;
-   }
-   time_esterror = txc->esterror;
-   }
 
-   if (txc->modes & ADJ_TIMECONST) {   /* p. 24 */
-   if (txc->constant < 0) { /* NTP v4 uses values > 6 */
-   result = -EINVAL;
-   goto leave;
-   }
-   time_constant = 

[RFC][PATCH - 3/12] NTP cleanup: Remove unused NTP PPS code

[john stultz]

All,
Since the NTP PPS code required an out of tree patch which I don't
believe there is a 2.6 version of, this patch removes the unused PPS
logic in the kernel.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part3_B4.patch

diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -46,26 +46,9 @@ void time_interpolator_update(long delta
 #define time_interpolator_update(x)
 #endif
 
-
-static long pps_offset;/* pps time offset (us) */
-static long pps_jitter = MAXTIME;  /* time dispersion (jitter) (us) */
-
-static long pps_freq;  /* frequency offset (scaled ppm) */
-static long pps_stabil = MAXFREQ;  /* frequency dispersion (scaled ppm) */
-
-static long pps_valid = PPS_VALID; /* pps signal watchdog counter */
-
-static int pps_shift = PPS_SHIFT;  /* interval duration (s) (shift) */
-
-static long pps_jitcnt;/* jitter limit exceeded */
-static long pps_calcnt;/* calibration intervals */
-static long pps_errcnt;/* calibration errors */
-static long pps_stbcnt;/* stability limit exceeded */
-
 /* Don't completely fail for HZ > 500.  */
 int tickadj = 500/HZ ? : 1;/* microsecs */
 
-
 /*
  * phase-lock loop variables
  */
@@ -235,21 +218,7 @@ void second_overflow(void)
time_adj = ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
}
 
-   /*
-* Compute the frequency estimate and additional phase
-* adjustment due to frequency error for the next
-* second. When the PPS signal is engaged, gnaw on the
-* watchdog counter and update the frequency computed by
-* the pll and the PPS signal.
-*/
-   pps_valid++;
-   if (pps_valid == PPS_VALID) {   /* PPS signal lost */
-   pps_jitter = MAXTIME;
-   pps_stabil = MAXFREQ;
-   time_status &= ~(STA_PPSSIGNAL | STA_PPSJITTER |
-   STA_PPSWANDER | STA_PPSERROR);
-   }
-   ltemp = time_freq + pps_freq;
+   ltemp = time_freq;
if (ltemp < 0)
time_adj -= -ltemp >> (SHIFT_USEC + SHIFT_HZ - SHIFT_SCALE);
else
@@ -307,10 +276,6 @@ int ntp_adjtimex(struct timex *txc)
/* Save for later - semantics of adjtime is to return old value */
save_adjust = time_next_adjust ? time_next_adjust : time_adjust;
 
-#if 0  /* STA_CLOCKERR is never set yet */
-   time_status &= ~STA_CLOCKERR;   /* reset STA_CLOCKERR */
-#endif
-
/* If there are input parameters, then process them */
if (txc->modes) {
if (txc->modes & ADJ_STATUS)/* only set allowed bits */
@@ -322,7 +287,7 @@ int ntp_adjtimex(struct timex *txc)
result = -EINVAL;
goto leave;
}
-   time_freq = txc->freq - pps_freq;
+   time_freq = txc->freq;
}
 
if (txc->modes & ADJ_MAXERROR) {
@@ -356,11 +321,8 @@ int ntp_adjtimex(struct timex *txc)
/* adjtime() is independent from ntp_adjtime() 
*/
if ((time_next_adjust = txc->offset) == 0)
time_adjust = 0;
-   } else if ( time_status & (STA_PLL | STA_PPSTIME) ) {
-   ltemp = (time_status
-   & (STA_PPSTIME | STA_PPSSIGNAL))
-   == (STA_PPSTIME | STA_PPSSIGNAL) ?
-   pps_offset : txc->offset;
+   } else if (time_status & STA_PLL) {
+   ltemp = txc->offset;
 
/*
 * Scale the phase adjustment and
@@ -415,7 +377,7 @@ int ntp_adjtimex(struct timex *txc)
time_freq = time_tolerance;
else if (time_freq < -time_tolerance)
time_freq = -time_tolerance;
-   } /* STA_PLL || STA_PPSTIME */
+   } /* STA_PLL */
} /* txc->modes & ADJ_OFFSET */
 
if (txc->modes & ADJ_TICK) {
@@ -425,17 +387,8 @@ int ntp_adjtimex(struct timex *txc)
} /* txc->modes */
 leave:
 
-   if ((time_status & (STA_UNSYNC|STA_CLOCKERR)) != 0
-   || ((time_status & (STA_PPSFREQ|STA_PPSTIME)) != 0
-   && (time_status & STA_PPSSIGNAL) == 0)
-   /* p. 24, (b) */
-   || ((time_status & (STA_PPSTIME|STA_PPSJITTER))
-   == (STA_PPSTIME|STA_PPSJITTER))
-   /* p. 24, (c) */
-   || ((time_status & STA_PPSFREQ) != 0
-   && (time_status & (STA_PPSWANDER|STA_PPSERROR)) != 0))
-   /* 

[RFC][PATCH - 4/12] NTP cleanup: Breakup ntp_adjtimex()

[john stultz]

All,
This patch breaks up the complex nesting of code in ntp_adjtimex() by
creating a ntp_hardupdate() function and simplifying some of the logic.
This also follows the documented NTP spec somewhat better.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part4_B4.patch

diff --git a/kernel/ntp.c b/kernel/ntp.c
--- a/kernel/ntp.c
+++ b/kernel/ntp.c
@@ -69,6 +69,9 @@ static long time_reftime;   
 long time_adjust;
 static long time_next_adjust;
 
+/* Required to safely shift negative values */
+#define shiftR(x,s) (x < 0) ? (-((-x) >> (s))) : ((x) >> (s))
+
 int ntp_advance(void)
 {
long time_adjust_step, delta_nsec;
@@ -244,12 +247,79 @@ void second_overflow(void)
 #endif
 }
 
+/**
+ * ntp_hardupdate - Calculates the offset and freq values
+ * offset: current offset
+ * tv: timeval holding the current time
+ *
+ * Private function, called only by ntp_adjtimex
+ *
+ * This function is called when an offset adjustment is requested.
+ * It calculates the offset adjustment and manipulates the
+ * frequency adjustement accordingly.
+ */
+static int ntp_hardupdate(long offset, struct timespec tv)
+{
+   int ret;
+   long current_offset, interval;
+
+   ret = 0;
+   if (!(time_status & STA_PLL))
+   return ret;
+
+   current_offset = offset;
+   /* Make sure offset is bounded by MAXPHASE */
+   current_offset = min(current_offset, MAXPHASE);
+   current_offset = max(current_offset, -MAXPHASE);
+   time_offset = current_offset << SHIFT_UPDATE;
+
+   if (time_status & STA_FREQHOLD || time_reftime == 0)
+   time_reftime = tv.tv_sec;
+
+   /* calculate seconds since last call to hardupdate */
+   interval = tv.tv_sec - time_reftime;
+   time_reftime = tv.tv_sec;
+
+   /*
+* Select whether the frequency is to be controlled
+* and in which mode (PLL or FLL). Clamp to the operating
+* range. Ugly multiply/divide should be replaced someday.
+*/
+   if ((time_status & STA_FLL) && (interval >= MINSEC)) {
+   long offset_ppm;
+
+   offset_ppm = time_offset / interval;
+   offset_ppm <<= (SHIFT_USEC - SHIFT_UPDATE);
+
+   time_freq += shiftR(offset_ppm, SHIFT_KH);
+
+   } else if ((time_status & STA_PLL) && (interval < MAXSEC)) {
+   long damping, offset_ppm;
+
+   offset_ppm = offset * interval;
+
+   damping = (2 * time_constant) + SHIFT_KF - SHIFT_USEC;
+
+   time_freq += shiftR(offset_ppm, damping);
+
+   } else { /* calibration interval out of bounds (p. 12) */
+   ret = TIME_ERROR;
+   }
+
+   /* bound time_freq */
+   time_freq = min(time_freq, time_tolerance);
+   time_freq = max(time_freq, -time_tolerance);
+
+   return ret;
+}
+
+
 /* adjtimex mainly allows reading (and writing, if superuser) of
  * kernel time-keeping variables. used by xntpd.
  */
 int ntp_adjtimex(struct timex *txc)
 {
-   long ltemp, mtemp, save_adjust;
+   long save_adjust;
int result;
 
/* Now we validate the data before disabling interrupts */
@@ -321,63 +391,9 @@ int ntp_adjtimex(struct timex *txc)
/* adjtime() is independent from ntp_adjtime() 
*/
if ((time_next_adjust = txc->offset) == 0)
time_adjust = 0;
-   } else if (time_status & STA_PLL) {
-   ltemp = txc->offset;
-
-   /*
-* Scale the phase adjustment and
-* clamp to the operating range.
-*/
-   if (ltemp > MAXPHASE)
-   time_offset = MAXPHASE << SHIFT_UPDATE;
-   else if (ltemp < -MAXPHASE)
-   time_offset = -(MAXPHASE
-   << SHIFT_UPDATE);
-   else
-   time_offset = ltemp << SHIFT_UPDATE;
-
-   /*
-* Select whether the frequency is to be 
controlled
-* and in which mode (PLL or FLL). Clamp to the 
operating
-* range. Ugly multiply/divide should be 
replaced someday.
-*/
-
-   if (time_status & STA_FREQHOLD || time_reftime 
== 0)
-   time_reftime = xtime.tv_sec;
-
-   mtemp = xtime.tv_sec - time_reftime;
-   time_reftime = xtime.tv_sec;
-
-   if (time_status & STA_FLL) {
-

[RFC][PATCH - 2/12] NTP cleanup: Move arches to new ntp interfaces

[john stultz]

All,
This patch converts all of arch specific code to use the new ntp_synced
() and ntp_clear() interfaces. This patch is required for the patch 1 of
the series to build. 

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part2_B4.patch

diff --git a/arch/alpha/kernel/time.c b/arch/alpha/kernel/time.c
--- a/arch/alpha/kernel/time.c
+++ b/arch/alpha/kernel/time.c
@@ -42,6 +42,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -149,7 +150,7 @@ irqreturn_t timer_interrupt(int irq, voi
 * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
 * called as close as possible to 500 ms before the new second starts.
 */
-   if ((time_status & STA_UNSYNC) == 0
+   if (ntp_synced()
&& xtime.tv_sec > state.last_rtc_update + 660
&& xtime.tv_nsec >= 50 - ((unsigned) TICK_SIZE) / 2
&& xtime.tv_nsec <= 50 + ((unsigned) TICK_SIZE) / 2) {
@@ -502,10 +503,7 @@ do_settimeofday(struct timespec *tv)
set_normalized_timespec(, sec, nsec);
set_normalized_timespec(_to_monotonic, wtm_sec, wtm_nsec);
 
-   time_adjust = 0;/* stop active adjtime() */
-   time_status |= STA_UNSYNC;
-   time_maxerror = NTP_PHASE_LIMIT;
-   time_esterror = NTP_PHASE_LIMIT;
+   ntp_clear();
 
write_sequnlock_irq(_lock);
clock_was_set();
diff --git a/arch/arm/kernel/time.c b/arch/arm/kernel/time.c
--- a/arch/arm/kernel/time.c
+++ b/arch/arm/kernel/time.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -102,7 +103,7 @@ static unsigned long next_rtc_update;
  */
 static inline void do_set_rtc(void)
 {
-   if (time_status & STA_UNSYNC || set_rtc == NULL)
+   if (!ntp_synced() || set_rtc == NULL)
return;
 
if (next_rtc_update &&
@@ -292,10 +293,7 @@ int do_settimeofday(struct timespec *tv)
set_normalized_timespec(, sec, nsec);
set_normalized_timespec(_to_monotonic, wtm_sec, wtm_nsec);
 
-   time_adjust = 0;/* stop active adjtime() */
-   time_status |= STA_UNSYNC;
-   time_maxerror = NTP_PHASE_LIMIT;
-   time_esterror = NTP_PHASE_LIMIT;
+   ntp_clear();
write_sequnlock_irq(_lock);
clock_was_set();
return 0;
diff --git a/arch/arm26/kernel/time.c b/arch/arm26/kernel/time.c
--- a/arch/arm26/kernel/time.c
+++ b/arch/arm26/kernel/time.c
@@ -28,6 +28,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -114,7 +115,7 @@ static unsigned long next_rtc_update;
  */
 static inline void do_set_rtc(void)
 {
-   if (time_status & STA_UNSYNC || set_rtc == NULL)
+   if (!ntp_synced() || set_rtc == NULL)
return;
 
 //FIXME - timespec.tv_sec is a time_t not unsigned long
@@ -189,10 +190,7 @@ int do_settimeofday(struct timespec *tv)
 
xtime.tv_sec = tv->tv_sec;
xtime.tv_nsec = tv->tv_nsec;
-   time_adjust = 0;/* stop active adjtime() */
-   time_status |= STA_UNSYNC;
-   time_maxerror = NTP_PHASE_LIMIT;
-   time_esterror = NTP_PHASE_LIMIT;
+   ntp_clear();
write_sequnlock_irq(_lock);
clock_was_set();
return 0;
diff --git a/arch/cris/arch-v10/kernel/time.c b/arch/cris/arch-v10/kernel/time.c
--- a/arch/cris/arch-v10/kernel/time.c
+++ b/arch/cris/arch-v10/kernel/time.c
@@ -240,7 +240,7 @@ timer_interrupt(int irq, void *dev_id, s
 * The division here is not time critical since it will run once in 
 * 11 minutes
 */
-   if ((time_status & STA_UNSYNC) == 0 &&
+   if (ntp_synced() &&
xtime.tv_sec > last_rtc_update + 660 &&
(xtime.tv_nsec / 1000) >= 50 - (tick_nsec / 1000) / 2 &&
(xtime.tv_nsec / 1000) <= 50 + (tick_nsec / 1000) / 2) {
diff --git a/arch/cris/kernel/time.c b/arch/cris/kernel/time.c
--- a/arch/cris/kernel/time.c
+++ b/arch/cris/kernel/time.c
@@ -30,6 +30,7 @@
 #include 
 #include 
 #include 
+#include 
 
 u64 jiffies_64 = INITIAL_JIFFIES;
 
@@ -113,10 +114,7 @@ int do_settimeofday(struct timespec *tv)
set_normalized_timespec(, sec, nsec);
set_normalized_timespec(_to_monotonic, wtm_sec, wtm_nsec);
 
-   time_adjust = 0;/* stop active adjtime() */
-   time_status |= STA_UNSYNC;
-   time_maxerror = NTP_PHASE_LIMIT;
-   time_esterror = NTP_PHASE_LIMIT;
+   ntp_clear();
write_sequnlock_irq(_lock);
clock_was_set();
return 0;
diff --git a/arch/frv/kernel/time.c b/arch/frv/kernel/time.c
--- a/arch/frv/kernel/time.c
+++ b/arch/frv/kernel/time.c
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -85,7 +86,7 @@ static irqreturn_t timer_interrupt(int i
 * CMOS clock accordingly every ~11 minutes. Set_rtc_mmss() has to be
 * called 

[RFC][PATCH - 1/12] NTP cleanup: Move NTP code into ntp.c

[john stultz]

All,
This patch moves the generic NTP code from time.c and timer.c into
ntp.c. It makes most of the NTP variables static providing more
understandable interfaces like ntp_synced() and ntp_clear(). 

Since some of the newly made static variables are used in arch generic
code, this patch alone will not compile. Thus this patch requires part 2
of the series which fixes the arch specific uses of the newly static
variables.

Any comments or feedback would be greatly appreciated.

thanks
-john


linux-2.6.13-rc3_timeofday-ntp-part1_B4.patch

diff --git a/include/linux/ntp.h b/include/linux/ntp.h
new file mode 100644
--- /dev/null
+++ b/include/linux/ntp.h
@@ -0,0 +1,28 @@
+/*  linux/include/linux/ntp.h
+ *
+ *  This file NTP state machine accessor functions.
+ */
+
+#ifndef _LINUX_NTP_H
+#define _LINUX_NTP_H
+#include 
+#include 
+#include 
+
+/* NTP state machine interfaces */
+int ntp_advance(void);
+int ntp_adjtimex(struct timex*);
+void second_overflow(void);
+void ntp_clear(void);
+int ntp_synced(void);
+
+/* Due to ppc64 having its own NTP  code,
+ * these variables cannot be made static just yet
+ */
+extern int tickadj;
+extern long time_offset;
+extern long time_freq;
+extern long time_adjust;
+extern long time_constant;
+
+#endif
diff --git a/include/linux/timex.h b/include/linux/timex.h
--- a/include/linux/timex.h
+++ b/include/linux/timex.h
@@ -226,39 +226,6 @@ struct timex {
  */
 extern unsigned long tick_usec;/* USER_HZ period (usec) */
 extern unsigned long tick_nsec;/* ACTHZ  period (nsec) 
*/
-extern int tickadj;/* amount of adjustment per tick */
-
-/*
- * phase-lock loop variables
- */
-extern int time_state; /* clock status */
-extern int time_status;/* clock synchronization status bits */
-extern long time_offset;   /* time adjustment (us) */
-extern long time_constant; /* pll time constant */
-extern long time_tolerance;/* frequency tolerance (ppm) */
-extern long time_precision;/* clock precision (us) */
-extern long time_maxerror; /* maximum error */
-extern long time_esterror; /* estimated error */
-
-extern long time_freq; /* frequency offset (scaled ppm) */
-extern long time_reftime;  /* time at last adjustment (s) */
-
-extern long time_adjust;   /* The amount of adjtime left */
-extern long time_next_adjust;  /* Value for time_adjust at next tick */
-
-/* interface variables pps->timer interrupt */
-extern long pps_offset;/* pps time offset (us) */
-extern long pps_jitter;/* time dispersion (jitter) (us) */
-extern long pps_freq;  /* frequency offset (scaled ppm) */
-extern long pps_stabil;/* frequency dispersion (scaled ppm) */
-extern long pps_valid; /* pps signal watchdog counter */
-
-/* interface variables pps->adjtimex */
-extern int pps_shift;  /* interval duration (s) (shift) */
-extern long pps_jitcnt;/* jitter limit exceeded */
-extern long pps_calcnt;/* calibration intervals */
-extern long pps_errcnt;/* calibration errors */
-extern long pps_stbcnt;/* stability limit exceeded */
 
 #ifdef CONFIG_TIME_INTERPOLATION
 
diff --git a/kernel/Makefile b/kernel/Makefile
--- a/kernel/Makefile
+++ b/kernel/Makefile
@@ -7,7 +7,7 @@ obj-y = sched.o fork.o exec_domain.o
sysctl.o capability.o ptrace.o timer.o user.o \
signal.o sys.o kmod.o workqueue.o pid.o \
rcupdate.o intermodule.o extable.o params.o posix-timers.o \
-   kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o
+   kthread.o wait.o kfifo.o sys_ni.o posix-cpu-timers.o ntp.o
 
 obj-$(CONFIG_FUTEX) += futex.o
 obj-$(CONFIG_GENERIC_ISA_DMA) += dma.o
diff --git a/kernel/ntp.c b/kernel/ntp.c
new file mode 100644
--- /dev/null
+++ b/kernel/ntp.c
@@ -0,0 +1,490 @@
+/
+* linux/kernel/ntp.c
+*
+* NTP state machine and time scaling code.
+*
+* Code moved from kernel/time.c and kernel/timer.c
+* Please see those files for original copyrights.
+*
+* This program is free software; you can redistribute it and/or modify
+* it under the terms of the GNU General Public License as published by
+* the Free Software Foundation; either version 2 of the License, or
+* (at your option) any later version.
+*
+* This program is distributed in the hope that it will be useful,
+* but WITHOUT ANY WARRANTY; without even the implied warranty of
+* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+* GNU General Public License for more details.
+*
+* You should have received a copy of the GNU General Public License
+* along with this program; if not, write to the Free Software
+* Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+*
+* Notes:
+*
+* Hopefully you should never have to understand or 

[RFC - 0/12] NTP cleanup work (v. B4)

[john stultz]

All,
In my attempts to rework the timeofday subsystem, it was suggested I
try to avoid mixing cleanups with functional changes. In response to the
suggestion I've tried to break out the majority of the NTP cleanups I've
been working out of my larger patch and try to feed it in piece meal. 

The goal of this patch set is to isolate the in kernel NTP state machine
in the hope of simplifying the current timeofday code.

Patches 1-10 should be fairly straight forward only moving and cleaning
up various bits of code.

Patches 11 and 12 are somewhat more functional changes and should be
reviewed more carefully. Especially by someone who knows the PPC64
ppc_adjtimex() function in depth.

I haven't been able to test this code, only checking that the code
builds on a number of arches, but since I may not have access to my
cogito repositories while I'm at OLS, I thought it might be worth while
to send this out for discussion.

Shortly after I send out these patches I hope to send out the rest of my
timeofday changes with apply on top of this patch set.

thanks
-john


-
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://www.tux.org/lkml/

Re: [11/11] x86_64: TASK_SIZE fixes for compatibility mode processes

[Siddha, Suresh B]

On Fri, Jul 15, 2005 at 10:53:33AM -0500, Justin M. Forbes wrote:
> That said, I will be testing this patch a bit further

Thanks. Let me know if you see any issues.

> myself, and because it does address a real memory leak issue, we should
> consider it or another fix for stable 2.6.12.4.

Appended patch will just fix the memory leak issue. Atleast, we should
apply this.

thanks,
suresh
--

malicious 32bit app can have an elf section at 0xe000.  During
exec of this app, we will have a memory leak as insert_vm_struct() is
not checking for return value in syscall32_setup_pages() and thus not
freeing the vma allocated for the vsyscall page.

Check the return value and free the vma incase of failure.

Signed-off-by: Suresh Siddha <[EMAIL PROTECTED]>


--- linux-2.6.12.2/arch/x86_64/ia32/syscall32.c.orig2005-06-29 
16:00:53.0 -0700
+++ linux-2.6.12.2/arch/x86_64/ia32/syscall32.c 2005-07-15 18:09:06.684409144 
-0700
@@ -57,6 +57,7 @@
int npages = (VSYSCALL32_END - VSYSCALL32_BASE) >> PAGE_SHIFT;
struct vm_area_struct *vma;
struct mm_struct *mm = current->mm;
+   int ret;
 
vma = kmem_cache_alloc(vm_area_cachep, SLAB_KERNEL);
if (!vma)
@@ -78,7 +79,11 @@
vma->vm_mm = mm;
 
down_write(>mmap_sem);
-   insert_vm_struct(mm, vma);
+   if ((ret = insert_vm_struct(mm, vma))) {
+   up_write(>mmap_sem);
+   kmem_cache_free(vm_area_cachep, vma);
+   return ret;
+   }
mm->total_vm += npages;
up_write(>mmap_sem);
return 0;

-
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://www.tux.org/lkml/

Re: Real-Time Preemption, -RT-2.6.12-final-V0.7.50-24

[Daniel Walker]

On Tue, 2005-07-12 at 07:56 -0700, Daniel Walker wrote:
> On Tue, 2005-07-12 at 16:46 +0200, Ingo Molnar wrote:
> > * Daniel Walker <[EMAIL PROTECTED]> wrote:
> > 
> > > I haven't tested it recently . This was on an older version of RT 
> > > though . I could try it if it's interesting ? Or do you think it's 
> > > already fixed?
> > 
> > it would be definitely interesting to see how robust the latest IO-APIC 
> > code is.
> 
> I'm sure you test that all the time, but I'll try it ..

I tried it, and it appears to be fixed in current RT ..

Daniel

-
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://www.tux.org/lkml/

Re: [PATCH] mb_cache_shrink() frees unexpected caches

[Andreas Gruenbacher]

On Friday 15 July 2005 17:07, Akinobu Mita wrote:
> 2005-07-15 (Fri) 16:36 +0200  Andreas Gruenbacher wrote:
> > The cache parameter could indeed be removed. Not that it would matter
> > much...
>
> Currently, mbcache is used only for xattr on ext2/ext3 and reiserfs.
> In other words, only one type of mbcache is used per-filesystem.
> So any problems don't happen without the patch I sent.

Actually, reiserfs doesn't use the mbcache, so this can go:

Index: linux-2.6.12/fs/reiserfs/xattr.c
===
--- linux-2.6.12.orig/fs/reiserfs/xattr.c
+++ linux-2.6.12/fs/reiserfs/xattr.c
@@ -41,3 +41,2 @@
 #include 
-#include 
 #include 

> But, for example when someone use mbcache as another purpose on ext3,
> The crash will be caused by using mb_cache_shrink().
>
> Therefore, I think your patch should not be committed until
> mbcache will be limited to use only type per-filesystem.

Removing the cache parameter from mb_cache_shrink would break when more than 
one mb_cache is used per filesystem, correct. Leaving the parameter in and 
adding your patch is more "future proof", so I'm fine with it. Are you 
actually using more than one mb_cache, or is this theoretical?

As you say in your follow-up mail, without your patch the cache would become 
less effective, it won't crash anything, though.

Thanks,
-- 
Andreas Gruenbacher <[EMAIL PROTECTED]>
SUSE Labs, SUSE LINUX PRODUCTS GMBH
-
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://www.tux.org/lkml/

Re: 2.6.13-rc3-mm1

[Yoichi Yuasa]

Hi,

On Fri, 15 Jul 2005 16:23:49 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:

> Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
> >
> > Hi Andrew
> > 
> > I got the following error.
> > 
> > make ARCH=mips oldconfig
> > scripts/kconfig/conf -o arch/mips/Kconfig
> > drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to 
> > 'tristate'
> > 
> > file drivers/char/speakup/Kconfig already scanned?
> > make[1]: *** [oldconfig] Error 1
> > make: *** [oldconfig] Error 2
> > 
> 
> Well arch/mips/Kconfig is defining CONFIG_FB as bool and
> drivers/video/Kconfig was changed a while ago to define it as tristate.  I
> assume this failure also happens in linus's current tree.  
> 
> It seems odd that mips is privately duplicating the generic code's
> definition.  Maybe that needs to be taken out of there.

Yes, It can be removed.

> I'll cc the fbdev guys - could someone please come up with fix?  It's a
> showstopper for the MIPS architecture.

Yoichi

Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>

diff -urN -X dontdiff mm1-orig/arch/mips/Kconfig mm1/arch/mips/Kconfig
--- mm1-orig/arch/mips/Kconfig  2005-07-15 21:44:53.0 +0900
+++ mm1/arch/mips/Kconfig   2005-07-16 10:01:29.0 +0900
@@ -1090,41 +1090,6 @@
depends on MACH_JAZZ || SNI_RM200_PCI || SGI_IP22 || SGI_IP32
default y
 
-config FB
-   bool
-   depends on MIPS_MAGNUM_4000 || OLIVETTI_M700
-   default y
-   ---help---
- The frame buffer device provides an abstraction for the graphics
- hardware. It represents the frame buffer of some video hardware and
- allows application software to access the graphics hardware through
- a well-defined interface, so the software doesn't need to know
- anything about the low-level (hardware register) stuff.
-
- Frame buffer devices work identically across the different
- architectures supported by Linux and make the implementation of
- application programs easier and more portable; at this point, an X
- server exists which uses the frame buffer device exclusively.
- On several non-X86 architectures, the frame buffer device is the
- only way to use the graphics hardware.
-
- The device is accessed through special device nodes, usually located
- in the /dev directory, i.e. /dev/fb*.
-
- You need an utility program called fbset to make full use of frame
- buffer devices. Please read 
- and the Framebuffer-HOWTO at 
- for more information.
-
- Say Y here and to the driver for your graphics board below if you
- are compiling a kernel for a non-x86 architecture.
-
- If you are compiling for the x86 architecture, you can say Y if you
- want to play with it, but it is not essential. Please note that
- running graphical applications that directly touch the hardware
- (e.g. an accelerated X server) and that are not frame buffer
- device-aware may cause unexpected results. If unsure, say N.
-
 config HAVE_STD_PC_SERIAL_PORT
bool
 
diff -urN -X dontdiff mm1-orig/drivers/video/Kconfig mm1/drivers/video/Kconfig
--- mm1-orig/drivers/video/Kconfig  2005-07-13 13:46:46.0 +0900
+++ mm1/drivers/video/Kconfig   2005-07-16 09:56:59.0 +0900
@@ -1399,8 +1399,8 @@
  Say Y here to enable kernel support for the on-board framebuffer.
 
 config FB_G364
-   bool
-   depends on MIPS_MAGNUM_4000 || OLIVETTI_M700
+   bool "G364 frame buffer support"
+   depends on (FB = y) && (MIPS_MAGNUM_4000 || OLIVETTI_M700)
select FB_CFB_FILLRECT
select FB_CFB_COPYAREA
select FB_CFB_IMAGEBLIT
-
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://www.tux.org/lkml/

Re: [PATCH] ramfs: pretend dirent sizes

[Chris Wedgwood]

On Fri, Jul 15, 2005 at 11:52:42AM -0700, Linus Torvalds wrote:

> I really think you should update the "simple_xxx()" functions
> instead, and thus make this happen for _any_ filesystem that uses
> the simple fs helper functions.

Why bother at all?

I don't see why zero sizes are a problem.  We've had them for year
without complaints.
-
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://www.tux.org/lkml/

init 0 stopped working

[Martin Mokrejs]

Hi,
  I used to shutdown my P4 machine based on ASUS P4C800E-Deluxe
with simple "init 0" command. That somehow broke between 2.6.12-rc6-git2
and 2.6.13-rc1. The machines makes the sound like shutdown but it
immediately turns the power on again. I used acpi and the kernel
configs should be almost identical in all cases, as I just recopy
previously used .config and run "make oldconfig".

  Any clues? I still happens even with 2.6.13-rc3-git2.
Please Cc: me in replies.
Martin
-
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://www.tux.org/lkml/

RE: 2.6.9 chrdev_open: serial_core: uart_open

[Alan Cox]

On Gwe, 2005-07-15 at 15:02 -0700, karl malbrain wrote:
> I've since answered part of my question.  Red Hat pulled some code-changes
> from 2.6.10 tty_io.c with the somewhat cryptic comment "fix the trivial
> exploits caused by Rolands controlling tty changes (part 1)" and moved the
> tty_sem ops.
> 
> Do you know if this would be Roland at Red Hat, or a Roland at lkml?

Roland at Red Hat. See the kernel list but 2.6.9 had an interesting hole
where you could crash the system by playing games with setsid and
threaded applications.

RHEL bugs really are best in the RHEL bugzilla, or through your support
contact as a customer. That ensures that the bug is processed promptly
and chased up for you while bugzilla is just for bug collection.

Alan

-
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://www.tux.org/lkml/

Incoming e-mail blocked

[viruscheck]

Please do not reply to this e-mail.  A reply to this e-mail will not be read.

An e-mail sent by you has been blocked by our automated software, because: 
•   it contains a virus which cannot be cleaned. 

What to do: Please ensure you have up to date virus protection, and clean the 
infected computer and files, before attempting to send any further messages to 
the recipient/s.

About the e-mail: 
From:   linux-kernel@vger.kernel.org
To: [EMAIL PROTECTED]

Date:   Fri, 15 Jul 2005 18:52:32 -0500
Subject:Anrxltqxdd

Virus detected:
Scenarios/Incoming/Familes Incoming/Sophos Anti-Virus: Information 0x42060008, 
W32/MyDoom-O
Scenarios/Incoming/Familes Incoming/Sophos Anti-Virus: Information 0x42060008, 
W32/MyDoom-O
Scenarios/Incoming/Familes Incoming/Exe Parking: 'ItemLength.GE.0'.


-
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://www.tux.org/lkml/

RE: 2.6.9 chrdev_open: serial_core: uart_open

[Alan Cox]

On Gwe, 2005-07-15 at 13:11 -0700, karl malbrain wrote:
> N.b. I don't pretend to understand how uart_change_pm, uart_startup, and
> uart_block_til_ready could ALL be on the call stack.  Uart_open calls them
> sequentially.  Perhaps you might explain how this works?  Thanks, karl m

gcc does smart things including deferring stack cleanup so that it can
turn

push, push, call, adjust stack, push, push call .. etc

into a sequence with less stack pointer adjustment for performance
reasons. That sometimes fools the traceback code. A good rule of thumb
is to trace the sequence of calls and assume that the last sane sequence
is the one that occurred before the failure.

Alan

-
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://www.tux.org/lkml/

Re: 2.6.13-rc3-mm1

[Andrew Morton]

Yoichi Yuasa <[EMAIL PROTECTED]> wrote:
>
> Hi Andrew
> 
> I got the following error.
> 
> make ARCH=mips oldconfig
> scripts/kconfig/conf -o arch/mips/Kconfig
> drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to 
> 'tristate'
> 
> file drivers/char/speakup/Kconfig already scanned?
> make[1]: *** [oldconfig] Error 1
> make: *** [oldconfig] Error 2
> 

Well arch/mips/Kconfig is defining CONFIG_FB as bool and
drivers/video/Kconfig was changed a while ago to define it as tristate.  I
assume this failure also happens in linus's current tree.  

It seems odd that mips is privately duplicating the generic code's
definition.  Maybe that needs to be taken out of there.

I'll cc the fbdev guys - could someone please come up with fix?  It's a
showstopper for the MIPS architecture.
-
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://www.tux.org/lkml/

Re: reiserfs+acl makes processes hang?

[Kasper Sandberg]

confirmed, i run 2.6.12 with reiserfs, created with reiserfsprogs 3.6.19

On Fri, 2005-07-15 at 23:19 +, Tarmo Tänav wrote:
> Hi,
> 
> I think I've found a bug in reiserfs acls. If triggered
> it means that any program trying to access the partition,
> where the bug occured, will just hang in D state, with
> no way to kill the program.
> 
> Here's how to reproduce:
> 1. mount a reiserfs volume (loopmount will do) with "-o acl".
> 2. create a directory "dir"
> 3. set some default acl: setfacl -d -m u:username:rwX dir
> 4. cd dir
> 5. dd if=/dev/zero of=somefile1 bs=4k count=10
> (the idea is to run out of space)
> 6. now df should show 0 free space, if not then repeat 5.
> 7. echo "1" > somefile2 # this should hang infinitely
> 
> Now no program will be able to access the partition.
> 
> I haven't tried to reproduce it, but the same problem also happened
> when a user hit his hard quota limit on my server. Then no program
> could access his homedir.
> 
> 
> PS. I'm not subscribed to lkml so please CC
> 
> --
> Tarmo Tänav
> [EMAIL PROTECTED]
> 
> -
> 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://www.tux.org/lkml/
> 

-
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://www.tux.org/lkml/

[PATCH] scsi/ibmvscsi/srp.h: Fix a wrong type code used for SRP_LOGIN_REJ

[Linda Xie]

Hi James,

This patch fixes srp.h which uses 0x80 for SRP_LOGIN_REJ instead of 
0xc2.  Please apply.


Thanks,

Linda

Signed-off-by: Linda Xie <[EMAIL PROTECTED]
diff -X ../dontdiff -purN large-sg/drivers/scsi/ibmvscsi/srp.h 
srp/drivers/scsi/ibmvscsi/srp.h
--- large-sg/drivers/scsi/ibmvscsi/srp.h2005-06-24 17:32:27.0 
-0500
+++ srp/drivers/scsi/ibmvscsi/srp.h 2005-07-15 17:36:45.0 -0500
@@ -35,7 +35,7 @@
 enum srp_types {
SRP_LOGIN_REQ_TYPE = 0x00,
SRP_LOGIN_RSP_TYPE = 0xC0,
-   SRP_LOGIN_REJ_TYPE = 0x80,
+   SRP_LOGIN_REJ_TYPE = 0xC2,
SRP_I_LOGOUT_TYPE = 0x03,
SRP_T_LOGOUT_TYPE = 0x80,
SRP_TSK_MGMT_TYPE = 0x01,

reiserfs+acl makes processes hang?

[Tarmo Tänav]

Hi,

I think I've found a bug in reiserfs acls. If triggered
it means that any program trying to access the partition,
where the bug occured, will just hang in D state, with
no way to kill the program.

Here's how to reproduce:
1. mount a reiserfs volume (loopmount will do) with "-o acl".
2. create a directory "dir"
3. set some default acl: setfacl -d -m u:username:rwX dir
4. cd dir
5. dd if=/dev/zero of=somefile1 bs=4k count=10
(the idea is to run out of space)
6. now df should show 0 free space, if not then repeat 5.
7. echo "1" > somefile2 # this should hang infinitely

Now no program will be able to access the partition.

I haven't tried to reproduce it, but the same problem also happened
when a user hit his hard quota limit on my server. Then no program
could access his homedir.


PS. I'm not subscribed to lkml so please CC

--
Tarmo Tänav
[EMAIL PROTECTED]

-
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://www.tux.org/lkml/

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[Rik van Riel]

On Fri, 15 Jul 2005, Mark Gross wrote:

> What would be wrong in expecting the folks making the driver changes 
> have some story on how they are validating there changes don't break 
> existing working hardware?  I could probly be accomplished in open 
> source with subsystem testing volenteers.

Are you volunteering ?

-- 
The Theory of Escalating Commitment: "The cost of continuing mistakes is
borne by others, while the cost of admitting mistakes is borne by yourself."
  -- Joseph Stiglitz, Nobel Laureate in Economics
-
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://www.tux.org/lkml/

Re: 2.6.13-rc3-mm1

[Yoichi Yuasa]

Hi again,

On Sat, 16 Jul 2005 07:52:42 +0900
Yoichi Yuasa <[EMAIL PROTECTED]> wrote:

> Hi Andrew
> 
> I got the following error.
> 
> make ARCH=mips oldconfig
> scripts/kconfig/conf -o arch/mips/Kconfig
> drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to 
> 'tristate'
> 
> file drivers/char/speakup/Kconfig already scanned?
> make[1]: *** [oldconfig] Error 1
> make: *** [oldconfig] Error 2
> 
> 
> gregkh-driver-speakup-core.patch
> 
>  arch/arm/Kconfig |1
>  arch/mips/Kconfig|2
>  arch/sparc64/Kconfig |2
> 
> It is not necessary to change these three files. 
> Please remove these changes.

Sorry, I mistook.
It is not necessary to change for mips.
Please remove mips Kconfig change.

Yoichi
-
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://www.tux.org/lkml/

Re: 2.6.13-rc3-mm1

[Yoichi Yuasa]

Hi Andrew

I got the following error.

make ARCH=mips oldconfig
scripts/kconfig/conf -o arch/mips/Kconfig
drivers/video/Kconfig:7:warning: type of 'FB' redefined from 'boolean' to 
'tristate'

file drivers/char/speakup/Kconfig already scanned?
make[1]: *** [oldconfig] Error 1
make: *** [oldconfig] Error 2


gregkh-driver-speakup-core.patch

 arch/arm/Kconfig |1
 arch/mips/Kconfig|2
 arch/sparc64/Kconfig |2

It is not necessary to change these three files. 
Please remove these changes.

Yoichi
-
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://www.tux.org/lkml/

[PATCH -linus] Really __nocast-annotate kmalloc_node().

[Alexey Dobriyan]

One chunk was lost somewhere between my and Andrew's machine.

Noticed by Victor Fusco.

Signed-off-by: Alexey Dobriyan <[EMAIL PROTECTED]>
---

 include/linux/slab.h |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

--- linux-vanilla/include/linux/slab.h  2005-07-08 13:52:46.0 +0400
+++ linux-slab/include/linux/slab.h 2005-07-08 21:02:47.0 +0400
@@ -111,7 +111,7 @@ static inline void *kmem_cache_alloc_nod
 {
return kmem_cache_alloc(cachep, flags);
 }
-static inline void *kmalloc_node(size_t size, int flags, int node)
+static inline void *kmalloc_node(size_t size, unsigned int __nocast flags, int 
node)
 {
return kmalloc(size, flags);
 }
-
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://www.tux.org/lkml/

Re: [2.6 patch] drivers/media/video/tveeprom.c: possible cleanups

[Mauro Carvalho Chehab]

Adrian,

Your patch is at my personal TODO list.

We had lots of patches for 2.6.13, with some sigificative enhancements.

Unfortunatelly, your patch from 19 Apr 2005 was not applied, maybe
because you've sent during a period where V4L was Orphaned.

We've decided to stop non-bug fixes just some days before your newer
attempt (July, 7) to focus on more tests at a stable branch. Until July,
18, V4L are applying only bug fixes. After that, we'll collect more
patches at V4L and, maybe at the end of the next week, we'll send the
patchsets, including yours (It will be #1 :-) ).

Cheers,

Mauro.

Adrian Bunk wrote:
> This patch contains the following possible cleanups:
> - make two needlessly global structs static
> - #if 0 the EXPORT_SYMBOL'ed but unused function tveeprom_dump
> 
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> 
> ---
> 
> This patch was already sent on:
> - 9 Jul 2005
> - 19 Apr 2005
> 

-
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://www.tux.org/lkml/

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[David Lang]

On Fri, 15 Jul 2005, Mark Gross wrote:


On Thursday 14 July 2005 19:09, Dave Jones wrote:

On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
>>> The problem is the process, not than the code.
>>> * The issues are too much ad-hock code flux without enough
>>> disciplined/formal regression testing and review.
>>
>> It's basically impossible to regression test swsusp except to release
>> it. Its success or failure depends on exactly the driver
>> combination/platform/BIOS version etc.  e.g. all drivers have to
>> cooperate and the particular bugs in your BIOS need to be worked
>> around etc. Since that is quite fragile regressions are common.
>>
>> However in some other cases I agree some more regression testing
>> before release would be nice. But that's not how Linux works.  Linux
>> does regression testing after release.
>
> And who says that couldn't change?
>
> In my oppinion it would be nice if Linus/Andrew had some basic
> regression tests they could run on kernels before releasing them.

The problem is that this wouldn't cover the more painful problems
such as hardware specific problems.

As Fedora kernel maintainer, I frequently get asked why peoples
sound cards stopped working when they did an update, or why
their system no longer boots, usually followed by a
"wasnt this update tested before it was released?"

The bulk of all the regressions I see reported every time
I put out a kernel update rpm that rebases to a newer
upstream release are in drivers. Those just aren't going
to be caught by folks that don't have the hardware.


This problem is the developer making driver changes without have the resources
to test the changes on a enough of the hardware effected by his change, and
therefore probubly shouldn't be making changes they cannot realisticaly test.

What would be wrong in expecting the folks making the driver changes have some
story on how they are validating there changes don't break existing working
hardware?  I could probly be accomplished in open source with subsystem
testing volenteers.


in that case you will have a lot of drivers that won't work becouse the 
rest of the kernel has changed and they haven't been changed to match.


do you have the resources to test a few hundred network cards, video 
cards, etc? if you do great, hope you can help out, if not why should you 
require other kernel folks to have resources that you don't have?


David Lang

--
There are two ways of constructing a software design. One way is to make it so 
simple that there are obviously no deficiencies. And the other way is to make 
it so complicated that there are no obvious deficiencies.
 -- C.A.R. Hoare
-
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://www.tux.org/lkml/

[PATCH] SMB fix

[J.A. Magallon]

On 07.16, J.A. Magallon wrote:
> 
> On 07.15, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > 

--- linux-2.6.12/fs/smbfs/request.c~2005-07-07 14:41:11.0 -0400
+++ linux-2.6.12/fs/smbfs/request.c 2005-07-07 14:41:22.0 -0400
@@ -348,6 +348,7 @@ int smb_add_request(struct smb_request *
smb_rput(req);
}
smb_unlock_server(server);
+   return -EINTR;
}
 
if (!timeleft) {


--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))


-
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://www.tux.org/lkml/

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[Dave Jones]

On Fri, Jul 15, 2005 at 02:47:46PM -0700, Mark Gross wrote:
 
 > This problem is the developer making driver changes without have the 
 > resources 
 > to test the changes on a enough of the hardware effected by his change, and 
 > therefore probubly shouldn't be making changes they cannot realisticaly test.

Such is life. The situation arises quite often where fixing a bug
for one person breaks it for another. The lack of hardware to test on
isn't the fault of the person making the change, nor the person requesting
the change. The problem is that the person it breaks for doesn't test
testing kernels, so the problem is only found out about when its too late.

The agpgart driver for example supports around 50-60 different chipsets.
I don't have a tenth of the hardware that it supports at my disposal,
yet when I get patches fixing some problem for someone, or adding support
for yet another variant, I'm not going to go out and find the variants
I don't have.  By your metric I shouldn't apply that change.

That's not how things work.

 > What would be wrong in expecting the folks making the driver changes have 
 > some 
 > story on how they are validating there changes don't break existing working 
 > hardware?

It's impractical given the plethora of hardware combinations out there.

 > I could probly be accomplished in open source with subsystem 
 > testing volenteers.

People tend not to test things marked 'test kernels' or 'rc kernels'.
They prefer to shout loudly when the final release happens, and
blame it on 'the new kernel development model sucking'.

 > > The only way to cover as many combinations of hardware
 > > out there is by releasing test kernels. (Updates-testing
 > > repository for Fedora users, or -rc kernels in Linus' case).
 > > If users won't/don't test those 'test' releases, we're
 > > going to regress when the final release happens, there's
 > > no two ways about it.
 > 
 > You can't blame the users!  Don't fall into that trap.  Its not productive.

You're missing my point. The bits are out there for people to
test with.  We can't help people who won't help themselves,
and they shouldn't be at all surprised to find things breaking
if they choose to not take part in testing.

Dave

-
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://www.tux.org/lkml/

[PATCH] signed char fixes for scripts

[J.A. Magallon]

On 07.16, J.A. Magallon wrote:
> 
> On 07.15, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > 

This time I did not break anything... and they shut up gcc4 ;)

--- linux-2.6.12-jam1/scripts/mod/sumversion.c.orig 2005-06-21 
23:44:30.0 +0200
+++ linux-2.6.12-jam1/scripts/mod/sumversion.c  2005-06-21 23:47:09.0 
+0200
@@ -252,9 +252,9 @@
 }
 
 /* FIXME: Handle .s files differently (eg. # starts comments) --RR */
-static int parse_file(const signed char *fname, struct md4_ctx *md)
+static int parse_file(const char *fname, struct md4_ctx *md)
 {
-   signed char *file;
+   char *file;
unsigned long i, len;
 
file = grab_file(fname, );
@@ -332,7 +332,7 @@
   Sum all files in the same dir or subdirs.
*/
while ((line = get_next_line(, file, flen)) != NULL) {
-   signed char* p = line;
+   char* p = line;
if (strncmp(line, "deps_", sizeof("deps_")-1) == 0) {
check_files = 1;
continue;
@@ -458,7 +458,7 @@
close(fd);
 }
 
-static int strip_rcs_crap(signed char *version)
+static int strip_rcs_crap(char *version)
 {
unsigned int len, full_len;
 
--- linux-2.6.12-jam1/scripts/lxdialog/inputbox.c.orig  2005-06-21 
23:40:27.0 +0200
+++ linux-2.6.12-jam1/scripts/lxdialog/inputbox.c   2005-06-21 
23:42:39.0 +0200
@@ -21,7 +21,7 @@
 
 #include "dialog.h"
 
-unsigned char dialog_input_result[MAX_LEN + 1];
+char dialog_input_result[MAX_LEN + 1];
 
 /*
  *  Print the termination buttons
@@ -48,7 +48,7 @@
 {
 int i, x, y, box_y, box_x, box_width;
 int input_x = 0, scroll = 0, key = 0, button = -1;
-unsigned char *instr = dialog_input_result;
+char *instr = dialog_input_result;
 WINDOW *dialog;
 
 /* center dialog box on screen */
--- linux-2.6.12-jam1/scripts/lxdialog/dialog.h.orig2005-06-21 
23:42:55.0 +0200
+++ linux-2.6.12-jam1/scripts/lxdialog/dialog.h 2005-06-21 23:43:19.0 
+0200
@@ -163,7 +163,7 @@
 int dialog_checklist (const char *title, const char *prompt, int height,
int width, int list_height, int item_no,
const char * const * items, int flag);
-extern unsigned char dialog_input_result[];
+extern char dialog_input_result[];
 int dialog_inputbox (const char *title, const char *prompt, int height,
int width, const char *init);
 
--- linux-2.6.12-jam1/scripts/conmakehash.c.orig2005-06-22 
00:16:58.0 +0200
+++ linux-2.6.12-jam1/scripts/conmakehash.c 2005-06-22 00:17:21.0 
+0200
@@ -33,7 +33,7 @@
 
 int getunicode(char **p0)
 {
-  unsigned char *p = *p0;
+  char *p = *p0;
 
   while (*p == ' ' || *p == '\t')
 p++;
--- linux-2.6.12-jam7/scripts/kallsyms.c.orig   2005-07-06 00:16:39.0 
+0200
+++ linux-2.6.12-jam7/scripts/kallsyms.c2005-07-06 00:42:24.0 
+0200
@@ -166,9 +166,9 @@
 * move then they may get dropped in pass 2, which breaks the
 * kallsyms rules.
 */
-   if ((s->addr == _etext && strcmp(s->sym + offset, "_etext")) ||
-   (s->addr == _einittext && strcmp(s->sym + offset, 
"_einittext")) ||
-   (s->addr == _eextratext && strcmp(s->sym + offset, 
"_eextratext")))
+   if ((s->addr == _etext && strcmp((char*)s->sym + offset, 
"_etext")) ||
+   (s->addr == _einittext && strcmp((char*)s->sym + offset, 
"_einittext")) ||
+   (s->addr == _eextratext && strcmp((char*)s->sym + offset, 
"_eextratext")))
return 0;
}
 


--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))


-
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://www.tux.org/lkml/

Re: Realtime Preemption, 2.6.12, Beginners Guide?

[Alistair John Strachan]

On Thursday 14 Jul 2005 21:16, Lee Revell wrote:
> On Thu, 2005-07-14 at 20:58 +0100, Alistair John Strachan wrote:
> > the responsiveness of our instrument to 300us which is low enough
> > for the real-time PCR industry
>
> PCR, as in polymerase chain reaction?  They can do that in realtime?
> Impressive.
>
> Lee

Yes, and yes. And it is impressive.

And Linux will power a major instrument in the future.

-- 
Cheers,
Alistair.

personal:   alistair()devzero!co!uk
university: s0348365()sms!ed!ac!uk
student:CS/CSim Undergraduate
contact:1F2 55 South Clerk Street,
Edinburgh. EH8 9PP.
-
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://www.tux.org/lkml/

[PATCH] SCSI SATA is a tristate

[J.A. Magallon]

On 07.16, J.A. Magallon wrote:
> 
> On 07.15, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > 

--- linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig.old   2005-07-02 
21:57:40.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig   2005-07-02 21:58:06.0 
+0200
@@ -447,7 +447,7 @@
 source "drivers/scsi/megaraid/Kconfig.megaraid"
 
 config SCSI_SATA
-   bool "Serial ATA (SATA) support"
+   tristate "Serial ATA (SATA) support"
depends on SCSI
help
  This driver family supports Serial ATA host controllers


--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))


-
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://www.tux.org/lkml/

[PATCH] fix LDT tss

[J.A. Magallon]

On 07.16, J.A. Magallon wrote:
> 
> On 07.15, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > 

--- linux.orig/include/asm-i386/processor.h
+++ linux/include/asm-i386/processor.h
@@ -476,7 +476,6 @@ struct thread_struct {
.esp0   = sizeof(init_stack) + (long)_stack,   \
.ss0= __KERNEL_DS,  \
.ss1= __KERNEL_CS,  \
-   .ldt= GDT_ENTRY_LDT,\
.io_bitmap_base = INVALID_IO_BITMAP_OFFSET, \
.io_bitmap  = { [ 0 ... IO_BITMAP_LONGS] = ~0 },\
 }

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))


-
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://www.tux.org/lkml/

[PATCH] fix kmalloc in IDE

[J.A. Magallon]

On 07.16, J.A. Magallon wrote:
> 
> On 07.15, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > 

--- linux-2.6.git.orig/drivers/ide/ide-probe.c  2005-06-23 11:38:02.0 
-0700
+++ linux-2.6.git/drivers/ide/ide-probe.c   2005-07-07 10:22:02.0 
-0700
@@ -960,6 +960,15 @@
 }
 #endif /* MAX_HWIFS > 1 */
 
+static inline int hwif_to_node(ide_hwif_t *hwif)
+{
+   if (hwif && hwif->pci_dev)
+   return pcibus_to_node(hwif->pci_dev->bus);
+   else
+   /* Add ways to determine the node of other busses here */
+   return -1;
+}
+
 /*
  * init request queue
  */
@@ -978,8 +987,7 @@
 *  do not.
 */
 
-   q = blk_init_queue_node(do_ide_request, _lock,
-   pcibus_to_node(drive->hwif->pci_dev->bus));
+   q = blk_init_queue_node(do_ide_request, _lock, hwif_to_node(hwif));
if (!q)
return 1;
 
@@ -1097,7 +1105,7 @@
spin_unlock_irq(_lock);
} else {
hwgroup = kmalloc_node(sizeof(ide_hwgroup_t), GFP_KERNEL,
-   pcibus_to_node(hwif->drives[0].hwif->pci_dev->bus));
+   hwif_to_node(hwif->drives[0].hwif));
if (!hwgroup)
goto out_up;
 


--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))


-
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://www.tux.org/lkml/

[2.6.13-rc3][SATA] - SIL 3114 controller w/ firmware 5.0.39 - Hanging only in 64bit mode

[Shawn Starr]

I just tried -rc3 today on the amd64 box which is a Asus K8N-E Deluxe 
motherboard. Is it possible the firmware for the controller is buggy? Anyone 
else reporting hangs?

I can reproduce the sata controller with various writes:

1) If I connect the box and allow a remote machine to PXE and TFTP boot from 
it, the machine hangs. This is consistent each time I try this but only if the 
box is in 64bit mode.

2) Certain times when doing disk writes it will just hang, there doesn't appear 
to be any messages from the sil driver logged to console. It still seems to be 
released to DMA problems.

I hope this info is helpful, 

thanks, 

Shawn.


lspci info:

00:00.0 Host bridge: nVidia Corporation nForce3 250Gb Host Bridge (rev a1)
00:01.0 ISA bridge: nVidia Corporation nForce3 250Gb LPC Bridge (rev a2)
00:01.1 SMBus: nVidia Corporation nForce 250Gb PCI System Management (rev a1)
00:02.0 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.1 USB Controller: nVidia Corporation CK8S USB Controller (rev a1)
00:02.2 USB Controller: nVidia Corporation nForce3 EHCI USB 2.0 Controller (rev 
a2)
00:06.0 Multimedia audio controller: nVidia Corporation nForce3 250Gb AC'97 
Audio Controller (rev a1)
00:08.0 IDE interface: nVidia Corporation CK8S Parallel ATA Controller (v2.5) 
(rev a2)
00:0a.0 IDE interface: nVidia Corporation CK8S Serial ATA Controller (v2.5) 
(rev a2)
00:0b.0 PCI bridge: nVidia Corporation nForce3 250Gb AGP Host to PCI Bridge 
(rev a2)
00:0e.0 PCI bridge: nVidia Corporation nForce3 250Gb PCI-to-PCI Bridge (rev a2)
00:18.0 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
HyperTransport Technology Configuration
00:18.1 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] Address 
Map
00:18.2 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] DRAM 
Controller
00:18.3 Host bridge: Advanced Micro Devices [AMD] K8 [Athlon64/Opteron] 
Miscellaneous Control
01:00.0 VGA compatible controller: nVidia Corporation NV6 [Vanta/Vanta LT] (rev 
15)
02:07.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] 
(rev 08)
02:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100] 
(rev 08)
02:0c.0 Unknown mass storage controller: Silicon Image, Inc. SiI 3114 
[SATALink/SATARaid] Serial ATA Controller (rev 02)

Relevent dmesg:

SCSI subsystem initialized
libata version 1.10 loaded.
sata_sil version 0.8
ata1: SATA max UDMA/100 cmd 0xFF004C80 ctl 0xFF004C8A bmdma 
0xFF004C00 irq 11
ata2: SATA max UDMA/100 cmd 0xFF004CC0 ctl 0xFF004CCA bmdma 
0xFF004C08 irq 11
ata3: SATA max UDMA/100 cmd 0xFF004E80 ctl 0xFF004E8A bmdma 
0xFF004E00 irq 11
ata4: SATA max UDMA/100 cmd 0xFF004EC0 ctl 0xFF004ECA bmdma 
0xFF004E08 irq 11
ata1: no device found (phy stat )
scsi0 : sata_sil
ata2: no device found (phy stat )
scsi1 : sata_sil
ata3: no device found (phy stat )
scsi2 : sata_sil
ata4: no device found (phy stat )
scsi3 : sata_sil
sata_nv version 0.6
PCI: Setting latency timer of device :00:0a.0 to 64
ata5: SATA max UDMA/133 cmd 0x9F0 ctl 0xBF2 bmdma 0xD000 irq 10
ata6: SATA max UDMA/133 cmd 0x970 ctl 0xB72 bmdma 0xD008 irq 10
ata5: dev 0 cfg 49:2f00 82:7c6b 83:7b09 84:4003 85:7c69 86:3a01 87:4003 88:007f
ata5: dev 0 ATA, max UDMA/133, 160086528 sectors:
nv_sata: Primary device added
nv_sata: Primary device removed
nv_sata: Secondary device removed
ata5: dev 0 configured for UDMA/133
scsi4 : sata_nv
ata6: no device found (phy stat )
scsi5 : sata_nv
  Vendor: ATA   Model: Maxtor 6Y080M0Rev: YAR5
  Type:   Direct-Access  ANSI SCSI revision: 05
SCSI device sda: 160086528 512-byte hdwr sectors (81964 MB)
SCSI device sda: drive cache: write back
 sda: sda1 sda2 sda3
Attached scsi disk sda at scsi4, channel 0, id 0, lun 0


Onboard IDE controller and devices information:

Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
NFORCE3-250: IDE controller at PCI slot :00:08.0
NFORCE3-250: chipset revision 162
NFORCE3-250: not 100% native mode: will probe irqs later
NFORCE3-250: :00:08.0 (rev a2) UDMA133 controller
ide0: BM-DMA at 0xffa0-0xffa7, BIOS settings: hda:DMA, hdb:DMA
ide1: BM-DMA at 0xffa8-0xffaf, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: GCR-8523B, ATAPI CD/DVD-ROM drive
hdb: LITE-ON DVD SOHD-16P9S, ATAPI CD/DVD-ROM drive
-
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://www.tux.org/lkml/

[PATCH] Assorted fixes

[J.A. Magallon]

On 07.15, Andrew Morton wrote:
> 
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> 
> (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> kernel.org syncs up)
> 

This are fixes that I still have in my small patchset, collected from the list,
Just post them fwiw (they don't hurt but I'm no more sure if they are needed)
Patches come in replys to this mail...

--
J.A. Magallon  \   Software is like sex:
werewolf!able!es \ It's better when it's free
Mandriva Linux release 2006.0 (Cooker) for i586
Linux 2.6.12-jam9 (gcc 4.0.1 (4.0.1-0.2mdk for Mandriva Linux release 2006.0))


-
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://www.tux.org/lkml/

RE: 2.6.9 chrdev_open: serial_core: uart_open

[karl malbrain]

> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 2:54 PM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote:
> > > -Original Message-
> > > From: Russell King
> > > Sent: Friday, July 15, 2005 1:59 PM
> > > To: karl malbrain
> > > Cc: [EMAIL PROTECTED] Kernel. Org
> > > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
> > >
> > >
> > > On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote:
> > > > On my 2.6.9-11EL source it clearly shows the up(_sem) after
> > > the call to
> > > > uart_open. Init_dev never touches tty_sem.
> > >
> > > In which case, I have to say...
> > >
> > > Congratulations!  You've found a bug with Red Hat's Enterprise Linux
> > > kernel!  Go straight to Red Hat's bugzilla!  Do not collect 200$.  Do
> > > not pass go.
> > >
> > > Seriously though, this bug is not present in mainline kernels, so I
> > > can't resolve this issue for you.  Mainline kernels appear to work
> > > properly.
> >
> > Could tty_io.c be all that changed by a small set of red-hat patches to
> > 2.6.9?  Why would they need to go in there to make so many
> changes in the
> > first place?  Which 2.6 release changed tty_io.c's use of tty_sem so
> > heavily?
>
> These are questions to ask of Red Hat, and can only be answered by
> their representatives.

I've since answered part of my question.  Red Hat pulled some code-changes
from 2.6.10 tty_io.c with the somewhat cryptic comment "fix the trivial
exploits caused by Rolands controlling tty changes (part 1)" and moved the
tty_sem ops.

Do you know if this would be Roland at Red Hat, or a Roland at lkml?

Thanks, karl m



-
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://www.tux.org/lkml/

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[Mark Gross]

On Thursday 14 July 2005 19:09, Dave Jones wrote:
> On Fri, Jul 15, 2005 at 03:45:28AM +0200, Jesper Juhl wrote:
>  > > > The problem is the process, not than the code.
>  > > > * The issues are too much ad-hock code flux without enough
>  > > > disciplined/formal regression testing and review.
>  > >
>  > > It's basically impossible to regression test swsusp except to release
>  > > it. Its success or failure depends on exactly the driver
>  > > combination/platform/BIOS version etc.  e.g. all drivers have to
>  > > cooperate and the particular bugs in your BIOS need to be worked
>  > > around etc. Since that is quite fragile regressions are common.
>  > >
>  > > However in some other cases I agree some more regression testing
>  > > before release would be nice. But that's not how Linux works.  Linux
>  > > does regression testing after release.
>  >
>  > And who says that couldn't change?
>  >
>  > In my oppinion it would be nice if Linus/Andrew had some basic
>  > regression tests they could run on kernels before releasing them.
>
> The problem is that this wouldn't cover the more painful problems
> such as hardware specific problems.
>
> As Fedora kernel maintainer, I frequently get asked why peoples
> sound cards stopped working when they did an update, or why
> their system no longer boots, usually followed by a
> "wasnt this update tested before it was released?"
>
> The bulk of all the regressions I see reported every time
> I put out a kernel update rpm that rebases to a newer
> upstream release are in drivers. Those just aren't going
> to be caught by folks that don't have the hardware.

This problem is the developer making driver changes without have the resources 
to test the changes on a enough of the hardware effected by his change, and 
therefore probubly shouldn't be making changes they cannot realisticaly test.

What would be wrong in expecting the folks making the driver changes have some 
story on how they are validating there changes don't break existing working 
hardware?  I could probly be accomplished in open source with subsystem 
testing volenteers.

>
> The only way to cover as many combinations of hardware
> out there is by releasing test kernels. (Updates-testing
> repository for Fedora users, or -rc kernels in Linus' case).
> If users won't/don't test those 'test' releases, we're
> going to regress when the final release happens, there's
> no two ways about it.

You can't blame the users!  Don't fall into that trap.  Its not productive.

>
>   Dave

-- 
--mgross
BTW: This may or may not be the opinion of my employer, more likely not.  

-
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://www.tux.org/lkml/

Re: 2.6.9 chrdev_open: serial_core: uart_open

[Russell King]

On Fri, Jul 15, 2005 at 02:17:01PM -0700, karl malbrain wrote:
> > -Original Message-
> > From: Russell King
> > Sent: Friday, July 15, 2005 1:59 PM
> > To: karl malbrain
> > Cc: [EMAIL PROTECTED] Kernel. Org
> > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
> >
> >
> > On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote:
> > > On my 2.6.9-11EL source it clearly shows the up(_sem) after
> > the call to
> > > uart_open. Init_dev never touches tty_sem.
> >
> > In which case, I have to say...
> >
> > Congratulations!  You've found a bug with Red Hat's Enterprise Linux
> > kernel!  Go straight to Red Hat's bugzilla!  Do not collect 200$.  Do
> > not pass go.
> >
> > Seriously though, this bug is not present in mainline kernels, so I
> > can't resolve this issue for you.  Mainline kernels appear to work
> > properly.
> 
> Could tty_io.c be all that changed by a small set of red-hat patches to
> 2.6.9?  Why would they need to go in there to make so many changes in the
> first place?  Which 2.6 release changed tty_io.c's use of tty_sem so
> heavily?

These are questions to ask of Red Hat, and can only be answered by
their representatives.

Thanks anyway, and I'm sorry that this hasn't been resolved given
the amount of time put into it by both of us.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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://www.tux.org/lkml/

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[Mark Gross]

On Thursday 14 July 2005 19:16, Dave Airlie wrote:
> > That, of course, you cannot do. But, you can regression test a lot of
> > other things, and having a default test suite that is constantly being
> > added to and always being run before releases (that test hardware
> > agnostic stuff) could help cut down on the number of regressions in
> > new releases.
> > You can't test everything this way, nor should you, but you can test
> > many things, and adding a bit of formal testing to the release
> > procedure wouldn't be a bad thing IMO.
>
> But if you read peoples complaints about regression they are nearly
> always to do with hardware that used to work not working any more ..
> alps touchpads, sound cards, software suspend.. so these people still
> gain nothing by you regression testing anything so you still get as
> many reports.. the -rc series is meant to provide the testing for the
> release so nothing really big gets through (like can't boot from IDE
> anymore or something like that)
>

I've seen large labs of lots of different systems used for dedicated testing 
of products I've worked on in the past.  The validation folks held the keys 
to the build and if a change got in that broke on an important OEM's 
hardware, then everything stops until that change is either fixed or backed 
out.

It aint cheap.  In open source we are attempting to simulate this, but we 
don't simulate the control of the validation leads.

> Dave.

-- 
--mgross
BTW: This may or may not be the opinion of my employer, more likely not.  

-
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://www.tux.org/lkml/

Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

[randy_dunlap]

On Fri, 15 Jul 2005 14:38:54 -0700 Tom Rini wrote:

> On Fri, Jul 15, 2005 at 02:24:32PM -0700, randy_dunlap wrote:
> > On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:
> > 
> > > When running depmod to check for the correct version number, extra
> > > output we don't need to see, such as "depmod: QM_MODULES: Function not
> > > implemented" may show up.  Redirect stderr to /dev/null as the version
> > > information that we do care about comes to stdout.
> > > 
> > > Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
> > > 
> > > diff --git a/Makefile b/Makefile
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post
> > >  
> > >  .PHONY: _modinst_
> > >  _modinst_:
> > > - @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \
> > > + @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \
> > >   echo "Warning: you may need to install module-init-tools"; \
> > >   echo "See 
> > > http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\
> > >   sleep 1; \
> > 
> > Well, seeing "QM_MODULES" is a great indicator that someone is using
> > modutils instead of module-init-tools, so I'd like to see it stay.
> > IOW, I somewhat disagree with "extra output we don't need to see."
> 
> This shows up when building a 2.6 kernel with incorrect tools installed.
> What shows up when building a 2.6 kernel on a 2.4 machine that's
> properly setup to do both is "depmod: Can't open
> /lib/modules/.../modules.dep for writing".

I see.  Thanks for clarifying.  No problem then (with the patch).

---
~Randy
-
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://www.tux.org/lkml/

Re: Why is 2.6.12.2 less stable on my laptop than 2.6.10?

[Mark Gross]

On Thursday 14 July 2005 19:09, Andi Kleen wrote:
> > You can't test everything this way, nor should you, but you can test
> > many things, and adding a bit of formal testing to the release
> > procedure wouldn't be a bad thing IMO.
>
> In the linux model that's left to the distributions. In fact doing it
> properly takes months. You wouldn't want to wait months for a new mainline
> kernel.
>
> Formal testing is not really compatible with "release early, release often"
>

This is true.  I think we are seeing the effects of releasing more often than 
we should be into a "stable" tree.  Early and Often make sence for developing 
new features, but should they be pushed into a stable release so often?

> You could do things like "run LTP first", but in practice LTP rarely finds
> bugs.
>
> -Andi

-- 
--mgross
BTW: This may or may not be the opinion of my employer, more likely not.  

-
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://www.tux.org/lkml/

[2.6 patch] drivers/media/video/tveeprom.c: possible cleanups

[Adrian Bunk]

This patch contains the following possible cleanups:
- make two needlessly global structs static
- #if 0 the EXPORT_SYMBOL'ed but unused function tveeprom_dump

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 9 Jul 2005
- 19 Apr 2005

 drivers/media/video/tveeprom.c |6 --
 include/media/tveeprom.h   |1 -
 2 files changed, 4 insertions(+), 3 deletions(-)

--- linux-2.6.12-rc2-mm3-full/include/media/tveeprom.h.old  2005-04-19 
01:41:24.0 +0200
+++ linux-2.6.12-rc2-mm3-full/include/media/tveeprom.h  2005-04-19 
01:41:28.0 +0200
@@ -20,4 +20,3 @@
   unsigned char *eeprom_data);
 
 int tveeprom_read(struct i2c_client *c, unsigned char *eedata, int len);
-int tveeprom_dump(unsigned char *eedata, int len);
--- linux-2.6.12-rc2-mm3-full/drivers/media/video/tveeprom.c.old
2005-04-19 01:40:39.0 +0200
+++ linux-2.6.12-rc2-mm3-full/drivers/media/video/tveeprom.c2005-04-19 
01:41:13.0 +0200
@@ -453,6 +453,7 @@
 }
 EXPORT_SYMBOL(tveeprom_read);
 
+#if 0
 int tveeprom_dump(unsigned char *eedata, int len)
 {
int i;
@@ -468,6 +469,7 @@
return 0;
 }
 EXPORT_SYMBOL(tveeprom_dump);
+#endif  /*  0  */
 
 /* --- */
 /* needed for ivtv.sf.net at the moment.  Should go away in the long   */
@@ -484,7 +486,7 @@
 };
 I2C_CLIENT_INSMOD;
 
-struct i2c_driver i2c_driver_tveeprom;
+static struct i2c_driver i2c_driver_tveeprom;
 
 static int
 tveeprom_command(struct i2c_client *client,
@@ -556,7 +558,7 @@
return 0;
 }
 
-struct i2c_driver i2c_driver_tveeprom = {
+static struct i2c_driver i2c_driver_tveeprom = {
.owner  = THIS_MODULE,
.name   = "tveeprom",
.id = I2C_DRIVERID_TVEEPROM,

-
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://www.tux.org/lkml/

Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

[Tom Rini]

On Fri, Jul 15, 2005 at 02:24:32PM -0700, randy_dunlap wrote:
> On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:
> 
> > When running depmod to check for the correct version number, extra
> > output we don't need to see, such as "depmod: QM_MODULES: Function not
> > implemented" may show up.  Redirect stderr to /dev/null as the version
> > information that we do care about comes to stdout.
> > 
> > Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
> > 
> > diff --git a/Makefile b/Makefile
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post
> >  
> >  .PHONY: _modinst_
> >  _modinst_:
> > -   @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \
> > +   @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \
> > echo "Warning: you may need to install module-init-tools"; \
> > echo "See 
> > http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\
> > sleep 1; \
> 
> Well, seeing "QM_MODULES" is a great indicator that someone is using
> modutils instead of module-init-tools, so I'd like to see it stay.
> IOW, I somewhat disagree with "extra output we don't need to see."

This shows up when building a 2.6 kernel with incorrect tools installed.
What shows up when building a 2.6 kernel on a 2.4 machine that's
properly setup to do both is "depmod: Can't open
/lib/modules/.../modules.dep for writing".

-- 
Tom Rini
http://gate.crashing.org/~trini/
-
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://www.tux.org/lkml/

[2.6 patch] fix IP_FIB_HASH kconfig warning

[Adrian Bunk]

This patch fixes the following kconfig warning:
  net/ipv4/Kconfig:92:warning: defaults for choice values not supported

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 9 Jul 2005

--- linux-2.6.13-rc2-mm1-modular/net/ipv4/Kconfig.old   2005-07-08 
23:55:31.0 +0200
+++ linux-2.6.13-rc2-mm1-modular/net/ipv4/Kconfig   2005-07-08 
23:56:23.0 +0200
@@ -56,9 +56,9 @@
 choice 
prompt "Choose IP: FIB lookup algorithm (choose FIB_HASH if unsure)"
depends on IP_ADVANCED_ROUTER
-   default IP_FIB_HASH
+   default ASK_IP_FIB_HASH
 
-config IP_FIB_HASH
+config ASK_IP_FIB_HASH
bool "FIB_HASH"
---help---
Current FIB is very proven and good enough for most users.
@@ -84,12 +84,8 @@

 endchoice
 
-# If the user does not enable advanced routing, he gets the safe
-# default of the fib-hash algorithm.
 config IP_FIB_HASH
-   bool
-   depends on !IP_ADVANCED_ROUTER
-   default y
+   def_bool ASK_IP_FIB_HASH || !IP_ADVANCED_ROUTER
 
 config IP_MULTIPLE_TABLES
bool "IP: policy routing"

-
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://www.tux.org/lkml/

[2.6 patch] fs/smbfs/request.c: turn NULL dereference into BUG()

[Adrian Bunk]

In a case documented as

  We should never be called with any of these states

BUG() in a case that would later result in a NULL pointer dereference.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 26 Mar 2005

--- linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c.old2005-03-26 
13:19:19.0 +0100
+++ linux-2.6.12-rc1-mm3-full/fs/smbfs/request.c2005-03-26 
13:41:30.0 +0100
@@ -786,8 +642,7 @@ int smb_request_recv(struct smb_sb_info 
/* We should never be called with any of these states */
case SMB_RECV_END:
case SMB_RECV_REQUEST:
-   server->rstate = SMB_RECV_END;
-   break;
+   BUG();
}
 
if (result < 0) {
-
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://www.tux.org/lkml/

[2.6 patch] SCSI_SATA has to be a tristate

[Adrian Bunk]

SCSI=m must disallow static drivers.

The problem is that all the SATA drivers depend on SCSI_SATA.

With SCSI=m and SCSI_SATA=y this allows the static enabling of the SATA
drivers with unwanted effects, e.g.:
- SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y
  -> SCSI_ATA_ADMA is built statically but scsi/built-in.o is not linked
 into the kernel
- SCSI=m, SCSI_SATA=y, SCSI_ATA_ADMA=y, SCSI_SATA_AHCI=m
  -> SCSI_ATA_ADMA and libata are built statically but
 scsi/built-in.o is not linked into the kernel,
 SCSI_SATA_AHCI is built modular (unresolved symbols due to missing
  libata)

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 8 Jul 2005
- 2 Jul 2005

--- linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig.old   2005-07-02 
21:57:40.0 +0200
+++ linux-2.6.13-rc1-mm1/drivers/scsi/Kconfig   2005-07-02 21:58:06.0 
+0200
@@ -447,7 +447,7 @@
 source "drivers/scsi/megaraid/Kconfig.megaraid"
 
 config SCSI_SATA
-   bool "Serial ATA (SATA) support"
+   tristate "Serial ATA (SATA) support"
depends on SCSI
help
  This driver family supports Serial ATA host controllers
k
-
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://www.tux.org/lkml/

Re: [PATCH 2.6.13-rc3] kbuild: When checking depmod version, redirect stderr

[randy_dunlap]

On Fri, 15 Jul 2005 07:56:36 -0700 Tom Rini wrote:

> When running depmod to check for the correct version number, extra
> output we don't need to see, such as "depmod: QM_MODULES: Function not
> implemented" may show up.  Redirect stderr to /dev/null as the version
> information that we do care about comes to stdout.
> 
> Signed-off-by: Tom Rini <[EMAIL PROTECTED]>
> 
> diff --git a/Makefile b/Makefile
> --- a/Makefile
> +++ b/Makefile
> @@ -875,7 +875,7 @@ modules_install: _modinst_ _modinst_post
>  
>  .PHONY: _modinst_
>  _modinst_:
> - @if [ -z "`$(DEPMOD) -V | grep module-init-tools`" ]; then \
> + @if [ -z "`$(DEPMOD) -V 2>/dev/null | grep module-init-tools`" ]; then \
>   echo "Warning: you may need to install module-init-tools"; \
>   echo "See 
> http://www.codemonkey.org.uk/docs/post-halloween-2.6.txt";\
>   sleep 1; \

Well, seeing "QM_MODULES" is a great indicator that someone is using
modutils instead of module-init-tools, so I'd like to see it stay.
IOW, I somewhat disagree with "extra output we don't need to see."

---
~Randy
-
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://www.tux.org/lkml/

RE: 2.6.9 chrdev_open: serial_core: uart_open

[karl malbrain]

> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 1:59 PM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote:
> > On my 2.6.9-11EL source it clearly shows the up(_sem) after
> the call to
> > uart_open. Init_dev never touches tty_sem.
>
> In which case, I have to say...
>
> Congratulations!  You've found a bug with Red Hat's Enterprise Linux
> kernel!  Go straight to Red Hat's bugzilla!  Do not collect 200$.  Do
> not pass go.
>
> Seriously though, this bug is not present in mainline kernels, so I
> can't resolve this issue for you.  Mainline kernels appear to work
> properly.

Could tty_io.c be all that changed by a small set of red-hat patches to
2.6.9?  Why would they need to go in there to make so many changes in the
first place?  Which 2.6 release changed tty_io.c's use of tty_sem so
heavily?

This conflict between main-line/redhat looks much worse than the unix sysV
r4.0 divergence after 3.2. Ouch.

Thanks for your help, though.  karl m



-
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://www.tux.org/lkml/

Re: 2.6.9 chrdev_open: serial_core: uart_open

[Russell King]

On Fri, Jul 15, 2005 at 01:52:15PM -0700, karl malbrain wrote:
> On my 2.6.9-11EL source it clearly shows the up(_sem) after the call to
> uart_open. Init_dev never touches tty_sem.

In which case, I have to say...

Congratulations!  You've found a bug with Red Hat's Enterprise Linux
kernel!  Go straight to Red Hat's bugzilla!  Do not collect 200$.  Do
not pass go.

Seriously though, this bug is not present in mainline kernels, so I
can't resolve this issue for you.  Mainline kernels appear to work
properly.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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://www.tux.org/lkml/

[patch] fix EFI memory map parsing for x86

[Matt Tolentino]

The memory descriptors that comprise the EFI memory map are
not fixed in stone such that the size could change in the 
future.  This uses the memory descriptor size obtained from
EFI to iterate over the memory map entries during boot. 
This enables the removal of an x86 specific pad (and ifdef) in
the EFI header.  I also couldn't stomach the broken up nature
of the function to put EFI runtime calls into virtual mode any 
longer so I fixed that up a bit as well.

For reference, this patch only impacts x86.

 arch/i386/kernel/efi.c   |  101 +++
 arch/i386/kernel/setup.c |   14 --
 arch/i386/mm/init.c  |5 +-
 include/asm-i386/setup.h |2 
 include/linux/efi.h  |   14 +-
 5 files changed, 67 insertions(+), 69 deletions(-)

Signed-off-by: Matt Tolentino <[EMAIL PROTECTED]>
---

diff -urNp linux-2.6.13-rc3/arch/i386/kernel/efi.c 
linux-2.6.13-rc3-efi/arch/i386/kernel/efi.c
--- linux-2.6.13-rc3/arch/i386/kernel/efi.c 2005-07-15 11:30:30.0 
-0400
+++ linux-2.6.13-rc3-efi/arch/i386/kernel/efi.c 2005-07-15 12:08:55.0 
-0400
@@ -233,22 +233,23 @@ void __init efi_map_memmap(void)
 {
memmap.map = NULL;
 
-   memmap.map = (efi_memory_desc_t *)
-   bt_ioremap((unsigned long) memmap.phys_map,
-   (memmap.nr_map * sizeof(efi_memory_desc_t)));
-
+   memmap.map = bt_ioremap((unsigned long) memmap.phys_map,
+   (memmap.nr_map * memmap.desc_size));
if (memmap.map == NULL)
printk(KERN_ERR PFX "Could not remap the EFI memmap!\n");
+
+   memmap.map_end = memmap.map + (memmap.nr_map * memmap.desc_size);
 }
 
 #if EFI_DEBUG
 static void __init print_efi_memmap(void)
 {
efi_memory_desc_t *md;
+   void *p;
int i;
 
-   for (i = 0; i < memmap.nr_map; i++) {
-   md = [i];
+   for (p = memmap.map, i = 0; p < memmap.map_end; p += memmap.desc_size, 
i++) {
+   md = p;
printk(KERN_INFO "mem%02u: type=%u, attr=0x%llx, "
"range=[0x%016llx-0x%016llx) (%lluMB)\n",
i, md->type, md->attribute, md->phys_addr,
@@ -271,10 +272,10 @@ void efi_memmap_walk(efi_freemem_callbac
} prev, curr;
efi_memory_desc_t *md;
unsigned long start, end;
-   int i;
+   void *p;
 
-   for (i = 0; i < memmap.nr_map; i++) {
-   md = [i];
+   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+   md = p;
 
if ((md->num_pages == 0) || (!is_available_memory(md)))
continue;
@@ -325,6 +326,7 @@ void __init efi_init(void)
memmap.phys_map = EFI_MEMMAP;
memmap.nr_map = EFI_MEMMAP_SIZE/EFI_MEMDESC_SIZE;
memmap.desc_version = EFI_MEMDESC_VERSION;
+   memmap.desc_size = EFI_MEMDESC_SIZE;
 
efi.systab = (efi_system_table_t *)
boot_ioremap((unsigned long) efi_phys.systab,
@@ -431,22 +433,30 @@ void __init efi_init(void)
printk(KERN_ERR PFX "Could not map the runtime service 
table!\n");
 
/* Map the EFI memory map for use until paging_init() */
-
-   memmap.map = (efi_memory_desc_t *)
-   boot_ioremap((unsigned long) EFI_MEMMAP, EFI_MEMMAP_SIZE);
-
+   memmap.map = boot_ioremap((unsigned long) EFI_MEMMAP, EFI_MEMMAP_SIZE);
if (memmap.map == NULL)
printk(KERN_ERR PFX "Could not map the EFI memory map!\n");
 
-   if (EFI_MEMDESC_SIZE != sizeof(efi_memory_desc_t)) {
-   printk(KERN_WARNING PFX "Warning! Kernel-defined memdesc 
doesn't "
-  "match the one from EFI!\n");
-   }
+   memmap.map_end = memmap.map + (memmap.nr_map * memmap.desc_size);
+
 #if EFI_DEBUG
print_efi_memmap();
 #endif
 }
 
+static inline void __init check_range_for_systab(efi_memory_desc_t *md)
+{
+   if (((unsigned long)md->phys_addr <= (unsigned long)efi_phys.systab) &&
+   ((unsigned long)efi_phys.systab < md->phys_addr +
+   ((unsigned long)md->num_pages << EFI_PAGE_SHIFT))) {
+   unsigned long addr;
+
+   addr = md->virt_addr - md->phys_addr + 
+   (unsigned long)efi_phys.systab;
+   efi.systab = (efi_system_table_t *)addr;
+   }
+}
+
 /*
  * This function will switch the EFI runtime services to virtual mode.
  * Essentially, look through the EFI memmap and map every region that
@@ -460,43 +470,32 @@ void __init efi_enter_virtual_mode(void)
 {
efi_memory_desc_t *md;
efi_status_t status;
-   int i;
+   void *p;
 
efi.systab = NULL;
 
-   for (i = 0; i < memmap.nr_map; i++) {
-   md = [i];
+   for (p = memmap.map; p < memmap.map_end; p += memmap.desc_size) {
+   md = p;
 
-   if (md->attribute & EFI_MEMORY_RUNTIME) {
-   md->virt_addr =
- 

RE: 2.6.9 chrdev_open: serial_core: uart_open

[karl malbrain]

> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 1:31 PM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Fri, Jul 15, 2005 at 01:11:33PM -0700, karl malbrain wrote:
> > > -Original Message-
> > > From: Russell King
> > > Sent: Friday, July 15, 2005 12:23 AM
> > > To: karl malbrain
> > > Cc: [EMAIL PROTECTED] Kernel. Org
> > > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
> > >
> > >
> > > On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote:
> > > > chrdev_open issues a lock_kernel() before calling uart_open.
> > > >
> > > > It would appear that servicing the blocking open request
> > > uart_open goes to
> > > > sleep with the kernel locked.  Would this shut down
> subsequent access to
> > > > opening "/dev/tty"???
> > >
> > > No.  lock_kernel() is automatically released when a process sleeps.
> >
> > Drilling down between the uart_open and chrdev_open into tty_open is a
> > semaphore tty_sem that is being held during the sleep cycle in
> uart_open.
>
> chrdev_open() calls tty_open(), which then calls init_dev().  init_dev()
> takes tty_sem, does its stuff, and then releases tty_sem.  A little
> later on, tty_open() calls the uart driver's uart_open() function.
>
> So it does this with tty_sem unlocked.

On my 2.6.9-11EL source it clearly shows the up(_sem) after the call to
uart_open. Init_dev never touches tty_sem.

karl m



-
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://www.tux.org/lkml/

Re: 2.6.9: serial_core: uart_open

[karl malbrain]

- Original Message - 
From: "Russell King" <[EMAIL PROTECTED]>
To: "karl malbrain" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED] Kernel. Org" 
Sent: Friday, July 15, 2005 1:32 PM
Subject: Re: 2.6.9: serial_core: uart_open


> On Fri, Jul 15, 2005 at 09:02:48AM -0700, karl malbrain wrote:
> > > -Original Message-
> > > From: Russell King
> > > Sent: Friday, July 15, 2005 12:29 AM
> > > To: karl malbrain
> > > Cc: [EMAIL PROTECTED] Kernel. Org
> > > Subject: Re: 2.6.9: serial_core: uart_open
> > >
> > >
> > > On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> > > > AT LAST I HAVE SOME DATA!!!
> > > >
> > > > The problem is that ALL SYSTEM CALLS to open "/dev/tty" are
> > > blocking!! even
> > > > with O_NDELAY set and even from completely disjoint sessions.
> > > I discovered
> > > > this via issuing "strace sh".  That's why the new xterm windows
froze.
> > > >
> > > > The original process doing the open("/dev/ttyS1", O_RDWR) is
> > > listed in the
> > > > ps aux listing as status S+.
> > >
> > > Ok, 'S' means it's sleeping.
> > >
> > > Can you enable Magic SYSRQ, and ensure that you have a large kernel
> > > log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
> > > /proc/sys/kernel/sysrq is 1, and re-run your test such that you have
> > > something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.
> > >
> > > You can then read the kernel messages with dmesg - you may need the
> > > -s argument to capture the entire kernel buffer.
> > >
> > > This will tell us where all processes are sleeping.
> >
> >
> >  shD 0006  3036  5341   5252 (NOTLB)
> > d0408eb0 0086 c01c14d7 0006 d0408e94 000f4fa5 c0d38f81 39a0
> >df461240 df4613cc c035ff00 0246 d0408ecc df461240 c0300e33
> > 0001
> >df461240 c011c856 c035ff20 c035ff20 d0408000 0001 c035abe0
> > d0408000
> > Call Trace:
> >  [] inode_has_perm+0x4c/0x54
> >  [] __down+0x103/0x1fe
> >  [] default_wake_function+0x0/0xc
> >  [] __down_failed+0x8/0xc
> >  [] .text.lock.tty_io+0x87/0x10f
> >  [] chrdev_open+0x325/0x3b9
>
> This seems to imply that there's a lock being taken in tty_open().  The
> 2.6.9 source contains no such thing.  Are you sure you're using an
> unpatched 2.6.9 kernel?
>
> >  [] dentry_open+0xbd/0x180
> >  [] filp_open+0x36/0x3c
> >  [] direct_strncpy_from_user+0x46/0x5d
> >  [] sys_open+0x31/0x7d
> >  [] syscall_call+0x7/0xb
>

The system is red-hat 4.6.9-11EL.  There is a patch to tty_io but it doesn't
mention locking anything.  karl m



-
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://www.tux.org/lkml/

Re: [2.6 patch] sparc: remove the useless APM_RTC_IS_GMT option

[Tom 'spot' Callaway]

On Fri, 2005-07-15 at 22:36 +0200, Adrian Bunk wrote:
> I can't see any effect of this option outside the i386-specific APM 
> code.

Doesn't the Javastation potentially use this?

~spot
-- 
Tom "spot" Callaway: Red Hat Senior Sales Engineer || GPG ID: 93054260
Fedora Extras Steering Committee Member (RPM Standards and Practices)
Aurora Linux Project Leader: http://auroralinux.org
Lemurs, llamas, and sparcs, oh my!

-
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://www.tux.org/lkml/

Re: serial: 8250 fails to detect Exar XR16L2551 correctly

[Alex Williamson]

On Thu, 2005-07-14 at 14:46 +0100, Russell King wrote:

> Then we try to register the console, which may result in this UART
> becoming a console.  So now we have a console which is in low power
> mode.  Bad bad bad.  No cookie for the serial layer today.

   I don't know if this is a possible short term option, but the code
David proposes would work fine on the A2 rev ST16C255x parts as long as
UART_CAP_SLEEP in not included in the list of capabilities.  The check
for the A2 part would not be needed (esp. since it doesn't work).  When
the console detection code is fixed up, this flag could be included, and
I'd be happy to test it.  This would at least give us both usable UARTs
until we can work out the other kinks.  Thanks,

Alex

-- 
Alex Williamson HP Linux & Open Source Lab

-
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://www.tux.org/lkml/

[2.6 patch] Documentation/Changes: document the required udev version

[Adrian Bunk]

Document that udev 058 is required.

A similar patch (that no longger applies due to unrelated context 
changes) was sent by Jesper Juhl.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 8 Jul 2005
- 2 Jul 2005

--- linux-2.6.13-rc1-mm1-full/Documentation/Changes.old 2005-07-02 
12:41:09.0 +0200
+++ linux-2.6.13-rc1-mm1-full/Documentation/Changes 2005-07-02 
12:41:42.0 +0200
@@ -66,6 +66,7 @@
 o  nfs-utils  1.0.5   # showmount --version
 o  procps 3.2.0   # ps --version
 o  oprofile   0.9 # oprofiled --version
+o  udev   058 # udevinfo -V
 
 Kernel compilation
 ==

-
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://www.tux.org/lkml/

[2.6 patch] sparc: remove the useless APM_RTC_IS_GMT option

[Adrian Bunk]

I can't see any effect of this option outside the i386-specific APM 
code.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

This patch was already sent on:
- 2 Jul 2005

--- linux-2.6.13-rc1-mm1-full/drivers/sbus/char/Kconfig.old 2005-07-02 
20:24:49.0 +0200
+++ linux-2.6.13-rc1-mm1-full/drivers/sbus/char/Kconfig 2005-07-02 
20:25:20.0 +0200
@@ -71,20 +71,6 @@
 
 # XXX Why don't we do "source drivers/char/Config.in" somewhere?
 # no shit
-config APM_RTC_IS_GMT
-   bool
-   depends on EXPERIMENTAL && SPARC32 && PCI
-   default y
-   help
- Say Y here if your RTC (Real Time Clock a.k.a. hardware clock)
- stores the time in GMT (Greenwich Mean Time). Say N if your RTC
- stores localtime.
-
- It is in fact recommended to store GMT in your RTC, because then you
- don't have to worry about daylight savings time changes. The only
- reason not to use GMT in your RTC is if you also run a broken OS
- that doesn't understand GMT.
-
 config RTC
tristate "PC-style Real Time Clock Support"
depends on PCI && EXPERIMENTAL && SPARC32

-
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://www.tux.org/lkml/

Re: 2.6.9: serial_core: uart_open

[Russell King]

On Fri, Jul 15, 2005 at 09:02:48AM -0700, karl malbrain wrote:
> > -Original Message-
> > From: Russell King
> > Sent: Friday, July 15, 2005 12:29 AM
> > To: karl malbrain
> > Cc: [EMAIL PROTECTED] Kernel. Org
> > Subject: Re: 2.6.9: serial_core: uart_open
> >
> >
> > On Thu, Jul 14, 2005 at 03:35:07PM -0700, karl malbrain wrote:
> > > AT LAST I HAVE SOME DATA!!!
> > >
> > > The problem is that ALL SYSTEM CALLS to open "/dev/tty" are
> > blocking!! even
> > > with O_NDELAY set and even from completely disjoint sessions.
> > I discovered
> > > this via issuing "strace sh".  That's why the new xterm windows froze.
> > >
> > > The original process doing the open("/dev/ttyS1", O_RDWR) is
> > listed in the
> > > ps aux listing as status S+.
> >
> > Ok, 'S' means it's sleeping.
> >
> > Can you enable Magic SYSRQ, and ensure that you have a large kernel
> > log buffer (the LOG_BUF_SHIFT configuration symbol).  Ensure that
> > /proc/sys/kernel/sysrq is 1, and re-run your test such that you have
> > something else waiting (eg, the strace sh).  Then hit Alt-SysRQ-T.
> >
> > You can then read the kernel messages with dmesg - you may need the
> > -s argument to capture the entire kernel buffer.
> >
> > This will tell us where all processes are sleeping.
> 
> 
>  shD 0006  3036  5341   5252 (NOTLB)
> d0408eb0 0086 c01c14d7 0006 d0408e94 000f4fa5 c0d38f81 39a0
>df461240 df4613cc c035ff00 0246 d0408ecc df461240 c0300e33
> 0001
>df461240 c011c856 c035ff20 c035ff20 d0408000 0001 c035abe0
> d0408000
> Call Trace:
>  [] inode_has_perm+0x4c/0x54
>  [] __down+0x103/0x1fe
>  [] default_wake_function+0x0/0xc
>  [] __down_failed+0x8/0xc
>  [] .text.lock.tty_io+0x87/0x10f
>  [] chrdev_open+0x325/0x3b9

This seems to imply that there's a lock being taken in tty_open().  The
2.6.9 source contains no such thing.  Are you sure you're using an
unpatched 2.6.9 kernel?

>  [] dentry_open+0xbd/0x180
>  [] filp_open+0x36/0x3c
>  [] direct_strncpy_from_user+0x46/0x5d
>  [] sys_open+0x31/0x7d
>  [] syscall_call+0x7/0xb

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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://www.tux.org/lkml/

Re: 2.6.9 chrdev_open: serial_core: uart_open

[Russell King]

On Fri, Jul 15, 2005 at 01:11:33PM -0700, karl malbrain wrote:
> > -Original Message-
> > From: Russell King
> > Sent: Friday, July 15, 2005 12:23 AM
> > To: karl malbrain
> > Cc: [EMAIL PROTECTED] Kernel. Org
> > Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
> >
> >
> > On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote:
> > > chrdev_open issues a lock_kernel() before calling uart_open.
> > >
> > > It would appear that servicing the blocking open request
> > uart_open goes to
> > > sleep with the kernel locked.  Would this shut down subsequent access to
> > > opening "/dev/tty"???
> >
> > No.  lock_kernel() is automatically released when a process sleeps.
> 
> Drilling down between the uart_open and chrdev_open into tty_open is a
> semaphore tty_sem that is being held during the sleep cycle in uart_open.

chrdev_open() calls tty_open(), which then calls init_dev().  init_dev()
takes tty_sem, does its stuff, and then releases tty_sem.  A little
later on, tty_open() calls the uart driver's uart_open() function.

So it does this with tty_sem unlocked.

> N.b. I don't pretend to understand how uart_change_pm, uart_startup, and
> uart_block_til_ready could ALL be on the call stack.  Uart_open calls them
> sequentially.  Perhaps you might explain how this works?  Thanks, karl m

The stack traces on x86 are very hap-hazard - the code just scans the
stack for anything which looks like it may be in kernel text and dumps
the result.  This means that stale words on the stack which may have
been return addresses at one time may still look like return addresses.

Don't believe everything you see in an x86 stacktrace!

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core
-
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://www.tux.org/lkml/

Re: [PATCH] MMC host class

[Pierre Ossman]

Russell King wrote:

>The allocation function should initialise class_dev as much as possible.
>The registration function should add the class device with the class
>model.  The unregistration should remove the class device from the class
>model, but _not_ free it.  The free function should drop the last
>reference to the class device, which results in the remove function
>(eventually) being called.  Finally, the remove function can free the
>mmc_host.
>  
>

New patch according to above system. I've moved the naming a bit earlier
to avoid having a nameless kobj floating around.

>Also note that since we have a class_dev, the mmc_host 'dev' field can
>be removed.  However, we'll probably have to update the host drivers
>to do this, so it should be a separate patch.
>
>  
>

I believe there's a bit of abstraction to be gained from not poking
around inside the class_dev struct in too many places. It's not like
we're wasting any large amounts of memory.

Rgds
Pierre

Index: linux-wbsd/drivers/mmc/mmc.h
===
--- linux-wbsd/drivers/mmc/mmc.h	(revision 134)
+++ linux-wbsd/drivers/mmc/mmc.h	(working copy)
@@ -13,4 +13,7 @@
 void mmc_init_card(struct mmc_card *card, struct mmc_host *host);
 int mmc_register_card(struct mmc_card *card);
 void mmc_remove_card(struct mmc_card *card);
+void mmc_init_host(struct mmc_host *host);
+int mmc_register_host(struct mmc_host *host);
+void mmc_unregister_host(struct mmc_host *host);
 #endif
Index: linux-wbsd/drivers/mmc/mmc_sysfs.c
===
--- linux-wbsd/drivers/mmc/mmc_sysfs.c	(revision 153)
+++ linux-wbsd/drivers/mmc/mmc_sysfs.c	(working copy)
@@ -20,6 +20,7 @@
 
 #define dev_to_mmc_card(d)	container_of(d, struct mmc_card, dev)
 #define to_mmc_driver(d)	container_of(d, struct mmc_driver, drv)
+#define cls_dev_to_mmc_host(d)	container_of(d, struct mmc_host, class_dev)
 
 #define MMC_ATTR(name, fmt, args...)	\
 static ssize_t mmc_##name##_show (struct device *dev, char *buf)	\
@@ -224,14 +225,64 @@
 	put_device(>dev);
 }
 
+static void mmc_host_class_dev_release(struct class_device *dev)
+{
+	struct mmc_host *host = cls_dev_to_mmc_host(dev);
+	kfree(host);
+}
+
+static struct class mmc_host_class = {
+	.name =		"mmc_host",
+	.release =	_host_class_dev_release,
+};
+
+void mmc_init_host(struct mmc_host *host)
+{
+	static unsigned int host_num;
+
+	snprintf(host->host_name, sizeof(host->host_name),
+		 "mmc%d", host_num++);
+
+	host->class_dev.dev = host->dev;
+	host->class_dev.class = _host_class;
+	strlcpy(host->class_dev.class_id, host->host_name, BUS_ID_SIZE);
+	
+	class_device_initialize(>class_dev);
+	class_device_get(>class_dev);
+}
+
+/*
+ * Internal function. Register a new MMC host with the MMC class.
+ */
+int mmc_register_host(struct mmc_host *host)
+{
+	return class_device_add(>class_dev);
+}
+
+/*
+ * Internal function. Unregister a MMC host with the MMC class.
+ */
+void mmc_unregister_host(struct mmc_host *host)
+{
+	class_device_unregister(>class_dev);
+}
 
 static int __init mmc_init(void)
 {
-	return bus_register(_bus_type);
+	int retval;
+	
+	retval = bus_register(_bus_type);
+	if (retval)
+		return retval;
+	retval = class_register(_host_class);
+	if (retval)
+		return retval;
+	return 0;
 }
 
 static void __exit mmc_exit(void)
 {
+	class_unregister(_host_class);
 	bus_unregister(_bus_type);
 }
 
Index: linux-wbsd/drivers/mmc/mmc.c
===
--- linux-wbsd/drivers/mmc/mmc.c	(revision 153)
+++ linux-wbsd/drivers/mmc/mmc.c	(working copy)
@@ -1178,6 +1178,8 @@
 		host->max_phys_segs = 1;
 		host->max_sectors = 1 << (PAGE_CACHE_SHIFT - 9);
 		host->max_seg_size = PAGE_CACHE_SIZE;
+		
+		mmc_init_host(host);
 	}
 
 	return host;
@@ -1191,10 +1193,7 @@
  */
 int mmc_add_host(struct mmc_host *host)
 {
-	static unsigned int host_num;
-
-	snprintf(host->host_name, sizeof(host->host_name),
-		 "mmc%d", host_num++);
+	mmc_register_host(host);
 
 	mmc_power_off(host);
 	mmc_detect_change(host);
@@ -1222,6 +1221,8 @@
 	}
 
 	mmc_power_off(host);
+	
+	mmc_unregister_host(host);
 }
 
 EXPORT_SYMBOL(mmc_remove_host);
@@ -1235,7 +1236,8 @@
 void mmc_free_host(struct mmc_host *host)
 {
 	flush_scheduled_work();
-	kfree(host);
+	
+	class_device_put(>class_dev);
 }
 
 EXPORT_SYMBOL(mmc_free_host);
Index: linux-wbsd/include/linux/mmc/host.h
===
--- linux-wbsd/include/linux/mmc/host.h	(revision 153)
+++ linux-wbsd/include/linux/mmc/host.h	(working copy)
@@ -69,6 +69,7 @@
 
 struct mmc_host {
 	struct device		*dev;
+	struct class_device	class_dev;
 	struct mmc_host_ops	*ops;
 	unsigned int		f_min;
 	unsigned int		f_max;

Re: 2.6.13-rc3-mm1 (ckrm)

[Andrew Morton]

Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
> On Fri, Jul 15, 2005 at 01:36:53AM -0700, Andrew Morton wrote:
> > 
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.13-rc3/2.6.13-rc3-mm1/
> > 
> > (http://www.zip.com.au/~akpm/linux/patches/stuff/2.6.13-rc3-mm1.gz until
> > kernel.org syncs up)
> > 
> > 
> > - Added the CKRM patches.  This is just here for people to look at at this
> >   stage.
> 
> Andrew, do we really need to add every piece of crap lying on the street
> to -mm?  It's far away from mainline enough already without adding obviously
> unmergeable stuff like this.

My gut reaction to ckrm is the same as yours.  But there's been a lot of
work put into this and if we're to flatly reject the feature then the
developers are owed a much better reason than "eww yuk".

Otherwise, if there are certain specific problems in the code then it's
best that they be pointed out now rather than later on.

What, in your opinion, makes it "obviously unmregeable"?
-
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://www.tux.org/lkml/

Re: [PATCH] add rlimit file to /proc/PID

[Francois Romieu]

dierbro <[EMAIL PROTECTED]> :
[...]
> with a friend i have made this patch that add rlimit file to /proc/PID
> directory.
> Trought this file you can set and get rlimit of a running process.

I am not sure that new proc-functions will be welcome, anyway...

[...]
> --- linux-2.6.13-rc3/fs/proc/base.c   2005-07-15 20:57:25.0 +0200
> +++ linux-2.6.13-rc3/fs/proc/base.c.rlimit2005-07-15 20:57:05.0 
> +0200
> +static int rlimit_read(struct file * file, char __user * buf,
> + size_t count, loff_t *ppos)
> +{
> + struct task_struct *task = proc_task(file->f_dentry->d_inode);
> + int res = 0, i;
> + unsigned long len;
> + char buffer[2048];

Ahem...

> + if(task){
> + 
> + for(i=0; i + switch(i){
> + case RLIMIT_AS:
> + len = sprintf(buffer+res, "RLIMIT_AS %d 
> %d\n",
> + (int) 
> task->signal->rlim[i].rlim_cur,
> + 
> (int)task->signal->rlim[i].rlim_max);
> + res+=len;
> + break;
[generous code duplication deleted]

You want an initialized array for the strings "RLIMIT_AS", "RLIMIT_CORE", etc.

[...]
> +static ssize_t rlimit_write(struct file * file, const char * buffer,
> +  size_t count, loff_t *ppos)
> +{
> + struct task_struct *task = proc_task(file->f_dentry->d_inode);
> + unsigned long cur,max;
> + char *c;
> + char *endptr;
> + char *buf=NULL;

Unneeded initialization

[...]
> + if( (buf=kmalloc(GFP_KERNEL,count))==NULL){

GFP_XXX must be the second arg.

> + return  -ENOMEM;
> + }
> +
> + memcpy(buf,buffer,count); 
> +
> + 
> + c=strchr(buf,' ');
> + if(!c) goto out_err;

CodingStyle (the whole patch is terrible).

> + 
> + *c='\0';
> + int resource=-1;
> + 
> + if(strcmp("RLIMIT_AS",buf)==0)
> + resource=RLIMIT_AS;
> + else if(strcmp("RLIMIT_CORE",buf)==0)
> + resource=RLIMIT_CORE;
> + else if(strcmp("RLIMIT_CPU",buf)==0)
> + resource=RLIMIT_CPU;
[...]

More code duplication. Use a loop instead.

[...]
> + out_err:
> + kfree(buf);
> + return EINVAL;

-EINVAL

--
Ueimor
-
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://www.tux.org/lkml/

RE: 2.6.9 chrdev_open: serial_core: uart_open

[karl malbrain]

> -Original Message-
> From: Russell King
> Sent: Friday, July 15, 2005 12:23 AM
> To: karl malbrain
> Cc: [EMAIL PROTECTED] Kernel. Org
> Subject: Re: 2.6.9 chrdev_open: serial_core: uart_open
>
>
> On Thu, Jul 14, 2005 at 04:50:00PM -0700, karl malbrain wrote:
> > chrdev_open issues a lock_kernel() before calling uart_open.
> >
> > It would appear that servicing the blocking open request
> uart_open goes to
> > sleep with the kernel locked.  Would this shut down subsequent access to
> > opening "/dev/tty"???
>
> No.  lock_kernel() is automatically released when a process sleeps.

Drilling down between the uart_open and chrdev_open into tty_open is a
semaphore tty_sem that is being held during the sleep cycle in uart_open.

This would appear to be the problem!!  Is this a new semaphore in 2.6? How
could this have ever worked with tty blocking mode?  It would appear that
tty_sem is going to have to be released before sleeping in uart_open.  What
a mess.

N.b. I don't pretend to understand how uart_change_pm, uart_startup, and
uart_block_til_ready could ALL be on the call stack.  Uart_open calls them
sequentially.  Perhaps you might explain how this works?  Thanks, karl m



-
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://www.tux.org/lkml/

Re: [patch] inotify: add x86-64 syscall numbers

[Robert Love]

On Fri, 2005-07-15 at 22:01 +0200, Andi Kleen wrote:

> It won't work anyways because you forgot to patch the compat 
> sys32_open.

Well, "won't work" is a bit harsh, its just one hook.  But that was
next.

I usually leave per-arch stuff to the arch folks.

Robert Love


Add fsnotify_open() hook to sys32_open() on x86-64.

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 arch/x86_64/ia32/sys_ia32.c |5 -
 1 files changed, 4 insertions(+), 1 deletion(-)

diff -urN linux-2.6.13-rc3/arch/x86_64/ia32/sys_ia32.c 
linux/arch/x86_64/ia32/sys_ia32.c
--- linux-2.6.13-rc3/arch/x86_64/ia32/sys_ia32.c2005-07-15 
16:08:27.0 -0400
+++ linux/arch/x86_64/ia32/sys_ia32.c   2005-07-15 16:07:21.0 -0400
@@ -61,6 +61,7 @@
 #include 
 #include 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -984,8 +985,10 @@
if (IS_ERR(f)) {
put_unused_fd(fd); 
fd = error;
-   } else
+   } else {
+   fsnotify_open(f->f_dentry);
fd_install(fd, f);
+   }
}
putname(tmp);
}


-
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://www.tux.org/lkml/

Re: [rfc patch 2/2] direct-io: remove address alignment check

[Daniel McNeil]

On Thu, 2005-07-14 at 22:27, Badari Pulavarty wrote:
> Daniel McNeil wrote:
> 
> > On Thu, 2005-07-14 at 16:16, Badari Pulavarty wrote:
> > 
> >>How does your patch ensures that we meet the driver alignment
> >>restrictions ? Like you said, you need atleast "even" byte alignment
> >>for IDE etc..
> >>
> >>And also, are there any restrictions on how much the "minimum" IO
> >>size has to be ? I mean, can I read "1" byte ? I guess you are
> >>not relaxing it (yet)..
> >>
> > 
> > 
> > This patch does not change the i/o size requirements -- they
> > must be a multiple of device block size (usually 512).
> > 
> > It only relaxes the address alignment restriction.  I do not
> > know what the driver alignment restrictions are.  Without the
> > 1st patch, it was impossible to relax the address space
> > check and have direct-io generate the correct i/o's to submit.
> > 
> > This 2nd patch, is just for testing and generating feedback
> > to find out what the address alignment issues are.  Then
> > we can decide how to proceed.
> > 
> > Did you look over the 1st patch?  Comments?
> 
> Yes. I did look at the first patch and my questions were basically
> towards the first patch. I don't see any enforcement of alignment
> with your patch at all. So, we let the driver fail if it can't
> handle it ?
> 

The 1st patch re-writes direct-io to handle non-512 aligned
addresses.  Without the 2nd patch, it will never see non-512
aligned user address and should work the same as before only
with slightly smaller code :).  The drivers will get the
same 512-byte aligned addresses.  Am I missing something?

> BTW, I don't think the first patch is really doing the right thing.
> You got little carried away while cleaning up.
> You are trying to relax "user buffer" alignment only. If your
> "offset" is in the middle of a filesystem block (say 4k), you still
> need to zero out the first portion to be able to write into the
> middle. That "evil" code is still needed. :(
> 

The code still does zero out the 1st portion.  dio_zero_block()
is being called twice still.  Sure looks like it is working to
me:

Test program d.c:

#define _GNU_SOURCE 1


#include 
#include 
#include 
#include 
#include 
#include 

main()
{
int fd;
char *buf;
int io_size = 512;
off_t skip = 512;
int i;

if (posix_memalign((void *), getpagesize(), io_size) != 0) {
perror("cannot alloc mem");
exit(1);
}

memset(buf, 'a', io_size);

fd = open("direct_test_file", O_RDWR|O_DIRECT|O_TRUNC|O_CREAT, 0666);

lseek(fd, skip, SEEK_SET);
if ((i = write(fd, buf, io_size)) != io_size) {
perror("bad write");
exit(2);
}

printf("write to direct_test_file %d bytes of 'a' at %d\n", i, skip);
memset(buf, 'b', io_size);
lseek(fd, getpagesize(), SEEK_SET);
if ((i = write(fd, buf, io_size)) != io_size) {
perror("bad write");
exit(2);
}
printf("write to direct_test_file %d bytes of 'b' at %d\n", i, 
getpagesize());
}
--

$ ./d
write to direct_test_file 512 bytes of 'a' at 512
write to direct_test_file 512 bytes of 'b' at 4096

$ hexdump direct_test_file
000        
*
200 6161 6161 6161 6161 6161 6161 6161 6161
*
400        
*
0001000 6262 6262 6262 6262 6262 6262 6262 6262
*
0001200

The 1st 512 bytes are zeroed as well as the bytes between
1k and 4k.

Thanks,
Daniel

-
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://www.tux.org/lkml/

Re: [patch] inotify: add x86-64 syscall numbers

[Andi Kleen]

Robert Love <[EMAIL PROTECTED]> writes:

> Andi,
> 
> Attached patch adds the inotify syscall numbers to x86-64.  Also adds
> the new ioprio_get() and ioprio_set() calls to the IA32 layer.

It won't work anyways because you forgot to patch the compat 
sys32_open.

-Andi
-
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://www.tux.org/lkml/

Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt

[Stephen Pollei]

On 7/14/05, Eric St-Laurent <[EMAIL PROTECTED]> wrote:
> On Thu, 2005-07-14 at 17:24 -0700, Linus Torvalds wrote:
> > Trust me. When I say that the right thing to do is to just have a fixed
> > (but high) HZ value, and just changing the timer rate, I'm -right-.

> Of course you are, jiffies are simple and efficient.

> If i sum-up the discussion from my POV:

> - use a 32-bit tick counter on 32-bit platforms and use a 64-bit counter
> on 64-bit platforms
If the 64bit counter doesn't have any overhead then sure.

> - keep the constant HZ=1000 (mS resolution) on 32-bit platforms
Which HZ Is that? CONFIG_JIFFIES_HZ or CONFIG_FIXED_PIT_HZ ?
I think you meant CONFIG_JIFFIES_HZ which I think for even 32bit
counters could go up to 1e4 to 5e4 , with some patching going on in
some places of course.

> - remove the assumption that timer interrupts and jiffies are 1:1 thing
> (jiffies may be incremented by >1 ticks at timer interrupt)
Yes maybe nuke CONFIG_HZ and replace it with CONFIG_JIFFIES_HZ and
CONFIG_(FIXED|DEFAULT|DYNAMIC)_PIT_HZ . Starting with just
CONFIG_FIXED_PIT_HZ, add others as needed.

Extreme might be to also just nuke HZ and replace it with JHZ and PHZ,
or whatever so that people are *crystal* clear about the difference.

> - determine jiffies_increment at boot
So CONFIG__PIT_HZ could be a per boot time thing maybe.
So you'd have CONFIG_DEFAULT_PIT_HZ if it was a per per boot or runtime thing.
CONFIG_DYNAMIC_PIT_HZ if it was changable as the system is running --
like windows.
CONFIG_FIXED_PIT_HZ if it is a compile time constant.
Or something like the that?

> - have a slow clock mode to help power management (adjust
> jiffies_increment by the slowdown factor)
CONFIG_DYNAMIC_PIT_HZ unless it's overhead is so low that everyone
just wants it by default.

> - it may be useful to bump up HZ to 1e6 (uS res.) or 1e9 (nS res.) on
> 64-bit platforms, if there are benefits such as better accuracy during
> time units conversions or if a higher frequency timer hardware is
> available/viable.
Too high starts to cause other troubles. I think that the real time
people want 10uS scheduling, but even the ipipe and rt-preempt has
18us-70uS delays at times IIRC. So 5e4 to 1e5 is about the extreme end
of the road for CONFIG_JIFFIES_HZ . I think even long term that 1e5 to
1e6 would be extreme because of speed of light issues, etc. Hpet is
only 1.4e7 IIRC.

I think that you should start with:
1) CONFIG_FIXED_PIT_HZ=50 CONFIG_JIFFIES_HZ=2000
2) try it out and fix any bugs, send the fixes to Linus to see if how
much he bitches.
3) if you still need CONFIG_JIFFIES_HZ to be larger, double it and then goto 2.
4) enjoy your higher frequency jiffies

I bet that even that going to somewhere between 2e3 through 1e5 will
make you want to change a few things for performance and sanity
reasons. So I'd focus on that before I even thought about 1e6 through
1e10 . Plus I think the interest level really fails off to go that
extreme.

Just making JIFFIES_HZ != PIT_HZ will require patches.
Dynamic pit hz or lazy update of jiffies based on tsc/hpet/other are
other patches.

> - it may be also useful to bump HZ on -RT (Real-time) kernels,
yes they sound like they want JIFFIES_HZ to be 1e3 through 1e5
depending on task. They also want hpet(or other), vertical retrace
interrupts(so xsync works for video), perhaps a nist mini atomic
clock, and a few other goodies AFAIK.
> -HRT (High-resolution timers support).
Yes tsc or hpet or whatever users might benefit in several ways.
1) both tsc and hpet might be able to bump up to a more accurate value
on entry to idle and then test to see if anything got scheduled.
2) hpet can set set one shot timers for the next up coming event on
idle if it's sooner than when the PIT interrupt is suppose to come in.
Of course update the jiffies when that hpet interrupt comes.

>Users of those kernel are willing
> to pay the cost of the overhead to have better resolution
Yes realtime users with something like hpet might not vary the pit
timer, but place hooks to update the jiffies between pit interrupts
like idle, scheduler(task switch), etc. And use the hpet one shot
interrupts as well.

> - avoid direct usage of the jiffies variable, instead use jiffies()
> (inline or MACRO), IMO monotonic_clock() would be a better name
I don't know I think it could remain a variable you usual just want it
to be a light-weight memory read not a call out to an hpet and then a
math conversion, or a call out to tsc that then has to known about if
the tsc represents work or time, and if the cpu has been slowed for
power save reasons etc etc etc. I think you want a symbol exported gpl
of something like void force_update_jiffies(void); that you can call
in different hook locations to force the update of jiffies from
non-interupt sources. Actually you might want more than one version of
that function or have it take an argument, becuase some people might
want to be super lazy and only update it when the enter or leave idle,
while 

[patch] inotify: add x86-64 syscall numbers

[Robert Love]

Andi,

Attached patch adds the inotify syscall numbers to x86-64.  Also adds
the new ioprio_get() and ioprio_set() calls to the IA32 layer.

Robert Love


Add the inotify syscalls to x86-64

Signed-off-by: Robert Love <[EMAIL PROTECTED]>

 arch/x86_64/ia32/ia32entry.S |8 ++--
 include/asm-x86_64/ia32_unistd.h |7 ++-
 include/asm-x86_64/unistd.h  |8 +++-
 3 files changed, 19 insertions(+), 4 deletions(-)

diff -urN linux-2.6.13-rc3/arch/x86_64/ia32/ia32entry.S 
linux/arch/x86_64/ia32/ia32entry.S
--- linux-2.6.13-rc3/arch/x86_64/ia32/ia32entry.S   2005-07-13 
10:51:10.0 -0400
+++ linux/arch/x86_64/ia32/ia32entry.S  2005-07-15 15:47:59.0 -0400
@@ -591,11 +591,15 @@
.quad compat_sys_mq_getsetattr
.quad compat_sys_kexec_load /* reserved for kexec */
.quad compat_sys_waitid
-   .quad quiet_ni_syscall  /* sys_altroot */
+   .quad quiet_ni_syscall  /* 285: sys_altroot */
.quad sys_add_key
.quad sys_request_key
.quad sys_keyctl
-   /* don't forget to change IA32_NR_syscalls */
+   .quad sys_ioprio_set
+   .quad sys_ioprio_get/* 290 */
+   .quad sys_inotify_init
+   .quad sys_inotify_add_watch
+   .quad sys_inotify_rm_watch
 ia32_syscall_end:  
.rept IA32_NR_syscalls-(ia32_syscall_end-ia32_sys_call_table)/8
.quad ni_syscall
diff -urN linux-2.6.13-rc3/include/asm-x86_64/ia32_unistd.h 
linux/include/asm-x86_64/ia32_unistd.h
--- linux-2.6.13-rc3/include/asm-x86_64/ia32_unistd.h   2005-07-13 
10:51:00.0 -0400
+++ linux/include/asm-x86_64/ia32_unistd.h  2005-07-15 15:48:50.0 
-0400
@@ -294,7 +294,12 @@
 #define __NR_ia32_add_key  286
 #define __NR_ia32_request_key  287
 #define __NR_ia32_keyctl   288
+#define __NR_ia32_ioprio_set   289
+#define __NR_ia32_ioprio_get   290
+#define __NR_ia32_inotify_init 291
+#define __NR_ia32_inotify_add_watch292
+#define __NR_ia32_inotify_rm_watch 293
 
-#define IA32_NR_syscalls 290   /* must be > than biggest syscall! */
+#define IA32_NR_syscalls 294   /* must be > than biggest syscall! */
 
 #endif /* _ASM_X86_64_IA32_UNISTD_H_ */
diff -urN linux-2.6.13-rc3/include/asm-x86_64/unistd.h 
linux/include/asm-x86_64/unistd.h
--- linux-2.6.13-rc3/include/asm-x86_64/unistd.h2005-07-13 
10:51:14.0 -0400
+++ linux/include/asm-x86_64/unistd.h   2005-07-15 15:49:37.0 -0400
@@ -565,8 +565,14 @@
 __SYSCALL(__NR_ioprio_set, sys_ioprio_set)
 #define __NR_ioprio_get252
 __SYSCALL(__NR_ioprio_get, sys_ioprio_get)
+#define __NR_inotify_init  253
+__SYSCALL(__NR_inotify_init, sys_inotify_init)
+#define __NR_inotify_add_watch 254
+__SYSCALL(__NR_inotify_add_watch, sys_inotify_add_watch)
+#define __NR_inotify_rm_watch  255
+__SYSCALL(__NR_inotify_rm_watch, sys_inotify_rm_watch)
 
-#define __NR_syscall_max __NR_ioprio_get
+#define __NR_syscall_max __NR_inotify_rm_watch
 #ifndef __NO_STUBS
 
 /* user-visible error numbers are in the range -1 - -4095 */


-
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://www.tux.org/lkml/

Module snd-intel8x0.ko broken in 2.6.12

[FyD]

Dear All,

I just compiled & install the kernels 2.6.12.2 & 2.6.12 & booted my laptop.

Here is the error message I get whatever the kernel 2.6.12 I use:
FATAL: Error inserting snd-intel8x0
(/lib/modules/2.6.12.2/kernel/sound/pci/snd-intel8x0.ko)
unknown symbol in module or unknown parameter (see dmesg)

Answer of dmesg:
vbug.c: Event. Dev: usb-:00:1d.1-2/input0, Type: 2, Code: 1, Value: 4
evbug.c: Event. Dev: usb-:00:1d.1-2/input0, Type: 0, Code: 0, Value: 0
evbug.c: Event. Dev: usb-:00:1d.1-2/input0, Type: 2, Code: 0, Value: -2
evbug.c: Event. Dev: usb-:00:1d.1-2/input0, Type: 2, Code: 1, Value: 4
[cut]
evbug.c: Event. Dev: isa0060/serio0/input0, Type: 1, Code: 34, Value: 0
evbug.c: Event. Dev: isa0060/serio0/input0, Type: 0, Code: 0, Value: 0
evbug.c: Event. Dev: isa0060/serio0/input0, Type: 4, Code: 4, Value: 28
evbug.c: Event. Dev: isa0060/serio0/input0, Type: 1, Code: 28, Value: 1
evbug.c: Event. Dev: isa0060/serio0/input0, Type: 0, Code: 0, Value: 0

Then, a window is automatically opened when I get in my login:
"No volume control elements and/or devices found."

Does it mean this module is broken in 2.6.12 ?
Indeed, I did not have this problem with 2.6.11.
What should I do to solve this _with 2.6.12_ since I do need 2.6.12 for
something else...?

Thanks, Regards, Francois

PS Please answer to my email address since I did not register...

-
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://www.tux.org/lkml/

Re: Kernel Bug Report

[Lee]

Hi,

> It should have been printed right after the output you posted.
>
> Anyway, the first step is to reproduce it with a non tainted kernel.


There was no call trace after what I saw.  No big deal.
I am now working to reproduce the error with a non tainted kernel.


-- 
Lee
[EMAIL PROTECTED]

 14:39:45 up  5:59,  0 users,  load average: 0.10, 0.08, 0.08
-
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://www.tux.org/lkml/

Re: Kernel Bug Report

[Lee Revell]

On Fri, 2005-07-15 at 14:24 -0500, Lee wrote:
> Hi,
> 
> > > [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> > > [20976.029194] Modules linked in: vmnet vmmon nvidia
> > > [20976.090907] CPU:695757158
> > > [20976.090909] EIP:0060:[]Tainted: P  VLI
> >
> > Please reproduce the bug without these proprietary modules loaded.  And
> > make sure to include the stack trace.
> 
> My current setup has the kernel and metalog logging to the serial port, which 
> I am monitoring using kermit rom another machine.
> 
> Would you mind explaining to me how to generate the strace track and/or how 
> to do "proper" debugging when this crash occurs?

It should have been printed right after the output you posted.

Anyway, the first step is to reproduce it with a non tainted kernel.

Lee

-
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://www.tux.org/lkml/

Re: [stable] Re: [05/11] SMP fix for 6pack driver

[Adrian Bunk]

On Wed, Jul 13, 2005 at 03:13:11PM -0700, Greg KH wrote:
> On Thu, Jul 14, 2005 at 12:01:23AM +0200, Francois Romieu wrote:
> > Greg KH <[EMAIL PROTECTED]> :
> > > -stable review patch.  If anyone has any objections, please let us know.
> > > 
> > > --
> > > 
> > > 
> > > Drivers really only work well in SMP if they actually can be selected.
> > > This is a leftover from the time when the 6pack drive only used to be
> > > a bitrotten variant of the slip driver.
> > 
> > Is the guideline above from 28/04/2005 obsoleted ?
> > 
> >  - It must fix a problem that causes a build error (but not for things
> >marked CONFIG_BROKEN), an oops, a hang, data corruption, a real
> >security issue, or some "oh, that's not good" issue.  In short,
> >something critical.
> 
> It lets the driver be built, when it previously could not be, unless the
> user used a config option that almost no one does...
> 
> That's pretty critical if you ask me.


I do agree with Francois regarding this issue:

AFAIR, there has been not one 2.6 kernel where this driver was available 
for SMP kernels. It's therefore untested which problems might arise with 
this driver on SMP systems. I'm not arguing against including this 
driver in 2.6.13, but 2.6.12.3 isn't the right place.


What surprises me most is that you accepted this patch is neither in 
2.6.13-rc3 nor in 2.6.13-rc3-mm1. There seems to be either an
(IMHO unfortunate) change in your policy of what patches to accept,
or there's a serious problem in your patch review process.


> thanks,
> 
> greg k-h

cu
Adrian

-- 

   "Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   "Only a promise," Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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://www.tux.org/lkml/

Re: Orinoco_plx woes on 2.6.13

[Nathan Mahon]

I got a suggestion that i needed to update firmware, along with a
suggestion to move to the hostap driver.
for what it's worth,  I'm pretty sure hostap won't work for this card.
it's listed under orinoco_cs at pcmcia-cs.sf.net, and hostap doesn't
like it:

hostap_crypt: registered algorithm 'NULL'
hostap_plx: 0.3.9 - 2005-06-10 (Jouni Malinen <[EMAIL PROTECTED]>)
PCI: Found IRQ 9 for device :00:0a.0
PLX9052 PCI/PCMCIA adapter: mem=0xdf001000, plx_io=0x2800, irq=9,
pccard_io=0x2c00
hostap_plx: CIS: 09 7c f0 00 ff 17 ...
hostap_plx: invalid CIS data
Unknown PC Card CIS - not a Prism2/2.5 card?
hostap_plx: Driver unloaded
hostap_crypt: unregistered algorithm 'NULL' (deinit)

Thanks,
n8

Nathan Mahon wrote:

>I use a Belkin F5D6020 wifi card, (version one), and a belkin f5d6000 pci 
>adapter for it.  A while ago, it was working flawlessly, though I
>didn't use it that much after the wife's laptop died.
>I've rolled through some kernel upgrades... and it appears my wifi does not 
>work anymore.
>here's the technical stuff:
>
>I was still using 2.4 when it was working for sure, but I can't verify that it 
>wasn't ever working on 2.6.
>under 2.6.11, i noticed the problem, I couldn't bring the interface up.
>dmesg produced similar results (to 2.6.13 i have now), but iirc, the
>iwconfig didn't make it look like the card was working at all.  I rolled
>to 2.6.13, and things improved only slightly.
>
>Now, with 2.6.13, I get a successful modprobe orinoco_plx:
>
>
>  
>
>>>auron root # dmesg
>>>orinoco_plx 0.15rc2 (Pavel Roskin <[EMAIL PROTECTED]>, David Gibson 
>>><[EMAIL PROTECTED]>, Daniel Barlow <[EMAIL PROTECTED]>)
>>>PCI: Found IRQ 9 for device :00:0a.0
>>>orinoco_plx: Detected Orinoco/Prism2 PLX device at :00:0a.0 irq:9, 
>>>io addr:0x2c00
>>>orinoco_plx: CIS: 01:03:00:00:FF:17:04:67:5A:08:FF:1D:05:01:67:5A:
>>>eth2: Hardware identity 8002::0001:
>>>eth2: Station identity  001f:0003::0008
>>>eth2: Firmware determined as Intersil 0.8.3
>>>eth2: Ad-hoc demo mode supported
>>>eth2: IEEE standard IBSS ad-hoc mode supported
>>>eth2: WEP supported, 104-bit key
>>>eth2: MAC address 00:30:BD:63:21:11
>>>eth2: Station name "Prism  I"
>>>eth2: ready
>>>  
>>>
>> 
>>
>>
>>
>
>and at this point, iwconfig looks like the card is behaving somewhat:
>
>
>  
>
>>>auron root # iwconfig eth2
>>>eth2  IEEE 802.11b  ESSID:""  Nickname:"Prism  I"
>>>  Mode:Managed  Frequency:2.462 GHz  Access Point: 
>>>00:00:00:00:00:00
>>>  Bit Rate:11 Mb/s   Sensitivity:1/3
>>>  Retry min limit:8   RTS thr:off   Fragment thr:off
>>>  Encryption key:off
>>>  Power Management:off
>>>  Link Quality=0/92  Signal level=134/153  Noise level=134/153
>>>  Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
>>>  Tx excessive retries:0  Invalid misc:0   Missed beacon:0
>>>  
>>>
>> 
>>
>>
>>
>
>dmesg hasn't changed at this point.
>however, ifconfig breaks it:
>auron root # ifconfig eth2 10.5.6.1 netmask 255.255.255.0 broadcast
>10.5.6.255
>
>
>  
>
>>>SIOCSIFFLAGS: No such device
>>>  
>>>
>> 
>>
>>
>>
>
>and dmesg now says this:
>
>
>  
>
>>>hermes @ 00012c00: Card removed while waiting for command 0x0f38 
>>>completion.
>>>eth2: Error -19 configuring card
>>>  
>>>
>> 
>>
>>
>>
>
>and if i retry the ifconfig, i get a different error and a different
>dmesg result:
>
>
>  
>
>>>SIOCSIFFLAGS: Connection timed out
>>>  
>>>
>> 
>>
>>
>>
>
>  
>
>>>eth2: Error -110 setting MAC address
>>>eth2: Error -110 configuring card
>>>  
>>>
>> 
>>
>>
>>
>
>
>Just to state the implied, I'm *not* removing the card, and rmmod'ing the 
>orinico_plx driver and re-modprobing it will produce consistantly the same 
>errors.
>
>Thanks,
>Nathan Mahon
>
>
>System: old amd k6-2 333mhz box with 256mb ram
>Distro: gentoo
>Kernel config: http://www.vaevictus.net/2.6.13_config.txt
>First Post: so flame me if necessary. :D
>
>
>
>
>
>
>
>
>
>
>-
>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://www.tux.org/lkml/
>  
>

-
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://www.tux.org/lkml/

Volatile vs Non-Volatile Spin Locks on SMP.

[multisyncfe991]

Hello,

By using volatile keyword for spin lock defined by in spinlock_t, it seems 
Linux choose to always
reload the value of spin locks from cache instead of using the content from 
registers. This may be

helpful for synchronization between multithreads in a single CPU.

I use two Xeon cpus with HyperThreading being disabled on both cpus. I think 
the MESI
protocol will enforce the cache coherency and update the spin lock value 
automatically between

these two cpus. So maybe we don't need to use the volatile any more, right?

Based on this, I rebuilt the Intel e1000 Gigabit network card driver with 
volatile being removed,

but I didn't notice any performance improvement.

Any idea about this,

Thanks a lot,

Liang



-
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://www.tux.org/lkml/

Re: Kernel Bug Report

[Lee]

Hi,

> > [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> > [20976.029194] Modules linked in: vmnet vmmon nvidia
> > [20976.090907] CPU:695757158
> > [20976.090909] EIP:0060:[]Tainted: P  VLI
>
> Please reproduce the bug without these proprietary modules loaded.  And
> make sure to include the stack trace.

My current setup has the kernel and metalog logging to the serial port, which I 
am monitoring using kermit rom another machine.

Would you mind explaining to me how to generate the strace track and/or how to 
do "proper" debugging when this crash occurs?

ATM, the machine writes the report to the serial console, and completely 
freezes.  I imagine that gdb would be involved here, but Im not sure how to go 
about setting that up.



-- 
Lee
[EMAIL PROTECTED]

 14:21:30 up  5:40,  0 users,  load average: 0.29, 0.20, 0.10
-
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://www.tux.org/lkml/

Re: Kernel Bug Report

[Lee Revell]

On Fri, 2005-07-15 at 14:04 -0500, Lee wrote:
> [20975.978911] PREEMPT SMP DEBUG_PAGEALLOC
> [20976.029194] Modules linked in: vmnet vmmon nvidia
> [20976.090907] CPU:695757158
> [20976.090909] EIP:0060:[]Tainted: P  VLI

Please reproduce the bug without these proprietary modules loaded.  And
make sure to include the stack trace.

Lee

-
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://www.tux.org/lkml/

[PATCH] add rlimit file to /proc/PID

[dierbro]

Hi all,
with a friend i have made this patch that add rlimit file to /proc/PID
directory.
Trought this file you can set and get rlimit of a running process.

rlimit file contains:
  

Example:
cave 5933 #  pwd
/proc/5933
cave 5933 # echo "RLIMIT_NOFILE 3 10" > rlimit
cave 5933 # cat rlimit
RLIMIT_CPU -1 -1
RLIMIT_FSIZE -1 -1
RLIMIT_DATA -1 -1
RLIMIT_STACK 8388608 -1
RLIMIT_CORE 0 -1
RLIMIT_RSS -1 -1
RLIMIT_NPROC 4095 4095
RLIMIT_NOFILE 3 10
RLIMIT_MEMLOCK 32768 32768
RLIMIT_AS -1 -1
RLIMIT_LOCKS -1 -1
RLIMIT_SIGPENDING 4095 4095
cave 5933 #


This is my first patch,i hope it will be usefull

Signed-off-by: Diego R. Brogna  <[EMAIL PROTECTED]>
Signed-off-by: Raffaele La Brocca <[EMAIL PROTECTED]>


--- linux-2.6.13-rc3/fs/proc/base.c 2005-07-15 20:57:25.0 +0200
+++ linux-2.6.13-rc3/fs/proc/base.c.rlimit  2005-07-15 20:57:05.0 
+0200




--- linux-2.6.13-rc3/fs/proc/base.c 2005-07-15 20:57:25.0 +0200
+++ linux-2.6.13-rc3/fs/proc/base.c.rlimit  2005-07-15 20:57:05.0 
+0200
@@ -86,6 +86,7 @@
PROC_TGID_FD_DIR,
PROC_TGID_OOM_SCORE,
PROC_TGID_OOM_ADJUST,
+   PROC_TGID_RLIMIT,
PROC_TID_INO,
PROC_TID_STATUS,
PROC_TID_MEM,
@@ -123,6 +124,7 @@
PROC_TID_FD_DIR = 0x8000,   /* 0x8000-0x */
PROC_TID_OOM_SCORE,
PROC_TID_OOM_ADJUST,
+   PROC_TID_RLIMIT,
 };
 
 struct pid_entry {
@@ -166,6 +168,7 @@
 #endif
E(PROC_TGID_OOM_SCORE, "oom_score",S_IFREG|S_IRUGO),
E(PROC_TGID_OOM_ADJUST,"oom_adj", S_IFREG|S_IRUGO|S_IWUSR),
+   E(PROC_TGID_RLIMIT,"rlimit",  S_IFREG|S_IRUGO),
 #ifdef CONFIG_AUDITSYSCALL
E(PROC_TGID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO),
 #endif
@@ -202,6 +205,7 @@
 #endif
E(PROC_TID_OOM_SCORE,  "oom_score",S_IFREG|S_IRUGO),
E(PROC_TID_OOM_ADJUST, "oom_adj", S_IFREG|S_IRUGO|S_IWUSR),
+   E(PROC_TID_RLIMIT, "rlimit",  S_IFREG|S_IRUGO),
 #ifdef CONFIG_AUDITSYSCALL
E(PROC_TID_LOGINUID, "loginuid", S_IFREG|S_IWUSR|S_IRUGO),
 #endif
@@ -582,6 +586,189 @@
.read   = proc_info_read,
 };
 
+static int rlimit_read(struct file * file, char __user * buf,
+   size_t count, loff_t *ppos)
+{
+   struct task_struct *task = proc_task(file->f_dentry->d_inode);
+   int res = 0, i;
+   unsigned long len;
+   char buffer[2048];
+   if(task){
+   
+   for(i=0; isignal->rlim[i].rlim_cur,
+   
(int)task->signal->rlim[i].rlim_max);
+   res+=len;
+   break;
+   case RLIMIT_CORE:
+   len = sprintf(buffer+res, "RLIMIT_CORE 
%d %d\n",
+   (int) 
task->signal->rlim[i].rlim_cur,
+   
(int)task->signal->rlim[i].rlim_max);
+   res+=len;
+   break;
+   case RLIMIT_CPU:
+   len = sprintf(buffer+res, "RLIMIT_CPU 
%d %d\n",
+   (int) 
task->signal->rlim[i].rlim_cur,
+   
(int)task->signal->rlim[i].rlim_max);
+   res+=len;
+   break;
+   case RLIMIT_DATA:
+   len = sprintf(buffer+res, "RLIMIT_DATA 
%d %d\n",
+   (int) 
task->signal->rlim[i].rlim_cur,
+   
(int)task->signal->rlim[i].rlim_max);
+   res+=len;
+   break;
+   case RLIMIT_FSIZE:
+   len = sprintf(buffer+res, "RLIMIT_FSIZE 
%d %d\n",
+   (int) 
task->signal->rlim[i].rlim_cur,
+   
(int)task->signal->rlim[i].rlim_max);
+   res+=len;
+   break;
+   case RLIMIT_LOCKS:
+   len = sprintf(buffer+res, "RLIMIT_LOCKS 
%d %d\n",
+   (int) 
task->signal->rlim[i].rlim_cur,
+   
(int)task->signal->rlim[i].rlim_max);
+   res+=len;
+   break;
+   case RLIMIT_MEMLOCK:
+   len = sprintf(buffer+res, 
"RLIMIT_MEMLOCK %d %d\n",
+