Re: [PATCH] reset VGA adapters via BIOS on resume... (non-fbdev/con)

2005-07-24 Thread Keith Owens
On Sat, 23 Jul 2005 08:53:00 +0200, 
Stefan Smietanowski [EMAIL PROTECTED] wrote:
Pavel Machek wrote:
 Well, we have debugged with beeps, but... It would be cool if someone
 got usb debug mode working but... and there are hardware debuggers.

If kdb is your thing then SGI has gotten kdb work over USB using
OHCI chipsets. They haven't done UHCI (Yet?).

SGI systems only use OHCI, so we have not done UHCI support in KDB.  If
anybody wants to do the work for UHCI and send me a working patch, that
patch will be included in KDB.

-
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 build empty object files in drivers/media?

2005-07-24 Thread Keith Owens
On Fri, 22 Jul 2005 19:46:00 +, 
Sam Ravnborg [EMAIL PROTECTED] wrote:
On Thu, Jul 21, 2005 at 11:06:21PM -0400, Chuck Ebbert wrote:
 
 I have this in my .config file for 2.6.13-rc3:
 
 
 #
 # Multimedia devices
 #
 # CONFIG_VIDEO_DEV is not set
 
 #
 # Digital Video Broadcasting Devices
 #
 # CONFIG_DVB is not set
 
 
 And yet these completely empty files are being built:
 
 ...
kbuild is told to visit these directories - and then it build an empty
.o file to make linking step possible.
The only solution is to tell kbuild not to visit these directories
unless they are in real use.
Following untested patch should do the trick. But the media people must
check if before being applied since I have only taken a brief look at
the Kconfig and Makefile files.

   Sam

diff --git a/drivers/media/Makefile b/drivers/media/Makefile
--- a/drivers/media/Makefile
+++ b/drivers/media/Makefile
@@ -2,4 +2,7 @@
 # Makefile for the kernel multimedia device drivers.
 #
 
-obj-y:= video/ radio/ dvb/ common/
+obj-y   := common/
+obj-$(CONFIG_VIDEO_DEV) := video/
+obj-$(CONFIG_VIDEO_DEV) := radio/
+obj-$(CONFIG_DVB)   := dvb/

That should be +=, not :=

+obj-$(CONFIG_VIDEO_DEV) += video/
+obj-$(CONFIG_VIDEO_DEV) += radio/
+obj-$(CONFIG_DVB)   += dvb/

-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Grant Coady
Greetings,

Few days ago I compiled 241 random configurations of 2.6.13-rc3, today 
I finally got around to parsing the results, top 40, sorted by name.  
Percentage is error_builds / total_builds.

build script similar to:
count=0
while [ $((++count)) -le $limit ]; do
trial=$(printf %003d $count)
make randconfig
cp .config $store/$trial-config
make clean
make -j2 2 $store/$trial-error
done

Curious whether this is worth doing, I'm about to start a run for 2.6.12.3, 
any interesting errors I can find the particular config + error to recover 
context.  Deliberately simplistic for traceability at the moment, truncated 
error length for this post.

# Linux kernel version: 2.6.13-rc3
# Tue Jul 19 04:04:05 2005..Wed Jul 20 09:46:33 2005  241 runs in three sessions

compile host 2.4.31-hf2 on: http://scatter.mine.nu/test/boxen/sempro/
data filter: http://scatter.mine.nu/test/scripts/count_errors-2.6.13-rc3.gz

arch/i386/mach-es7000/es7000.h: error: field `Header' has incomplete type   4.9%
arch/i386/mach-es7000/es7000.h: error: field `id' has incomplete type   4.9%
arch/i386/mach-es7000/es7000plat.c: error: `es7000_rename_gsi' undeclared   4.9%
arch/i386/mach-es7000/es7000plat.c: error: dereferencing pointer to incomp 49.7%
arch/i386/mach-es7000/es7000plat.c: error: invalid application of `sizeof' 14.9%
drivers/char/drm/gamma_context.h: error: `DRM' declared as function return 24.8%
drivers/char/drm/gamma_context.h: error: `DRM' previously defined here 24.8%
drivers/char/drm/gamma_context.h: error: `arg' undeclared (first use in th 14.5%
drivers/char/drm/gamma_context.h: error: `dev' undeclared (first use in th 10.3%
drivers/char/drm/gamma_context.h: error: `filp' undeclared (first use in t 12.4%
drivers/char/drm/gamma_context.h: error: called object is not a function   26.9%
drivers/char/drm/gamma_context.h: error: redefinition of `DRM' 22.8%
drivers/char/drm/gamma_context.h: error: structure has no member named `de 16.5%
drivers/char/drm/gamma_drv.h: error: `DRM' declared as function returning  31.1%
drivers/char/drm/gamma_lists.h: error: `DRM' declared as function returnin 18.6%
drivers/char/drm/gamma_lists.h: error: `DRM' previously defined here   18.6%
drivers/char/drm/gamma_lists.h: error: `bl' undeclared (first use in this  18.6%
drivers/char/drm/gamma_lists.h: error: called object is not a function  8.2%
drivers/char/drm/gamma_lists.h: error: redefinition of `DRM'   18.6%
drivers/char/drm/gamma_lock.h: error: `DRM' declared as function returning 10.3%
drivers/char/drm/gamma_lock.h: error: `DRM' previously defined here 8.2%
drivers/char/drm/gamma_lock.h: error: `context' undeclared (first use in t  8.2%
drivers/char/drm/gamma_lock.h: error: `dev' undeclared (first use in this   8.2%
drivers/char/drm/gamma_lock.h: error: called object is not a function  16.5%
drivers/char/drm/gamma_lock.h: error: redefinition of `DRM'10.3%
drivers/char/drm/gamma_old_dma.h: error: `DRM' declared as function return 10.3%
drivers/char/drm/gamma_old_dma.h: error: `DRM' previously defined here 10.3%
drivers/char/drm/gamma_old_dma.h: error: `filp' undeclared (first use in t  6.2%
drivers/char/drm/gamma_old_dma.h: error: called object is not a function   18.6%
drivers/char/drm/gamma_old_dma.h: error: redefinition of `DRM' 10.3%
drivers/char/drm/gamma_old_dma.h: error: structure has no member named `ne 18.6%
drivers/char/ipmi/ipmi_msghandler.c: error: (near initialization for `__ks 14.9%
drivers/char/ipmi/ipmi_msghandler.c: error: __ksymtab_proc_ipmi_root cause 14.9%
drivers/char/ipmi/ipmi_msghandler.c: error: `proc_ipmi_root' undeclared he 14.9%
drivers/char/ipmi/ipmi_msghandler.c: error: initializer element is not con 14.9%
drivers/mtd/chips/amd_flash.c: error: structure has no member named `buswi 14.9%
drivers/mtd/chips/jedec.c: error: structure has no member named `buswidth' 13.2%
include/asm-i386/mach-default/mach_apic.h: error: `phys_cpu_present_map' u  4.9%
include/asm-i386/mach-default/mach_apic.h: error: dereferencing pointer to  8.2%
include/asm-i386/mach-visws/do_timer.h: error: `i8259A_lock' undeclared (f 14.1%

Grant.

-
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: Lack of Documentation about SA_RESTART...

2005-07-24 Thread Paolo Ornati
On Sat, 23 Jul 2005 17:30:42 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:

  According to the Single Unix Specification V3, all functions that
  return EINTR are supposed to restart if a process receives a signal
  where signal handler has been installed with the SA_RESTART flag.  
 
 That can't be right.


SUV3 is really lacking about it:


sigaction()
SA_RESTART
[XSI] [Option Start] This flag affects the behavior of interruptible
functions; that is, those specified to fail with errno set to [EINTR].
If set, and a function specified as interruptible is interrupted by this
signal, the function shall restart and shall not fail with [EINTR]
unless otherwise specified. If the flag is not set, interruptible
functions interrupted by this signal shall fail with errno set to
[EINTR].


Note the unless otherwise specified... but then SA_RESTART is only
mentioned for:


select/pselect
[XSI] [Option Start] If SA_RESTART has been set for the interrupting
signal, it is implementation-defined whether the function restarts or
returns with [EINTR].


and for other few signal handling functions like bsd_signal(),
siginterrupt(), signal()... but just to say what SA_RESTART means.



Then, reading xrat/xsh_chap02.html:

Signal Effects on Other Functions

The most common behavior of an interrupted function after a
signal-catching function returns is for the interrupted function to give
an [EINTR] error unless the SA_RESTART flag is in effect for the signal.
However, there are a number of specific exceptions, including sleep()
and certain situations with read() and write().

The historical implementations of many functions defined by IEEE Std
1003.1-2001 are not interruptible, but delay delivery of signals
generated during their execution until after they complete. This is
never a problem for functions that are guaranteed to complete in a short
(imperceptible to a human) period of time. It is normally those
functions that can suspend a process indefinitely or for long periods of
time (for example, wait(), pause(), sigsuspend(), sleep(), or read()/
write() on a slow device like a terminal) that are interruptible. This
permits applications to respond to interactive signals or to set
timeouts on calls to most such functions with alarm(). Therefore,
implementations should generally make such functions (including ones
defined as extensions) interruptible.

Functions not mentioned explicitly as interruptible may be so on some
implementations, possibly as an extension where the function gives an
[EINTR] error. There are several functions (for example, getpid(),
getuid()) that are specified as never returning an error, which can thus
never be extended in this way.

If a signal-catching function returns while the SA_RESTART flag is in
effect, an interrupted function is restarted at the point it was
interrupted. Conforming applications cannot make assumptions about the
internal behavior of interrupted functions, even if the functions are
async-signal-safe. For example, suppose the read() function is
interrupted with SA_RESTART in effect, the signal-catching function
closes the file descriptor being read from and returns, and the read()
function is then restarted; in this case the application cannot assume
that the read() function will give an [EBADF] error, since read() might
have checked the file descriptor for validity before being interrupted.



FreeBSD doc (man page of sigaction) is much better:
http://www.gsp.com/cgi-bin/man.cgi?section=2topic=sigaction

If a signal is caught during the system calls listed below, the call
may be forced to terminate with the error  EINTR, the call may return
with a data transfer shorter than requested, or the call may be
restarted. Restart of pending calls is requested by setting the 
SA_RESTART bit in  sa_flags. The affected system calls include open(2),
read(2), write(2), sendto(2), recvfrom(2), sendmsg(2) and recvmsg(2) on
a communications channel or a slow device (such as a terminal, but not a
regular file) and during a wait(2) or ioctl(2). However, calls that have
already committed are not restarted, but instead return a partial
success (for example, a short read count).


Finally, in Linux other syscalls can be restarted... like connect(), for
example.

 -- 
Paolo Ornati
Linux 2.6.13-rc3 on x86_64
-
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: fix suspend/resume irq request free for yenta..

2005-07-24 Thread Russell King
On Sun, Jul 24, 2005 at 08:40:00AM +1000, Dave Airlie wrote:
   What if some other driver is sharing the IRQ, and requires IRQs to be
   enabled for the resume to complete?
 
 All drivers re-enable IRQs on their way back up in their resume code,
 they shouldn't be doing anything before that point..

I think you missed the point.  If a driver resume method requires
to send some commands to the chip to restore it to the state it was
before it was suspended, and requires interrupts to complete that
operation.

This is quite possible if a device has child devices which will be
resumed after it has been resumed, and they share this interrupt.

This is why I think request_irq/free_irq is a better solution.

Alternatively, we need to go to a two stage resume model - 1st
stage to re-setup the devices such that they are in a quiescent
state, 2nd stage to complete.

-- 
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.13-rc3 test: finding compile errors with make randconfig

2005-07-24 Thread Adrian Bunk
On Sun, Jul 24, 2005 at 04:28:54PM +1000, Grant Coady wrote:

 Greetings,

Hi Grant,

 Few days ago I compiled 241 random configurations of 2.6.13-rc3, today 
 I finally got around to parsing the results, top 40, sorted by name.  
 Percentage is error_builds / total_builds.
 
 build script similar to:
 count=0
 while [ $((++count)) -le $limit ]; do
 trial=$(printf %003d $count)
 make randconfig
 cp .config $store/$trial-config
 make clean
 make -j2 2 $store/$trial-error
 done
 
 Curious whether this is worth doing, I'm about to start a run for 2.6.12.3, 
 any interesting errors I can find the particular config + error to recover 
 context.  Deliberately simplistic for traceability at the moment, truncated 
 error length for this post.
...

it's generally useful, but the target kernel should be the latest -mm
kernel. 

And doing the compilations is really the trivial part of the work, the 
main work is to analyze what causes the build failures and sending 
patches.

 Grant.

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: [2.6 patch] sound drivers select'ing ISAPNP must depend on PNP ISA

2005-07-24 Thread Bodo Eggert
On Sat, 23 Jul 2005, Adrian Bunk wrote:
 On Tue, Jul 19, 2005 at 10:50:53PM +0200, Bodo Eggert wrote:

  OTOH, the build system
  should automatically propagate the dependencies. I asume that should be
  easy, except for having the time to implement that.
 ...
 
 There are nontrivial problems:
 E.g. what should happen if you select option A that depends on (B || C)?

You should in effect depend on ($original_depends)  (B || C). You'll 
just need to append all (recursive) dependencies in the selecting option.


last_length:=-1; /* impossible value */
while |options_with_unresolved_selects|  0 do begin
if |options_with_unresolved_selects| == last_length
then goto circular_recursion_detected;
last_length:=|options_with_unresolved_selects|;

for i in options_with_unresolved_selects do begin
for s in i-unresolved_selects do
if 0 == |s-unresolved_selects|
then begin
add(i-depends, s-depends)
delete_from(i-unresolved_selects, s)
end
if 0 == |i-unresolved_selects|
then delete_from(options_with_unresolved_selects, i);
end
end

 There's one opinion that options should be either select'able _or_ user 
 visible.

That would only result in ugly workarounds. Think about the kernel 
libraries. You'll want to manually select them, and you'll want to 
automatically select them, and you want both to be visible.

-- 
Funny quotes:
22. When everything's going your way, you're in the wrong lane and and going
the wrong way.
-
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] [1/5+1] menu - menuconfig part 1

2005-07-24 Thread Bodo Eggert
On Thu, 21 Jul 2005, randy_dunlap wrote:
 On Sun, 17 Jul 2005 13:29:03 +0200 (CEST) Bodo Eggert wrote:

   These patches change some menus into menuconfig options.

 When using xconfig (not menuconfig), the drivers/MTD menu
 needs some help IMO, but it's not clear where/why.
 
 Before the patch, there was only Memory Technology
 Devices (MTD) in the left xconfig panel.  After the patch,
 under that heading there are 4 other MTD entries,
 which are in the right-side panel before the patch and should
 remain there.  These are:
 
   RAM/ROM/Flash chip drivers
   Mapping drivers for chip access
   Self-contained MTD device drivers
   NAND Flash Device support

That's because of the xconfig way of handling menus. Off cause this should 
not happen, but I'll need something like a submenuconfig option to 
resolve that issue. It would need to be like a menu in menuconfig, and 
like a config in xconfig.


BTW: Thanks for testing.
-- 
Top 100 things you don't want the sysadmin to say:
83. Damn, and I just bought that pop...
-
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] autofs4 - fix infamous Busy inodes after umount ... message.

2005-07-24 Thread Andreas Gruenbacher
Hi Ian,

On Sunday 24 July 2005 04:12, Ian Kent wrote:
 If the automount daemon receives a signal which causes it to sumarily
 terminate the autofs4 module leaks dentries. The same problem exists with
 detached mount requests without the warning.

 This patch cleans these dentries at umount.

thanks for working on this. For credits, SGI reported this bug, helped with 
debugging, and verified the fix.

Cheers,
-- 
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: [shorty: Re: 2.6.12 debian powerpc kernels and ppc64 ...]

2005-07-24 Thread Sven Luther
On Mon, Jul 18, 2005 at 10:39:05PM +0200, Wolfgang Pfeiffer wrote:
 The first try to send the message below didn't work. Hoping it does
 now ... :)
 
 Regards
 Wolfgang
 
 - Forwarded message from Wolfgang Pfeiifer -
 
 To: Sven Luther [EMAIL PROTECTED]
 Cc: debian-powerpc@lists.debian.org, debian-kernel@lists.debian.org,
   linux-kernel@vger.kernel.org
 Subject: Re: 2.6.12 debian powerpc kernels and ppc64 ...
 Date: Mon, 18 Jul 2005 22:17:37 +0200
 User-Agent: Mutt/1.5.9i
 X-URL: http://www.wolfgangpfeiffer.com
 
 On Mon, Jul 18, 2005 at 07:23:05AM +0200, Sven Luther wrote:
  On Sun, Jul 17, 2005 at 07:52:30PM +0200, Wolfgang Pfeiffer wrote:
   Hi Sven
   
   On Fri, Jul 15, 2005 at 11:04:17PM +0200, Sven Luther wrote:
Hello,

I would like testers who want to test new powerpc kernels on ppc64 
machines :

These i have uploaded here :

  
http://people.debian.org/~luther/ppc64/kernel-image-2.6.12-sven_1_powerpc.deb
   
   At least the latter one works here. Or at least it boots here without any 
   probs,
   as it seems .. :
   
   $ uname -a
   Linux debby 2.6.12-sven #1 Fri Jul 15 13:44:26 UTC 2005 ppc GNU/Linux
   
   $ cat /proc/cpuinfo 
   processor   : 0
   cpu : 7455, altivec supported
   clock   : 867MHz
   revision: 0.2 (pvr 8001 0302)
   bogomips: 865.18
   machine : PowerBook3,5
   motherboard : PowerBook3,5 MacRISC2 MacRISC Power Macintosh
   detected as : 80 (PowerBook Titanium IV)
   pmac flags  : 001b
   L2 cache: 256K unified
   memory  : 768MB
   pmac-generation : NewWorld
  
  As was expectet, the 64bit is the one i am not sure about.
  
   But how come this kernel still does not have the necessary patches
   applied to run kismet: 
  
  Please provide a bug report with this info, 
 
 No. Please see:
 http://lkml.org/lkml/2004/8/27/303
 
 As you can see I sent them a bug report once. It won't happen again in
 the foreseeable future.

Send a bug report to the debian kernel package i meant, not upstream, altough
ther policy is to follow upstream on this, there may be exceptions.

The debian kernel maintainer is a team, not just me, and sending personal mail
and nort an archived bug report, is bound to get lost in my (huge) inbox,
especially now that i am mostly offline 2 weeks.

 that page nobody seemed to be interested in the problem. IIRC I could
 not compile for weeks or perhaps even months a new 2.4 kernel version
 because of the mentioned errors.

2.4 is dead on desktop powerpc for over a year and a half now, so ...

  i will apply as soon as i am back
  in 2 weeks, if someone from the kernel team doesn't beat me to it.
 
 The site for the patch I used, IIRC:
 http://www.kismetwireless.net/download.shtml#orinoco2611
 
 wget http://www.kismetwireless.net/code/orinoco-2.6.12-rfmon-dragorn-1.diff
 
 The md5sum for the latter that I have here is 
 41fb7cec09f4de93cd2432eb1aceba92
 
 So if yours will be different you can let me know.

Nice , but please apply this info to a debian bug report (reportbug kernel on
a running debian system).

 
 And I applied the patch to 2.6.12. Or better: I probably patched a
 2.6.11 (tarball) source with patch-2.6.12.bz2, and then applied the
 above orinoco patch. (Uncertainty because it's already a few weeks ago
 I compiled this kernel ... ) 
 
 And just in case it might help someone else:
 The following snippet might serve as an example of how to compile this
 more or less wifi ready patched source [Please check for yourself in
 case I made any mistakes ... :) ... ]:
 
 
 tar xzvf linux-2.6.11.tar.gz
 cd linux-2.6.11/
 bzip2 -cd  /path/to/patch-2.6.12.bz2 | patch -p1
 
 [then applying the orinoco patch from above]
 
 cp /boot/someconfig .
 make oldconfig
 fakeroot make-kpkg clean
 
 time MAKEFLAGS=CC=gcc-4.0  fakeroot make-kpkg --append-to-version=-somename 
 --revision +anothername kernel_image
 
 or
 
  time MAKEFLAGS=CC=gcc-4.0  fakeroot make-kpkg 
 --append-to-version=+orinoco-patched --revision +050703 kernel_image
 
 
 HTH
 
 Thanks for responding, Sven ... and yes: for your work, too :)
 
 And sorry for refusing to play nice if things run ugly ..

Well, just provide a debian bug report so we can continue having this
conversation the right way.

TW, is this a different patch than the one Jens had applied back them in the
2.6.4 debian powerpc kenrel days ? And which was removed for bugginess or
something ?

Friendly,

Sven Luther

-
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: HELP: NFS mount hangs when attempting to copy file

2005-07-24 Thread Michael Clark
Timothy Miller wrote:

On 7/23/05, Trond Myklebust [EMAIL PROTECTED] wrote:

  

I beg to disagree. A lot of these VPN solutions are unfriendly to MTU
path discovery over UDP. Sun uses TCP by default when mounting NFS
partitions. Have you tried this on your Linux box?



I changed the protocol to TCP and changed rsize and wsize to 1024.  I
don't know which of those fixed it, but I'm going to leave it for now.

As for MTU, yeah, the Watchguard box seems to have some hard-coded
limits, and for whatever reason KDE and GNOME graphical logins do
something that exceeds those limits, completely independent of NFS,
and hang up hard.
  


If possible it would also be good to fix the misconfigured VPN box
that's breaking the PMTU discovery if you can (usually it's too
aggressive blocking of ICMP messages). Although a wsize/rzise of 1024
and using TCP probably makes sense for NFS over a VPN (avoid
framentation overhead and let TCP handle the retransmission).

My guess is the Watchguard is blocking ICMP fragmentation needed
messages (which is resulting in the PMTU discovery breakage).

Enabling ICMP fragmentation needed messages to pass through the VPNs
firewall if you can should fix your other problems aswell.

~mc
-
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] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT

2005-07-24 Thread Russell King
On Sat, Jul 23, 2005 at 10:11:13PM +0200, Dominik Brodowski wrote:
 Thanks for the excellent debugging. Your patch seems to work, however it
 might be better to do just this:

This can be racy if two drivers are simultaneously trying to request an
IRQ.  'data' must be unique to different threads if they are to avoid
interfering with each other.

-- 
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] i386: Selectable Frequency of the Timer Interrupt

2005-07-24 Thread Bill Davidsen

Jesper Juhl wrote:


On 7/24/05, randy_dunlap [EMAIL PROTECTED] wrote:
 


On Fri, 15 Jul 2005 05:46:44 +0200 Jesper Juhl wrote:

   


+static int __init jiffies_increment_setup(char *str)
+{
+ printk(KERN_NOTICE setting up jiffies_increment : );
+ if (str) {
+ printk(kernel_hz = %s, , str);
+ } else {
+ printk(kernel_hz is unset, );
+ }
+ if (!strncmp(100, str, 3)) {
 


BTW, if someone enters kernel_hz=1000, this check (above) for 100
matches (detects) 100, not 1000.

   


ouch. You are right - thanks. I'll be sure to fix that.
I haven't had time to look more at this little thing for the last few
days, but I'll get back to it soon. Thank you for the feedback.

 

I have to admit that I like paranoid programming, and would rather see 
this look for kernel_hz= then convert the digits after to an integer 
and validate that. It would catch invalid values far better, allow other 
values to be either implemented as best as is possible if desired, and 
NOT ignore invalid values if they didn't match these predefined strings.


--
bill davidsen [EMAIL PROTECTED]
 CTO TMR Associates, Inc
 Doing interesting things with small computers since 1979

-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Jesper Juhl
On 7/24/05, Grant Coady [EMAIL PROTECTED] wrote:
 Greetings,
 
 Few days ago I compiled 241 random configurations of 2.6.13-rc3, today
 I finally got around to parsing the results, top 40, sorted by name.
 Percentage is error_builds / total_builds.
 
 build script similar to:
 count=0
 while [ $((++count)) -le $limit ]; do
 trial=$(printf %003d $count)
 make randconfig
 cp .config $store/$trial-config
 make clean
 make -j2 2 $store/$trial-error
 done
 
 Curious whether this is worth doing, I'm about to start a run for 2.6.12.3,
 any interesting errors I can find the particular config + error to recover
 context.  Deliberately simplistic for traceability at the moment, truncated
 error length for this post.
 
If you could put the data online somewhere I'd be interrested in
taking a look at it.
An easy way to look at the build log and grab the matching .config for
any given run would be great.

-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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/


ext2: buffer_head usage with and without O_DIRECT

2005-07-24 Thread li nux
This is with respect to 2.4.28 on
http://lxr.linux.no/source/?v=2.4.18 

When i do read/write on ext2 without opening files
with O_DIRECT, i can see buffer_head constantly
increasing in /proc/slabinfo.

But when I open files with O_DIRECT, the i/o is done
without using buffer_head, /proc/slabinfo shows this
as constant throughout the i/o.
There is no other i/o activity on the box.

Stacks below show that both of them creates
buffer_head's. Any idea why this is happening ?

As per the code, Without O_DIRECT, stack is:
(See fs/buffer.c)
submit_bh_rsector
submit_bh
block_read_full_page (This calls create_buffers to
create buffer_head's)
ext2_readpage
do_generic_file_read
generic_file_new_read
generic_file_read

With O_DIRECT:
brw_kiovec (This creates buffer_head's)
generic_direct_sector_IO (cals
prepare_direct_IO_iobuf)
ext2_direct_IO
generic_file_direct_IO 
generic_file_new_read
generic_file_read

-Thanks.




Start your day with Yahoo! - make it your home page 
http://www.yahoo.com/r/hs 
 
-
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] Filesystem capabilities support

2005-07-24 Thread Arnout Engelen
Nicholas Hans Simmonds wrote:
 This is a simple attempt at providing capability support

Very good to see progress in this field. I'm not familiar with the 
technical details yet, but this seems an important security feature imho.

How does this patch relate to the one at
http://www.olafdietsche.de/linux/capability ?

I do think the LD_PRELOAD / LD_LIBRARY_PATH problem (also described by
Olaf) should be mentioned in the kernel config, and fs capabilities should 
remain marked EXPERIMENTAL until that's resolved.


Kind regards,

-- 
Arnout Engelen [EMAIL PROTECTED]

  If it sounds good, it /is/ good.
  -- Duke Ellington
-
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][V4L] fix tuning with MXB driver

2005-07-24 Thread Michael Hunold
Hello Linus, Andrew,

I noticed that some past changes to the gerneric Video4Linux tuner
module for analog tuners broke my Multimedia eXtension Board driver.

The tuner driver was made aware of Video4Linux2 tuning ioctls, but my
driver was not ported and still uses the Video4Linux1 ioctls. This does
not work anymore as intendend, the tuning is currently broken.

The attached patch fixes non-working tuning in MXB driver introduced by
some recent generic tuner changes by replacing Video4Linux1 tuner ioctls
with proper Video4Linux2 tuner ioctls.

Please apply.

Thanks!
Michael.

- fix non-working tuning in MXB driver introduced by some recent generic tuner changes
by replacing Video4Linux1 tuner ioctls with proper Video4Linux2 tuner ioctls

Signed-off-by: Michael Hunold [EMAIL PROTECTED]

diff -ura xx-linux-2.6.12.1/drivers/media/video/mxb.c linux-2.6.12.1/drivers/media/video/mxb.c
--- xx-linux-2.6.12.1/drivers/media/video/mxb.c	2005-07-24 13:00:17.0 +0200
+++ linux-2.6.12.1/drivers/media/video/mxb.c	2005-07-24 13:08:02.0 +0200
@@ -142,8 +142,8 @@
 
 	int	cur_mode;	/* current audio mode (mono, stereo, ...) */
 	int	cur_input;	/* current input */
-	int	cur_freq;	/* current frequency the tuner is tuned to */
 	int	cur_mute;	/* current mute status */
+	struct v4l2_frequency	cur_freq;	/* current frequency the tuner is tuned to */
 };
 
 static struct saa7146_extension extension;
@@ -349,8 +349,13 @@
 	mxb-saa7111a-driver-command(mxb-saa7111a,DECODER_SET_VBI_BYPASS, i);
 
 	/* select a tuner type */
-	i = 5; 
+	i = TUNER_PHILIPS_PAL; 
 	mxb-tuner-driver-command(mxb-tuner,TUNER_SET_TYPE, i);
+	/* tune in some frequency on tuner */
+	mxb-cur_freq.tuner = 0;
+	mxb-cur_freq.type = V4L2_TUNER_ANALOG_TV;
+	mxb-cur_freq.frequency = freq;
+	mxb-tuner-driver-command(mxb-tuner, VIDIOC_S_FREQUENCY, mxb-cur_freq);
 	
 	/* mute audio on tea6420s */
 	mxb-tea6420_1-driver-command(mxb-tea6420_1,TEA6420_SWITCH, TEA6420_line[6][0]);
@@ -368,12 +373,8 @@
 	vm.out = 13;
 	mxb-tea6415c-driver-command(mxb-tea6415c,TEA6415C_SWITCH, vm);
 
-	/* tune in some frequency on tuner */
-	mxb-tuner-driver-command(mxb-tuner, VIDIOCSFREQ, freq);
-
 	/* the rest for mxb */
 	mxb-cur_input = 0;
-	mxb-cur_freq = freq;
 	mxb-cur_mute = 1;
 
 	mxb-cur_mode = V4L2_TUNER_MODE_STEREO;
@@ -816,18 +817,14 @@
 			return -EINVAL;
 		}
 
-		memset(f,0,sizeof(*f));
-		f-type = V4L2_TUNER_ANALOG_TV;
-		f-frequency =  mxb-cur_freq;
+		*f = mxb-cur_freq;
 
-		DEB_EE((VIDIOC_G_FREQ: freq:0x%08x.\n, mxb-cur_freq));
+		DEB_EE((VIDIOC_G_FREQ: freq:0x%08x.\n, mxb-cur_freq.frequency));
 		return 0;
 	}
 	case VIDIOC_S_FREQUENCY:
 	{
 		struct v4l2_frequency *f = arg;
-		int t_locked = 0;
-		int v_byte = 0;
 
 		if (0 != f-tuner)
 			return -EINVAL;
@@ -840,20 +837,11 @@
 			return -EINVAL;
 		}
 
-		DEB_EE((VIDIOC_S_FREQUENCY: freq:0x%08x.\n,f-frequency));
-
-		mxb-cur_freq = f-frequency;
+		mxb-cur_freq = *f;
+		DEB_EE((VIDIOC_S_FREQUENCY: freq:0x%08x.\n, mxb-cur_freq.frequency));
 
 		/* tune in desired frequency */			
-		mxb-tuner-driver-command(mxb-tuner, VIDIOCSFREQ, mxb-cur_freq);
-
-		/* check if pll of tuner  saa7111a is locked */
-//		mxb-tuner-driver-command(mxb-tuner,TUNER_IS_LOCKED, t_locked);
-		mxb-saa7111a-driver-command(mxb-saa7111a,DECODER_GET_STATUS, v_byte);
-
-		/* not locked -- anything to do here ? */
-		if( 0 == t_locked || 0 == (v_byte  DECODER_STATUS_GOOD)) {
-		}
+		mxb-tuner-driver-command(mxb-tuner, VIDIOC_S_FREQUENCY, mxb-cur_freq);
 
 		/* hack: changing the frequency should invalidate the vbi-counter (= alevt) */
 		spin_lock(dev-slock);


Re: kernel debugging

2005-07-24 Thread Jesper Juhl
On 7/24/05, UmaMaheswari Devi [EMAIL PROTECTED] wrote:
 I am new to kernel hacking and am facing problems in trying to peek at the
 runtime values of some kernel variables using gdb.
 
 I am issuing the gdb command as follows:
  gdb vmlinux /proc/kcore
 This displays the message
 /proc/kcore: Operation not permitted
 before the (gdb) prompt is displayed.
 gdb then prints a value of 0 for any valid variable that is requested.
 
 vmlinux appears to be OK, as gdb correctly identifies undefined variables.
 The problem seems to be with /proc/kcore. This file has a permission of 400. I
 am using the Red Hat distribution.
 
 Any help is appreciated.
 
If you want to use gdb to debug the kernel you should probably
investigate UML (User Mode Linux). Take a look at this link :
http://user-mode-linux.sourceforge.net/debugging.html

Alternatives include kgdb - http://kgdb.sourceforge.net/ 
and kdb - http://oss.sgi.com/projects/kdb/

You can also find many documents on Linux Kernel debugging aids and
techniques via google.

-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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 debugging

2005-07-24 Thread Jesper Juhl
On 7/24/05, Jesper Juhl [EMAIL PROTECTED] wrote:
 On 7/24/05, UmaMaheswari Devi [EMAIL PROTECTED] wrote:
  I am new to kernel hacking and am facing problems in trying to peek at the
  runtime values of some kernel variables using gdb.
 
  I am issuing the gdb command as follows:
   gdb vmlinux /proc/kcore
  This displays the message
  /proc/kcore: Operation not permitted
  before the (gdb) prompt is displayed.
  gdb then prints a value of 0 for any valid variable that is requested.
 
  vmlinux appears to be OK, as gdb correctly identifies undefined variables.
  The problem seems to be with /proc/kcore. This file has a permission of 
  400. I
  am using the Red Hat distribution.
 
  Any help is appreciated.
 
 If you want to use gdb to debug the kernel you should probably
 investigate UML (User Mode Linux). Take a look at this link :
 http://user-mode-linux.sourceforge.net/debugging.html
 
 Alternatives include kgdb - http://kgdb.sourceforge.net/
 and kdb - http://oss.sgi.com/projects/kdb/
 
 You can also find many documents on Linux Kernel debugging aids and
 techniques via google.
 
Ohh, and do search the LKML archives, kernel debuggers have been
discussed endlessly over the years on the list, so you should be able
to find many threads covering that.

-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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: IRQ routing problem in 2.6.10-rc2

2005-07-24 Thread Pierre Ossman
Pierre Ossman wrote:
 ** PCI interrupts are no longer routed automatically.  If this
 ** causes a device to stop working, it is probably because the
 ** driver failed to call pci_enable_device().  As a temporary
 ** workaround, the pci=routeirq argument restores the old
 ** behavior.  If this argument makes the device work again,
 ** please email the output of lspci to [EMAIL PROTECTED]
 ** so I can fix the driver.

If I had just bothered to diff the dmesg:es properly I would have found
the problem... Sorry for the noice.

Bjorn, the 3c59x driver breaks on this system, but only in one specific
slot. lspci -vv included.

(The problem is still present on 2.6.12 so I haven't just tried 2.6.10.)

Rgds
Pierre
00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 
03)
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort+ SERR- PERR-
Latency: 64
Region 0: Memory at f400 (32-bit, prefetchable)
Capabilities: [a0] AGP version 1.0
Status: RQ=32 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 
64bit- FW- AGP3- Rate=x1,x2
Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=none

00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 
(prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap- 66Mhz+ UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 64
Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
I/O behind bridge: e000-efff
Memory behind bridge: fc00-feff
Prefetchable memory behind bridge: f900-f9ff
Expansion ROM at e000 [disabled] [size=4K]
BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- Reset- FastB2B+

00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02)
Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 0

00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) (prog-if 80 
[Master])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 32
Region 4: I/O ports at ffa0 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) (prog-if 
00 [UHCI])
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 64
Interrupt: pin D routed to IRQ 11
Region 4: I/O ports at dce0 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02)
Control: I/O+ Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
Status: Cap- 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Interrupt: pin ? routed to IRQ 9

00:0d.0 Ethernet controller: 3Com Corporation 3c905C-TX/TX-M [Tornado] (rev 78)
Subsystem: 3Com Corporation 3C905C-TX Fast Etherlink for PC Management 
NIC
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=medium TAbort- 
TAbort- MAbort- SERR- PERR-
Latency: 64 (2500ns min, 2500ns max), Cache Line Size 08
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at dc00 [size=fb00]
Region 1: Memory at ff000400 (32-bit, non-prefetchable) [size=128]
Expansion ROM at 0002 [disabled]
Capabilities: [dc] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:0e.0 Multimedia audio controller: Ensoniq ES1371 [AudioPCI-97] (rev 06)
Subsystem: Ensoniq Creative Sound Blaster AudioPCI64V, AudioPCI128
Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR+ FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B- ParErr- DEVSEL=slow TAbort- TAbort- 
MAbort- SERR- PERR-
Latency: 64 (3000ns min, 32000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at dc80
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI+ D1- D2+ AuxCurrent=0mA 
PME(D0+,D1-,D2+,D3hot+,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 
24)
Subsystem: Dell 

Re: IRQ routing problem in 2.6.10-rc2

2005-07-24 Thread Jesper Juhl
On 7/24/05, Pierre Ossman [EMAIL PROTECTED] wrote:
 Sorry about reporting this error so late but the machine in question had
 gone some time without upgrades.
 
 The problem I'm seeing is that IRQs stop working for one of the IRQ
 slots on the machine. It's only that slot, not the entire IRQ, since the
 two slots (it's a small machine) both get routed to IRQ 10.
 
 I've included dmesg from 2.6.10-rc1 (which works) and 2.6.10-rc2 (which
 doesn't).
 
 I've also tried reverting the patches that modifies
 arch/i386/kernel/irq.c and arch/i386/pci/irq.c but it didn't solve the
 problem. So now I need some more input on which patches to try.
 
[snip]
 
 Linux version 2.6.10-rc2 ([EMAIL PROTECTED]) (gcc version 3.3.3 20040412 (Red 
 Hat Linux 3.3.3-7)) #8 Wed Jul 20 02:57:15 CEST 2005
[snip]
 ACPI: Using PIC for interrupt routing
[snip]
 PCI: Using ACPI for IRQ routing
 ** PCI interrupts are no longer routed automatically.  If this
 ** causes a device to stop working, it is probably because the
 ** driver failed to call pci_enable_device().  As a temporary
 ** workaround, the pci=routeirq argument restores the old
 ** behavior.  If this argument makes the device work again,
 ** please email the output of lspci to [EMAIL PROTECTED]
 ** so I can fix the driver.
[snip]
Have you tried the suggestion given ... As a temporary workaround,
the pci=routeirq argument... ?
You could also try the pci=noacpi boot option to see if that changes anything.

Also, that's a fairly old kernel you have there, could you try
2.6.13-rc3, 2.6.13-rc3-git6 or 2.6.13-rc3-mm1 ?

-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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.3] dyntick 050610-1 breaks makes S3 suspend

2005-07-24 Thread Pavel Machek
Hi!

  I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it
  actually makes a noticeable difference on my laptop's battery life. I don't
  have hard numbers, lets just say that instead of the usual ~3 hours i get
  out of it, i was ~4 before it started nagging, usual use pattern at work.
 
  The only gripe I have with it that it stops S3 from working. If the patch
  is compiled in the kernel, it makes S3 suspend correctly, but resuming goes
  into a solid hang (nothing get's it back alive, have to keep the
  powerbutton for ~5 secs to shutdown the system)
 
  Anything I could test? The logs don't give anything useful..
 
 I reported this some time ago [1], but there's no sulution so far...
 
 [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it

Does it also break if swsusp? Does it break if you replace enter sleep
function with some kind of dummy functions? (Or perhaps S1 is enough
for this test?)
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)

2005-07-24 Thread Pavel Machek
Hi!

 Thanks for your suggestions and help.
 
 We started it from 2.6.7 last year and then it was sitting idle for several 
 months for lack of resources. We'll go back to that version and generate a 
 diff that's easier to read.
 
 Yes, changing the name has made the task of rebasing wrt. changing kernels 
 lot 
 difficult. Our original intention was to make testing easier by keeping ext3 
 and checkfs filesystems in the same kernel. Had we continued it at that 
 point, we would have posted differences wrt. ext3 sources themselves. There 
 was compelling reason to change the name.

Maybe you want to put your development machines on ext*2* while doing
this ;-). Or perhaps reiserfs/xfs/something.
Pavel

-- 
teflon -- maybe it is a trademark, but it should not be.
-
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 NFS 0/3] Cleanup/fix nfs_block_size() and nfs_block_bits()

2005-07-24 Thread Rene Scharfe
[PATCH NFS 0/3] Cleanup/fix nfs_block_size() and nfs_block_bits()

The Plan 9 filesystem for Linux had some code which wrongly calculated
the size of blocks.  A comment said this code has been taken from NFS.

Patch 3 of this series contains a fix for the bug, the first two patches
are preparation work and shouldn't change the results.  I didn't went so
far and actually test the patch, so please be careful. =)  Compiles fine
here, at least.

Rene
-
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 NFS 1/3] Lose second parameter of nfs_block_size().

2005-07-24 Thread Rene Scharfe
[PATCH NFS 1/3] Lose second parameter of nfs_block_size().

Most calls to nfs_block_size() were done with a NULL pointer as second
parameter anyway.  We can simply calculate the number of bits ourselves
instead of using that ugly pointer thingy.

Signed-off-by: Rene Scharfe [EMAIL PROTECTED]
---

 fs/nfs/inode.c |   30 --
 1 files changed, 16 insertions(+), 14 deletions(-)

6ba4cb36d1e905852917305146fbe0076ad1d86f
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -217,14 +217,14 @@ nfs_calc_block_size(u64 tsize)
  * Compute and set NFS server blocksize
  */
 static inline unsigned long
-nfs_block_size(unsigned long bsize, unsigned char *nrbitsp)
+nfs_block_size(unsigned long bsize)
 {
if (bsize  1024)
bsize = NFS_DEF_FILE_IO_BUFFER_SIZE;
else if (bsize = NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
 
-   return nfs_block_bits(bsize, nrbitsp);
+   return nfs_block_bits(bsize, NULL);
 }
 
 /*
@@ -293,16 +293,16 @@ nfs_sb_init(struct super_block *sb, rpc_
server-namelen = pathinfo.max_namelen;
/* Work out a lot of parameters */
if (server-rsize == 0)
-   server-rsize = nfs_block_size(fsinfo.rtpref, NULL);
+   server-rsize = nfs_block_size(fsinfo.rtpref);
if (server-wsize == 0)
-   server-wsize = nfs_block_size(fsinfo.wtpref, NULL);
+   server-wsize = nfs_block_size(fsinfo.wtpref);
 
if (fsinfo.rtmax = 512  server-rsize  fsinfo.rtmax)
-   server-rsize = nfs_block_size(fsinfo.rtmax, NULL);
+   server-rsize = nfs_block_size(fsinfo.rtmax);
if (fsinfo.wtmax = 512  server-wsize  fsinfo.wtmax)
-   server-wsize = nfs_block_size(fsinfo.wtmax, NULL);
+   server-wsize = nfs_block_size(fsinfo.wtmax);
 
-   max_rpc_payload = nfs_block_size(rpc_max_payload(server-client), NULL);
+   max_rpc_payload = nfs_block_size(rpc_max_payload(server-client));
if (server-rsize  max_rpc_payload)
server-rsize = max_rpc_payload;
if (server-wsize  max_rpc_payload)
@@ -325,7 +325,7 @@ nfs_sb_init(struct super_block *sb, rpc_
 sb-s_blocksize_bits);
server-wtmult = nfs_block_bits(fsinfo.wtmult, NULL);
 
-   server-dtsize = nfs_block_size(fsinfo.dtpref, NULL);
+   server-dtsize = nfs_block_size(fsinfo.dtpref);
if (server-dtsize  PAGE_CACHE_SIZE)
server-dtsize = PAGE_CACHE_SIZE;
if (server-dtsize  server-rsize)
@@ -419,12 +419,14 @@ nfs_fill_super(struct super_block *sb, s
server   = NFS_SB(sb);
sb-s_blocksize_bits = 0;
sb-s_blocksize = 0;
-   if (data-bsize)
-   sb-s_blocksize = nfs_block_size(data-bsize, 
sb-s_blocksize_bits);
+   if (data-bsize) {
+   sb-s_blocksize = nfs_block_size(data-bsize);
+   sb-s_blocksize_bits = fls(sb-s_blocksize - 1);
+   }
if (data-rsize)
-   server-rsize = nfs_block_size(data-rsize, NULL);
+   server-rsize = nfs_block_size(data-rsize);
if (data-wsize)
-   server-wsize = nfs_block_size(data-wsize, NULL);
+   server-wsize = nfs_block_size(data-wsize);
server-flags= data-flags  NFS_MOUNT_FLAGMASK;
 
server-acregmin = data-acregmin*HZ;
@@ -1619,9 +1621,9 @@ static int nfs4_fill_super(struct super_
sb-s_blocksize = 0;
server = NFS_SB(sb);
if (data-rsize != 0)
-   server-rsize = nfs_block_size(data-rsize, NULL);
+   server-rsize = nfs_block_size(data-rsize);
if (data-wsize != 0)
-   server-wsize = nfs_block_size(data-wsize, NULL);
+   server-wsize = nfs_block_size(data-wsize);
server-flags = data-flags  NFS_MOUNT_FLAGMASK;
server-caps = NFS_CAP_ATOMIC_OPEN;
 
-
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 NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

2005-07-24 Thread Rene Scharfe
[PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

Function nfs_block_bits() an open-coded version of (the non-existing)
rounddown_pow_of_two().  That means that for non-power-of-two target
sizes it returns half the size needed for a block to fully contain
the target.  I guess this is wrong. :-)  The patch uses the built-in
roundup_pow_of_two() instead.

Signed-off-by: Rene Scharfe [EMAIL PROTECTED]
---

 fs/nfs/inode.c |   22 +++---
 1 files changed, 3 insertions(+), 19 deletions(-)

4130722d1eeb5eb22c38df9f09dfa6be554bc72c
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -185,22 +185,6 @@ nfs_umount_begin(struct super_block *sb)
rpc_killall_tasks(rpc);
 }
 
-
-static inline unsigned long
-nfs_block_bits(unsigned long bsize)
-{
-   /* make sure blocksize is a power of two */
-   if (bsize  (bsize - 1)) {
-   unsigned char   nrbits;
-
-   for (nrbits = 31; nrbits  !(bsize  (1  nrbits)); nrbits--)
-   ;
-   bsize = 1  nrbits;
-   }
-
-   return bsize;
-}
-
 /*
  * Calculate the number of 512byte blocks used.
  */
@@ -222,7 +206,7 @@ nfs_block_size(unsigned long bsize)
else if (bsize = NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
 
-   return nfs_block_bits(bsize);
+   return roundup_pow_of_two(bsize);
 }
 
 /*
@@ -319,10 +303,10 @@ nfs_sb_init(struct super_block *sb, rpc_
}
 
if (sb-s_blocksize == 0) {
-   sb-s_blocksize = nfs_block_bits(server-wsize);
+   sb-s_blocksize = roundup_pow_of_two(server-wsize);
sb-s_blocksize_bits = fls(sb-s_blocksize - 1);
}
-   server-wtmult = nfs_block_bits(fsinfo.wtmult);
+   server-wtmult = roundup_pow_of_two(fsinfo.wtmult);
 
server-dtsize = nfs_block_size(fsinfo.dtpref);
if (server-dtsize  PAGE_CACHE_SIZE)
-
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 NFS 2/3] Lose second parameter of nfs_block_bits

2005-07-24 Thread Rene Scharfe
[PATCH NFS 2/3] Lose second parameter of nfs_block_bits

Two of the three calls were passing a NULL pointer and we can simply
calculate the number of bits ourselves.

Signed-off-by: Rene Scharfe [EMAIL PROTECTED]
---

 fs/nfs/inode.c |   17 -
 1 files changed, 8 insertions(+), 9 deletions(-)

d81155b5789ac9d7e05261f5f4bf639e7982fa4b
diff --git a/fs/nfs/inode.c b/fs/nfs/inode.c
--- a/fs/nfs/inode.c
+++ b/fs/nfs/inode.c
@@ -187,17 +187,15 @@ nfs_umount_begin(struct super_block *sb)
 
 
 static inline unsigned long
-nfs_block_bits(unsigned long bsize, unsigned char *nrbitsp)
+nfs_block_bits(unsigned long bsize)
 {
/* make sure blocksize is a power of two */
-   if ((bsize  (bsize - 1)) || nrbitsp) {
+   if (bsize  (bsize - 1)) {
unsigned char   nrbits;
 
for (nrbits = 31; nrbits  !(bsize  (1  nrbits)); nrbits--)
;
bsize = 1  nrbits;
-   if (nrbitsp)
-   *nrbitsp = nrbits;
}
 
return bsize;
@@ -224,7 +222,7 @@ nfs_block_size(unsigned long bsize)
else if (bsize = NFS_MAX_FILE_IO_BUFFER_SIZE)
bsize = NFS_MAX_FILE_IO_BUFFER_SIZE;
 
-   return nfs_block_bits(bsize, NULL);
+   return nfs_block_bits(bsize);
 }
 
 /*
@@ -320,10 +318,11 @@ nfs_sb_init(struct super_block *sb, rpc_
 server-wsize = server-wpages  PAGE_CACHE_SHIFT;
}
 
-   if (sb-s_blocksize == 0)
-   sb-s_blocksize = nfs_block_bits(server-wsize,
-sb-s_blocksize_bits);
-   server-wtmult = nfs_block_bits(fsinfo.wtmult, NULL);
+   if (sb-s_blocksize == 0) {
+   sb-s_blocksize = nfs_block_bits(server-wsize);
+   sb-s_blocksize_bits = fls(sb-s_blocksize - 1);
+   }
+   server-wtmult = nfs_block_bits(fsinfo.wtmult);
 
server-dtsize = nfs_block_size(fsinfo.dtpref);
if (server-dtsize  PAGE_CACHE_SIZE)
-
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/


RTC Timezone

2005-07-24 Thread Jan Engelhardt
Hi,


My RTC clock is set to the local timezone. However, when I boot linux using 
the -b option, to stop by a shell before the bootscripts begin, the clock is 
exaclty two hours ahead.
Is the timezone stored in the RTC? If no, how can Linux know I am in UTC+0200?



Jan Engelhardt
-- 
-
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.3] dyntick 050610-1 breaks makes S3 suspend

2005-07-24 Thread Jan De Luyck
On Sunday 24 July 2005 16:23, Pavel Machek wrote:
 Hi!

   I recently tried out dyntick 050610-1 against 2.6.12.3, works great, it
   actually makes a noticeable difference on my laptop's battery life. I
   don't have hard numbers, lets just say that instead of the usual ~3
   hours i get out of it, i was ~4 before it started nagging, usual use
   pattern at work.
  
   The only gripe I have with it that it stops S3 from working. If the
   patch is compiled in the kernel, it makes S3 suspend correctly, but
   resuming goes into a solid hang (nothing get's it back alive, have to
   keep the powerbutton for ~5 secs to shutdown the system)
  
   Anything I could test? The logs don't give anything useful..
 
  I reported this some time ago [1], but there's no sulution so far...
 
  [1] http://groups.google.com/groups?selm=4b4NI-7mJ-9%40gated-at.bofh.it

 Does it also break if swsusp? Does it break if you replace enter sleep
 function with some kind of dummy functions? (Or perhaps S1 is enough
 for this test?)

I have only tried with S3.. how do I test with S1?

Jan

-- 
YOW!!  I'm in a very clever and adorable INSANE ASYLUM!!
-
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: IRQ routing problem in 2.6.10-rc2

2005-07-24 Thread Jan Engelhardt
 PCI: Using ACPI for IRQ routing
 ** PCI interrupts are no longer routed automatically.  If this
 ** causes a device to stop working, it is probably because the
 ** driver failed to call pci_enable_device().  As a temporary
 ** workaround, the pci=routeirq argument restores the old
 ** behavior.  If this argument makes the device work again,
 ** please email the output of lspci to [EMAIL PROTECTED]
 ** so I can fix the driver.
Have you tried the suggestion given ... As a temporary workaround,
the pci=routeirq argument... ?
You could also try the pci=noacpi boot option to see if that changes anything.

Hi,

and what's the proper fix for pci=routeirq? I got a driver that is only 
maintained by myself and would like to fix up the issue.



Jan Engelhardt
-- 
-
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: CheckFS: Checkpoints and Block Level Incremental Backup (BLIB)

2005-07-24 Thread Jan Engelhardt

Maybe you want to put your development machines on ext*2* while doing
this ;-). Or perhaps reiserfs/xfs/something.

Or perhaps into at the VFS level, so any fs can benefit from it.



Jan Engelhardt
-- 
-
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

2005-07-24 Thread Adrian Bunk
On Sun, Jul 17, 2005 at 05:09:39PM -0400, Ralf Baechle wrote:
 On Fri, Jul 15, 2005 at 09:35:56PM +0200, Adrian Bunk wrote:
 
  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.
 
 Eh...  That after all is the raison d'etre for this patch :)
 
  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.
 
 Nonsense.  Most development activity for this stuff happens not on the
 internet and you won't be able to follow it unless you're a licensed ham.
 I've been circulating things patch since a while and nobody has been unhappy.

So why was it important to get it into 2.6.12.3?

I must have missed the announcement that the original -stable goals have 
been declared obsolete.

  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.
 
 I've sent it to jgarzik so it's somewhere on it's long way there.
 
   Ralf

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: IRQ routing problem in 2.6.10-rc2

2005-07-24 Thread Jesper Juhl
On 7/24/05, Jan Engelhardt [EMAIL PROTECTED] wrote:
  PCI: Using ACPI for IRQ routing
  ** PCI interrupts are no longer routed automatically.  If this
  ** causes a device to stop working, it is probably because the
  ** driver failed to call pci_enable_device().  As a temporary
  ** workaround, the pci=routeirq argument restores the old
  ** behavior.  If this argument makes the device work again,
  ** please email the output of lspci to [EMAIL PROTECTED]
  ** so I can fix the driver.
 Have you tried the suggestion given ... As a temporary workaround,
 the pci=routeirq argument... ?
 You could also try the pci=noacpi boot option to see if that changes 
 anything.
 
 Hi,
 
 and what's the proper fix for pci=routeirq? I got a driver that is only
 maintained by myself and would like to fix up the issue.
 
While I don't /know/ exactely what the proper fix is I'll venture a
guess based on the information in the text above : The driver probably
doesn't call pci_enable_device().
Quoting the message at bootup time If this causes a device to stop
working, it is probably because the driver failed to call
pci_enable_device()..
Also, the Kernel Janitors TODO list
(http://janitor.kernelnewbies.org/TODO) has this to say about
pci_enable_device() :
  - ALL PCI drivers should call pci_enable_device --before-- reading
pdev-irq or pdev-resource[].  irq and resource[] may not have correct
values until after PCI hotplug setup occurs at pci_enable_device()
time.  Many PCI drivers need to be evaluated and checked for this.

-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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

2005-07-24 Thread Richard Purdie
On Fri, 2005-07-15 at 01:36 -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/

On the Zaurus I'm seeing a couple of false BUG: soft lockup detected on
CPU#0! reports. These didn't show under 2.6.12-mm1 which was the last
-mm kernel I tested. softlockup.c seems identical between these versions
so it looks like some other change has caused this to appear...

Both of these are triggered from the nand driver. The functions
concerned (nand_wait_ready and nand_read_buf) are known to be slow (they
wait on hardware).

Richard

BUG: soft lockup detected on CPU#0!
Pid: 1, comm:  swapper
CPU: 0
PC is at sharpsl_nand_dev_ready+0x14/0x28
LR is at nand_wait_ready+0x30/0x50
pc : [c015f15c]lr : [c0159ea4]Not tainted
sp : c034fa24  ip : c034fa34  fp : c034fa30
r10: c3c09400  r9 : c035e890  r8 : c75a
r7 : c022533c  r6 : c3c09580  r5 : c3c09400  r4 : 8fc3
r3 : c027f0bc  r2 : c4856000  r1 : c4856000  r0 : c3c09400
Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  Segment kernel
Control: 397F  Table: A0004000  DAC: 0017
[c001dd38] (show_regs+0x0/0x4c) from [c0059f48] (softlockup_tick
+0x7c/0xb0)
 r4 = C034E000
[c0059ecc] (softlockup_tick+0x0/0xb0) from [c0042198] (do_timer
+0x278/0x500)
 r5 =   r4 = 0001
[c0041f20] (do_timer+0x0/0x500) from [c00211ac] (timer_tick
+0xb4/0xf8)
[c00210f8] (timer_tick+0x0/0xf8) from [c00279a0]
(pxa_timer_interrupt+0x48/0xa8)
 r6 = C034F9DC  r5 = C034E000  r4 = F2A0
[c0027958] (pxa_timer_interrupt+0x0/0xa8) from [c001cb60] (__do_irq
+0x6c/0xc4)
 r8 = C034F9DC  r7 =   r6 =   r5 = C034E000
 r4 = C0226314
[c001caf4] (__do_irq+0x0/0xc4) from [c001cddc] (do_level_IRQ
+0x68/0xb8)
[c001cd74] (do_level_IRQ+0x0/0xb8) from [c001ce80] (asm_do_IRQ
+0x54/0x164)
 r6 = 0400  r5 = F2D0  r4 = 
[c001ce2c] (asm_do_IRQ+0x0/0x164) from [c001b9b8] (__irq_svc
+0x38/0x78)
[c015f148] (sharpsl_nand_dev_ready+0x0/0x28) from [c0159ea4]
(nand_wait_ready+0x30/0x50)
[c0159e74] (nand_wait_ready+0x0/0x50) from [c0159f60] (nand_command
+0x9c/0x1f0)
 r7 =   r6 = C3C09400  r5 = C3C09580  r4 = 
[c0159ec4] (nand_command+0x0/0x1f0) from [c015b4b8]
(nand_do_read_ecc+0x720/0x7c8)
 r8 = C034FACC  r7 = 0200  r6 = C3C09580  r5 = C75A
 r4 = 
[c015ad98] (nand_do_read_ecc+0x0/0x7c8) from [c015b5e8]
(nand_read_ecc+0x44/0x4c)
[c015b5a4] (nand_read_ecc+0x0/0x4c) from [c0155364] (part_read_ecc
+0xa4/0xbc)
 r4 = 
[c01552c0] (part_read_ecc+0x0/0xbc) from [c00e5280]
(jffs2_flash_read+0x1fc/0x2b0)
 r7 =   r6 = 011E8B70  r5 =   r4 = C034FBF0
[c00e5084] (jffs2_flash_read+0x0/0x2b0) from [c00dbd48]
(jffs2_fill_scan_buf+0x2c/0x4c)
[c00dbd1c] (jffs2_fill_scan_buf+0x0/0x4c) from [c00dc424]
(jffs2_scan_medium+0x63c/0x1884)
 r4 = 011E8B7C
[c00dbde8] (jffs2_scan_medium+0x0/0x1884) from [c00e0020]
(jffs2_do_mount_fs+0x1bc/0x6cc)
[c00dfe64] (jffs2_do_mount_fs+0x0/0x6cc) from [c00e2d60]
(jffs2_do_fill_super+0x130/0x2b4)
[c00e2c30] (jffs2_do_fill_super+0x0/0x2b4) from [c00e3244]
(jffs2_get_sb_mtd+0xf4/0x134)
 r8 = 8401  r7 = C3C4B4E0  r6 = C3C4B4FC  r5 = C3C4B200
 r4 = C3C4B400
[c00e3150] (jffs2_get_sb_mtd+0x0/0x134) from [c00e32d4]
(jffs2_get_sb_mtdnr+0x50/0x5c)
[c00e3284] (jffs2_get_sb_mtdnr+0x0/0x5c) from [c00e3410]
(jffs2_get_sb+0x130/0x1c0)
 r7 = 8001  r6 = C034FD5C  r5 = C3C5  r4 = FFEA
[c00e32e0] (jffs2_get_sb+0x0/0x1c0) from [c00890d0] (do_kern_mount
+0x50/0xf4)
[c0089080] (do_kern_mount+0x0/0xf4) from [c00a3de8] (do_mount
+0x3ac/0x650)
[c00a3a3c] (do_mount+0x0/0x650) from [c00a44c8] (sys_mount
+0x9c/0xe8)
[c00a442c] (sys_mount+0x0/0xe8) from [c0008b64] (mount_block_root
+0xb0/0x264)
 r7 = C0343000  r6 = C034FF54  r5 = C0343006  r4 = C0343000
[c0008ab4] (mount_block_root+0x0/0x264) from [c0008d74] (mount_root
+0x5c/0x6c)
[c0008d18] (mount_root+0x0/0x6c) from [c0008dc4] (prepare_namespace
+0x40/0xe4)
 r5 = C0019C70  r4 = C0019CC0
[c0008d84] (prepare_namespace+0x0/0xe4) from [c001b200] (init
+0x190/0x1fc)
 r5 = C034E000  r4 = C01F5AA0
[c001b070] (init+0x0/0x1fc) from [c0039a10] (do_exit+0x0/0xd8c)
 r8 =   r7 =   r6 =   r5 = 
 r4 = 
VFS: Mounted root (jffs2 filesystem) readonly.

and 

BUG: soft lockup detected on CPU#0!
Pid: 1063, comm:  busybox
CPU: 0
PC is at nand_read_buf+0x28/0x3c
LR is at 0x100
pc : [c0159cb8]lr : [0100]Not tainted
sp : c355dac8  ip : 003b  fp : c355dad4
r10: c3c09400  r9 : c3b20884  r8 : 0002
r7 :   r6 : c3c09580  r5 :   r4 : c3b20884
r3 : c4856014  r2 : 00d3  r1 : c3b20884  r0 : c3c09580
Flags: Nzcv  IRQs on  FIQs on  Mode SVC_32  Segment user
Control: 397F  Table: A354C000  DAC: 0015
[c001dd38] (show_regs+0x0/0x4c) from [c0059f48] (softlockup_tick
+0x7c/0xb0)
 r4 = C355C000
[c0059ecc] (softlockup_tick+0x0/0xb0) from [c0042198] (do_timer
+0x278/0x500)
 r5 =   r4 = 0001
[c0041f20] (do_timer+0x0/0x500) from [c00211ac] 

xor as a lazy comparison

2005-07-24 Thread Jan Engelhardt
Hi list,


I have seen this in kernel/signal.c:check_kill_permission()

 (current-euid ^ t-suid)  (current-euid ^ t-uid)

If current-euid and t-suid are the same, the xor returns 0, so these 
statements are effectively the same as a !=

current-euid != t-suid ...

Why ^ ?


Jan Engelhardt
-- 
-
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 1/2] Touchscreen support for sharp sl-5500

2005-07-24 Thread Russell King
On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
 This adds support for reading ADCs (etc), neccessary to operate touch
 screen on Sharp Zaurus sl-5500.

I would like to know what the diffs are between my version (attached)
and this version before they get applied.

The only reason my version has not been submitted is because it lives
in the drivers/misc directory, and mainline kernel folk don't like
drivers which clutter up that directory.  In fact, I had been told
that drivers/misc should remain completely empty - which makes this
set of miscellaneous drivers homeless.

-- 
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:  2.6 Serial core


ucb1x00.tar.gz
Description: GNU Zip compressed data


Re: [patch 1/2] Touchscreen support for sharp sl-5500

2005-07-24 Thread Richard Purdie
On Sun, 2005-07-24 at 17:47 +0100, Russell King wrote:
 On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
  This adds support for reading ADCs (etc), neccessary to operate touch
  screen on Sharp Zaurus sl-5500.
 
 I would like to know what the diffs are between my version (attached)
 and this version before they get applied.
 
 The only reason my version has not been submitted is because it lives
 in the drivers/misc directory, and mainline kernel folk don't like
 drivers which clutter up that directory.  In fact, I had been told
 that drivers/misc should remain completely empty - which makes this
 set of miscellaneous drivers homeless.

I've been wondering about suggesting the creation of a drivers/soc
directory. The idea would be for it to contain system on chip type
support code. I use that description loosely to fit any code which needs
to support drivers in multiple driver subsections.

An example use in my Zaurus tree is the TSC2101 which contains a
touchscreen, battery monitoring and sound. Handhelds.org has devices
such as the ASIC2/ASIC3 in the ipaqs (and other handhelds) which cover
many different drivers subsections.

Where practical, the sub drivers such as the touchscreen could be placed
into the specific driver areas such as drivers/input/touchscreen/ but
the core chip specific support would be in drivers/soc and the files
would be connected. 

Would that be acceptable in mainline?

Richard








-
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 1/2] Touchscreen support for sharp sl-5500

2005-07-24 Thread randy_dunlap
On Sun, 24 Jul 2005 17:47:56 +0100 Russell King wrote:

 On Fri, Jul 22, 2005 at 08:01:09PM +0200, Pavel Machek wrote:
  This adds support for reading ADCs (etc), neccessary to operate touch
  screen on Sharp Zaurus sl-5500.
 
 I would like to know what the diffs are between my version (attached)
 and this version before they get applied.
 
 The only reason my version has not been submitted is because it lives
 in the drivers/misc directory, and mainline kernel folk don't like
 drivers which clutter up that directory.  In fact, I had been told
 that drivers/misc should remain completely empty - which makes this
 set of miscellaneous drivers homeless.

but clearly drivers/misc/ is not empty, unless you mean at its
top level.

The IBM ASM service processor driver is there (added in 2.6.x)
as well as some hdpuftrs/ driver, which is not in any Kconfig file
or defconfig file.  :(

---
~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: CIFS slowness crashes

2005-07-24 Thread Lasse Kärkkäinen / Tronic
nor umount -f
 What are the errors?  What is the version of cifs.ko module?

umount2: Device or resource busy
umount: /tmpmnt: device is busy
umount2: Device or resource busy
umount: /tmpmnt: device is busy

Without -f it doesn't print those umount2 errors, just the other two.

The version is whatever comes with 2.6.12 or 2.6.13rc1.

 My tests of reconnection after server crash or network reconnection with
 smbfs works (for the past year or two) and also of course for cifs. 
 cifs also reconnects state (open files) not just the connection to
 \\server\share

Reconnection usually (or perhaps always, with new versions) works, but
nothing cannot be done if the server goes permanently offline (nor until
it comes back online). When the server is down, the programs that were
using the CIFS mount or that try to access it will halt.

 My informal tests (cifs-samba) showed a maximum of about 20%
 utilization of gigabit doing large file writes and about double that for
 large file reads with a single cifs client to Samba over gigabit. Should
 be somewhat simalar to Windows server.

This seems quite bad. Is it waiting for packet confirmations or what?

However, I have never got anything better than about 40 Mo/s with a
gigabit network so far. Jumbo frames and using direct cross-over cable
between the clients make no difference. Still, all protocols that I have
tried, except for SMB and CIFS, can reach that easily. I'll try to get
two Windows machines that I can test with. Perhaps the problem is with
Linux network drivers.

Anyway, 20 Mo/s or something like that would not be a big problem. The
real problem occurs when the speed drops under 3 Mo/s.

 The most common cause of widely varying speeds are the following:
 1) memory fragmentation - some versions of the kernel badly fragment
 slab allocations greater than 4 pages (cifs by default allocates 16.5K
 buffers - which results in larger size allocations when more than 5
 processes are accessing the mount and the cifs buffer pool is exceeded)

Wouldn't this show up as increased system loads?

 2) write behind due to oplock - smbfs does not do oplock, cifs does -
 which means that cifs client caching can cause a large amount of
 writebehind data to accumulate (with great performance for a while) -
 then when memory gets tight due to the inode caching in linux's mm
 layer, the cifs client is asked to write out a large amount of file data
 at one time (which it does synchronously). 
 
 Both of these are being improved.  You can bypass the inode caching on
 the client by using the cifs mount option
   forcedirectio

This option has little or no effect. Still runs slowly (2.4 Mo/s right now).

My benchmark is reading data in 50 Mio chunks, as quickly as it can,
calculating the average read speed. The files being read are bigger than
4 Gio. I haven't tried writing anything (the shares that I play with are
read-only).

For the record, I am using O_RDONLY | O_LARGEFILE on open and then pread
 for all reads. However, I am getting similar results with all programs,
so I don't think that the reading method really matters that much.

- Tronic -



signature.asc
Description: OpenPGP digital signature


Re: Why build empty object files in drivers/media?

2005-07-24 Thread Johannes Stezenbach
On Sun, Jul 24, 2005 at 08:58:45AM +, Sam Ravnborg wrote:
 On Sun, Jul 24, 2005 at 04:10:13PM +1000, Keith Owens wrote:
  
  diff --git a/drivers/media/Makefile b/drivers/media/Makefile
  --- a/drivers/media/Makefile
  +++ b/drivers/media/Makefile
  @@ -2,4 +2,7 @@
   # Makefile for the kernel multimedia device drivers.
   #
   
  -obj-y:= video/ radio/ dvb/ common/
  +obj-y   := common/
  +obj-$(CONFIG_VIDEO_DEV) := video/
  +obj-$(CONFIG_VIDEO_DEV) := radio/
  +obj-$(CONFIG_DVB)   := dvb/
  
  That should be +=, not :=
  
  +obj-$(CONFIG_VIDEO_DEV) += video/
  +obj-$(CONFIG_VIDEO_DEV) += radio/
  +obj-$(CONFIG_DVB)   += dvb/
 
 Correct - thanks!

OK, I'll pick this up and put it in CVS.

Thanks,
Johannes
-
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/


do_gettimeofday monotony?

2005-07-24 Thread bert hubert
Is do_gettimeofday supposed to be monotonous? I'm seeing time go backward by
tiny amounts, and then progressing.

I'm using do_gettimeofday on a single processor, CONFIG_PREEMPT_NONE=y, and
saving stuff from generic_make_request - see http://ds9a.nl/diskstat for the
source. 2.6.13-rc3-mm1, HZ=250.

I'll try to figure out how much it is going back, and it is some kind of
magic interval.

Is there another monotonous clock in the kernel that doesn't wrap (all
that often)? Doesn't really need to be wall time.

Thanks!

-- 
http://www.PowerDNS.com  Open source, database driven DNS Software 
http://netherlabs.nl  Open and Closed source services
-
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 page size explanation

2005-07-24 Thread Nix
On 22 Jul 2005, Jesper Juhl suggested tentatively:
 You can
  A) look in the .config file for your current kernel (if your arch
 supports different page sizes at all).
  B) You can use the  getpagesize(2) syscall at runtime. getpagesize()
 returns the nr of bytes in a page - man getpagesize - I'm not sure
 that's universally supported though.
  C) You can look at /proc/cpuinfo or /proc/meminfo , IIRC some archs
 report page size there - not quite sure, can't remember...

D) getconf PAGE_SIZE should work, although what it does on arches
   with variable page sizes isn't clear to me.

-- 
`But of course, GR is the very best relativity for the masses.'
 --- Wayne Throop
-
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: Giving developers clue how many testers verified certain kernel version

2005-07-24 Thread Martin MOKREJŠ

Hi Adrian,
 well, the idea was to give you a clue how many people did NOT complain
because it either worked or they did not realize/care. The goal
was different. For example, I have 2 computers and both need current acpi
patch to work fine. I went to bugzilla and found nobody has filed such bugs
before - so I did and said it is already fixed in current acpi patch.
But you'd never know that I tested that successfully. And I don't believe
to get emails from lkml that I installed a patch and it did not break
anything. I hope you get the idea now. ;)
Martin

Adrian Bunk wrote:

On Fri, Jul 22, 2005 at 03:34:09AM +0200, Martin MOKREJ? wrote:



Hi,



Hi Martin,



I think the discussion going on here in another thread about lack
of positive information on how many testers successfully tested certain
kernel version can be easily solved with real solution.

How about opening separate project in bugzilla.kernel.org named
kernel-testers or whatever, where whenever cvs/svn/bk gatekeepers
would release some kernel patch, would open an empty bugreport
for that version, say for 2.6.13-rc3-git4.

Anybody willing to join the crew who cared to download the patch
and tested the kernel would post just a single comment/follow-up
to _that_ bugreport with either positive rating or URL
of his own bugreport with some new bug. When the bug get's closed
it would be immediately obvious in the 2.6.13-rc3-git4 bug ticket
as that bug will be striked-through as closed.

Then, we could easily just browse through and see that 2.6.13-rc2
was tested by 33 fellows while 3 of them found a problem and 2 such
problems were closed since then.
...



most likely, only a small minory of the people downloading a patch would 
register at such a project.


The important part of the work, the bug reports, can already today go to 
lnux-kernel and/or the Bugzilla.


You'd spend efforts for such a project that would only produce some 
numbers of questionable value.




Martin



cu
Adrian



--
Martin Mokrejs
Email: 'bW9rcmVqc21Acmlib3NvbWUubmF0dXIuY3VuaS5jeg==\n'.decode('base64')
GPG key is at http://www.natur.cuni.cz/~mmokrejs
-
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: Giving developers clue how many testers verified certain kernel version

2005-07-24 Thread Adrian Bunk
On Sun, Jul 24, 2005 at 08:45:16PM +0200, Martin MOKREJ? wrote:

 Hi Adrian,

Hi Martin,

  well, the idea was to give you a clue how many people did NOT complain
 because it either worked or they did not realize/care. The goal
 was different. For example, I have 2 computers and both need current acpi
 patch to work fine. I went to bugzilla and found nobody has filed such bugs
 before - so I did and said it is already fixed in current acpi patch.
 But you'd never know that I tested that successfully. And I don't believe
 to get emails from lkml that I installed a patch and it did not break
 anything. I hope you get the idea now. ;)

in your ACPI example there is a bug/problem (ACPI needs updating).

And ACPI is a good example where even 1000 success reports wouldn't help 
because a slightly different hardware or BIOS version might make the 
difference.

Usually no bug report indicates that something is OK.
And if you are unsure whether an unusual setup or hardware is actually 
tested, it's usually the best to ask on linux-kernel whether someone 
could test it.

 Martin

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

2005-07-24 Thread Neil Horman
On Sat, Jul 23, 2005 at 08:16:20PM -0300, Márcio Oliveira wrote:
 Neil,
 
 The best way I can think to do that is take a look at /proc/slabinfo.  
 That will
 likely give you a pointer to which area of code is eating up your memory.
  
 
 OK. I will monitor the /proc/slabinfo file.
 
 Based on the sysrq-m info you posted it looks like due to fragmentation the
 largest chunk of memory you can allocate is 2MB (perhaps less depending on
 address space availability).  If you can build a test kernel to do a 
 show_state
 rather than a show_mem at the beginning of oom_kil, then you should be 
 able to
 tell who is trying to do an allocation that leads to kswapd calling
 out_of_memory.
  
 
 Neil, I'm trying to recompile the kernel source 2.4.21-32.0.1 and get 
 some error messages:
 
 In file included from 
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h:13,
 from 
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h:6,
 from 
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:12,
 from 3w-.c:172:
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: warning: 
 parameter names (without types) in function declaration
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: field 
 `loops_per_jiffy_R_ver_str' declared as a function
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: invalid 
 suffix on integer constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: syntax error 
 before numeric constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: warning: 
 function declaration isn't a prototype
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: invalid 
 suffix on integer constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: syntax 
 error before numeric constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: warning: 
 function declaration isn't a prototype
 /usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:273: warning: 
 parameter names (without types) in function declaration
 In file included from 3w-.c:172:
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: invalid 
 suffix on integer constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: syntax error 
 before numeric constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: 
 `inter_module_register_R_ver_str' declared as function returning a function
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: warning: 
 function declaration isn't a prototype
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: invalid 
 suffix on integer constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: syntax error 
 before numeric constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: 
 `inter_module_unregister_R_ver_str' declared as function returning a 
 function
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: warning: 
 function declaration isn't a prototype
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: 
 `inter_module_get_R_ver_str' declared as function returning a function
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: warning: 
 parameter names (without types) in function declaration
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: 
 `inter_module_get_request_R_ver_str' declared as function returning a 
 function
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: warning: 
 parameter names (without types) in function declaration
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: invalid 
 suffix on integer constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: syntax error 
 before numeric constant
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: 
 `inter_module_put_R_ver_str' declared as function returning a function
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: warning: 
 function declaration isn't a prototype
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: 
 `try_inc_mod_count_R_ver_str' declared as function returning a function
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: warning: 
 parameter names (without types) in function declaration
 make[3]: *** [3w-_10200033.o] Error 1
 make[3]: Leaving directory 
 `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon/3w-_10200033'
 make[2]: *** [_modsubdir_3w-_10200033] Error 2
 make[2]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon'
 make[1]: *** [_modsubdir_addon] Error 2
 make[1]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers'
 make: *** [_mod_drivers] Error 2
 
 Is there any relationship between the sysrq-m changes to do show_state() 
 rather than a show_mem() and the compiling erros?
 
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h, line 13:
#include asm/processor.h
 
 /usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h ,line 6:
#include linux/prefetch.h
 
 

Re: kernel page size explanation

2005-07-24 Thread VASM
i had one question 
does the linux kernel support only one default page size even if the
processor on which it is working supports multiple ?

On 7/25/05, Nix [EMAIL PROTECTED] wrote:
 On 22 Jul 2005, Jesper Juhl suggested tentatively:
  You can
   A) look in the .config file for your current kernel (if your arch
  supports different page sizes at all).
   B) You can use the  getpagesize(2) syscall at runtime. getpagesize()
  returns the nr of bytes in a page - man getpagesize - I'm not sure
  that's universally supported though.
   C) You can look at /proc/cpuinfo or /proc/meminfo , IIRC some archs
  report page size there - not quite sure, can't remember...
 
 D) getconf PAGE_SIZE should work, although what it does on arches
   with variable page sizes isn't clear to me.
 
 --
 `But of course, GR is the very best relativity for the masses.'
  --- Wayne Throop
 -
 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/


Re: Giving developers clue how many testers verified certain kernel version

2005-07-24 Thread Martin MOKREJŠ

Hi Adrian,
 I think you don't understand me. I do report bugs and will always
do. The point was that developers could be assured there is possibly
no problem when people do NOT report bugs in that piece of code
because they would know that it _was_ tested by 1000 people on 357 different
HW's. And they could even check the .configs, lshw etc. Sure the people
would report a problem, but if you do NOT hear of one then there is either no
problem or nobody cared to report that or nobody tested. So you known
just nothing and you better wait some days, weeks so the patch get's lost
in lkml archives if it doesn't happend it gets into -ac or -mm.

 And that is exactly why I proposed this. Then you will know that 1000
people really cared and used that and most probably then it is reasonable
to expect there is really no bug in the code.

 Take it the other way around. You may be reluctant to commit some
patch to the official tree. ;) The guy who wrote the patch says It was tested,
please apply. ;-) If he says the patch is lying in -mm or -ac tree for
a while - like 2 months you might be more in favor to commit, right?
If you know the patch was tested between -git5 and -git6 by 1000 people
within 5 days you wouldn't wait either, right?
Martin

Adrian Bunk wrote:

On Sun, Jul 24, 2005 at 08:45:16PM +0200, Martin MOKREJ? wrote:

well, the idea was to give you a clue how many people did NOT complain
because it either worked or they did not realize/care. The goal
was different. For example, I have 2 computers and both need current acpi
patch to work fine. I went to bugzilla and found nobody has filed such bugs
before - so I did and said it is already fixed in current acpi patch.
But you'd never know that I tested that successfully. And I don't believe
to get emails from lkml that I installed a patch and it did not break
anything. I hope you get the idea now. ;)



in your ACPI example there is a bug/problem (ACPI needs updating).

And ACPI is a good example where even 1000 success reports wouldn't help 
because a slightly different hardware or BIOS version might make the 
difference.


Usually no bug report indicates that something is OK.
And if you are unsure whether an unusual setup or hardware is actually 
tested, it's usually the best to ask on linux-kernel whether someone 
could test it.

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


kernel 2.6 speed

2005-07-24 Thread Ciprian
Hi guys!

I got a question for you. Apparently kernel 2.6 is
much slower then 2.4 and about 30 times slower then
the windows one.

I'm not an OS guru, but I ran a little and very simple
test. The program bellow, as you can see, measures the
number of cycles performed in 30 seconds.

//- START CODE 

#include stdio.h
#include time.h


int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;


time(initialTime);
testTime = initialTime;

printf(Here we go...\n);

while((testTime-initialTime)  30)
{
time(testTime);
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf(No. of cycles: %ld\n, counter);

return 0;
}

// END CODE ---


In windows were performed about 300 millions cycles,
while in Linux about 10 millions. This test was run on
Fedora 4 and Suse 9.2 as Linux machines, and Windows
XP Pro with VS .Net 2003 on the MS side. My CPU is a
P4 @3GHz HT 800MHz bus.

I published my little test on several forums and I
wasn't the only one who got these results. All the
other users using 2.6 kernel obtained similar results
regardless of the CPU they had (Intel or AMD). 

Also I downloaded the latest kernel (2.6.12),
configured it specifically for my machine, disabled
all the modules I don't need and compiled it. The
result was a 1.7 MB kernel on which KDE moves faster,
but the processing speed it's the same - same huge
speed ratios.

Also, it shouldn't have any importance, but my HDD is
SATA so the specific modules were required. I don't
think its SCSI modules have any impact on the
processing speed, but you know more on the kernel
architecture then I do.

Now, can anyone explain this and suggest what other
optimizations I should use? The 2.4 version was a lot
faster. I thought the newer versions were supposed to
work faster (or at least just as fast) AND to offer
extra features.

Any help would appreciate.

Thanks,
Ciprian



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Grant Coady
On Sun, 24 Jul 2005 15:01:22 +0200, Jesper Juhl [EMAIL PROTECTED] wrote:
 context.  Deliberately simplistic for traceability at the moment, truncated
 error length for this post.
 
If you could put the data online somewhere I'd be interrested in
taking a look at it.
7.4MB raw data -- low info content.  Needs garbage removal.  Good 
test case for gzip vs bzip2 -- 1.4MB vs 481kB, 

  ftp://ftp.scatter.mine.nu/develop/first_run.tar.bz2 (481kB)

If you mean online info-sys, I don't have bandwidth for that :(

An easy way to look at the build log and grab the matching .config for
any given run would be great.

Revisit the data extraction and build an errorlog line_index...  
Will let you know.  

Grant.

-
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 page size explanation

2005-07-24 Thread Fawad Lateef
On 7/25/05, VASM [EMAIL PROTECTED] wrote:
 i had one question
 does the linux kernel support only one default page size even if the
 processor on which it is working supports multiple ?
 

The PAGE_SIZE depends on the architecture and it do supports different
page_sizes depending on the architecture (AFAIK for almost all
supported architectures)

-- 
Fawad Lateef
-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Jesper Juhl
On 7/24/05, Grant Coady [EMAIL PROTECTED] wrote:
 On Sun, 24 Jul 2005 15:01:22 +0200, Jesper Juhl [EMAIL PROTECTED] wrote:
  context.  Deliberately simplistic for traceability at the moment, truncated
  error length for this post.
 
 If you could put the data online somewhere I'd be interrested in
 taking a look at it.
 7.4MB raw data -- low info content.  Needs garbage removal.  Good
 test case for gzip vs bzip2 -- 1.4MB vs 481kB,
 
   ftp://ftp.scatter.mine.nu/develop/first_run.tar.bz2 (481kB)
 
 If you mean online info-sys, I don't have bandwidth for that :(
 
Ok. Would you be able to bzip2 the raw data and email it to me off list ?


-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Grant Coady
On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:

it's generally useful, but the target kernel should be the latest -mm
kernel. 
097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
`drm_ioremap_nocache'
097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
previously defined here
097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
`drm_ioremapfree'
097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
previously defined here
098-error:drivers/usb/gadget/ether.c:2510: error: `STATUS_BYTECOUNT' undeclared 
(first use in this function)
098-error:drivers/usb/gadget/ether.c:2510: error: (Each undeclared identifier 
is reported only once
098-error:drivers/usb/gadget/ether.c:2510: error: for each function it appears 
in.)
[EMAIL PROTECTED]:/opt/linux/trial4$ grep error *-error |wc -l
2105

With  2k (raw) errors in 97.something builds of 2.6.12.3, why go 
looking for trouble in -mm?  

And doing the compilations is really the trivial part of the work, the 
Got to start somewhere :)  

Grant.

-
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 2.6 speed

2005-07-24 Thread Dag Nygren

 In windows were performed about 300 millions cycles,
 while in Linux about 10 millions. This test was run on
 Fedora 4 and Suse 9.2 as Linux machines, and Windows
 XP Pro with VS .Net 2003 on the MS side. My CPU is a
 P4 @3GHz HT 800MHz bus.
 
 I published my little test on several forums and I
 wasn't the only one who got these results. All the
 other users using 2.6 kernel obtained similar results
 regardless of the CPU they had (Intel or AMD). 

Looking at the gcc-produced code from youe test program I 
can see the floating point math beeing optimized away all
together as you are not using the result and the rest more
or less boils down to the call to time() and a few moves
and compares of the time values.
In other words it seems like you are testing the efficiency of
the time() function...

BRGDS
Dag

-
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] pcmcia: pcmcia_request_irq for !IRQ_HANDLE_PRESENT

2005-07-24 Thread Dominik Brodowski
On Sun, Jul 24, 2005 at 12:40:40PM +0100, Russell King wrote:
 On Sat, Jul 23, 2005 at 10:11:13PM +0200, Dominik Brodowski wrote:
  Thanks for the excellent debugging. Your patch seems to work, however it
  might be better to do just this:
 
 This can be racy if two drivers are simultaneously trying to request an
 IRQ.  'data' must be unique to different threads if they are to avoid
 interfering with each other.

As it's enough to keep PCMCIA functions apart (there can't be two drivers
registering with the same PCMCIA function at the same moment), I'll use that
now.
void *data = p_dev-dev.driver; /* something unique to this device */


Thanks,
Dominik
-
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: Supermount

2005-07-24 Thread zhilla
well, for a bit of OT discussion sake, here's how it imho SHOULD work, 
from user (noobs and non guru) desktop point of view:
cd/dvds: mounted automatically on insert / first access. if a program is 
running from it (or a file is open from it), and user tries to eject it 
using button, or any eject-like software, kernel sends a signal to a 
central place. which is, for example, picked up from a window manager, 
or even X itself. which, in a friendly and non intrusive way, displays 
something like this: drive hdc busy, please close the following 
processes first: 1. mplayer 2. blabla.

also, if a blank media is detected on access, it should not be mounted.
usb drives: similar. if user plugs it out without unmounting, its 
unmounted, and processes using files on it gracefully killed, or somehow 
warned. how to warn them? ill let someonbe smarter think of the way 
:) and about ripping it out without closing, wm/anything should yell 
bad user!! you should ALWAYS unmount first!
floppys: i suggest leaving things 100% same. btw. i saw some distros 
having problem with accessing ie /mnt/floppy when there is no floppy 
present. bash goes wild with autocompletion. programs pause for a looong 
time. this could be a kernel bug.
other stuff: dont want to sound like troll, but i guess 98% of people 
dont use anything else.
system partitions: make a clear cut between folders which should be seen 
at all by anyone but root, kernel, special software. in other words: 
reduce clutter in / by hiding almost anything! and partition specific 
mount option such as

userinvisiblefolder=/dev;/sys;/lib;/proc;/sys;/var
should also be possible. face it, for regular user in varoius distros, / 
is to crowded.
i'm not saying this is all 100% correct or possible. couse this is, 
imho, greatest ugliness, user friendlyness and productivity reducer in 
linux. m$ has it a bit better in some ways, but crappier in other. any 
of these could be a killer feature for 2.8 kernel series. or 2.6.2x :)

i would like people to discuss this. be polite please :)
-
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: xor as a lazy comparison

2005-07-24 Thread Grant Coady
On Sun, 24 Jul 2005 18:40:25 +0200 (MEST), Jan Engelhardt [EMAIL PROTECTED] 
wrote:

I have seen this in kernel/signal.c:check_kill_permission()

 (current-euid ^ t-suid)  (current-euid ^ t-uid)

If current-euid and t-suid are the same, the xor returns 0, so these 
statements are effectively the same as a !=

   current-euid != t-suid ...

Why ^ ?
To confuse you, coders with assembly or hardware background throw in 
equivalent bit operations to succinctly describe their visualisation 
of solution space...  Perhaps the writer _wanted_ you to pause and 
think?  Maybe the compiler produces better code?  Try it and see.

Grant.

-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Jesper Juhl
On 7/24/05, Grant Coady [EMAIL PROTECTED] wrote:
 On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
 
 With  2k (raw) errors in 97.something builds of 2.6.12.3, why go
 looking for trouble in -mm?

Because -mm is the development tree. The things in -mm are what's
eventually going to end up in mainline, so that's what you want to be
testing and fixing, and it's also further ahead than 2.6.12.3 (which
is esentially a dead branch except for critical fixes) so stuff may
already have been fixed there that was broken in 2.6.12.3

 
 And doing the compilations is really the trivial part of the work, the
 Got to start somewhere :)
 
Right you are, and I for one am glad you do it. I build randconfig
kernels myself to look for trouble spots, but I can't get anywhere
near building 200+ configs. On a good day I may build 5 or 6
randconfigs of the latest kernel inbetween doing other things, so
getting hold of the results of several hundred randconfig builds gives
me a lot of material to work on that I would never have the time to
gather myself. Thanks.

-- 
Jesper Juhl [EMAIL PROTECTED]
Don't top-post  http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please  http://www.expita.com/nomime.html
-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Adrian Bunk
On Mon, Jul 25, 2005 at 05:42:58AM +1000, Grant Coady wrote:
 On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
 
 it's generally useful, but the target kernel should be the latest -mm
 kernel. 
 097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
 `drm_ioremap_nocache'
 097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
 previously defined here
 097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
 `drm_ioremapfree'
 097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
 previously defined here

This requires the .config for debugging.

My first guess is that drm_memory.h requires a simple #ifdef to allow 
multiple inclusions.

 098-error:drivers/usb/gadget/ether.c:2510: error: `STATUS_BYTECOUNT' 
 undeclared (first use in this function)
 098-error:drivers/usb/gadget/ether.c:2510: error: (Each undeclared identifier 
 is reported only once
 098-error:drivers/usb/gadget/ether.c:2510: error: for each function it 
 appears in.)

Already fixed in 2.6.13-rc3.

 [EMAIL PROTECTED]:/opt/linux/trial4$ grep error *-error |wc -l
 2105
 
 With  2k (raw) errors in 97.something builds of 2.6.12.3, why go 
 looking for trouble in -mm?  
...

You aren't running into problems that are already fixed (see your second 
example above).

 Grant.

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: kernel 2.6 speed

2005-07-24 Thread Puneet Vyas

Ciprian wrote:


Hi guys!

I got a question for you. Apparently kernel 2.6 is
much slower then 2.4 and about 30 times slower then
the windows one.

I'm not an OS guru, but I ran a little and very simple
test. The program bellow, as you can see, measures the
number of cycles performed in 30 seconds.

//- START CODE 

#include stdio.h
#include time.h


int main()
{
time_t initialTime;
time_t testTime;
long counter = 0;
double test = 1;


time(initialTime);
testTime = initialTime;

printf(Here we go...\n);

while((testTime-initialTime)  30)
{
time(testTime);
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf(No. of cycles: %ld\n, counter);

return 0;
}

// END CODE ---


In windows were performed about 300 millions cycles,
while in Linux about 10 millions. This test was run on
Fedora 4 and Suse 9.2 as Linux machines, and Windows
XP Pro with VS .Net 2003 on the MS side. My CPU is a
P4 @3GHz HT 800MHz bus.

I published my little test on several forums and I
wasn't the only one who got these results. All the
other users using 2.6 kernel obtained similar results
regardless of the CPU they had (Intel or AMD). 


Also I downloaded the latest kernel (2.6.12),
configured it specifically for my machine, disabled
all the modules I don't need and compiled it. The
result was a 1.7 MB kernel on which KDE moves faster,
but the processing speed it's the same - same huge
speed ratios.

Also, it shouldn't have any importance, but my HDD is
SATA so the specific modules were required. I don't
think its SCSI modules have any impact on the
processing speed, but you know more on the kernel
architecture then I do.

Now, can anyone explain this and suggest what other
optimizations I should use? The 2.4 version was a lot
faster. I thought the newer versions were supposed to
work faster (or at least just as fast) AND to offer
extra features.

Any help would appreciate.

Thanks,
Ciprian



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 
-

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/

 



Want to increase the latest kernel speed by 5 times ? Use the 
follwoing code instead. :)


// -- Start Code
#include stdio.h
#include time.h


int main()
{
clock_t initialTime;
clock_t testTime;
long counter = 0;
double test = 1;


initialTime = clock() / CLOCKS_PER_SEC;
testTime = initialTime;

printf(Here we go...\n);

while((testTime-initialTime)  30)
{
testTime = clock()/CLOCKS_PER_SEC;
test /= 10;
test *= 10;
test += 10;
test -= 10;

counter ++;

}

printf(No. of cycles: %ld\n, counter);

return 0;
}
//  End code

so essentially you are timing just the time() function.

HTH,
Puneet
-
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 2.6 speed

2005-07-24 Thread Florin Malita
On 7/24/05, Ciprian [EMAIL PROTECTED] wrote:
 test /= 10;
 test *= 10;
 test += 10;
 test -= 10;

You're not trying to benchmark the kernel with those arithmetic
operations are you?! That's completely bogus, the kernel is not
involved in any of that.

As it has been already pointed out, the only OS-dependent and (by far)
the most expensive operation in your loop is the time() function call
- so that's the only thing you're really benchmarking there (besides
compiler optimizations).

 In windows were performed about 300 millions cycles,
 while in Linux about 10 millions. This test was run on
 Fedora 4 and Suse 9.2 as Linux machines, and Windows
 XP Pro with VS .Net 2003 on the MS side. My CPU is a
 P4 @3GHz HT 800MHz bus.

I can only speculate as of why the windoze time() call seems so much
faster: maybe it is implemented in userspace and doesn't involve a
system call. Somebody with more knowledge in the area might
confirm/infirm this.

Even in Linux your results will vary a lot depending on whether the
kernel and glibc support vsyscalls. The FC kernels disable vsyscall
because it's incompatible with NX, not sure about the Suse kernels.
Here's what I get on a P4 1.7 with a vsyscall enabled kernel
(2.6.11.12):

No. of cycles: 65688977

Check this thread for a FC4 kernel performance discussion:
http://www.redhat.com/archives/fedora-devel-list/2005-June/msg01126.html


 Now, can anyone explain this and suggest what other
 optimizations I should use? The 2.4 version was a lot
 faster. 

Your bogus test aside, a certain userland performance degradation when
moving from 2.4 to 2.6 is expected as the x86 timer interrupt
frequency has increased from 100Hz to 1KHz (it's about to be lowered
to 250Hz) - so your apps are interrupted more often. But I wouldn't
expect that degradation to be substantial. If you want to dig in and
measure it you should use asm/rdtsc instead of time().
-
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: IRQ routing problem in 2.6.10-rc2

2005-07-24 Thread Pierre Ossman
Jesper Juhl wrote:


Have you tried the suggestion given ... As a temporary workaround,
the pci=routeirq argument... ?
You could also try the pci=noacpi boot option to see if that changes anything.
  


No, I missed that one. The machine works fine with either of those two
options. I sent a comment with lspci to Bjorn Helgaas as suggested.

Also, that's a fairly old kernel you have there, could you try
2.6.13-rc3, 2.6.13-rc3-git6 or 2.6.13-rc3-mm1 ?

  


I discovered the problem running 2.6.12. I only tried these kernels to
pinpoint where the problem began.

Rgds
Pierre


-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Grant Coady
On Sun, 24 Jul 2005 22:39:32 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:

On Mon, Jul 25, 2005 at 05:42:58AM +1000, Grant Coady wrote:
 On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
 
 it's generally useful, but the target kernel should be the latest -mm
 kernel. 
 097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
 `drm_ioremap_nocache'
 097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
 previously defined here
 097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
 `drm_ioremapfree'
 097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
 previously defined here

This requires the .config for debugging.
Here:
  ftp://ftp.scatter.mine.nu/develop/trial4-097-config.gz

My first guess is that drm_memory.h requires a simple #ifdef to allow 
multiple inclusions.

I can tell you:
--- linux-2.6.12.3b/drivers/char/drm/drm_memory.h.orig  2005-06-18 
05:48:29.0 +1000
+++ linux-2.6.12.3b/drivers/char/drm/drm_memory.h   2005-07-25 
06:57:41.0 +1000
@@ -33,6 +33,9 @@
  * OTHER DEALINGS IN THE SOFTWARE.
  */
 
+#ifndef DRM_MEMORY_H
+#define DRM_MEMORY_H
+
 #include linux/config.h
 #include linux/highmem.h
 #include linux/vmalloc.h
@@ -194,4 +197,5 @@
iounmap(pt);
 }
 
+#endif

does not fix it, though it's probably not what you had in mind, first try...
Simple fix didn't...  Now I got to read the code, takes a little more 
effort :)
...
You aren't running into problems that are already fixed (see your second 
example above).
I see your point, thanks for feedback.  

Grant.

-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Adrian Bunk
On Mon, Jul 25, 2005 at 07:13:02AM +1000, Grant Coady wrote:
 On Sun, 24 Jul 2005 22:39:32 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
 
 On Mon, Jul 25, 2005 at 05:42:58AM +1000, Grant Coady wrote:
  On Sun, 24 Jul 2005 11:13:27 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
  
  it's generally useful, but the target kernel should be the latest -mm
  kernel. 
  097-error:drivers/char/drm/drm_memory.h:163: error: redefinition of 
  `drm_ioremap_nocache'
  097-error:drivers/char/drm/drm_memory.h:163: error: `drm_ioremap_nocache' 
  previously defined here
  097-error:drivers/char/drm/drm_memory.h:174: error: redefinition of 
  `drm_ioremapfree'
  097-error:drivers/char/drm/drm_memory.h:174: error: `drm_ioremapfree' 
  previously defined here
 
 This requires the .config for debugging.
 Here:
   ftp://ftp.scatter.mine.nu/develop/trial4-097-config.gz
 
 My first guess is that drm_memory.h requires a simple #ifdef to allow 
 multiple inclusions.
 
 I can tell you:
 --- linux-2.6.12.3b/drivers/char/drm/drm_memory.h.orig2005-06-18 
 05:48:29.0 +1000
 +++ linux-2.6.12.3b/drivers/char/drm/drm_memory.h 2005-07-25 
 06:57:41.0 +1000
 @@ -33,6 +33,9 @@
   * OTHER DEALINGS IN THE SOFTWARE.
   */
  
 +#ifndef DRM_MEMORY_H
 +#define DRM_MEMORY_H
 +
  #include linux/config.h
  #include linux/highmem.h
  #include linux/vmalloc.h
 @@ -194,4 +197,5 @@
   iounmap(pt);
  }
  
 +#endif
 
 does not fix it, though it's probably not what you had in mind, first try...

That's what I had in mind.

 Simple fix didn't...  Now I got to read the code, takes a little more 
 effort :)
...

Looking at the .config, the problem is actually:
  CONFIG_BROKEN=y

You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
any errors you see with CONFIG_BROKEN=y aren't interesting.

 Grant.

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: kernel page size explanation

2005-07-24 Thread Nix
On Mon, 25 Jul 2005, VASM wrote:
 i had one question 
 does the linux kernel support only one default page size even if the
 processor on which it is working supports multiple ?

No. Some architectures have compile-time support for multiple different
page sizes (e.g. Itanium, SPARC64); many have support for a
(non-swappable) `large pages) system, and a filesystem backed by huge
pages. (Often, the kernel is stored in huge pages, to keep the number
of page table entries wasted by the nonswappable kernel to a minimum.)

What is *not* presently supported is using multiple page sizes to
back userspace processes; that size is currently fixed at compile-time,
even on architectures supporting multiple variably-sized pages.

-- 
`But of course, GR is the very best relativity for the masses.'
 --- Wayne Throop
-
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: RTC Timezone

2005-07-24 Thread Bernd Eckenfels
In article [EMAIL PROTECTED] you wrote:
 My RTC clock is set to the local timezone. However, when I boot linux using 
 the -b option, to stop by a shell before the bootscripts begin, the clock is 
 exaclty two hours ahead.

The problem is that the clock is correct, but the timezone of your system is
not set yet. You can fix this by running the clock in UTC or not stop the boot
process that early.

Greetings
Bernd
-
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: xor as a lazy comparison

2005-07-24 Thread Jan Engelhardt
To confuse you, coders with assembly or hardware background throw in 

I doubt that. I'm good enough assembly to see this :)

equivalent bit operations to succinctly describe their visualisation 
of solution space...  Perhaps the writer _wanted_ you to pause and 
think?  Maybe the compiler produces better code?  Try it and see.

It produces a simple CMP. Should not be inefficient, though.


Jan Engelhardt
-- 
-
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 2.6 speed

2005-07-24 Thread Jan Engelhardt
I got a question for you. Apparently kernel 2.6 is
much slower then 2.4 and about 30 times slower then
the windows one.

I'm not an OS guru, but I ran a little and very simple
test. The program bellow, as you can see, measures the
number of cycles performed in 30 seconds.

I suggest that you take out the time stuff and measure the whole running time, 
at the shell level.
Under Linux you can do that using time ./myprog - how you do it under 
Windows is another concern, but you can write a small time program for 
windows, too.


Jan Engelhardt
-- 
-
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 test: finding compile errors with make randconfig

2005-07-24 Thread Grant Coady
On Sun, 24 Jul 2005 23:27:22 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
Looking at the .config, the problem is actually:
  CONFIG_BROKEN=y

You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
any errors you see with CONFIG_BROKEN=y aren't interesting.

Very good point.

$ grep CONFIG_BROKEN=y *config |wc -l
24

From 106 .configs, trap for young players...  I'll skip compiling 
CONFIG_BROKEN=y .configs then.

Thanks,
Grant.

-
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: xor as a lazy comparison

2005-07-24 Thread Puneet Vyas

Jan Engelhardt wrote:

To confuse you, coders with assembly or hardware background throw in 
   



I doubt that. I'm good enough assembly to see this :)

 

equivalent bit operations to succinctly describe their visualisation 
of solution space...  Perhaps the writer _wanted_ you to pause and 
think?  Maybe the compiler produces better code?  Try it and see.
   



It produces a simple CMP. Should not be inefficient, though.


Jan Engelhardt
 

I just compiled two identical program , one with != and other with 
^. The assembly output is identical.

-
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] Rename __lock_page to lock_page_slow

2005-07-24 Thread Christoph Hellwig
On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote:
 In order to allow for interruptible and asynchronous versions of
 lock_page in conjunction with the wait_on_bit changes, we need to
 define low-level lock page routines which take an additional
 argument, i.e a wait queue entry and may return non-zero status,
 e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc. This patch renames 
 __lock_page to lock_page_slow, so that __lock_page and 
 __lock_page_slow can denote the versions which take a wait queue 
 parameter.

How many users that don't use a waitqueue parameter will be left
once all AIO patches go in?

-
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] fix compilation in collie.c

2005-07-24 Thread Russell King
On Thu, Jul 21, 2005 at 07:25:27AM +0200, Pavel Machek wrote:
 This fixes wrong number of arguments in call to write_scoop_reg, fixes
 map_name and John's email. Please apply,
 
 Signed-off-by: Pavel Machek [EMAIL PROTECTED]

Nacked.

I'd like John (or someone) to look at this.  I'm particularly worred
about:

1. passing NULL into (read|write)_scoop_reg() - which use dev_get_drvdata()
   on this.  Given the choice between creating code which will definitely
   oops but not error or warn vs not compiling, I'll take not compiling
   any day.

2. whether this is supposed to be using the sharp chip driver rather
   than the cfi stuff.

-- 
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 2/6] Rename __lock_page to lock_page_slow

2005-07-24 Thread Christoph Hellwig
On Sun, Jul 24, 2005 at 11:17:02PM +0100, Christoph Hellwig wrote:
 On Mon, Jun 20, 2005 at 09:54:04PM +0530, Suparna Bhattacharya wrote:
  In order to allow for interruptible and asynchronous versions of
  lock_page in conjunction with the wait_on_bit changes, we need to
  define low-level lock page routines which take an additional
  argument, i.e a wait queue entry and may return non-zero status,
  e.g -EINTR, -EIOCBRETRY, -EWOULDBLOCK etc. This patch renames 
  __lock_page to lock_page_slow, so that __lock_page and 
  __lock_page_slow can denote the versions which take a wait queue 
  parameter.
 
 How many users that don't use a waitqueue parameter will be left
 once all AIO patches go in?

Actually looking at the later patches we always seem to pass
current-io_wait anyway, so is there a real point for having the
argument?

-
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 2.6 speed

2005-07-24 Thread Lee Revell
On Sun, 2005-07-24 at 17:03 -0400, Florin Malita wrote:
 the x86 timer interrupt
 frequency has increased from 100Hz to 1KHz (it's about to be lowered
 to 250Hz)

This is by no means a done deal.  So far no one has posted ANY evidence
that dropping HZ to 250 helps (except one result on a atypically large
system), and there's plenty of evidence that it doesn't.

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/


ping^2: [PATCH] move /proc/ppc_htab creating self-contained in arch/ppc/ code

2005-07-24 Thread Christoph Hellwig
On Mon, Jun 27, 2005 at 11:05:02PM +0200, Christoph Hellwig wrote:
 On Wed, May 04, 2005 at 08:44:39PM +0200, Christoph Hellwig wrote:
  additional benefit is cleaning up the ifdef mess in ppc_htab.c
  
  
  Signed-off-by: Christoph Hellwig [EMAIL PROTECTED]
 
 ping?


Index: arch/ppc/kernel/ppc_htab.c
===
--- b023d524fb0a3b71aa0b957ce7c5540611497370/arch/ppc/kernel/ppc_htab.c  
(mode:100644 sha1:ca810025993f3a9ab882fb46722cd46543b6e85e)
+++ uncommitted/arch/ppc/kernel/ppc_htab.c  (mode:100644)
@@ -32,9 +32,6 @@
 #include asm/system.h
 #include asm/reg.h
 
-static int ppc_htab_show(struct seq_file *m, void *v);
-static ssize_t ppc_htab_write(struct file * file, const char __user * buffer,
- size_t count, loff_t *ppos);
 extern PTE *Hash, *Hash_end;
 extern unsigned long Hash_size, Hash_mask;
 extern unsigned long _SDR1;
@@ -46,19 +43,7 @@
 extern unsigned int primary_pteg_full;
 extern unsigned int htab_hash_searches;
 
-static int ppc_htab_open(struct inode *inode, struct file *file)
-{
-   return single_open(file, ppc_htab_show, NULL);
-}
-
-struct file_operations ppc_htab_operations = {
-   .open   = ppc_htab_open,
-   .read   = seq_read,
-   .llseek = seq_lseek,
-   .write  = ppc_htab_write,
-   .release= single_release,
-};
-
+#ifdef CONFIG_PROC_FS
 static char *pmc1_lookup(unsigned long mmcr0)
 {
switch ( mmcr0  (0x7f7) )
@@ -132,6 +117,16 @@
return 0;
}
 
+   seq_printf(m, PTE Hash Table Information\n
+ Size\t\t: %luKb\n
+ Buckets\t\t: %lu\n
+ Address\t\t: %08lx\n
+ Entries\t\t: %lu\n,
+  (unsigned long)(Hash_size10),
+ (Hash_size/(sizeof(PTE)*8)),
+ (unsigned long)Hash,
+ Hash_size/sizeof(PTE));
+
 #ifndef CONFIG_PPC64BRIDGE
for (ptr = Hash; ptr  Hash_end; ptr++) {
unsigned int mctx, vsid;
@@ -146,32 +141,16 @@
else
uptes++;
}
-#endif
 
-   seq_printf(m,
- PTE Hash Table Information\n
- Size\t\t: %luKb\n
- Buckets\t\t: %lu\n
- Address\t\t: %08lx\n
- Entries\t\t: %lu\n
-#ifndef CONFIG_PPC64BRIDGE
- User ptes\t: %u\n
+   seq_printf(m, User ptes\t: %u\n
  Kernel ptes\t: %u\n
- Percent full\t: %lu%%\n
-#endif
-  , (unsigned long)(Hash_size10),
- (Hash_size/(sizeof(PTE)*8)),
- (unsigned long)Hash,
- Hash_size/sizeof(PTE)
-#ifndef CONFIG_PPC64BRIDGE
-  , uptes,
+ Percent full\t: %lu%%\n,
+ uptes,
  kptes,
- ((kptes+uptes)*100) / (Hash_size/sizeof(PTE))
+ ((kptes+uptes)*100) / (Hash_size/sizeof(PTE)));
 #endif
-   );
 
-   seq_printf(m,
- Reloads\t\t: %lu\n
+   seq_printf(m, Reloads\t\t: %lu\n
  Preloads\t: %lu\n
  Searches\t: %u\n
  Overflows\t: %u\n
@@ -180,20 +159,19 @@
  primary_pteg_full, htab_evicts);
 #endif /* CONFIG_PPC_STD_MMU */
 
-   seq_printf(m,
- Non-error misses: %lu\n
+   seq_printf(m, Non-error misses: %lu\n
  Error misses\t: %lu\n,
  pte_misses, pte_errors);
return 0;
 }
 
+#ifdef CONFIG_PPC_STD_MMU
 /*
  * Allow user to define performance counters and resize the hash table
  */
 static ssize_t ppc_htab_write(struct file * file, const char __user * ubuffer,
  size_t count, loff_t *ppos)
 {
-#ifdef CONFIG_PPC_STD_MMU
unsigned long tmp;
char buffer[16];
 
@@ -312,12 +290,43 @@
}
 
return count;
+}
 #else /* CONFIG_PPC_STD_MMU */
+static ssize_t ppc_htab_write(struct file * file, const char __user * ubuffer,
+ size_t count, loff_t *ppos)
+{
return 0;
+}
 #endif /* CONFIG_PPC_STD_MMU */
+
+static int ppc_htab_open(struct inode *inode, struct file *file)
+{
+   return single_open(file, ppc_htab_show, NULL);
 }
 
-int proc_dol2crvec(ctl_table *table, int write, struct file *filp,
+static struct file_operations ppc_htab_operations = {
+   .open   = ppc_htab_open,
+   .read   = seq_read,
+   .llseek = seq_lseek,
+   .write  = ppc_htab_write,
+   .release= single_release,
+};
+
+static int __init ppc_htab_proc_init(void)
+{
+   struct proc_dir_entry *entry;
+
+   entry = create_proc_entry(ppc_htab, S_IRUGO|S_IWUSR, NULL);
+   if (entry)
+   

Re: [patch] fix compilation in collie.c

2005-07-24 Thread Richard Purdie
On Sun, 2005-07-24 at 23:35 +0100, Russell King wrote:
 I'd like John (or someone) to look at this.  I'm particularly worred
 about:
 
 1. passing NULL into (read|write)_scoop_reg() - which use dev_get_drvdata()
on this.  Given the choice between creating code which will definitely
oops but not error or warn vs not compiling, I'll take not compiling
any day.

They should read write_scoop_reg(colliescoop_device.dev, ...); in this
case. 

There is a similar problem with drivers/input/keyboard/corgikbd.c for
which the patch has been in the input maintainer's queue for months :-(.

 2. whether this is supposed to be using the sharp chip driver rather
than the cfi stuff.

I think the aim was to use the cfi code but there were problems with it
not working so the sharp chip driver was being used in the meantime.
John will hopefully be able to comment more about this.

Richard

-
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 NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

2005-07-24 Thread Trond Myklebust
su den 24.07.2005 Klokka 16:36 (+0200) skreiv Rene Scharfe:
 [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()
 
 Function nfs_block_bits() an open-coded version of (the non-existing)
 rounddown_pow_of_two().  That means that for non-power-of-two target
 sizes it returns half the size needed for a block to fully contain
 the target.  I guess this is wrong. :-)  The patch uses the built-in
 roundup_pow_of_two() instead.

What non-power-of-two target? Anything _not_ aligned to a power of two
boundary is a BUG!

Cheers,
  Trond

-
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: Device supported by the OSS trident driver not supported by ALSA

2005-07-24 Thread Alan Cox
On Sad, 2005-07-23 at 22:04 +0200, Adrian Bunk wrote:
 The OSS trident driver has 5 different pci_device_id entries.
 
 For 4 of them there seems to be similar ALSA support, but I can't find 
 any ALSA equivalent for the following entry:
 {PCI_VENDOR_ID_INTERG, PCI_DEVICE_ID_INTERG_5050,
  PCI_ANY_ID, PCI_ANY_ID, 0, 0, CYBER5050},
 
 Can anyone tell my why this device is supported by the OSS trident 
 driver but not by ALSA?

The OSS driver supports the CyberPro T-squared core integrated into the
cyberpro chipset while the ALSA driver only supports the others. Should
be easy for someone to resolve. I don't have any 5000 hardware to test
it however.

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: kernel 2.6 speed

2005-07-24 Thread Alan Cox
On Sul, 2005-07-24 at 12:12 -0700, Ciprian wrote:
 I'm not an OS guru, but I ran a little and very simple
 test. The program bellow, as you can see, measures the
 number of cycles performed in 30 seconds.

No it measures the performance of the time() call. Windows has some
funky optimisations that we never bother with because time() isn't a hot
path in the real world.

Instead try code which does


time(start);
while(count++  LOTS) {
  Do_stuff
}
time(end)

and you'll find the numbers on pure CPU work are essentially CPU bound
not OS affected at all

-
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 NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()

2005-07-24 Thread Trond Myklebust
su den 24.07.2005 Klokka 19:09 (-0400) skreiv Trond Myklebust:
 su den 24.07.2005 Klokka 16:36 (+0200) skreiv Rene Scharfe:
  [PATCH NFS 3/3] Replace nfs_block_bits() with roundup_pow_of_two()
  
  Function nfs_block_bits() an open-coded version of (the non-existing)
  rounddown_pow_of_two().  That means that for non-power-of-two target
  sizes it returns half the size needed for a block to fully contain
  the target.  I guess this is wrong. :-)  The patch uses the built-in
  roundup_pow_of_two() instead.
 
 What non-power-of-two target? Anything _not_ aligned to a power of two
 boundary is a BUG!

Furthermore, rounding UP in order to correct this non-alignment would
definitely be a bug.

If users choose to override the default rsize/wsize, that is almost
always in order to limit the UDP fragmentation per read/write request on
lossy networks. By rounding up, you are doubling the number of fragments
that the user requested instead of respecting the limit.

Cheers,
  Trond

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


[-mm PATCH] v4l: hybrid dvb: rename CFLAGS from CONFIG_DVB_xxxx back to original HAVE_xxxx

2005-07-24 Thread Michael Krufky


The #define CONFIG_DVB_* are actually CFLAGS set by Makefile.
CONFIG_* namespace is reserved for Kconfig. This renames them back to HAVE_*

Signed-off-by: Michael Krufky [EMAIL PROTECTED]

 linux/drivers/media/video/cx88/Makefile |8 ++--
 linux/drivers/media/video/cx88/cx88-dvb.c   |   26 
 linux/drivers/media/video/saa7134/Makefile  |4 +-
 linux/drivers/media/video/saa7134/saa7134-dvb.c |   16 -
 4 files changed, 27 insertions(+), 27 deletions(-)

diff -u linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c 
linux/drivers/media/video/cx88/cx88-dvb.c
--- linux-2.6.13/drivers/media/video/cx88/cx88-dvb.c2005-07-24 
17:59:15.0 +
+++ linux/drivers/media/video/cx88/cx88-dvb.c   2005-07-24 18:21:52.0 
+
@@ -1,5 +1,5 @@
 /*
- * $Id: cx88-dvb.c,v 1.51 2005/07/24 19:09:28 mkrufky Exp $
+ * $Id: cx88-dvb.c,v 1.52 2005/07/24 22:12:47 mkrufky Exp $
  *
  * device driver for Conexant 2388x based TV cards
  * MPEG Transport Stream (DVB) routines
@@ -35,17 +35,17 @@
 #include cx88.h
 #include dvb-pll.h
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 # include mt352.h
 # include mt352_priv.h
 #endif
-#ifdef CONFIG_DVB_CX22702
+#ifdef HAVE_CX22702
 # include cx22702.h
 #endif
-#ifdef CONFIG_DVB_OR51132
+#ifdef HAVE_OR51132
 # include or51132.h
 #endif
-#ifdef CONFIG_DVB_LGDT3302
+#ifdef HAVE_LGDT3302
 # include lgdt3302.h
 #endif
 
@@ -104,7 +104,7 @@
 
 /* -- */
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 static int dvico_fusionhdtv_demod_init(struct dvb_frontend* fe)
 {
static u8 clock_config []  = { CLOCK_CTL,  0x38, 0x39 };
@@ -174,7 +174,7 @@
 };
 #endif
 
-#ifdef CONFIG_DVB_CX22702
+#ifdef HAVE_CX22702
 static struct cx22702_config connexant_refboard_config = {
.demod_address = 0x43,
.output_mode   = CX22702_SERIAL_OUTPUT,
@@ -190,7 +190,7 @@
 };
 #endif
 
-#ifdef CONFIG_DVB_OR51132
+#ifdef HAVE_OR51132
 static int or51132_set_ts_param(struct dvb_frontend* fe,
int is_punctured)
 {
@@ -207,7 +207,7 @@
 };
 #endif
 
-#ifdef CONFIG_DVB_LGDT3302
+#ifdef HAVE_LGDT3302
 static int lgdt3302_pll_set(struct dvb_frontend* fe,
struct dvb_frontend_parameters* params,
u8* pllbuf)
@@ -258,7 +258,7 @@
 
/* init frontend */
switch (dev-core-board) {
-#ifdef CONFIG_DVB_CX22702
+#ifdef HAVE_CX22702
case CX88_BOARD_HAUPPAUGE_DVB_T1:
dev-dvb.frontend = cx22702_attach(hauppauge_novat_config,
   dev-core-i2c_adap);
@@ -269,7 +269,7 @@
   dev-core-i2c_adap);
break;
 #endif
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
case CX88_BOARD_DVICO_FUSIONHDTV_DVB_T1:
dev-core-pll_addr = 0x61;
dev-core-pll_desc = dvb_pll_lg_z201;
@@ -291,13 +291,13 @@
 dev-core-i2c_adap);
break;
 #endif
-#ifdef CONFIG_DVB_OR51132
+#ifdef HAVE_OR51132
case CX88_BOARD_PCHDTV_HD3000:
dev-dvb.frontend = or51132_attach(pchdtv_hd3000,
 dev-core-i2c_adap);
break;
 #endif
-#ifdef CONFIG_DVB_LGDT3302
+#ifdef HAVE_LGDT3302
case CX88_BOARD_DVICO_FUSIONHDTV_3_GOLD_Q:
dev-ts_gen_cntrl = 0x08;
{
diff -u linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c 
linux/drivers/media/video/saa7134/saa7134-dvb.c
--- linux-2.6.13/drivers/media/video/saa7134/saa7134-dvb.c  2005-07-24 
17:56:27.0 +
+++ linux/drivers/media/video/saa7134/saa7134-dvb.c 2005-07-24 
18:21:52.0 +
@@ -1,5 +1,5 @@
 /*
- * $Id: saa7134-dvb.c,v 1.22 2005/07/23 10:08:00 mkrufky Exp $
+ * $Id: saa7134-dvb.c,v 1.23 2005/07/24 22:12:47 mkrufky Exp $
  *
  * (c) 2004 Gerd Knorr [EMAIL PROTECTED] [SuSE Labs]
  *
@@ -35,11 +35,11 @@
 #include saa7134-reg.h
 #include saa7134.h
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 # include mt352.h
 # include mt352_priv.h /* FIXME */
 #endif
-#ifdef CONFIG_DVB_TDA1004X
+#ifdef HAVE_TDA1004X
 # include tda1004x.h
 #endif
 
@@ -53,7 +53,7 @@
 
 /* -- */
 
-#ifdef CONFIG_DVB_MT352
+#ifdef HAVE_MT352
 static int pinnacle_antenna_pwr(struct saa7134_dev *dev, int on)
 {
u32 ok;
@@ -152,7 +152,7 @@
 
 /* -- */
 
-#ifdef CONFIG_DVB_TDA1004X
+#ifdef HAVE_TDA1004X
 static int philips_tu1216_pll_init(struct dvb_frontend *fe)
 {
struct saa7134_dev *dev = fe-dvb-priv;
@@ -384,7 +384,7 @@
return 0;
 }
 
-#ifdef CONFIG_DVB_TDA1004X
+#ifdef HAVE_TDA1004X
 static struct tda1004x_config medion_cardbus = {
.demod_address = 0x08,
.invert= 1,
@@ -547,14 +547,14 @@

Re: Lack of Documentation about SA_RESTART...

2005-07-24 Thread Theodore Ts'o
On Sat, Jul 23, 2005 at 05:30:42PM -0700, Linus Torvalds wrote:
 On Mon, 11 Jul 2005, Theodore Ts'o wrote:
  
  According to the Single Unix Specification V3, all functions that
  return EINTR are supposed to restart if a process receives a signal
  where signal handler has been installed with the SA_RESTART flag.  
 
 That can't be right.
 
 Some operations, like select() and pause() always return EINTR, and 
 indeed, real applications will break if you always restart. Restarting a 
 pause() would be nonsensical.

The spect says unless otherwise specified.  The description for
pause() states that the process will sleep until receiving a signal
that terminates the process or causes it to call signal-handling
function.  That would presumably count as an otherwise specified.

- Ted
-
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/


Problem with Asus P4C800-DX and P4 -Northwood-

2005-07-24 Thread Andreas Baer

Hi everyone,

First I want to say sorry for this BIG post, but it seems that I have no 
other chance. :)


I have a Asus P4C800-DX with a P4 2,4 GHz 512 KB L2 Cache Northwood 
Processor (lowest Processor that supports HyperThreading) and 1GB DDR400 
RAM. I'm also running S-ATA disks with about 50 MB/s (just to show that 
it shouldn't be due to hard disk speed). Everything was bought back in 
2003 and I recently upgraded to the lastest BIOS Version. I've installed 
Gentoo Linux and WinXP with dual-boot on this system.


Now to my problem:

I'm currently developing a little database in C++ (runs currently under 
Windows and Linux) that internally builds up an R-Tree and does a lot of 
equality tests and other time consuming checks. For perfomance issue I 
ran a test with 20 entries and it took me about 3 minutes to 
complete under Gentoo Linux.


So I ran the same test in Windows on the same platform and it took about 
30(!) seconds. I was a little bit surprised about this result so I 
started to run several tests on different machines like an Athlon XP 
2000+ platform and on my P4 3GHz Prescott Notebook and they all showed 
something about 30 seconds or below. Then I began to search for errors 
or any misconfiguration in Gentoo, in my code and also for people that 
have made equal experiences with that hardware configuration on the 
internet. I thought I have a problem with a broken gcc or libraries like 
glibc or libstdc++ and so I recompiled my whole system with the stable 
gcc 3.3.5 release, but that didn't make any changes. I also tried an 
Ubuntu and a Suse LiveCD to verify that it has nothing to do with Gentoo 
and my kernel version and they had the same problem and ran the test in 
about 3 min.


Currently I'm at a loss what to do. I'm beginning to think that this is 
maybe a kernel problem because I have no problems under Windows and it 
doesn't matter whether I change any software or any configuration in 
Gentoo. I'm currently running kernel-2.6.12, but the Livecd's had other 
kernels.


HyperThreading(HT) is also not the reason for the loss of power, because 
I tried to disable it and to create a uniprocessor kernel, but that 
didn't solve the problem.


If you need some output of my configuration/log files or anything like 
that, just mail me.


Is it possible that the kernel has a lack of support for P4 with 
Northwood core? Maybe only this one? Could I solve the problem if I 
change the processor to a Prescott core? Perhaps someone could provide 
any information if this would make any sense or not.


Thanks in advance for anything that could help.

...sorry for bad english :)
-
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] pcibios_bus_to_resource for parisc [Was: Re: [PATCH 8/8] pci and yenta: pcibios_bus_to_resource]

2005-07-24 Thread Grant Grundler
On Sat, Jul 23, 2005 at 09:54:11PM +0200, Dominik Brodowski wrote:
 Oh, yes, I seem to have missed it. Sorry. Does this patch look good?

Yes.

Acked-by: Grant Grundler [EMAIL PROTECTED]

I'll commit this to the cvs.parisc-linux.org tree as well.
Willy can let me deal with the collision if it's not trivial
on his next merge.

thanks,
grant

 
 
 Add pcibios_bus_to_resource for parisc.
 
 Signed-off-by: Dominik Brodowski [EMAIL PROTECTED]
 
 Index: 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
 ===
 --- 2.6.13-rc3-git2.orig/arch/parisc/kernel/pci.c
 +++ 2.6.13-rc3-git2/arch/parisc/kernel/pci.c
 @@ -255,8 +255,26 @@ void __devinit pcibios_resource_to_bus(s
   pcibios_link_hba_resources(hba-lmmio_space, bus-resource[1]);
  }
  
 +void pcibios_bus_to_resource(struct pci_dev *dev, struct resource *res,
 +   struct pci_bus_region *region)
 +{
 + struct pci_bus *bus = dev-bus;
 + struct pci_hba_data *hba = HBA_DATA(bus-bridge-platform_data);
 +
 + if (res-flags  IORESOURCE_MEM) {
 + res-start = PCI_HOST_ADDR(hba, region-start);
 + res-end = PCI_HOST_ADDR(hba, region-end);
 + }
 +
 + if (res-flags  IORESOURCE_IO) {
 + res-start = region-start;
 + res-end = region-end;
 + }
 +}
 +
  #ifdef CONFIG_HOTPLUG
  EXPORT_SYMBOL(pcibios_resource_to_bus);
 +EXPORT_SYMBOL(pcibios_bus_to_resource);
  #endif
  
  /*
-
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: Memory Management

2005-07-24 Thread Márcio Oliveira

Neil Horman wrote:


On Sat, Jul 23, 2005 at 08:16:20PM -0300, Márcio Oliveira wrote:
 


Neil,

   

The best way I can think to do that is take a look at /proc/slabinfo.  
That will

likely give you a pointer to which area of code is eating up your memory.


 


OK. I will monitor the /proc/slabinfo file.

   


Based on the sysrq-m info you posted it looks like due to fragmentation the
largest chunk of memory you can allocate is 2MB (perhaps less depending on
address space availability).  If you can build a test kernel to do a 
show_state
rather than a show_mem at the beginning of oom_kil, then you should be 
able to

tell who is trying to do an allocation that leads to kswapd calling
out_of_memory.


 

Neil, I'm trying to recompile the kernel source 2.4.21-32.0.1 and get 
some error messages:


In file included from 
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h:13,
   from 
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h:6,
   from 
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:12,

   from 3w-.c:172:
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: warning: 
parameter names (without types) in function declaration
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:61: field 
`loops_per_jiffy_R_ver_str' declared as a function
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:84: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: syntax 
error before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:269: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/asm/processor.h:273: warning: 
parameter names (without types) in function declaration

In file included from 3w-.c:172:
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: 
`inter_module_register_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:190: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: 
`inter_module_unregister_R_ver_str' declared as function returning a 
function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:191: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: 
`inter_module_get_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:192: warning: 
parameter names (without types) in function declaration
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: 
`inter_module_get_request_R_ver_str' declared as function returning a 
function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:193: warning: 
parameter names (without types) in function declaration
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: invalid 
suffix on integer constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: syntax error 
before numeric constant
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: 
`inter_module_put_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:194: warning: 
function declaration isn't a prototype
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: 
`try_inc_mod_count_R_ver_str' declared as function returning a function
/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h:203: warning: 
parameter names (without types) in function declaration

make[3]: *** [3w-_10200033.o] Error 1
make[3]: Leaving directory 
`/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon/3w-_10200033'

make[2]: *** [_modsubdir_3w-_10200033] Error 2
make[2]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers/addon'
make[1]: *** [_modsubdir_addon] Error 2
make[1]: Leaving directory `/usr/src/linux-2.4.21-32.0.1.EL/drivers'
make: *** [_mod_drivers] Error 2

Is there any relationship between the sysrq-m changes to do show_state() 
rather than a show_mem() and the compiling erros?


/usr/src/linux-2.4.21-32.0.1.EL/include/linux/prefetch.h, line 13:
  #include asm/processor.h

/usr/src/linux-2.4.21-32.0.1.EL/include/linux/list.h ,line 6:
  #include linux/prefetch.h

/usr/src/linux-2.4.21-32.0.1.EL/include/linux/module.h, line 

Fault tolerance. . .

2005-07-24 Thread John Richard Moser
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I'm playing Skies of Arcadia Legends on my GameCube and noticing that
software bugs continuously produce errors (no scratch on the disk; I can
have an error, reset, play through it easy).  This leads me on and on,
but now it's lead me into thinking about fault tolerance.

Leaving the GameCube and moving to my computer, I'm wondering if
something could be done kernel-end to provide automatic application and
system fault recovery.  Thinking about it, I can come up with a few cute
ideas, though they don't really seem all that realistic.  Still, it
might be fun to share them and see what kinds of comments I get.

I'm thinking of application level fault tolerance using roll-back states
or something weird, to restore the system as affected by that
application to a point before the error.  The obvious visual effect
would be that if an application were to crash, it and potentially
interrelated applications would suddenly reset to a state a few seconds
to a few minutes earlier.

Like I said, this is a really dumb idea, but it's kind of cute to think
about.  In the 5 minutes I think about this, I'll type some crap here,
then go back to my game and leave this for you all so you can take a
break from real work and read something mildly ammusing.

Interrelating applications:

 - Tasks sharing memory are synchronized at state saves
 - Tasks having mappings to files where writing to the mapping writes to
the file have state saves synchronized starting where one could affect
another and ending where they no longer can affect eachother
  - When a process opens a file another process has open for writing,
the two both have a state save made
  - Following state saves are sychronized temporally between the tasks
  - When neither task can affect the other by writing to said file, the
state saves no longer are required to be synchronized
 - Tasks communicating over sockets are synchronized at save states
 - Tasks communicating via pipes are synchronized at save states
 - When a parent is rolled back to precede a fork(), the fork() child dies

Synchronized means that when the state is set to be saved for
roll-back in one task, interrelated tasks are also frozen and saved at
the same time.

Saving a state is easy:

 - Lock a spinlock
 - Add an entry to a linked list for a state save, with registers and such
 - Remove entries older than the limit for the oldest save
 - Open spinlock

Maintaining the state is also easy:

 - When a file is changed, track the changes and attach them to the last
state save
 - When memory pages are written to, cache the old copies first
(unfortunately each page has to be made CoW after every state save)

Restoring a state is also easy:

 - At untrapped sigsegv, sigabrt, roll back changes and related changes
 - Repeted incident means rolling back farther

This of course raises many questions and concerns that make this
rediculous and probably not entirely possible:

 - What about huge modifications to files in a short time?  Make a new
file, then write 10,000,000,000 bytes past the end and watch it crash.
 - What about lost work in interrelated applications?
 - Will the system state remain consistent?
 - Will it crash over and over and over?
 - Connecting to named pipes? (easily handled, not discussed here)
 - Crashes are usually trappable, and then programs exit cleanly.  They
won't care about this
 - How does a process know to change course if it gets restored?
 - We can probably use this to do some deep-and-dirty espionage, relying
on the fault tolerance when we crash something trying to leak information
 - Darth Vader will use this to find Luke Skywalker

Anyway, whatever.  Comment if you want, I just thought the idea was
cute.  Not practical, but cute.

- --
All content of all messages exchanged herein are left in the
Public Domain, unless otherwise explicitly stated.

Creative brains are a valuable, limited resource. They shouldn't be
wasted on re-inventing the wheel when there are so many fascinating
new problems waiting out there.
 -- Eric Steven Raymond
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFC5EeehDd4aOud5P8RAhK/AJ90BXofS/XPJcr5xsGFhqlf9jJiBQCfcbSG
v2Di7VqKv29jlRjoJiphy0c=
=5H6M
-END PGP SIGNATURE-
-
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/


Incorrect driver getting loaded for Qlogic FC-HBA

2005-07-24 Thread Rajat Jain
Hi,

I do not know which list to put this problem on. And hence ...

I'm using Kernel 2.6.9 and am having a Qlogic QLE2362 FC-HBA in my
system. I selected all the Qlogic SCSI drivers while buiding the
kernel. Now the problem is that every time I reboot, I have to
MANUALLY modprobe the qla2322.ko module in the kernel and only then my
HBA works. By default, the kernel loads qla2300.ko, which is not the
correct driver for the card, and hence the HBA does not work. Here is
the lspci output:

-
0d:07.1 Fibre Channel: QLogic Corp.: Unknown device 2322 (rev 03)
Subsystem: QLogic Corp.: Unknown device 0118
Flags: bus master, 66Mhz, medium devsel, latency 128, IRQ 185
I/O ports at 6400 [size=256]
Memory at d0401000 (64-bit, non-prefetchable) [size=4K]
Capabilities: [44] Power Management version 2
Capabilities: [4c] PCI-X non-bridge device.
Capabilities: [54] Message Signalled Interrupts: 64bit+ Queue=0/3 
Enable-
---

Here is the relevant extract from modules.pcimap:
---
#module  vendor device subvendor  subdevice  class 
class_mask driver_data
qla2300  0x1077 0x2300 0x 0x 0x 0x 0x0
qla2300  0x1077 0x2312 0x 0x 0x 0x 0x0
qla2322  0x1077 0x2322 0x 0x 0x 0x 0x0
---

As can be seen from above, qla2322 is the correct driver for device
2322 (My QLE2362 HBA has a device no 2322, as seen in lspci output).
But for some reason the kernel always loads qla2300 instead on
qla2322. I even tried putting the qla2322 line on top of the two
qla2300 lines in the modules.pcimap file. But with no result.

TIA,

Rajat
-
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] 1 Wire drivers illegally overload NETLINK_NFLOG

2005-07-24 Thread David S. Miller
From: Harald Welte [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 09:33:53 -0400

 I strongly disrecommend increasing NPROTO.  Maybe we should look into
 reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface).

That is how I will fix this 1-wire case, by reusing the NETLINK_FIREWALL
thing.

 But to be honest, I don't really care all that much as long as existing
 and still very actively used values are not just overloaded.

Absolutely.
-
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/


[no subject]

2005-07-24 Thread Matt
subscribe linux-kernel
-
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] 1 Wire drivers illegally overload NETLINK_NFLOG

2005-07-24 Thread David S. Miller
From: Harald Welte [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 09:33:53 -0400

 I strongly disrecommend increasing NPROTO.  Maybe we should look into
 reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface).

ip_queue.c still uses NETLINK_FIREWALL so we really can't use
that.

So instead, as in the patch below, I solved this for now by using
the NETLINK_SKIP value which was reserved years ago yet never
made use of.

diff --git a/drivers/w1/w1_int.c b/drivers/w1/w1_int.c
--- a/drivers/w1/w1_int.c
+++ b/drivers/w1/w1_int.c
@@ -88,7 +88,7 @@ static struct w1_master * w1_alloc_dev(u
 
dev-groups = 23;
dev-seq = 1;
-   dev-nls = netlink_kernel_create(NETLINK_NFLOG, NULL);
+   dev-nls = netlink_kernel_create(NETLINK_W1, NULL);
if (!dev-nls) {
printk(KERN_ERR Failed to create new netlink socket(%u) for w1 
master %s.\n,
NETLINK_NFLOG, dev-dev.bus_id);
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -5,7 +5,7 @@
 #include linux/types.h
 
 #define NETLINK_ROUTE  0   /* Routing/device hook  
*/
-#define NETLINK_SKIP   1   /* Reserved for ENskip  
*/
+#define NETLINK_W1 1   /* 1-wire subsystem 
*/
 #define NETLINK_USERSOCK   2   /* Reserved for user mode socket 
protocols  */
 #define NETLINK_FIREWALL   3   /* Firewalling hook 
*/
 #define NETLINK_TCPDIAG4   /* TCP socket monitoring
*/
-
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/


[no subject]

2005-07-24 Thread Matt Heler
subscribe linux-kernel
-
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] 1 Wire drivers illegally overload NETLINK_NFLOG

2005-07-24 Thread David S. Miller
From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400

 Andrew has no objection against connector and it lives in -mm

A patch sitting in -mm has zero significance.  A lot of junk
and useless things end up there as often Andrew incorporates
just about every single patch he sees posted to linux-kernel
unless he personally knows of some reason why the change might
be wrong.

So it's in -mm is not a metric to use.

 All objections against it was only type of - I do not like it
 Dmitry had some bugfixes which were added.

People like James Morris had very specific objections about it.

You are a control freak and in general very very difficult to work
with, so nobody wants to help you fix things up.
-
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/


(was Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG) Fw: Mail delivery failed: returning message to sender

2005-07-24 Thread David S. Miller

Well, this may be the reason why Evgeniy thinks nobody
has any concrete objections to his connector layer :-(
---BeginMessage---
This message was created automatically by mail delivery software.

A message that you sent could not be delivered to one or more of its
recipients. This is a permanent error. The following address(es) failed:

  [EMAIL PROTECTED]
SMTP error from remote mail server after initial connection:
host mailer.campus.mipt.ru [194.85.82.4]: 554 mailer.campus.mipt.ru ESMTP 
not accepting messages

-- This is a copy of the message, including all the headers. --

Return-path: [EMAIL PROTECTED]
Received: from localhost ([127.0.0.1] ident=davem)
by sunset.davemloft.net with esmtp (Exim 4.52)
id 1DwsXV-0007pe-24; Sun, 24 Jul 2005 19:17:57 -0700
Date: Sun, 24 Jul 2005 19:17:56 -0700 (PDT)
Message-Id: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED], [EMAIL PROTECTED],
 linux-kernel@vger.kernel.org
Subject: Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG
From: David S. Miller [EMAIL PROTECTED]
In-Reply-To: [EMAIL PROTECTED]
References: [EMAIL PROTECTED]
[EMAIL PROTECTED]
X-Mailer: Mew version 4.2 on Emacs 21.4 / Mule 5.0 (SAKAKI)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

From: Evgeniy Polyakov [EMAIL PROTECTED]
Date: Sat, 23 Jul 2005 13:14:55 +0400

 Andrew has no objection against connector and it lives in -mm

A patch sitting in -mm has zero significance.  A lot of junk
and useless things end up there as often Andrew incorporates
just about every single patch he sees posted to linux-kernel
unless he personally knows of some reason why the change might
be wrong.

So it's in -mm is not a metric to use.

 All objections against it was only type of - I do not like it
 Dmitry had some bugfixes which were added.

People like James Morris had very specific objections about it.

You are a control freak and in general very very difficult to work
with, so nobody wants to help you fix things up.
---End Message---


Re: Re: Problem while inserting pciehp (PCI Express Hot-plug) driver

2005-07-24 Thread Rajat Jain
 On Tue, Jul 12, 2005 at 06:01:22PM +0900, Rajat Jain
 wrote:

  Hi,
  
  I'm trying to use the PCI Express Hot-Plug Controller driver
  (pciehp.ko) with Kernel 2.6 so that I can get hot-plug events 
  whenever I add a card to my PCI Express slot.
  
  I built the driver as a module, and am trying to load it 
  manually using modprobe. However, when trying to insert,
  I'm getting the following error:
 
  pciehp: acpi_pciehprm:\_SB.PCI0 _OSC fails=0x5
  pciehp: Both _OSC and OSHP methods do not exist
  FATAL: Error inserting pciehp
 
  (/lib/modules/2.6.9-5.18AXcustom-hotplug/kernel/drivers/pci/hotplug/pciehp.ko):
  No such device
 

 --- Greg KH [EMAIL PROTECTED] wrote:
 Your bios does not support pci express hotplug.  Are
 you sure you have pci express hotplug hardware in your
 system?  If so, contact your bios vendor to get an 
 updated version.
 
 Good luck,
 
  greg k-h

Thanks for replying Greg. I checked again, I have the hardware in my
system. I asked the vendor for bios update, but he says mine is the
latest version.

I downloaded the Intel iasl compiler
(http://developer.intel.com/technology/iapc/acpi/downloads.htm),  and
used it to decompile /proc/acpi/dsdt file (in AML) to its equivalent
ACPI source code. I could not find the _OSC and OSHP control methods
there. Is this information sufficient enough to deduce that I need a
BIOS update? And the hardware is OK but the problem is with the bios?

Just out of curosity, I would appreciate if you could provide me
pointers to OSHP and _OSC methods. What exactly do they mean? Does
every hardware containing a hot-plug controller necessarily has to
implement them both? I checked with ACPI Specs but it contains no
refrence to OSHP method.

Any pointers are more than appreciated,

TIA,

Rajat
-
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] fix compilation in collie.c

2005-07-24 Thread Pavel Machek
This fixes wrong number of arguments in call to write_scoop_reg and
John's email. Please apply,
Pavel

Signed-off-by: Pavel Machek [EMAIL PROTECTED]

diff --git a/arch/arm/mach-sa1100/collie.c b/arch/arm/mach-sa1100/collie.c
--- a/arch/arm/mach-sa1100/collie.c
+++ b/arch/arm/mach-sa1100/collie.c
@@ -11,7 +11,7 @@
  * published by the Free Software Foundation.
  *
  * ChangeLog:
- *  03-06-2004 John Lenz [EMAIL PROTECTED]
+ *  03-06-2004 John Lenz [EMAIL PROTECTED]
  *  06-04-2002 Chris Larson [EMAIL PROTECTED]
  *  04-16-2001 Lineo Japan,Inc. ...
  */
@@ -111,16 +180,18 @@ static struct mtd_partition collie_parti
 
 static void collie_set_vpp(int vpp)
 {
-   write_scoop_reg(SCOOP_GPCR, read_scoop_reg(SCOOP_GPCR) | 
COLLIE_SCP_VPEN);
+   struct device *dev = colliescoop_device.dev;
+
+   write_scoop_reg(dev, SCOOP_GPCR, read_scoop_reg(dev, SCOOP_GPCR) | 
COLLIE_SCP_VPEN);
if (vpp) {
-   write_scoop_reg(SCOOP_GPWR, read_scoop_reg(SCOOP_GPWR) | 
COLLIE_SCP_VPEN);
+   write_scoop_reg(dev, SCOOP_GPWR, read_scoop_reg(dev, 
SCOOP_GPWR) | COLLIE_SCP_VPEN);
} else {
-   write_scoop_reg(SCOOP_GPWR, read_scoop_reg(SCOOP_GPWR)  
~COLLIE_SCP_VPEN);
+   write_scoop_reg(dev, SCOOP_GPWR, read_scoop_reg(dev, 
SCOOP_GPWR)  ~COLLIE_SCP_VPEN);
}
 }
 
 static struct flash_platform_data collie_flash_data = {
.map_name   = cfi_probe,
.set_vpp= collie_set_vpp,
.parts  = collie_partitions,
.nr_parts   = ARRAY_SIZE(collie_partitions),

-- 
teflon -- maybe it is a trademark, but it should not be.
-
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] driver core: Add the ability to unbind drivers to devices from userspace

2005-07-24 Thread Jon Smirl
I just pulled from GIT to test bind/unbind. I couldn't get it to work;
it isn't taking into account the CR on the end of the input value of
the sysfs attribute.  This patch will fix it but I'm sure there is a
cleaner solution.

-- 
Jon Smirl
[EMAIL PROTECTED]


diff --git a/drivers/base/bus.c b/drivers/base/bus.c
--- a/drivers/base/bus.c
+++ b/drivers/base/bus.c
@@ -137,9 +137,11 @@ decl_subsys(bus, ktype_bus, NULL);
 static int driver_helper(struct device *dev, void *data)
 {
const char *name = data;
-
-   if (strcmp(name, dev-bus_id) == 0)
+printk(KERN_ERR unbind: %s %s\n, name, dev-bus_id);
+   if (strncmp(name, dev-bus_id, strlen(dev-bus_id)) == 0) {
+printk(KERN_ERR match\n);
return 1;
+   }
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: kernel 2.6 speed

2005-07-24 Thread Florin Malita
On 7/24/05, Alan Cox [EMAIL PROTECTED] wrote:
 time() isn't a hot
 path in the real world.

That's what you would expect but I've straced stuff calling
gettimeofday() in huge bursts every other second. Obviously braindead
stuff but so is the real world most of the time() ... :)
-
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] I2C: Separate non-i2c hwmon drivers from i2c-core (2/9)

2005-07-24 Thread Greg KH
On Wed, Jul 20, 2005 at 11:46:03PM +0200, Jean Delvare wrote:
 
 So, the approximate timeline would be 1* to 3* right now, 4* after that
 as time permits, and 5* when we estimate that 3* happened long enough
 ago (roughly 1st half of 2006?)
 
 I hope I explained it correctly this time. If not, just complain ;)

Ah, much better, thanks.  Sounds like a great plan, I'll go apply your
patches in a day or so when I catch up from my travels.

thanks,

greg k-h
-
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: device_remove_file and disconnect

2005-07-24 Thread Greg KH
On Thu, Jun 30, 2005 at 10:31:44PM +0200, matthieu castet wrote:
 Then they should be fixed.  Any specific examples?
 
 
 I am a little lasy to list all, but some drivers in driver/usb should 
 have this problem : the first driver I look : ./misc/phidgetkit.c do 
 [1]. So sysfs read don't check if to_usb_interface or usb_get_intfdata 
 return NULL pointer...
 And it is a bit your fault, as many developper should have read your 
 great tutorial [2] ;)

You are correct, I'll go fix those drivers, thanks for pointing it out.
Others pointed out the same thing this week at OLS :)

 Also I always see driver free their privatre data in device disconnect,
 so if read/write from sysfs aren't serialized with device disconnect
 there are still a possible race like I show in my example.
 
 
 Yes, you are correct.  Again, any specific drivers you see with this
 problem?
 I believe near all drivers that use sysfs via device_create_file, as I 
 never see them use mutex in read/write in order to check there aren't in 
 the same time in their disconnect that could free there private data 
 when they do operation on it...
 
 
 Couldn't be possible the make device_remove_file blocking until all the 
 open file are closed ?

Hm, do we even know that those files are opened then?  I'll poke around
in sysfs and see if we could do that.

thanks,

greg k-h
-
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] driver core: Add the ability to unbind drivers to devices from userspace

2005-07-24 Thread Dmitry Torokhov
On Sunday 24 July 2005 23:09, Jon Smirl wrote:
 I just pulled from GIT to test bind/unbind. I couldn't get it to work;
 it isn't taking into account the CR on the end of the input value of
 the sysfs attribute.  This patch will fix it but I'm sure there is a
 cleaner solution.
 

echo -n should take care of this problem I think.

-- 
Dmitry
-
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.11-rc5 and 2.6.12: cannot transmit anything

2005-07-24 Thread Denis Vlasenko
[resend. Did not reach mailing lists, most probably due
to KMail's unstoppable desire to use base64 encoding :)]

Hi folks,

I reported earlied that around linux-2.6.11-rc5 my home box sometimes
does not want to send anything over ethetnet. That report is repeated below
sig.

I finally managed to nail down where this happens.
I instrumented sch_generic.c to trace what happens with packets
to be sent over interface named if. 

On 'good' boot, I see   

2005-07-12_17:26:29.72158 kern.info: qdisc_restart: start
2005-07-12_17:26:29.72164 kern.info: qdisc_restart: skb!=NULL
2005-07-12_17:26:29.72166 kern.info: qdisc_restart: if !netif_queue_stopped...
2005-07-12_17:26:29.72167 kern.info: qdisc_restart: ...hard_start_xmit

in the log, on 'bad' one only qdisc_restart: start.

Below is first report and instrumented part of sch_generic.c.
--
vda

Subject: linux-2.6.11-rc5: mysterious loss of tx

My home box has onboard via-rhine NIC.

Several days ago my father called me and said that
it does not send anything (tcpdump shows only rx'ed pkts
despite pings being attempted etc). I did not investigate
then.

Yesterday I've seen it myself. I bumped up ethtool msglvl.
Looks like via-rhine's hard_start_xmit was not called at all
from network core code! (I did not see debug printks from
rhine's hard_stat_xmit routine)

Whatever I tried (ifconfig down/up, reinit IP config from scratch),
nothing helped. No tx whatsoever was attempted by kernel, it seems.

Reboot 'fixed' things.

It hever happened on the same hardware before I switched to rc5.

int qdisc_restart(struct net_device *dev)
{
struct Qdisc *q = dev-qdisc;
struct sk_buff *skb;
int track = (dev-name[0]=='i'  dev-name[1]=='f'  dev-name[2]=='\0');

//'via rhine bug':
//I see ONLY qdisc_restart: start,
//but not any of below msgs.
//On 'good' boots, it looks like this:
//...
//2005-07-12_17:26:29.72158 kern.info: qdisc_restart: start
//2005-07-12_17:26:29.72164 kern.info: qdisc_restart: skb!=NULL
//2005-07-12_17:26:29.72166 kern.info: qdisc_restart: if !netif_queue_stopped...
//2005-07-12_17:26:29.72167 kern.info: qdisc_restart: ...hard_start_xmit
//...
if(track) { printk(qdisc_restart: start\n); }
/* Dequeue packet */
if ((skb = q-dequeue(q)) != NULL) {
if(track) { printk(qdisc_restart: skb!=NULL\n); }
unsigned nolock = (dev-features  NETIF_F_LLTX);
/*
 * When the driver has LLTX set it does its own locking
 * in start_xmit. No need to add additional overhead by
 * locking again. These checks are worth it because
 * even uncongested locks can be quite expensive.
 * The driver can do trylock like here too, in case
 * of lock congestion it should return -1 and the packet
 * will be requeued.
 */
if (!nolock) {
if (!spin_trylock(dev-xmit_lock)) {
collision:
if(track) { printk(qdisc_restart: collision\n); }
/* So, someone grabbed the driver. */

/* It may be transient configuration error,
   when hard_start_xmit() recurses. We detect
   it by checking xmit owner and drop the
   packet when deadloop is detected.
*/
if (dev-xmit_lock_owner == smp_processor_id()) 
{
kfree_skb(skb);
if (net_ratelimit())
printk(KERN_DEBUG Dead loop on 
netdevice %s, fix it urgently!\n, dev-name);
return -1;
}
__get_cpu_var(netdev_rx_stat).cpu_collision++;
goto requeue;
}
/* Remember that the driver is grabbed by us. */
dev-xmit_lock_owner = smp_processor_id();
}

{
/* And release queue */
spin_unlock(dev-queue_lock);


//vda
if(track) { printk(qdisc_restart: if !netif_queue_stopped...\n); }
if (!netif_queue_stopped(dev)) {
int ret;
if (netdev_nit)
dev_queue_xmit_nit(skb, dev);
if(track) { printk(qdisc_restart: ...hard_start_xmit\n); }
ret = dev-hard_start_xmit(skb, dev);
if (ret == NETDEV_TX_OK) {
if (!nolock) {
dev-xmit_lock_owner = -1;
spin_unlock(dev-xmit_lock);
 

  1   2   >