Re: [BK] upgrade will be needed

2005-02-18 Thread Andrea Arcangeli
On Mon, Feb 14, 2005 at 12:05:44PM -0800, Larry McVoy wrote:
 That's not how others are reading it and when we requested clarification
 from the legal firm we use for contracts (FenwickWest if you care) they
 said that it could well be interpreted that if you use BK you are giving
 up your right to hack on another system.  That wasn't our intent but nor

You know I'm not a lawyer but that's exactly the way I read it too:

http://lkml.org/lkml/2004/10/25/224
http://lkml.org/lkml/2004/10/25/400
http://lkml.org/lkml/2004/10/25/249

I've been too harsh in the past on this, but the no time limit was
unbearable to me, and finally some sanity showed up today and things
become bearable for the first time ever as far as I'm concerned.

Now it seems that many folks misunderstood the old licence if they're
complaining about the licence change. Complaints about the new licence
are a no sense as far as I can see.

I'm only amazed you didn't clarify this earlier if your intention was
really to allow hacking on other systems after a certain amount of time.
You had ton of chances to clarify it before the layers lined things up,
including in answer to the above messages.  Anyway I don't care since a
clarification by email wouldn't been enough as far as I was concerned,
so I'm glad eventually the licence is changing.

A big thanks to FenwickWest from my part.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH] add I/O error uevent for block devices

2005-02-18 Thread Kay Sievers
For HAL we want to get notified about I/O errors of block devices.
This is especially useful for devices we are unable to poll and
therefore can't know if something goes wrong here.

Signed-off-by: David Zeuthen [EMAIL PROTECTED]
Signed-off-by: Kay Sievers [EMAIL PROTECTED]

= fs/buffer.c 1.270 vs edited =
--- 1.270/fs/buffer.c   2005-01-21 06:02:13 +01:00
+++ edited/fs/buffer.c  2005-02-17 22:56:05 +01:00
@@ -105,6 +105,7 @@ static void buffer_io_error(struct buffe
printk(KERN_ERR Buffer I/O error on device %s, logical block %Lu\n,
bdevname(bh-b_bdev, b),
(unsigned long long)bh-b_blocknr);
+   kobject_uevent(bh-b_bdev-bd_disk-kobj, KOBJ_IO_ERROR, NULL);
 }
 
 /*
@@ -550,7 +551,8 @@ static void end_buffer_async_read(struct
set_buffer_uptodate(bh);
} else {
clear_buffer_uptodate(bh);
-   buffer_io_error(bh);
+   if (printk_ratelimit())
+   buffer_io_error(bh);
SetPageError(page);
}
 
= include/linux/kobject_uevent.h 1.6 vs edited =
--- 1.6/include/linux/kobject_uevent.h  2004-11-08 20:43:30 +01:00
+++ edited/include/linux/kobject_uevent.h   2005-02-17 23:10:05 +01:00
@@ -29,6 +29,7 @@ enum kobject_action {
KOBJ_UMOUNT = (__force kobject_action_t) 0x05,  /* umount event 
for block devices */
KOBJ_OFFLINE= (__force kobject_action_t) 0x06,  /* offline 
event for hotplug devices */
KOBJ_ONLINE = (__force kobject_action_t) 0x07,  /* online event 
for hotplug devices */
+   KOBJ_IO_ERROR   = (__force kobject_action_t) 0x08,  /* I/O error 
for devices */
 };
 
 
= lib/kobject_uevent.c 1.18 vs edited =
--- 1.18/lib/kobject_uevent.c   2005-01-08 06:44:13 +01:00
+++ edited/lib/kobject_uevent.c 2005-02-17 22:52:03 +01:00
@@ -44,6 +44,8 @@ static char *action_to_string(enum kobje
return offline;
case KOBJ_ONLINE:
return online;
+   case KOBJ_IO_ERROR:
+   return io_error;
default:
return NULL;
}

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Ray Bryant
Andi Kleen wrote:
[Sorry for the late answer.]
No problem, remember, I'm supposed to be on vacation, anyway.  :-)
Let's start off with at least one thing we can agree on.  If xattrs
are already part of XFS, then it seems reasonable to use an extended
attribute to mark certain files as non-migratable.   (Some further
thought is going to be required here -- r/o sections of a
shared library need not be migrated, but r/w sections containing
program or thread private data would need to be migrated.  So
the extended attribute may be a little more complicated than
just don't migrate.)
The fact that NFS doesn't support this means that we will have to
have some other way to handle files from NFS though.  It is possible
we can live with the notion that files mapped in from NFS are always
migratable.  (I'll need to look into that some more).
On Tue, Feb 15, 2005 at 09:44:41PM -0600, Ray Bryant wrote:
Sorry, but the only real difference between your API and mbind is that
yours has a pid argument. 

OK, so I've lost the thread a little bit here.  Specifically what
would you propose the API for page migration be?  As I read through your note,
I see a couple of different possibilities being considered:
(1)  Map each object to be migrated into a management process,
 update the object's memory policy to match the new node locations
 and then unmap the object.  Use the MPOL_F_STRICT argument to mbind() and
 the result is that migration happens as part of the call.
(2)  Something along the lines of:
 page_migrate(pid, old_node, new_node);
 or perhaps
 page_migrate(pid, old_node_mask, new_node_mask);
or
(3)  mbind() with a pid argument?
I'm sorry to be so confused, but could you briefly describe what
your proposed API would be (or choose from the above list if I
have guessed correctly?)  :-)


The fundamental disconnect here is that I think that very few
programs use the NUMA API, and you think that most programs do.

All programs use NUMA policy (assuming you have a CONFIG_NUMA kernel) 
Internally it's all the same.
Well, yes, I guess to be more precise I should have said that
very few programs use any NUMA policy other than the DEFAULT
policy.  And that they instead make page placement decisions implicitly
using first touch.
Hmm, I see perhaps my distinction of these cases with programs
already using NUMA API and not using it was not very useful
and lead you to a tangent. Perhaps we can just drop it.
I think one problem that you have that you essentially
want to keep DEFAULT policy, but change the nodes.
Yes, that is correct.  This has been exactly my point from the
beginning.
We have programs that use the DEFAULT policy and do placement
by first touch, and we want to migrate  those programs without
requiring them to create a non-DEFAULT policy of some kind.
NUMA API currently doesn't offer a way to do that, 
not even with Steve's patch that does simple page migration.
You only get a migration when you set a BIND or PREFERED
policy, and then it would stay. But I guess you could
force that and then set back DEFAULT. It's a big ugly,
but not too bad.

Very ugly, I think.  Particularly if you have to do a lot of
vma splitting to get the correct node placement.  (Worst case
is a VMA with nodes interleaved by first touch across a set of
nodes in a way that doesn't match the INTERLEAVE mempolicy.
Then you would have to create a separate VMA for each page
and use the BIND policy.  Then after migration you would
have to go through and set the policy back to DEFAULT,
resulting in a lot of vma merges.)

Sure, but NUMA API goes to great pains to handle such programs.
Yes, it does.  But, how do we handle legacy NUMA codes that people
use today on our Linux 2.4.21 based Altix kernels?  Such programs
don't have access to the NUMA API, so they aren't using it.  They
work fine on 2.6 with the DEFAULT memory policy.  It seems unreasonable
to go back and require these programs to use numactl to solve a problem that
they are already solving without it.  And it certainly seems difficult
to require them to use numactl to enable migration of those programs.
(I'm sorry to keep harping on this but I think this is the
heart of the issue we are discussing.  Are you of the opinion that
we sould require every program that runs on ALTIX under Linux 2.6 to use 
numactl?)

So lets go with the idea of dropping the va_start and va_end arguments from
the system call I proposed.  Then, we get into the kernel and starting

That would make the node array infinite, won't it?  What happens when
you want to migrate a 1TB process? @) I think you have to replace
that one with a single target node argument too.
I'm sorry, I don't follow that at all.  The node array has nothing to do 
with
the size of the address range to be migrated.  It is not the case that the
ith entry in the node array says what to do with the ith page.  Instead the
old and new node arrays defining a mapping of pages:  for pages found on
old_node[i], move them to 

BUG: stallion module cannot register it's ISR in a 2.6.10 kernel on a FC3 system

2005-02-18 Thread Burn Alting
Here is the bug report. Stallion was purchased by Lantronix and they
don't really care about this bug.

[1.] One line summary of the problem:
Stallion 4 port IO card fails when modprobe'd into kernel

[2.] Full description of the problem/report:
Under Fedora Core 3 using a ftp.kernel.org 2.6.10 kernel, when
the stallion driver module is loaded into the kernel error
messages appear in /var/log/messages. Then, if a port is accessed
further messages appear and IRQ 11 is disabled/turned off.

[3.] Keywords (i.e., modules, networking, kernel):
stallion, serial, kernel

[4.] Kernel version (from /proc/version):
Linux version 2.6.10 ([EMAIL PROTECTED]) (gcc version 3.4.2
20041017 (Red Hat 3.4.2-6.fc3)) #1 Fri Feb 18 17:44:05 EST 2005

[5.] Output of Oops.. message (if applicable) with symbolic information 
 resolved (see Documentation/oops-tracing.txt)

[6.] A small shell script or example program which triggers the
 problem (if possible)

modprobe stallion

[7.] Environment
[7.1.] Software (add the output of the ver_linux script here)
Linux swtf.comptex.com.au 2.6.10 #1 Fri Feb 18 17:44:05 EST 2005 i686
i686 i386 GNU/Linux
 
Gnu C  3.4.2
Gnu make   3.80
binutils   2.15.92.0.2
util-linux 2.12a
mount  2.12a
module-init-tools  3.1-pre5
e2fsprogs  1.35
jfsutils   1.1.7
reiserfsprogs  3.6.18
reiser4progs   line
xfsprogs   2.6.13
pcmcia-cs  3.2.7
quota-tools3.12.
PPP2.4.2
isdn4k-utils   3.3
nfs-utils  1.0.6
Linux C Library2.3.4
Dynamic linker (ldd)   2.3.4
Procps 3.2.3
Net-tools  1.60
Kbd1.12
Sh-utils   5.2.1
Modules Loaded nfsd exportfs lockd parport_pc lp parport autofs4
sunrpc dm_mod video button battery ac pl2303 ftdi_sio usbserial md5 ipv6
uhci_hcd ehci_hcd i2c_i801 i2c_core snd_usb_audio snd_usb_lib
snd_rawmidi snd_seq_device snd_intel8x0 snd_ac97_codec snd_pcm_oss
snd_mixer_oss snd_pcm snd_timer snd soundcore snd_page_alloc e1000
floppy ext3 jbd aic7xxx sd_mod scsi_mod


[7.2.] Processor information (from /proc/cpuinfo):

processor   : 0
vendor_id   : GenuineIntel
cpu family  : 15
model   : 2
model name  : Intel(R) Pentium(R) 4 CPU 2.53GHz
stepping: 4
cpu MHz : 2546.579
cache size  : 512 KB
fdiv_bug: no
hlt_bug : no
f00f_bug: no
coma_bug: no
fpu : yes
fpu_exception   : yes
cpuid level : 2
wp  : yes
flags   : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov
pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm
bogomips: 5046.27

[7.3.] Module information (from /proc/modules):

nfsd 210976 9 - Live 0xf8ccb000
exportfs 9344 1 nfsd, Live 0xf8c8a000
lockd 68264 2 nfsd, Live 0xf8c5a000
parport_pc 29636 1 - Live 0xf8c51000
lp 13292 0 - Live 0xf8c6d000
parport 41928 2 parport_pc,lp, Live 0xf8cbf000
autofs4 28292 0 - Live 0xf8a06000
sunrpc 182372 19 nfsd,lockd, Live 0xf8c23000
dm_mod 64276 0 - Live 0xf89ec000
video 16132 0 - Live 0xf89e7000
button 6928 0 - Live 0xf8a0
battery 9604 0 - Live 0xf89c9000
ac 5124 0 - Live 0xf883d000
pl2303 24964 0 - Live 0xf89c1000
ftdi_sio 33796 0 - Live 0xf89b7000
usbserial 30312 2 pl2303,ftdi_sio, Live 0xf8985000
md5 4608 1 - Live 0xf893d000
ipv6 273088 22 - Live 0xf8d85000
uhci_hcd 36112 0 - Live 0xf89ad000
ehci_hcd 41732 0 - Live 0xf89a1000
i2c_i801 8844 0 - Live 0xf897a000
i2c_core 23040 1 i2c_i801, Live 0xf8973000
snd_usb_audio 67904 2 - Live 0xf8961000
snd_usb_lib 13824 1 snd_usb_audio, Live 0xf898
snd_rawmidi 29984 1 snd_usb_lib, Live 0xf8998000
snd_seq_device 9484 1 snd_rawmidi, Live 0xf8939000
snd_intel8x0 36768 2 - Live 0xf898e000
snd_ac97_codec 76000 1 snd_intel8x0, Live 0xf89cd000
snd_pcm_oss 55588 0 - Live 0xf892a000
snd_mixer_oss 19968 3 snd_pcm_oss, Live 0xf8884000
snd_pcm 110856 4 snd_usb_audio,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,
Live 0xf8a1
snd_timer 34692 1 snd_pcm, Live 0xf892
snd 60260 13
snd_usb_audio,snd_rawmidi,snd_seq_device,snd_intel8x0,snd_ac97_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer,
 Live 0xf88ed000
soundcore 11360 3 snd, Live 0xf888
snd_page_alloc 10372 2 snd_intel8x0,snd_pcm, Live 0xf8864000
e1000 88756 0 - Live 0xf88d6000
floppy 66736 0 - Live 0xf886e000
ext3 134280 3 - Live 0xf88fe000
jbd 86808 1 ext3, Live 0xf888a000
aic7xxx 184024 0 - Live 0xf88a8000
sd_mod 18944 0 - Live 0xf8868000
scsi_mod 136320 2 aic7xxx,sd_mod, Live 0xf881a000

[7.4.] Loaded driver and hardware information
(/proc/ioports, /proc/iomem)

-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-006f : keyboard
0070-0077 : rtc
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0170-0177 : ide1
01f0-01f7 : ide0
02f8-02ff : serial
0376-0376 : ide1

Re: [BK] upgrade will be needed

2005-02-18 Thread Andrea Arcangeli
On Mon, Feb 14, 2005 at 10:03:45AM -0500, Steven Rostedt wrote:
 were employed by bitmover, or signed an NDA to look at the code. But
 just the act of using it is ridicules.  Can you see Ford Motors telling
 someone that you can't go work for GM if you drive a Ford?

Your point makes sense to me too, but really, this 1 year delay is
nothing compared to the previous status, so this is a great improvement.

The previous licence was not enforceable in Germany and I guess in Italy
too, but really seeing so many other people using a product with such a
licence and without any care (even if void) was unbearable to me.

Now the new licence may still not be enforceable, but I don't care
anymore, because even if it's enforceable by bad luck, it would be
bearable to wait 1 year. Switching SCM is a costly operation regardless.
This time limit has been declared for the first time ever, and this is a
great news, so now the FUD is over.
-
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/


pty_chars_in_buffer NULL pointer (kernel oops)

2005-02-18 Thread nuclearcat
Dear, linux-kernel.

Is discussed at
http://kerneltrap.org/mailarchive/1/message/12508/thread
bug fixed in 2.4.x tree? Cause seems i have downloaded 2.4.29, and it
is not fixed (still my kernel on vpn server crashing almost at start),
i have grepped fast pre and bk patches, but didnt found any fixed
related to tty/pty.
Provided in thread patch from Linus working, but after night i have
checked server, and see load average jumped to 700.
Can anybody help in that? I am not kernel guru to provide a patch, but
seems by search in google it is actual problem for people, who own
poptop vpn servers, it is really causing serious instability for
servers.


-- 
With best regards,
GlobalProof Globax Division Manager,
Denys Fedoryshchenko
mailto:[EMAIL PROTECTED]

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Swsusp, resume and kernel versions

2005-02-18 Thread Stefan Seyfried
Nigel Cunningham wrote:

 If the mistakenly booted kernel isn't suspend enabled, however, you need
 a more generic method of removing the image, such as mkswapping the
 storage device. This is what I was speaking of.

The following code is used in the SUSE bootscripts to do exactly this:


get_swap_id() {
local line;
fdisk -l | while read line; do
case $line in
/*Linux\ [sS]wap*) echo ${line%% *}
esac
done
}

check_swap_sig () {
local part=$(get_swap_id)
local where what type rest p c
while read  where what type rest ; do
test $type = swap || continue
c=continue
for p in $part ; do
test $p = $where  c=true
done
$c
case $(dd if=$where bs=1 count=6 skip=4086 2/dev/null) in
S1SUSP|S2SUSP) mkswap $where
esac
done  /etc/fstab
}
-

This invalidates the suspend signature if the kernel has not already
done it. It probably does not cover the softwaresuspend2 signature but
that should be trivial to add.

Regards,

  Stefan

-
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: [darcs-users] Re: [BK] upgrade will be needed

2005-02-18 Thread Andrea Arcangeli
On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
 small to medium sized ones). Last I checked, Arch was still too slow in 
 some areas, though that might have changed in recent months. Also, many 

IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
backend and a single file for the changesets and with sane parameters
conventions miming SVN. The internal algorithms of arch seems the most
advanced possible. It's just the interface and the fs backend that's so
bad and doesn't compress in the backups either.  SVN bsddb doesn't
compress either by default, but at least the new fsfs compresses pretty
well, not as good as CVS, but not as badly as bsddb and arch either.

I may be completely wrong, so take the above just as a humble
suggestion.

darcs scares me a bit because it's in haskell, I don't believe very much
in functional languages for compute intensive stuff, ram utilization
skyrockets sometime (I wouldn't like to need 1G of ram to manage the
tree). Other languages like python or perl are much slower than C/C++
too but at least ram utilization can be normally dominated to sane
levels with them and they can be greatly optimized easily with C/C++
extensions of the performance critical parts.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[2.6 patch] obey HOSTLOADLIBES_programname for single-file compilation

2005-02-18 Thread Matthias Urlichs
Single-file HOSTCC calls added the libraries from $(HOSTLOADLIBES),
but not from $(HOSTLOADLIBES_programname). Multi-file HOSTCC calls do
both.

This patch fixes that inconsistency.

Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]

diff -Nru a/scripts/Makefile.host b/scripts/Makefile.host
--- a/scripts/Makefile.host 2005-02-18 10:19:29 +01:00
+++ b/scripts/Makefile.host 2005-02-18 10:19:29 +01:00
@@ -98,7 +98,8 @@
 # Create executable from a single .c file
 # host-csingle - Executable
 quiet_cmd_host-csingle = HOSTCC  $@
-  cmd_host-csingle = $(HOSTCC) $(hostc_flags) $(HOST_LOADLIBES) -o $@ $
+  cmd_host-csingle = $(HOSTCC) $(hostc_flags) -o $@ $ \
+   $(HOST_LOADLIBES) $(HOSTLOADLIBES_$(@F))
 $(host-csingle): %: %.c FORCE
$(call if_changed_dep,host-csingle)
 
-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]


signature.asc
Description: Digital signature


[2.6 patch] CREDITS Update

2005-02-18 Thread Matthias Urlichs
Small CREDITS update for Mattihas Urlichs.

Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]

diff -Nru a/CREDITS b/CREDITS
--- a/CREDITS   2005-02-18 10:06:04 +01:00
+++ b/CREDITS   2005-02-18 10:06:04 +01:00
@@ -3336,10 +3336,11 @@
 S: USA
 
 N: Matthias Urlichs
-E: [EMAIL PROTECTED]
-E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
+E: [EMAIL PROTECTED]
 D: Consultant, developer, kernel hacker
-D: Playing with Streams, ISDN, and BSD networking code for Linux
+D: In a previous life, worked on Streams/ISDN/BSD networking code for Linux
 S: Schleiermacherstrasse 12
 S: 90491 Nuernberg
 S: Germany

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]


signature.asc
Description: Digital signature


[2.6 patch] bksend example script fix

2005-02-18 Thread Matthias Urlichs
The bksend example script doesn't work if PAGER (used by bk changes)
is set to something which doesn't fallback to plain stdout if its output
isn't a tty.

Fixed by forcing PAGER to be /bin/cat.

Signed-Off-By: Matthias Urlichs [EMAIL PROTECTED]

diff -Nru a/Documentation/BK-usage/bksend b/Documentation/BK-usage/bksend
--- a/Documentation/BK-usage/bksend 2005-02-18 10:06:04 +01:00
+++ b/Documentation/BK-usage/bksend 2005-02-18 10:06:04 +01:00
@@ -27,7 +27,7 @@
 
 SEP=\n===\n\n
 echo -e $SEP
-bk changes -r$REV
+env PAGER=/bin/cat bk changes -r$REV
 echo
 bk export -tpatch -du -h -r$REV | diffstat
 echo; echo

-- 
Matthias Urlichs   |   {M:U} IT Design @ m-u-it.de   |  [EMAIL PROTECTED]


signature.asc
Description: Digital signature


[TTY] 2 points seems strange to me.

2005-02-18 Thread Franck Bui-Huu
Hi,
Looking at TTY code, I noticed a weird test done in opost_bock
located in n_tty.c file. I don't understand why the following test is
done at the start of the function:
if (nr  sizeof(buf))
   nr = sizeof(buf);
Actually it limits the size of processing blocks to 4 bytes and I can't
find a reason why.
Second point, a lot of serial drivers call in their interrupt handler
tty_flip_buffer_push function. This function must no be called
in interrupt context. Why is it done anyway ?
Thanks for your answers.
  Franck
-
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 modules query

2005-02-18 Thread linux lover
Hello,
I want to know can a variable be exported by a linux kernel
modules? How can i make a variable getting assigned in kernel module
available to other kernel modules?
regards,
linux.lover.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] add I/O error uevent for block devices

2005-02-18 Thread Andrew Morton
Kay Sievers [EMAIL PROTECTED] wrote:

 For HAL we want to get notified about I/O errors of block devices.
  This is especially useful for devices we are unable to poll and
  therefore can't know if something goes wrong here.
 
  Signed-off-by: David Zeuthen [EMAIL PROTECTED]
  Signed-off-by: Kay Sievers [EMAIL PROTECTED]
 
  = fs/buffer.c 1.270 vs edited =
  --- 1.270/fs/buffer.c2005-01-21 06:02:13 +01:00
  +++ edited/fs/buffer.c   2005-02-17 22:56:05 +01:00
  @@ -105,6 +105,7 @@ static void buffer_io_error(struct buffe
   printk(KERN_ERR Buffer I/O error on device %s, logical block %Lu\n,
   bdevname(bh-b_bdev, b),
   (unsigned long long)bh-b_blocknr);
  +kobject_uevent(bh-b_bdev-bd_disk-kobj, KOBJ_IO_ERROR, NULL);
   }

- buffer_io_error() is called from interrupt context, and
  kobject_uevent() does multiple GFP_KERNEL allocations.  You'll need to
  use kobject_uevent_atomic().

- the prink_ratelimit() fix in end_buffer_async_read() should be a
  separate patch, really.  I'll fix that up.

- there are numerous other places where an I/O error can be detected:
  grep the tree for b_end_io and bio_end_io.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] Sparse Memory Handling (hot-add foundation)

2005-02-18 Thread Andi Kleen
Dave Hansen [EMAIL PROTECTED] writes:

 The attached patch, largely written by Andy Whitcroft, implements a
 feature which is similar to DISCONTIGMEM, but has some added features.
 Instead of splitting up the mem_map for each NUMA node, this splits it
 up into areas that represent fixed blocks of memory.  This allows
 individual pieces of that memory to be easily added and removed.

[...]

I'm curious - how does this affect .text size for a i386 or x86-64 NUMA
kernel? One area I wanted to improve on x86-64 for a long time was
to shrink the big virt_to_page() etc. inline macros. Your new code
actually looks a bit smaller.

-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: ide-scsi is deprecated for cd burning! Use ide-cd and give dev=/dev/hdX as device

2005-02-18 Thread Kiniger, Karl (GE Healthcare)
On Thu, Feb 17, 2005 at 05:58:05PM -0500, Bill Davidsen wrote:
 [EMAIL PROTECTED] wrote:
 On Wed, 16 Feb 2005 10:42:21 +0100, Kiniger, Karl (GE Healthcare) said:
 
 
   Have you tested the ISO on some *OTHER* hardware?  The impression I got
   was that the cd was *burned* right by ide-cd, but when *read back*, it
   bollixed things up at the end of the CD.
 
 Using ide-scsi is enough to get all the data till the real end of the CD.
 
 
 OK, so the problem is that ide-cd is able to *burn* the CD just fine, but 
 it
 suffers lossage when ide-cd tries to read it back...
 
 Alan - are the sense-byte patches for ide-cd in a shape to push either 
 upstream
 or to -mm?
 
 The last time I looked at this, the issue was that the user software did 
 a large read and the ide-cd didn't properly return a small data block 
 with no error, but rather returned an error with no data. If you get the 
 size of the ISO image, you can read that with any program which doesn't 
 try to read MORE than that.

Not entirely true (at least for me). I actually tried to read the 
last iso9660 data sector with a small C program (reading 2 kb) and
it failed to read the sector. Using ide-scsi I was able to read it.

sdd (from Joerg Schilling) should not try to read more than ivsize
bytes (InputVolumeSize) if that argument is given - I did not
verify with strace though.


Karl

-- 
Karl Kiniger   mailto:[EMAIL PROTECTED]
GE Medical Systems Kretztechnik GmbH  Co OHG
Tiefenbach 15   Tel: (++43) 7682-3800-710
A-4871 Zipf Austria Fax: (++43) 7682-3800-47
-
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: Swsusp, resume and kernel versions

2005-02-18 Thread Nigel Cunningham
Hi Stefan.

For Suspend2, we also put a device id in the space, so there's only room
for one character, which is a lower or upper case Z. (We also validate
the device ID, so a random Z won't cause an oops).

Thanks for the code. With your/Suse's permission, I'll ask Bernard
(cc'd) to include the script in the docs somewhere with the appropriate
credit.

Thanks and regards,

Nigel

On Fri, 2005-02-18 at 08:05, Stefan Seyfried wrote:
 Nigel Cunningham wrote:
 
  If the mistakenly booted kernel isn't suspend enabled, however, you need
  a more generic method of removing the image, such as mkswapping the
  storage device. This is what I was speaking of.
 
 The following code is used in the SUSE bootscripts to do exactly this:
 
 
 get_swap_id() {
 local line;
 fdisk -l | while read line; do
 case $line in
 /*Linux\ [sS]wap*) echo ${line%% *}
 esac
 done
 }
 
 check_swap_sig () {
 local part=$(get_swap_id)
 local where what type rest p c
 while read  where what type rest ; do
 test $type = swap || continue
 c=continue
 for p in $part ; do
 test $p = $where  c=true
 done
 $c
 case $(dd if=$where bs=1 count=6 skip=4086 2/dev/null) in
 S1SUSP|S2SUSP) mkswap $where
 esac
 done  /etc/fstab
 }
 -
 
 This invalidates the suspend signature if the kernel has not already
 done it. It probably does not cover the softwaresuspend2 signature but
 that should be trivial to add.
 
 Regards,
 
   Stefan
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028  Mob: +61 (417) 100 574

-
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: [ACPI] Call for help: list of machines with working S3

2005-02-18 Thread Norbert Preining
On Don, 17 Feb 2005, Stefan Dösinger wrote:
  Ok, I installed xlibmesa-gl1-dri-trunk, xserver-xfree86-dri-trunk and
  compiled linux-2.6.11-rc4 and drm modules from drm-trunk-module-src, all
  from http://www.nixnuts.net/files/
 
  But I had no success whatsoever. With this (Xorg server, current dri/drm
  stuff, ..) the laptop not even wakes up from sleep!
 Sorry, no Idea. What about 2.6.11-rc3-mm2 + Xorg 6.8.1.99? Did you test this 
 combination?

I tried:
2.6.11-rc3-mm2 + Xorg + DRI disabled
and this works.

I cannot enable dri/drm with the cvs version of the drm modules, because
the drm modules do not compile for -mm kernels, since there is the patch
for multiple agp bridges included (that's the reason why I tried -rc4
without mm) and the drm modules from drm-trunk-module-src are not
prepared to the change of the api. I even tried to incorporate the
changes to the api but gave up.

I *can* active dri but with the builtin kernel drm modules, which makes
the kernel freeze while resuming.

 Am I right with assuming that resumeworked after the X upgrade if X wasn't 
 started before suspend?

NO!!! Most interestingly: Doing a suspend from single user mode makes
the machine freeze (not even sysrq!)

I suspect that it has to do with the restoring of graphics state with
vbetool from a data set which was taken *while* running X: My
suspend2ram script looks like this (as suggested here):

statedir=/root/s3/state
/usr/bin/chvt 1
cat /dev/vcsa $statedir/vcsa
sync
echo 3  /proc/acpi/sleep
sync
vbetool post
vbetool vbestate restore $statedir/vbe
cat $statedir/vcsa /dev/vcsa
...

but $statedir/vbe was taken once for XFree86 running. Can this be the
reason for the freeze?


Best wishes

Norbert

---
Norbert Preining preining AT logic DOT at Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
MAVIS ENDERBY (n.)
The almost-completely-forgotten girlfriend from your distant past for
whom your wife has a completely irrational jealousy and hatred.
--- Douglas Adams, The Meaning of Liff
-
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/


Linux-kernel, Get a new home

2005-02-18 Thread Gyv
Homeowners 

- do you have less-than-perfect credit* 

We'll quickly match you up with the B.EST provider based on YOUR NEEDS.

Whether its a Home Equity Loan or a Low-Rate-Re-financing

We specialize in less-than-perfect *credit.  

We'll help you get the YES! you deserve.

http://www.nocturnull.com/save.asp

Future reference options:
http://www.nocturnull.com/gone.asp


-
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: [darcs-users] Re: [BK] upgrade will be needed

2005-02-18 Thread Tomasz Zielonka
On Fri, Feb 18, 2005 at 10:09:00AM +0100, Andrea Arcangeli wrote:
 darcs scares me a bit because it's in haskell, I don't believe very much
 in functional languages for compute intensive stuff, ram utilization
 skyrockets sometime (I wouldn't like to need 1G of ram to manage the
 tree).

AFAICS, most of memory related problems in darcs are not necessarily a
result of using Haskell.

 Other languages like python or perl are much slower than C/C++ too but
 at least ram utilization can be normally dominated to sane levels with
 them and they can be greatly optimized easily with C/C++ extensions of
 the performance critical parts.

With those languages, you often have no other choice than resorting to
C. GHC is quite a good compiler and I've often been able to get my
programs run almost as fast as programs written in C++ - however, if I
were to write those programs in C++, I would never do that, despite
being quite a good C++ programmer.

Also, in Haskell you can use extensions written in C, as easily or even
easier than in Python or Perl (I've done this in Perl, heard the battle
stories about C extensions in Python). Haskell's FFI is quite good,
there are also many supporting tools.

Best regards
Tomasz

-- 
Szukamy programisty C++ i Haskell'a: http://tinyurl.com/5mw4e
-
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: Swsusp, resume and kernel versions

2005-02-18 Thread Pavel Machek
Hi!

Just remember you're doing the mkswap if you decide to rearrange your
partitions at all, or code a script smart enough to grep your swap
partitions out of your fstab.
   
   It could be a workaround. Still it will cause loss of unsaved work if
   I happen to load wrong kernel. Given that the code checking for swsusp
   image can be marked __init I don't understand the reasons gainst doing
   it.
  
  How do you know which partitions to check? swsusp gets it from resume= 
  parameter,
  but if you do not have it compiled, you probably have wrong cmdline, too.
 
 In many cases, you might have added the resume= line to every kernel
 that's booted (eg, LILO's global append= parameter, or Debian GRUB's
 magic kopts gear). Alternately (or additionally), you could examine
 the signature when sys_swapon is called on a swap partition (though
 the code couldn't be __init then).
 
 These together I want to claim would catch many of these cases, and
 any effort to avoid severe filesystem corruption is a good thing.

Messing up the kernel to avoid fs corruption in some cases is bad
idea.

If you want to be 100% safe, add support to LILO/GRUB: just do not
allow selecting wrong kernel if last action was suspend. Bootloader
knows, it seen the command lines.

Or simply use Stefan's userland code.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: Swsusp, resume and kernel versions

2005-02-18 Thread Stefan Seyfried
Nigel Cunningham wrote:
 Hi Stefan.
 
 For Suspend2, we also put a device id in the space, so there's only room
 for one character, which is a lower or upper case Z. (We also validate
 the device ID, so a random Z won't cause an oops).
 
 Thanks for the code. With your/Suse's permission, I'll ask Bernard
 (cc'd) to include the script in the docs somewhere with the appropriate
 credit.

i have consulted our license guy and the original author of
/etc/init.d/boot.swap and am glad to say that it is GPL'd ;-)

Have fun,

  Stefan

-- 
Stefan Seyfried, QA / RD Team Mobile Devices, SUSE LINUX, Nürnberg.

Any ideas, John?
Well, surrounding them's out.
-
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/


Realtime preempt

2005-02-18 Thread Sven Dietrich

Ingo,

this patch turns off the preemptable BKL when 
either PREEMPT_VOLUNTARY or PREEMPT_NONE is selected.

Signed-off-by: Sven-Thorsten Dietrich [EMAIL PROTECTED]

Index: linux-2.6.10-vaio/lib/Kconfig.RT
===
--- linux-2.6.10-vaio.orig/lib/Kconfig.RT   2005-02-18 11:13:42.050554215 
+
+++ linux-2.6.10-vaio/lib/Kconfig.RT2005-02-18 11:20:16.021273614 +
@@ -144,5 +144,6 @@
 config PREEMPT_BKL
bool
depends on PREEMPT_RT || !SPINLOCK_BKL
+   default n if !PREEMPT
default y


-
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: [Oops] 2.6.10: PREEMPT SMP

2005-02-18 Thread Klaus Steinberger
David Howells wrote:

 Hmmm... I see it involves the key stuff I wrote.

Did you find out something about this bug? I did get the same crash on a 
heavily loaded NFS and Samba Server running Fedora Core 2 with 
kernel-2.6.10-1.12_FC2.

Here the OOPS:
Feb 18 09:58:08 mllrd02 kernel: Unable to handle kernel NULL pointer 
dereference at virtual address 000c
Feb 18 09:58:08 mllrd02 kernel:  printing eip:
Feb 18 09:58:08 mllrd02 kernel: c01b48ec
Feb 18 09:58:08 mllrd02 kernel: *pde = 111b3001
Feb 18 09:58:08 mllrd02 kernel: Oops:  [#1]
Feb 18 09:58:08 mllrd02 kernel: SMP
Feb 18 09:58:08 mllrd02 kernel: Modules linked in: nfsd exportfs nfs lockd 
parport_pc lp parport autofs4 sunrpc iptable_filter ip_tables tg3 floppy sg 
microcode ohci_hcd video button battery ac md5 ipv6 ext3 jbd dm_mod qla2300 
qla2xxx scsi_transport_fc aacraid(U) aic79xx sd_mod scsi_mod
Feb 18 09:58:08 mllrd02 kernel: CPU:3
Feb 18 09:58:08 mllrd02 kernel: EIP:0060:[c01b48ec]Not tainted VLI
Feb 18 09:58:08 mllrd02 kernel: EFLAGS: 00010203   (2.6.10-1.12_FC2smp)
Feb 18 09:58:08 mllrd02 kernel: EIP is at __rb_rotate_left+0x8/0x36
Feb 18 09:58:08 mllrd02 kernel: eax: de05f940   ebx: c04265e4   ecx: de05f940   
edx: 
Feb 18 09:58:08 mllrd02 kernel: esi: de05f940   edi: f652db80   ebp: c04265e4   
esp: eef86ed0
Feb 18 09:58:08 mllrd02 kernel: ds: 007b   es: 007b   ss: 0068
Feb 18 09:58:08 mllrd02 kernel: Process smbd (pid: 3204, threadinfo=eef86000 
task=f72e7020)
Feb 18 09:58:08 mllrd02 kernel: Stack: c5887700 c01b49fd f652db80 f652db80 
c5887708 00b1 c0197650 c5887700
Feb 18 09:58:08 mllrd02 kernel:000d eef86f54 eef86f61 ffea 
c0197704 0015  00b1
Feb 18 09:58:08 mllrd02 kernel:c031f1e0 eef86f54  f5675a40 
00b1 c019887d  001f
Feb 18 09:58:08 mllrd02 kernel: Call Trace:
Feb 18 09:58:08 mllrd02 kernel:  [c01b49fd] rb_insert_color+0xad/0xcc
Feb 18 09:58:08 mllrd02 kernel:  [c0197650] key_user_lookup+0xd4/0x101
Feb 18 09:58:08 mllrd02 kernel:  [c0197704] key_alloc+0x53/0x2bf
Feb 18 09:58:08 mllrd02 kernel:  [c019887d] keyring_alloc+0x1a/0x48
Feb 18 09:58:08 mllrd02 kernel:  [c0199dfb] alloc_uid_keyring+0x2b/0x7b
Feb 18 09:58:08 mllrd02 kernel:  [c0125fa2] alloc_uid+0xb6/0x143
Feb 18 09:58:08 mllrd02 kernel:  [c0129489] set_user+0xb/0x8c
Feb 18 09:58:08 mllrd02 kernel:  [c012988b] sys_setresuid+0x105/0x1a4
Feb 18 09:58:08 mllrd02 kernel:  [c0103ccb] syscall_call+0x7/0xb
Feb 18 09:58:08 mllrd02 kernel: Code: 59 83 bc 82 04 01 00 00 00 75 ea 41 83 
f9 01 76 ed 31 c0 5b c3 57 b9 45 00 00 00 89 c7 31 c0 f3 ab 5f c3 53 89 c1 89 
d3 8b 50 08 8b 42 0c 85 c0 89 41 08 74 02 89 08 89 4a 0c 8b 01 85 c0 89 02


Sincerly,
Klaus


-- 
Klaus Steinberger Maier-Leibnitz Labor
Phone: (+49 89)289 14287  Am Coulombwall 6, D-85748 Garching, Germany
FAX:   (+49 89)289 14280  EMail: [EMAIL PROTECTED]
URL: http://www.physik.uni-muenchen.de/~k2/

In a world without Walls and Fences, who needs Windows and Gates
-
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: [darcs-users] Re: [BK] upgrade will be needed

2005-02-18 Thread Erik Bågfors
On Fri, 18 Feb 2005 10:09:00 +0100, Andrea Arcangeli [EMAIL PROTECTED] wrote:
 On Thu, Feb 17, 2005 at 06:24:53PM -0800, Tupshin Harper wrote:
  small to medium sized ones). Last I checked, Arch was still too slow in
  some areas, though that might have changed in recent months. Also, many
 
 IMHO someone needs to rewrite ARCH using the RCS or SCCS format for the
 backend and a single file for the changesets and with sane parameters
 conventions miming SVN.

RCS/SCCS format doesn't make much sence for a changeset oriented SCM.

/Erik
-
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] quiet non-x86 option ROM warnings

2005-02-18 Thread Gabriel Paubert
On Thu, Feb 17, 2005 at 05:56:03PM -0500, Jon Smirl wrote:
 On Fri, 18 Feb 2005 09:45:50 +1100, Benjamin Herrenschmidt
 [EMAIL PROTECTED] wrote:
 
  Can't the size be obtained like any other BAR ?
 
 yes, but cards that don't fully decode their ROM address space can
 waste memory in copy_rom. For example I have a card around here that
 reports a BAR address space of 128K and has a 2K ROM in it. You only
 want to copy the 2K, not the 128K.

Indeed, but they normally repeat by powers of 2, ignoring
high order address bits. Is it that hard to detect?

For example if it declares 128k, compare the two halves, reduce
to 64k if equal. Lather, rinse, repeat.

It's equivalent to reading the BAR declared size twice in 
the worst case, so it's not that bad performance-wise.

That would only be in the case of an unknown signature
in the first bytes, otherwise the third byte gives you
the size IIUC.

Gabriel
-
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] __be'ify include/linux/cdrom.h

2005-02-18 Thread Alexey Dobriyan
Fix sparse warnings in drivers/cdrom/cdrom.c and drivers/block/pktcdvd.c

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

Index: linux-warnings/include/linux/cdrom.h
===
--- linux-warnings/include/linux/cdrom.h(revision 21)
+++ linux-warnings/include/linux/cdrom.h(revision 22)
@@ -750,7 +750,7 @@
 #define MRW_MODE_PC0x03
 
 struct mrw_feature_desc {
-   __u16 feature_code;
+   __be16 feature_code;
 #if defined(__BIG_ENDIAN_BITFIELD)
__u8 reserved1  : 2;
__u8 feature_version: 4;
@@ -777,7 +777,7 @@
 
 /* cf. mmc4r02g.pdf 5.3.10 Random Writable Feature (0020h) pg 197 of 635 */
 struct rwrt_feature_desc {
-   __u16 feature_code;
+   __be16 feature_code;
 #if defined(__BIG_ENDIAN_BITFIELD)
__u8 reserved1  : 2;
__u8 feature_version: 4;
@@ -804,7 +804,7 @@
 };
 
 typedef struct {
-   __u16 disc_information_length;
+   __be16 disc_information_length;
 #if defined(__BIG_ENDIAN_BITFIELD)
__u8 reserved1  : 3;
 __u8 erasable  : 1;
@@ -850,7 +850,7 @@
 } disc_information;
 
 typedef struct {
-   __u16 track_information_length;
+   __be16 track_information_length;
__u8 track_lsb;
__u8 session_lsb;
__u8 reserved1;
@@ -881,12 +881,12 @@
__u8 lra_v  : 1;
__u8 reserved3  : 6;
 #endif
-   __u32 track_start;
-   __u32 next_writable;
-   __u32 free_blocks;
-   __u32 fixed_packet_size;
-   __u32 track_size;
-   __u32 last_rec_address;
+   __be32 track_start;
+   __be32 next_writable;
+   __be32 free_blocks;
+   __be32 fixed_packet_size;
+   __be32 track_size;
+   __be32 last_rec_address;
 } track_information;
 
 struct feature_header {
@@ -897,12 +897,12 @@
 };
 
 struct mode_page_header {
-   __u16 mode_data_length;
+   __be16 mode_data_length;
__u8 medium_type;
__u8 reserved1;
__u8 reserved2;
__u8 reserved3;
-   __u16 desc_length;
+   __be16 desc_length;
 };
 
 #ifdef __KERNEL__
@@ -1109,7 +1109,7 @@
 #endif
__u8 session_format;
__u8 reserved6;
-   __u32 packet_size;
+   __be32 packet_size;
__u16 audio_pause;
__u8 mcn[16];
__u8 isrc[16];
@@ -1154,7 +1154,7 @@
 } rpc_state_t;
 
 struct event_header {
-   __u16 data_len;
+   __be16 data_len;
 #if defined(__BIG_ENDIAN_BITFIELD)
__u8 nea: 1;
__u8 reserved1  : 4;
Index: linux-warnings/drivers/cdrom/cdrom.c
===
--- linux-warnings/drivers/cdrom/cdrom.c(revision 21)
+++ linux-warnings/drivers/cdrom/cdrom.c(revision 22)
@@ -705,7 +705,7 @@
 {
struct packet_command cgc;
char buffer[16];
-   __u16 *feature_code;
+   __be16 *feature_code;
int ret;
 
init_cdrom_command(cgc, buffer, sizeof(buffer), CGC_DATA_READ);
@@ -718,7 +718,7 @@
if ((ret = cdi-ops-generic_packet(cdi, cgc)))
return ret;
 
-   feature_code = (__u16 *) buffer[sizeof(struct feature_header)];
+   feature_code = (__be16 *) buffer[sizeof(struct feature_header)];
if (be16_to_cpu(*feature_code) == CDF_HWDM)
return 0;
 
@@ -2767,7 +2767,7 @@
   how much data is available for transfer. buffer[1] is
   unfortunately ambigious and the only reliable way seem
   to be to simply skip over the block descriptor... */
-   offset = 8 + be16_to_cpu(*(unsigned short *)(buffer+6));
+   offset = 8 + be16_to_cpu(*(__be16 *)(buffer+6));
 
if (offset + 16  sizeof(buffer))
return -E2BIG;
-
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: drivers/input/power.c is never built

2005-02-18 Thread Pavel Machek
Hi!

   In 2.6, drivers/input/power.c would only have been built if 
   CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable 
   this option.
  
  That was written a long time ago before the new power management went in. 
  On PDA's there is a power button and suspend button. So this was a hook 
  so that the input layer could detect the power/suspend button being 
  presses and then power down or turn off the device. Now that the new power
  management is in what should we do?
  
 Change power.c to generate power events like ACPI does, most likely.

Actually I believe you want to fix ACPI to use inputs. You hardly want
/proc/acpi/events on PDA, right?
Pavel

-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: Swsusp, resume and kernel versions

2005-02-18 Thread Bernard Blackham
On Fri, Feb 18, 2005 at 12:24:09PM +0100, Pavel Machek wrote:
 If you want to be 100% safe, add support to LILO/GRUB: just do not
 allow selecting wrong kernel if last action was suspend. Bootloader
 knows, it seen the command lines.

That's a very good point/solution indeed. The hibernate script
available from the Software Suspend 2 homepage already has options
to reconfigure LILO/GRUB upon suspending. I'd forgotten about them!

Bernard.

-- 
 Bernard Blackham bernard at blackham dot com dot au
-
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] __be'ify include/linux/nbd.h

2005-02-18 Thread Alexey Dobriyan
Fix sparse warnings in drivers/block/nbd.c

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

Index: linux-warnings/include/linux/nbd.h
===
--- linux-warnings/include/linux/nbd.h  (revision 22)
+++ linux-warnings/include/linux/nbd.h  (revision 23)
@@ -68,11 +68,11 @@
  * server. All data are in network byte order.
  */
 struct nbd_request {
-   u32 magic;
-   u32 type;   /* == READ || == WRITE  */
+   __be32 magic;
+   __be32 type;/* == READ || == WRITE  */
char handle[8];
-   u64 from;
-   u32 len;
+   __be64 from;
+   __be32 len;
 }
 #ifdef __GNUC__
__attribute__ ((packed))
@@ -84,8 +84,8 @@
  * it has completed an I/O request (or an error occurs).
  */
 struct nbd_reply {
-   u32 magic;
-   u32 error;  /* 0 = ok, else error   */
+   __be32 magic;
+   __be32 error;   /* 0 = ok, else error   */
char handle[8]; /* handle you got from request  */
 };
 #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: [BK] upgrade will be needed

2005-02-18 Thread Ed Tomlinson
On Friday 18 February 2005 02:26, Sean wrote:
 On Thu, February 17, 2005 11:00 pm, Theodore Ts'o said:
 
  If you think that, you truly do not understand the value of BK, and
  why Linus chose it.
 
 Hey Ted,
 
 No, I just disagree that it was an absolute requirement or worth its cost
 that so many want to completely discount.   Andrew has pretty much shown
 BK is not required, he's still using patches.

Andrew uses BK too.  He extends its function by maintaining a set of patches
above and beyond the committed BK tree...  Ted made a really valid point.  The
people at the top _are_ _very_ _very_ important.  

There are several ways to get kernel source if _you_ do not want to use BK.  I 
use BK.  There are enough projects around that I can avoid working on a SVM 
for a year...  Thats my option though - you do not have to agree.

Ed 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] add I/O error uevent for block devices

2005-02-18 Thread Kay Sievers
On Fri, Feb 18, 2005 at 01:46:21AM -0800, Andrew Morton wrote:
 Kay Sievers [EMAIL PROTECTED] wrote:
 
  For HAL we want to get notified about I/O errors of block devices.
   This is especially useful for devices we are unable to poll and
   therefore can't know if something goes wrong here.

 - buffer_io_error() is called from interrupt context, and
   kobject_uevent() does multiple GFP_KERNEL allocations.  You'll need to
   use kobject_uevent_atomic().

Fixed.

 - the prink_ratelimit() fix in end_buffer_async_read() should be a
   separate patch, really.  I'll fix that up.

Removed that part.

 - there are numerous other places where an I/O error can be detected:
   grep the tree for b_end_io and bio_end_io.

You mean the mmap and direct-io stuff?

Thanks,
Kay

-
For HAL we want to get notified about I/O errors of block devices.
This is especially useful for devices we are unable to poll and
therefore can't know if something goes wrong here.

Signed-off-by: David Zeuthen [EMAIL PROTECTED]
Signed-off-by: Kay Sievers [EMAIL PROTECTED]

= fs/buffer.c 1.270 vs edited =
--- 1.270/fs/buffer.c   2005-01-21 06:02:13 +01:00
+++ edited/fs/buffer.c  2005-02-18 13:00:18 +01:00
@@ -105,6 +105,7 @@ static void buffer_io_error(struct buffe
printk(KERN_ERR Buffer I/O error on device %s, logical block %Lu\n,
bdevname(bh-b_bdev, b),
(unsigned long long)bh-b_blocknr);
+   kobject_uevent_atomic(bh-b_bdev-bd_disk-kobj, KOBJ_IO_ERROR, NULL);
 }
 
 /*
= include/linux/kobject_uevent.h 1.6 vs edited =
--- 1.6/include/linux/kobject_uevent.h  2004-11-08 20:43:30 +01:00
+++ edited/include/linux/kobject_uevent.h   2005-02-18 12:59:18 +01:00
@@ -29,6 +29,7 @@ enum kobject_action {
KOBJ_UMOUNT = (__force kobject_action_t) 0x05,  /* umount event 
for block devices */
KOBJ_OFFLINE= (__force kobject_action_t) 0x06,  /* offline 
event for hotplug devices */
KOBJ_ONLINE = (__force kobject_action_t) 0x07,  /* online event 
for hotplug devices */
+   KOBJ_IO_ERROR   = (__force kobject_action_t) 0x08,  /* I/O error 
for devices */
 };
 
 
= lib/kobject_uevent.c 1.18 vs edited =
--- 1.18/lib/kobject_uevent.c   2005-01-08 06:44:13 +01:00
+++ edited/lib/kobject_uevent.c 2005-02-18 12:59:18 +01:00
@@ -44,6 +44,8 @@ static char *action_to_string(enum kobje
return offline;
case KOBJ_ONLINE:
return online;
+   case KOBJ_IO_ERROR:
+   return io_error;
default:
return NULL;
}

-
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: [darcs-users] Re: [BK] upgrade will be needed

2005-02-18 Thread Andrea Arcangeli
On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
 RCS/SCCS format doesn't make much sence for a changeset oriented SCM.

The advantage it will provide is that it'll be compact and a backup will
compress at best too. Small compressed tarballs compress very badly
instead, it wouldn't be even comparable. Once the thing is very compact
it has a better chance to fit in cache, and if it fits in cache
extracting diffs from each file will be very fast. Once it'll be compact
the cost of a changeset will be diminished allowing it to scale better
too.

Now it's true new disks are bigger, but they're not much faster, so if
the size of the repository is much larger, it'll be much slower to
checkout if it doesn't fit in cache. And if it's smaller it has better
chances of fitting in cache too.

The thing is, RCS seems a space efficient format for storing patches,
and it's efficient at extracting them too (plus it's textual so it's not
going to get lost info even if something goes wrong).

The whole linux-2.5 CVS is 500M uncompressed and 75M tar.bz2 compressed.

My suggestion is to convert _all_ dozen thousand changesets to arch or
SVN and then compare the size with CVS (also the compressed size is
interesting for backups IMHO). Unfortunately I know nothing about darcs
yet (except it eats quite some memory ;)
-
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/


bio refcount problem

2005-02-18 Thread Philip R Auld
Hi,
I think there are some potential issues with the reference
counting of bios as used in 2.6.10. The __make_request function 
which is the default block device routine accesses the bio structure 
after issuing the call to add_request. This means that the bio could 
have completed before __make_request uses it. 

The submit_bh path takes an extra reference with an explicit
bio_get/put pair around the submit_bio, but many other users of
submit_bio do not. Given that most of the end_io routines remove a
reference and hence could free the bio this can lead at the least to 
__make_request mis-reading the sync flag. In more extreme cases it can 
cause an oops when run with CONFIG_DEBUG_PAGEALLOC.

The question is what is the preferred fix? I think it may be to simply
have submit_bio take its own reference (and remove the extra one from 
submit_bh).

Alternatively __make_request could be adjusted so that it does not
access the bio after calling add_request. All it is doing is checking
the bi_rw field for the sync bit.

Or make all users of submit_bio take and release and extra reference
like submit_bh.

Thoughts?


Cheers,

Phil


-- 
Philip R. Auld, Ph.D.  Egenera, Inc.
Software Architect165 Forest St.
(508) 858-2628Marlboro, MA 01752
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Andi Kleen
[Enjoy your vacation]

On Fri, Feb 18, 2005 at 02:38:42AM -0600, Ray Bryant wrote:
 
 Let's start off with at least one thing we can agree on.  If xattrs
 are already part of XFS, then it seems reasonable to use an extended
 attribute to mark certain files as non-migratable.   (Some further
 thought is going to be required here -- r/o sections of a
 shared library need not be migrated, but r/w sections containing
 program or thread private data would need to be migrated.  So
 the extended attribute may be a little more complicated than
 just don't migrate.)

I assume they would allow marking arbitary segments with specific
policies, so it should be possible.

An alternative way to handle shared libraries BTW would be to add the ELF
headers Steve did in his patch. And then handle them in user space
in ld.so and let it apply the necessary policy. 

This won't work for non ELF files though.


 
 The fact that NFS doesn't support this means that we will have to
 have some other way to handle files from NFS though.  It is possible
 we can live with the notion that files mapped in from NFS are always
 migratable.  (I'll need to look into that some more).

I don't know details, but I would assume selinux (and other advanced security 
people who generally need more security information per file) have plans in 
this area too.

 
 
 Sorry, but the only real difference between your API and mbind is that
 yours has a pid argument. 
 
 
 OK, so I've lost the thread a little bit here.  Specifically what
 would you propose the API for page migration be?  As I read through your 
 note,
 I see a couple of different possibilities being considered:
 
 (1)  Map each object to be migrated into a management process,
  update the object's memory policy to match the new node locations
  and then unmap the object.  Use the MPOL_F_STRICT argument to mbind() 
  and
  the result is that migration happens as part of the call.
 
 (2)  Something along the lines of:
 
  page_migrate(pid, old_node, new_node);
 
  or perhaps
 
  page_migrate(pid, old_node_mask, new_node_mask);

+ node mask length. 

I don't like old_node* very much because it's imho unreliable
(because you can usually never fully know on which nodes the old
process was and there can be good reasons to just migrate everything)

I assume the second way would be more flexible, although I found
having node masks for this has the problem that you tend to allocate
most memory on the lowest numbered node because it's not easy to
round-robin over all set nodes (that's an issue in PREFERED policy
in NUMA API currently). So maybe the simple  new_node argument
is preferable.

page_migrate(pid, new_node)

(or putting it into a writable /proc file if you prefer that)   

 
 or
 
 (3)  mbind() with a pid argument?

That would bring it to 7 arguments, really too much for a system
call (and a function in general). Also it would mean needing
to know about other process private addresses again.

Maybe set_mempolicy, but a new call is probably better.

 NUMA API currently doesn't offer a way to do that, 
 not even with Steve's patch that does simple page migration.
 You only get a migration when you set a BIND or PREFERED
 policy, and then it would stay. But I guess you could
 force that and then set back DEFAULT. It's a big ugly,
 but not too bad.
 
 
 Very ugly, I think.  Particularly if you have to do a lot of

Well, I guess it could be made a new flag that says to
not change the future policy. 

 vma splitting to get the correct node placement.  (Worst case
 is a VMA with nodes interleaved by first touch across a set of
 nodes in a way that doesn't match the INTERLEAVE mempolicy.
 Then you would have to create a separate VMA for each page
 and use the BIND policy.  Then after migration you would
 have to go through and set the policy back to DEFAULT,
 resulting in a lot of vma merges.)

Umm - I hope you don't want to do such tricks from external
processes. If a program does it by itself it can just use interleave
policy.

But I think I now understand why you want this complicated
user space control. You want to preserve relative ordering
on a set of nodes, right? 

e.g. job runs threads on nodes 0,1,2,3  and you want it to move
to nodes 4,5,6,7 with all memory staying staying in the same
distance from the new CPUs as it were from the old CPUs, right? 

It explains why you want old_node, you would do 
(assuming node mask arguments) 

page_migrate(pid, 0, 4)
page_migrate(pid, 1, 5)
...
page_migrate(pid, 3, 7) 

keeping the memory in the same relative order. Problem is what happens
when some memory is in some other node due to memory pressure fallbacks.
Your scheme would not migrate this memory at all. While you may
get away with this in your application I think it would make 
page migration much less useful in the general case than it could
be.  e.g. for a single threaded process it is very useful to just
force all its pages that have been allocated on 

Re: Please open sysfs symbols to proprietary modules

2005-02-18 Thread Arjan van de Ven
On Thu, 2005-02-17 at 17:13 -0600, [EMAIL PROTECTED] wrote:
 On Thu, 03 Feb 2005 09:41:00 +0100, Arjan van de Ven [EMAIL PROTECTED] 
 wrote:
  On Wed, 2005-02-02 at 17:56 -0500, Pavel Roskin wrote:
   Hello!
  
   I'm writing a module under a proprietary license.  I decided to use sysfs
   to do the configuration.  Unfortunately, all sysfs exports are available
   to GPL modules only because they are exported by EXPORT_SYMBOL_GPL.
  
  I suggest you talk to a lawyer and review the general comments about
  binary modules with him (http://people.redhat.com/arjanv/COPYING.modules
  for example). You are writing an addition to linux from scratch, and it
  is generally not considered OK to do that in binary form (I certainly do
  not consider it OK).
 
 So what about companies like ImageStream who write proprietary Linux network
 drivers for their hardware from scratch with no previous ports from another 
 OS?

Note that has a previous port is not enough for me to consider a
proprietary driver ok. 

Anyway you asked... if your description is accurate then yes I consider
those modules (if they are distributed of course) a violation of the
license of the code I contributed to the 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: 2.6: drivers/input/power.c is never built

2005-02-18 Thread Richard Purdie
  In 2.6, drivers/input/power.c would only have been built if
  CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
  this option.

 That was written a long time ago before the new power management went 
 in.
 On PDA's there is a power button and suspend button. So this was a hook
 so that the input layer could detect the power/suspend button being
 presses and then power down or turn off the device. Now that the new 
 power
 management is in what should we do?

Change power.c to generate power events like ACPI does, most likely.

There was some recent discussion of this on linux-input. It was basically 
agreed that the input system should pass the request on to ACPI and/or apm 
and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed 
to be slightly modified to work with arm apm, the final result being:

http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch
I can confirm this works well on arm with apm enabled.
Regards,
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: 2.6: drivers/input/power.c is never built

2005-02-18 Thread Pavel Machek
Hi!


   CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
   this option.
 
  That was written a long time ago before the new power management went 
  in.
  On PDA's there is a power button and suspend button. So this was a hook
  so that the input layer could detect the power/suspend button being
  presses and then power down or turn off the device. Now that the new 
  power
  management is in what should we do?
 
 Change power.c to generate power events like ACPI does, most likely.
 
 
 There was some recent discussion of this on linux-input. It was basically 
 agreed that the input system should pass the request on to ACPI and/or apm 
 and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed 
 to be slightly modified to work with arm apm, the final result being:
 
 http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch
 
 I can confirm this works well on arm with apm enabled.

It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
and it will not work on i386/APM, anyway. I still believe right
solution is to add input interface to ACPI. /proc/acpi/events needs to
die, being replaced by input subsystem.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: drivers/input/power.c is never built

2005-02-18 Thread Oliver Neukum

 It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
 and it will not work on i386/APM, anyway. I still believe right
 solution is to add input interface to ACPI. /proc/acpi/events needs to
 die, being replaced by input subsystem.

But aren't there power events (battery low, etc) which are not
input events?

Regards
Oliver

-
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: [ACPI] Call for help: list of machines with working S3

2005-02-18 Thread Norbert Preining
On Fre, 18 Feb 2005, Norbert Preining wrote:
 I tried:
   2.6.11-rc3-mm2 + Xorg + DRI disabled
 and this works.
 
 I cannot enable dri/drm with the cvs version of the drm modules, because
 the drm modules do not compile for -mm kernels, since there is the patch
 for multiple agp bridges included (that's the reason why I tried -rc4

Final observation: After patching in the changes from mm kernels for
multiple agp bridges to the drm-source code (the patch
drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the
broken out archive) I could compile the drm-trunk-src modules.

So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and
working) with the drm modules from drm-trunk-module-src.

Outcome: freeze when switching to X. As with the other modules (in fact
I think that most of the changes to the drm stuff are included in the mm
kernel, so this should not change anything, as mm pulls from bk-agpgart,
bk-drm-via) a funny screen, and the CapsLock light is blinking.

Best wishes

Norbert

---
Norbert Preining preining AT logic DOT at Università di Siena
sip:[EMAIL PROTECTED] +43 (0) 59966-690018
gpg DSA: 0x09C5B094  fp: 14DF 2E6C 0307 BE6D AD76  A9C0 D2BF 4AA3 09C5 B094
---
`That young girl is one of the least benightedly
unintelligent organic life forms it has been my profound
lack of pleasure not to be able to avoid meeting.'
 --- Marvin's first ever compliment about anybody.
 --- Douglas Adams, The Hitchhikers Guide to the Galaxy
-
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/


gpio api

2005-02-18 Thread Jamey Hicks
GPIO API
Motivation: On many of the little Linux devices I've seen, there are 
multiple
chips providing GPIO and in many cases GPIO pins from one chip are
used to control unrelated functions.  The first approach I took to
solving this problem was to implement a per-function framework.  I
wrote the first version of the lcd_device and backlight_device
framework to separate out the platform-specific parts of a framebuffer
video driver from the framebuffer chip parts.  (That framework was
finished by Andrew Zabolotny and has been accepted into the main
kernel tree.) However, such a framework is quite a bit of overhead for
very simple controls, so I think it would be worthwhile to have a
generic GPIO API.

My initial thought was to provide a synchronous API for configuring
GPIO mode and setting and getting values.  However, GPIOs are
sometimes implemented by chips on slow buses such as I2C and SPI, so
an asynchronous interface should be provided.  For example, a bus
extender such as the MAX7317 provides a set of GPIO pins accessible
via SPI.  There are similar I2C parts.  Since SPI and I2C are much
slower than CPU speeds, it seems best to treat operations on those
GPIO pins as asynchronous.  The SPI bus used to reach the MAX7317
could in turn be implemented by other onchip GPIO pins.  The next
question is to separate the sync and async APIs or combine them. I
have a feeling that if two separate sets of calls are provided that
people using boards with async GPIOs will end up having to rewrite
drivers.
This proposal provides an async interface via a callback registered
via request_gpio.  If a driver supports async operations, it should
provide flags GPIOF_SYNC|GPIOF_ASYNC, a non-NULL callback.  This will
work for both sync and async gpios.  If a driver only supports sync
GPIOs, then it should only provide the GPIOF_SYNC flag and a NULL
callback.  If at runtime the requested gpio is async, then
request_gpio will return -EINVAL.  It is a BUG to go ahead and call
set_gpio_mode, set_gpio_value, or get_gpio_value on an async gpio
without registering a callback.
Platform GPIO Resource
In order to use platform_device to specify the GPIOs used by a device,
we need a definition of IORESOURCE_GPIO.
  #define IORESOURCE_GPIO0x0800
An alternative is to reuse IORESOURCE_IRQ with a flag set.
  #define IORESOURCE_IRQ_GPIO(14)
SYFS Interface to GPIOs
For debugging purposes and for one-off gpio uses, it is very useful to
have a userspace interface to particular gpios.  However, exposing all
gpios this way is a grave security (denial of service) and possibly
safety risk.  The implementation will include an optional sysfs
interface that exposes unrequested GPIOs that have their GPIOF_SYSFS
flag set.
One of the flags could enable a gpio sysfs module to expose the GPIO
to user space.  I am in favor of a sysfs module that only has access
to explicitly exposed GPIOs, as you did in your driver.
GPIO Client Driver API
The first two calls are analogous to request_irq/free_irq, so that
driver can ensure that they have exclusive access to a GPIO and can
specify asynchronous or synchronous access.  I have run into problems
due to out-of-date or misconfigured drivers that would be prevented by
the use of these calls.
  #define GPIOF_SYNC  (1  0)
  #define GPIOF_ASYNC (1  1)
  #define GPIOF_SYSFS (1  2)
  #define GPIOF_VALID (1  3)
  int request_gpio(int gpio_num, const char *name,
  void (*callback)(int gpionum, void *devid), int flags, void *devid);
  void free_gpio(int gpio_num, void *devid);
It is a BUG to supply a NULL callback if GPIO is successfully
requested with GPIOF_ASYNCH set.  [Alternatively, split into sync and
async calls and consider it a BUG to use the synchronous calls on a
GPIO requested with GPIOF_ASYNC set.]
   int set_gpio_mode(int gpionum, int modeflags);
   int set_gpio_value(int gpionum, int value);
   int get_gpio_value(int gpionum);
GPIO Provider API
   struct gpiochip {
  int (*set)(struct gpiochip *chip, void *context, int value);
  int (*get)(struct gpiochip *chip void *context);
  int (*mode)(struct gpiochip *chip, void *context, int modeflags);
   };
GPIOs are associated with gpiochip instances by calling set_gpio_chip.
If the -1 is provided as the gpionum, then the next free gpionum is
returned.  If a positive gpionum is provided and it is already
allocated, then -EINVAL is returned.  If there are no free gpionums,
then -ENOMEM is returned.
   int set_gpio_chip(int gpionum, struct gpiochip *chip, void *context, 
int flags);
   int free_gpio_chip(int gpionum);

=end-of-proposal=
-
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: bio refcount problem

2005-02-18 Thread Jens Axboe
On Fri, Feb 18 2005, Philip R Auld wrote:
 Hi,
   I think there are some potential issues with the reference
 counting of bios as used in 2.6.10. The __make_request function 
 which is the default block device routine accesses the bio structure 
 after issuing the call to add_request. This means that the bio could 
 have completed before __make_request uses it. 
 
 The submit_bh path takes an extra reference with an explicit
 bio_get/put pair around the submit_bio, but many other users of
 submit_bio do not. Given that most of the end_io routines remove a
 reference and hence could free the bio this can lead at the least to 
 __make_request mis-reading the sync flag. In more extreme cases it can 
 cause an oops when run with CONFIG_DEBUG_PAGEALLOC.
 
 The question is what is the preferred fix? I think it may be to simply
 have submit_bio take its own reference (and remove the extra one from 
 submit_bh).
 
 Alternatively __make_request could be adjusted so that it does not
 access the bio after calling add_request. All it is doing is checking
 the bi_rw field for the sync bit.
 
 Or make all users of submit_bio take and release and extra reference
 like submit_bh.

The queue lock is still held at that point, so the driver hasn't had a
chance to process the request yet.

-- 
Jens Axboe

-
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: drivers/input/power.c is never built

2005-02-18 Thread Richard Purdie
Pavel Machek:
It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
and it will not work on i386/APM, anyway. I still believe right
solution is to add input interface to ACPI. /proc/acpi/events needs to
die, being replaced by input subsystem.
I'm not too familiar with ACPI so I can't really comment on that. The system 
I'm working on only has APM. I think some attempt needs to be made to use 
apm if available. As i386 won't support it, lets drop the i386/APM until it 
does and just keep the arm case.

Regards,
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: 2.6: drivers/input/power.c is never built

2005-02-18 Thread Dmitry Torokhov
On Fri, 18 Feb 2005 14:26:51 +0100, Pavel Machek [EMAIL PROTECTED] wrote:
 Hi!
 
 
CONFIG_INPUT_POWER was enabled - but it is nowhere possible to enable
this option.
  
   That was written a long time ago before the new power management went
   in.
   On PDA's there is a power button and suspend button. So this was a hook
   so that the input layer could detect the power/suspend button being
   presses and then power down or turn off the device. Now that the new
   power
   management is in what should we do?
  
  Change power.c to generate power events like ACPI does, most likely.
 
 
  There was some recent discussion of this on linux-input. It was basically
  agreed that the input system should pass the request on to ACPI and/or apm
  and Dmitry Torokhov (cc'd) proposed a patch that did this. His patch needed
  to be slightly modified to work with arm apm, the final result being:
 
  http://www.rpsys.net/openzaurus/2.6.11-rc4/input_power-r1.patch
 
  I can confirm this works well on arm with apm enabled.
 
 It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,

Yes, power.c is an aggregator that transports power events from the
input system into whatever power scheme is in use, so there will
always be a lot of ifdefs unless we will invent grand unified power
interface with userspace. I wonder if we could use kevents.

 and it will not work on i386/APM, anyway.

We could add fix i386 APM case but it looks like most people are
concentrating on ACPI.

 I still believe right
 solution is to add input interface to ACPI. /proc/acpi/events needs to
 die, being replaced by input subsystem.

There are many more events from ACPI that are not related to input, so
we need to keep it. Still, I can see buttons converted to input
devices which bind to power.c and then transmit requests to acpid
through /acpi/proc/event.

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


initialize_acct_integrals

2005-02-18 Thread Jay Lan
Hi Andrew,
The new move-accounting-function-calls-out-of-critical-vm-code-paths
patch in 2.6.11-rc3-mm2 was different from the code i tested.
In particular, it mistakenly dropped the accounting routine calls
in fs/exec.c. The calls in do_execve() are needed to properly
initialize accounting fields. Specifically, the tsk-acct_stimexpd
needs to be initialized to tsk-stime.
I have discussed this with Christoph Lameter and he gave me full
blessings to bring the calls back.
This initialize_acct_integrals patch was generated against
2.6.11-rc3-mm2 to fix the problem. Thanks!
Signed-off-by: Jay Lan [EMAIL PROTECTED]
Index: linux/fs/exec.c
===
--- linux.orig/fs/exec.c2005-02-17 19:24:45.785343748 -0800
+++ linux/fs/exec.c 2005-02-18 05:45:19.868493728 -0800
@@ -1193,6 +1193,8 @@ int do_execve(char * filename,
 
/* execve success */
security_bprm_free(bprm);
+   acct_update_integrals(current);
+   update_mem_hiwater(current);
kfree(bprm);
return retval;
}


Re: bio refcount problem

2005-02-18 Thread Philip R Auld
Hi,

Rumor has it that on Fri, Feb 18, 2005 at 02:59:32PM +0100 Jens Axboe said:
 On Fri, Feb 18 2005, Philip R Auld wrote:

...
  Or make all users of submit_bio take and release and extra reference
  like submit_bh.
 
 The queue lock is still held at that point, so the driver hasn't had a
 chance to process the request yet.

Interesting. This is not a theoretical problem though. I've got traces of 
the oops showing the bio getting freed before the bio_sync(bio) test. 
When you say driver here what level do you mean? scsi_request_fn at 
least drops the queue lock. 

What if it's merged instead of added directly? That could also get to
the same place.

The end_io callback _is_ getting called before __make_request 
does its if(bio_sync(bio)) test. 


Cheers,

Phil


 
 -- 
 Jens Axboe

-- 
Philip R. Auld, Ph.D.  Egenera, Inc.
Software Architect165 Forest St.
(508) 858-2628Marlboro, MA 01752
-
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/


compiling two modules from separate directories out of kernel tree

2005-02-18 Thread Olivier Smeesters
Dear all,
I'm currently developping two kernel modules that I'm compiling outside 
of the kernel tree. One is a device driver and one is a pseudo-network 
device driver (encapsulating network packets).
The output of the encapsulator is supposed to go to the device driver. 
For this reason, the device driver exports a send_packet function 
which the encapsulator calls.

When loading the encapsulator module, the kernel reports a 'no version 
for send_packet found' and goes in tainted mode.
It seems that this is caused by the fact that the two modules are 
compiled in different directories (there is no CRC for the send_packet 
function in the encapsulator module, only for the kernel functions it 
calls).

One solution is to put all the modules in one directory. When this is 
done, a CRC is present in the encapsulator module as expected by the 
module loader and there is no warning anymore.
But as the two drivers are not definitely related (the device driver can 
be used without the encapsulator), I would like to keep them in separate 
directories.
This situation ressembles to the situation of the PLIP and the parport 
driver.

Is there a way to avoid the warning (and tainted mode) while still 
compiling them outside of the kernel tree and in separate directories ?

Thanks in advance,
Olivier Smeesters
-
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: gpio api

2005-02-18 Thread Jörn Engel
On Fri, 18 February 2005 08:46:08 -0500, Jamey Hicks wrote:
 
 GPIO Client Driver API
 
 The first two calls are analogous to request_irq/free_irq, so that
 driver can ensure that they have exclusive access to a GPIO and can
 specify asynchronous or synchronous access.  I have run into problems
 due to out-of-date or misconfigured drivers that would be prevented by
 the use of these calls.
 
   #define GPIOF_SYNC  (1  0)
   #define GPIOF_ASYNC (1  1)
   #define GPIOF_SYSFS (1  2)
   #define GPIOF_VALID (1  3)
 
   int request_gpio(int gpio_num, const char *name,
   void (*callback)(int gpionum, void *devid), int flags, void *devid);
   void free_gpio(int gpio_num, void *devid);
 
 It is a BUG to supply a NULL callback if GPIO is successfully
 requested with GPIOF_ASYNCH set.  [Alternatively, split into sync and
 async calls and consider it a BUG to use the synchronous calls on a
 GPIO requested with GPIOF_ASYNC set.]

Don't split the interface.  BUG_ON((flagsGPIOF_ASYNC)  !callback)
might be a good idea, but most likely there are valid reasons for NULL
callbacks as well.

Also, it's not unusual to request several pins at one.  If the
requester can simply provide a bitmask, the calling code is *much*
simpler.

int set_gpio_mode(int gpionum, int modeflags);
int set_gpio_value(int gpionum, int value);
int get_gpio_value(int gpionum);

These functions either lack a struct gpiochip argument or could be
omitted completely.

 GPIO Provider API
 
struct gpiochip {
   int (*set)(struct gpiochip *chip, void *context, int value);
   int (*get)(struct gpiochip *chip void *context);
   int (*mode)(struct gpiochip *chip, void *context, int modeflags);
};

A private structure is surely needed, no?


Overall, I like the idea.  Having a standard interface for gpio
drivers makes life somewhat easier when writing a driver, and a *lot*
easier when using one.  With every driver having their own custom
interface, some *will* end up broken and unusable.

Jörn

-- 
He that composes himself is wiser than he that composes a book.
-- B. Franklin
-
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: bio refcount problem

2005-02-18 Thread Jens Axboe
On Fri, Feb 18 2005, Philip R Auld wrote:
 Hi,
 
 Rumor has it that on Fri, Feb 18, 2005 at 02:59:32PM +0100 Jens Axboe said:
  On Fri, Feb 18 2005, Philip R Auld wrote:
 
 ...
   Or make all users of submit_bio take and release and extra reference
   like submit_bh.
  
  The queue lock is still held at that point, so the driver hasn't had a
  chance to process the request yet.
 
 Interesting. This is not a theoretical problem though. I've got traces of 
 the oops showing the bio getting freed before the bio_sync(bio) test. 
 When you say driver here what level do you mean? scsi_request_fn at 
 least drops the queue lock. 

But it must be holding the lock to retrieve the request in question, so
there should be no opening for a completion race there.

 What if it's merged instead of added directly? That could also get to
 the same place.

Same deal - if the request is already seen by the driver, merging is not
allowed. If not, then the same rules apply.

 The end_io callback _is_ getting called before __make_request 
 does its if(bio_sync(bio)) test. 

Sounds strange, it sounds like a driver issue. If you have time, please
do poke some more at this. I'll try to be responsive, but I'm busy with
other things atm. Are you using a vanilla kernel?

-- 
Jens Axboe

-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Paul Fulghum
Franck Bui-Huu wrote:
Looking at TTY code, I noticed a weird test done in opost_bock
located in n_tty.c file. I don't understand why the following test is
done at the start of the function:
if (nr  sizeof(buf))
   nr = sizeof(buf);
Actually it limits the size of processing blocks to 4 bytes and I can't
find a reason why.
No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)
Second point, a lot of serial drivers call in their interrupt handler
tty_flip_buffer_push function. This function must no be called
in interrupt context. Why is it done anyway ?
Calling tty_flip_buffer_push() is fine from interrupt
as long as tty-low_latency is not set. It just queues
work for later.
--
Paul Fulghum
Microgate Systems, Ltd.
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Paulo Marques
Paul Fulghum wrote:
Franck Bui-Huu wrote:
Looking at TTY code, I noticed a weird test done in opost_bock
located in n_tty.c file. I don't understand why the following test is
done at the start of the function:
if (nr  sizeof(buf))
   nr = sizeof(buf);
Actually it limits the size of processing blocks to 4 bytes and I can't
find a reason why.

No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)
Looking at the code, I think Franck is right. buf is a const unsigned 
char * for which sizeof(buf) is the size of a pointer.

This certainly looks like a bug.
Since the function doesn't guarantee that nr bytes are written, and the 
caller must handle the case of fewer bytes, this probably went unnoticed.

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Paul Fulghum
Paulo Marques wrote:
Paul Fulghum wrote:
No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)
Looking at the code, I think Franck is right. buf is a const unsigned 
char * for which sizeof(buf) is the size of a pointer.
What kernel version are you looking at?
I'm looking at 2.4.20 n_tty.c opost_block() and
buf is a char array.
--
Paul Fulghum
Microgate Systems, Ltd.
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread linux-os
On Fri, 18 Feb 2005, Paulo Marques wrote:
Franck Bui-Huu wrote:
Looking at TTY code, I noticed a weird test done in opost_bock
located in n_tty.c file. I don't understand why the following test is
done at the start of the function:
if (nr  sizeof(buf))
   nr = sizeof(buf);
Actually it limits the size of processing blocks to 4 bytes and I can't
find a reason why.
No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)
Huh?? buf is a pointer. On this system pointers are 4-bytes
in length. What standard C are you using? Frank found a bug.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Paulo Marques
Paul Fulghum wrote:
Paulo Marques wrote:
Paul Fulghum wrote:
No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)

Looking at the code, I think Franck is right. buf is a const unsigned 
char * for which sizeof(buf) is the size of a pointer.

What kernel version are you looking at?
I'm looking at 2.4.20 n_tty.c opost_block() and
buf is a char array.
Oops, this should have been clarified sooner...
I was looking at a 2.6.11-rc2 tree I have hanging around here. So maybe 
the buf type was changed and the condition remained, and that produced 
the bug.

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread linux-os
On Fri, 18 Feb 2005, Paul Fulghum wrote:
Paulo Marques wrote:
Paul Fulghum wrote:
No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)
Looking at the code, I think Franck is right. buf is a const unsigned char 
* for which sizeof(buf) is the size of a pointer.
What kernel version are you looking at?
I'm looking at 2.4.20 n_tty.c opost_block() and
buf is a char array.
--
Paul Fulghum
Microgate Systems, Ltd.
Ahaa!  That's how the bug got introduced. It used to be an
array and then it got changed to a pointer! linux-2.4.26
also shows a local array.
Cheers,
Dick Johnson
Penguin : Linux version 2.6.10 on an i686 machine (5537.79 BogoMips).
 Notice : All mail here is now cached for review by Dictator Bush.
 98.36% of all statistics are fiction.
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Paulo Marques
linux-os wrote:
On Fri, 18 Feb 2005, Paul Fulghum wrote:
Paulo Marques wrote:
Paul Fulghum wrote:
No, it limits the size to 80 bytes,
which is the size of buf.
sizeof returns the size of the char array buf[80]
(standard C)

Looking at the code, I think Franck is right. buf is a const 
unsigned char * for which sizeof(buf) is the size of a pointer.

What kernel version are you looking at?
I'm looking at 2.4.20 n_tty.c opost_block() and
buf is a char array.
--
Paul Fulghum
Microgate Systems, Ltd.

Ahaa!  That's how the bug got introduced. It used to be an
array and then it got changed to a pointer! linux-2.4.26
also shows a local array.
Yes, just looked at the revision history in linux.bkbits.net and Linus 
just fixed this 67 hours ago... So we're too late :)

--
Paulo Marques - www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] Sparse Memory Handling (hot-add foundation)

2005-02-18 Thread Dave Hansen
On Thu, 2005-02-17 at 21:16 -0800, Mike Kravetz wrote:
 On Thu, Feb 17, 2005 at 04:03:53PM -0800, Dave Hansen wrote:
  The attached patch
 
 Just tried to compile this and noticed that there is no definition
 of valid_section_nr(),  referenced in sparse_init.

What's your .config?  I didn't actually try it on ppc64, and I may have
missed one of the necessary patches.  I trimmed it down to very near the
minimum set on x86.

-- Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() irqs_disabled()

2005-02-18 Thread Dan Dennedy
I have tested the patches (including for allocation), and it is working
great, but should I only commit for now the deallocation patch? Hmm..
which is worse the debug or the 200K waste?

On Fri, 2005-02-11 at 22:54 -0500, Parag Warudkar wrote:
 Jody,
 This happens every time you connect a device which ends up doing
 ISO_LISTEN_CHANNEL. We fixed the device disconnect case in -mm recently.
 
 I had sent you and Andrew an alternative patch which fixes this
 dma_pool_create case as well as the dma_pool_destroy case, albeit with a
 disadvantage - The patch does pre-allocation of the IR Legacy DMA in
 _pci_probe and deallocates it in _pci_remove. However I am not truly
 happy with it since it possibly wastes 200K of memory for people who
 don't have devices which need it.
 
 As I said earlier, I think the way to fix this is via schedule_work
 similar to the disconnect case, but it involves good amount of code
 change. I am working on it - any better ideas most welcome.
 
 Dan - Can you try the attached patch - on top current -mm1? (It's pretty
 no brainer that it will fix both cases but two testing heads are better
 than one.. :)
 


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][PATCH] Sparse Memory Handling (hot-add foundation)

2005-02-18 Thread Dave Hansen
On Fri, 2005-02-18 at 11:04 +0100, Andi Kleen wrote:
 Dave Hansen [EMAIL PROTECTED] writes:
 
  The attached patch, largely written by Andy Whitcroft, implements a
  feature which is similar to DISCONTIGMEM, but has some added features.
  Instead of splitting up the mem_map for each NUMA node, this splits it
  up into areas that represent fixed blocks of memory.  This allows
  individual pieces of that memory to be easily added and removed.

 I'm curious - how does this affect .text size for a i386 or x86-64 NUMA
 kernel? One area I wanted to improve on x86-64 for a long time was
 to shrink the big virt_to_page() etc. inline macros. Your new code
 actually looks a bit smaller.

On x86, it looks like a 3k increase in text size.  I know Matt Tolentino
has been testing it on x86_64, he might have a comparison there for you.

$ size i386-T41-laptop*/vmlinux
   textdata bss dec hex filename
2897131  580592  204252 3681975  382eb7 i386-T41-laptop.sparse/vmlinux
2894166  581832  203228 3679226  3823fa i386-T41-laptop/vmlinux

BTW, this PAE is on and uses 36-bits of physaddr space.  

-- Dave

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] ohci1394: dma_pool_destroy while in_atomic() irqs_disabled()

2005-02-18 Thread Parag Warudkar
On Friday 18 February 2005 10:32 am, Dan Dennedy wrote:
 I have tested the patches (including for allocation), and it is working
 great, but should I only commit for now the deallocation patch? Hmm..
 which is worse the debug or the 200K waste?
Thanks for following it up.

IMHO, we should commit both patches for now since we don't have an alternative 
solution yet. 

Jody - Is the 200K waste for sure or do you want me to verify it by some 
means? ( Reason I am asking is firstly, Dave Brownell was quite sure it 
wasn't that costly and secondly, I am hoping it isn't.. ;)

Parag
-
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: [uml-devel] [BUG: UML 2.6.11-rc4-bk-latest] sleeping function called from invalid context and segmentation fault

2005-02-18 Thread Anton Altaparmakov
On Wed, 2005-02-16 at 19:35 +0100, Blaisorblade wrote:
 On Monday 14 February 2005 12:48, Anton Altaparmakov wrote:
  Hi,
 
  I get a few Debug messages of the form from UML:
 
  Debug: sleeping function called from invalid context at
  include/asm/arch/semaphore.h:107
  in_atomic():0, irqs_disabled():1
  Call Trace:
  087d77b0:  [0809aaa5] __might_sleep+0x135/0x180
  087d77d8:  [084d377f] mcount+0xf/0x20
  087d77e0:  [0807cc13] uml_console_write+0x33/0x80
 
  Most are coming via uml_console_write.
 The problem is that the UML tty drivers use a semaphore instead of a spinlock 
 for the locking, which also causes some other problems.
 
 The attached patch should fix this, but I've not yet made sure it is not 
 deadlock-prone (I didn't hit any during some very limited testing).
 
 So it's not yet ready for 2.6.11.

Trying with the above patch in now only get two sleeping function
called from invalid context warnings during boot and none during
running.  However I get a lot of those errors:

arch/um/drivers/line.c:262: spin_lock(arch/um/drivers/line.c:085b5900)
already locked by arch/um/drivers/line.c/262

Also both before and after the patch I see a lot of messages like:

kernel: line_write_room: tty2: no room left in buffer

Best regards,

Anton
-- 
Anton Altaparmakov aia21 at cam.ac.uk (replace at with @)
Unix Support, Computing Service, University of Cambridge, CB2 3QH, UK
Linux NTFS maintainer / IRC: #ntfs on irc.freenode.net
WWW: http://linux-ntfs.sf.net/  http://www-stu.christs.cam.ac.uk/~aia21/

-
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: drivers/input/power.c is never built

2005-02-18 Thread Pavel Machek
Hi!

  It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
  and it will not work on i386/APM, anyway. I still believe right
  solution is to add input interface to ACPI. /proc/acpi/events needs to
  die, being replaced by input subsystem.
 
 But aren't there power events (battery low, etc) which are not
 input events?

Yes, there are. They can probably stay... Or we can get battery low
key.
Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Franck Bui-Huu

Ahaa!  That's how the bug got introduced. It used to be an
array and then it got changed to a pointer! linux-2.4.26
also shows a local array.

Yes, just looked at the revision history in linux.bkbits.net and Linus 
just fixed this 67 hours ago... So we're too late :)

ok, maybe next time :)
 Franck
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Paul Jackson
Andi - what does this line mean:

  + node mask length. 

I guess its the names of the parameters in a proposed
migration system call.  Length of what, mask of what,
what's the node mean, huh?

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Paul Jackson
Andi wrote:
 I don't like old_node* very much because it's imho unreliable
 (because you can usually never fully know on which nodes the old
 process was and there can be good reasons to just migrate everything)

That's one way that the arrays of old and new nodes pays off.
You can list any old node that might have a page, and state
which new node that page should go to.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Paul Jackson
Andi wrote:
 e.g. job runs threads on nodes 0,1,2,3  and you want it to move
 to nodes 4,5,6,7 with all memory staying staying in the same
 distance from the new CPUs as it were from the old CPUs, right? 
 
 It explains why you want old_node, you would do 
 (assuming node mask arguments) 

Yup - my immediately preceeding post repeated this - sorry.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
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: [BK] upgrade will be needed

2005-02-18 Thread Theodore Ts'o
On Fri, Feb 18, 2005 at 02:52:20AM -0500, Sean wrote:
 There are ways that the tools could coexist and work together better than
 they do today. If people would stop acting like BK was in jeopardy of
 being taken away from them and realize that others just want the ability
 to use their tools of choice too.

If you truly believe that BK would be able to add the value that it
does to the kernel development process by using some other SCM as the
master SCM, with BK being underneath, as you proposed earlier, then
you do not understand why BK is fundamentally better than the current
open source SCM systems that are out there.

And people *can* use the tools of their choice today.  They can use
CVS, and diff+patch, and suffer with all of the limitations that those
tools have today.  And for people who are doing stuff around the
periphery, quilt is often really the best tool for them.  

  Linus clearly considered not just his /own/ workflow, but the workflow
  for the /whole/ kernel development community. In fact, BK was designed
 
 Well, the /whole/ community isn't yet included, that's what we're talking
 about.

If it's about the whole ***kernel*** development community, then it's
pretty clear that the current system works quite well.  All of the
complaints have been coming primarily from SCM hackers, it seems, and
not people who truly need the power of more powerful than downloading
the bk snapshots, using the CVS export tree, and in the case where
they need to look at the changes in a single changeset bkbits.net.  

The cost of using BK seems to be primarily more theoretical, and
ideological, than real.  It's always seems to be about someone
kvetching that they want to use SVN and get finely grained changsets
through SVN, and they can't.  But how often does that happen, and
what's so painful of getting the finely grained changeset through
bkbits.net?  Not very.  So at the end of the day, it finally boils
down to being all about ideology, doesn't it?

Once again proving that Linus, as is often the case, was right all
along.

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


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Paul Jackson
Andi wrote:
 Problem is what happens
 when some memory is in some other node due to memory pressure fallbacks.
 Your scheme would not migrate this memory at all. 

The arrays of old and new nodes handle this fine.
Include that 'other node' in the array of old nodes,
and the corresponding new node, where those pages
should migrate, in the array of new nodes.

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
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: [TTY] 2 points seems strange to me.

2005-02-18 Thread Franck Bui-Huu

Second point, a lot of serial drivers call in their interrupt handler
tty_flip_buffer_push function. This function must no be called
in interrupt context. Why is it done anyway ?

Calling tty_flip_buffer_push() is fine from interrupt
as long as tty-low_latency is not set. It just queues
work for later.
I was looking at driver for 8250 in 8250.c file and at the end
of receive_chars interrupt handler, it calls tty_flip_buffer_push
even if tty-low_latency is set since no such test is done before
the call...
I was also wondering why not always calling schedule_delayed_work
whatever the state of tty-latency?
 Franck
-
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: Pty is losing bytes

2005-02-18 Thread Theodore Ts'o
On Thu, Feb 17, 2005 at 07:45:56AM -0800, Linus Torvalds wrote:
 
 
 On Wed, 16 Feb 2005, Theodore Ts'o wrote:
  
  Yes, but then when the buffer is full, and we return the we'll take
  anything return value, the code that was getting confused with the
  incorrect receive_room value will still be getting confused
 
 But that's fine - at that point we're literally _supposed_ to drop 
 characters: we have to, in order to see the EOLN.
 
 But we're only supposed to drop characters IFF:
  - the buffer is full
  - we are in canon mode
  - we _still_ haven't seen a single EOLN in the whole buffer

Sure, but in that case, if we return no worries, we have plenty of
memory, then we're opening ourselves up to the memory overrun problem
that was the original issue in the first place.  I suspect that the
underlying problem is that somewhere in the tty layer there is code
that is using receive_room() as permission to simply push that many
characters into the receive queue, instead of using that function as
an hint of how many characters would be profitable to feed into the
line discpline.

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


Re: [TTY] 2 points seems strange to me.

2005-02-18 Thread Paul Fulghum
Franck Bui-Huu wrote:
I was looking at driver for 8250 in 8250.c file and at the end
of receive_chars interrupt handler, it calls tty_flip_buffer_push
even if tty-low_latency is set since no such test is done before
the call...
Yes this is a known problem. In the case of SMP kernel
and low_latency, and 8250.c, this causes a dead lock. This has
resurfaced again and again for many months from
different sources.
There is disagreement on what code is
in error and what should be fixed. So it stays broken.
I was also wondering why not always calling schedule_delayed_work
whatever the state of tty-latency?
If low_latency is set and you are not calling
from interrupt, then calling work directly speeds processing.
I submitted a patch that forced schedule_delayed_work
if in interrupt context to avoid this problem. It was rejected.
--
Paul Fulghum
Microgate Systems, Ltd.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] inotify for 2.6.11-rc3-mm2

2005-02-18 Thread Robert Love
On Thu, 2005-02-10 at 13:47 -0500, Robert Love wrote:

 Attached, find a patch against 2.6.11-rc3-mm2 of the latest inotify.

Updated patch, fixes a bug.

Robert Love


inotify, bitches

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

 arch/sparc64/Kconfig   |   13 
 drivers/char/Kconfig   |   13 
 drivers/char/Makefile  |2 
 drivers/char/inotify.c | 1053 +
 drivers/char/misc.c|   14 
 fs/attr.c  |   34 -
 fs/compat.c|   14 
 fs/file_table.c|4 
 fs/inode.c |3 
 fs/namei.c |   38 -
 fs/open.c  |9 
 fs/read_write.c|   28 -
 fs/super.c |3 
 include/linux/fs.h |7 
 include/linux/fsnotify.h   |  235 ++
 include/linux/inotify.h|  118 +
 include/linux/miscdevice.h |5 
 include/linux/sched.h  |2 
 kernel/user.c  |2 
 19 files changed, 1522 insertions(+), 75 deletions(-)

diff -urN linux-2.6.10/arch/sparc64/Kconfig linux/arch/sparc64/Kconfig
--- linux-2.6.10/arch/sparc64/Kconfig   2004-12-24 16:35:25.0 -0500
+++ linux/arch/sparc64/Kconfig  2005-02-01 12:24:26.0 -0500
@@ -88,6 +88,19 @@
bool
default y
 
+config INOTIFY
+   bool Inotify file change notification support
+   default y
+   ---help---
+ Say Y here to enable inotify support and the /dev/inotify character
+ device.  Inotify is a file change notification system and a
+ replacement for dnotify.  Inotify fixes numerous shortcomings in
+ dnotify and introduces several new features.  It allows monitoring
+ of both files and directories via a single open fd.  Multiple file
+ events are supported.
+
+ If unsure, say Y.
+
 config SMP
bool Symmetric multi-processing support
---help---
diff -urN linux-2.6.10/drivers/char/inotify.c linux/drivers/char/inotify.c
--- linux-2.6.10/drivers/char/inotify.c 1969-12-31 19:00:00.0 -0500
+++ linux/drivers/char/inotify.c2005-02-09 16:05:07.959265648 -0500
@@ -0,0 +1,1053 @@
+/*
+ * drivers/char/inotify.c - inode-based file event notifications
+ *
+ * Authors:
+ * John McCutchan  [EMAIL PROTECTED]
+ * Robert Love [EMAIL PROTECTED]
+ *
+ * Copyright (C) 2005 John McCutchan
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of the GNU General Public License as published by the
+ * Free Software Foundation; either version 2, or (at your option) any
+ * later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+ * General Public License for more details.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include linux/sched.h
+#include linux/spinlock.h
+#include linux/idr.h
+#include linux/slab.h
+#include linux/fs.h
+#include linux/namei.h
+#include linux/poll.h
+#include linux/device.h
+#include linux/miscdevice.h
+#include linux/init.h
+#include linux/list.h
+#include linux/writeback.h
+#include linux/inotify.h
+
+#include asm/ioctls.h
+
+static atomic_t inotify_cookie;
+static kmem_cache_t *watch_cachep;
+static kmem_cache_t *event_cachep;
+static kmem_cache_t *inode_data_cachep;
+
+static int sysfs_attrib_max_user_devices;
+static int sysfs_attrib_max_user_watches;
+static unsigned int sysfs_attrib_max_queued_events;
+
+/*
+ * struct inotify_device - represents an open instance of an inotify device
+ *
+ * For each inotify device, we need to keep track of the events queued on it,
+ * a list of the inodes that we are watching, and so on.
+ *
+ * This structure is protected by 'lock'.  Lock ordering:
+ *
+ * dev-lock (protects dev)
+ * inode_lock (used to safely walk inode_in_use list)
+ * inode-i_lock (only needed for getting ref on inode_data)
+ */
+struct inotify_device {
+   wait_queue_head_t   wait;
+   struct idr  idr;
+   struct list_headevents;
+   struct list_headwatches;
+   spinlock_t  lock;
+   unsigned intqueue_size;
+   unsigned intevent_count;
+   unsigned intmax_events;
+   struct user_struct  *user;
+};
+
+struct inotify_watch {
+   s32 wd; /* watch descriptor */
+   u32 mask;   /* event mask for this watch */
+   struct inode*inode; /* associated inode */
+   struct inotify_device   *dev;   /* associated device */
+   struct list_headd_list; /* entry in device's list */
+   struct list_headi_list; /* entry in inotify_data's list */
+};
+
+/*
+ * A list of these is attached to each instance of the driver.  In read(), this
+ * this list is walked and all events 

Re: [PATCH] quiet non-x86 option ROM warnings

2005-02-18 Thread Jon Smirl
On Fri, 18 Feb 2005 13:09:14 +0100, Gabriel Paubert [EMAIL PROTECTED] wrote:
 For example if it declares 128k, compare the two halves, reduce
 to 64k if equal. Lather, rinse, repeat.
 
 It's equivalent to reading the BAR declared size twice in
 the worst case, so it's not that bad performance-wise.
 
 That would only be in the case of an unknown signature
 in the first bytes, otherwise the third byte gives you
 the size IIUC.

The third byte size is wrong in too many cards to be useful. I have
always found the size in the PCIR header to be accurate.

 
 Gabriel
 


-- 
Jon Smirl
[EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.10-ac12 + kernbench == oom-killer: (OSDL)

2005-02-18 Thread Cliff White
 On Tue, Feb 08, 2005 at 02:57:07PM -0800, cliff white wrote:
 
  Running 2.6.10-ac10 on the STP 1-CPU machines, we don't seem to be able to 
 complete
  a kernbench run without hitting the OOM-killer. ( kernbench is multiple ker
 nel compiles,
  of course ) Machine is 800 mhz PIII with 1GB memory. We reduce memory for s
 ome of the runs.
  
  Typical results:
  
  Out of Memory: Killed process 14970 (cc1).
  -
  It looks like some oom-related stuff went into -ac10, will try retest with 
  -ac9 and -ac10, see what happens. Lemme know if we can do more
 
 I am always curious to hear how things are when you set
 /proc/sys/vm/overcommit_memory to 2
 (and possibly /proc/sys/vm/overcommit_ratio to something
 appropriate).

Okay, with just vm.overcommit=2, things are still bad:
http://khack.osdl.org/stp/300854/logs/TestRunFailed.console.log.txt

Suggestion for vm.overcommit_ratio ?
Or should i repeat with later -ac ?
cliffw

---Some output---
Free pages:8872kB (0kB HighMem)

Active:14865 inactive:4118 dirty:0 writeback:629 unstable:0 free:2218 
slab:11489 mapped:32027 pagetables:13800

DMA free:1224kB min:128kB low:160kB high:192kB active:552kB inactive:196kB 
present:16384kB pages_scanned:401 all_unreclaimable? no

protections[]: 0 0 0

Normal free:7648kB min:1920kB low:2400kB high:2880kB active:58908kB 
inactive:16276kB present:245760kB pages_scanned:1395 all_unreclaimable? no

protections[]: 0 0 0

HighMem free:0kB min:128kB low:160kB high:192kB active:0kB inactive:0kB 
present:0kB pages_scanned:0 all_unreclaimable? no

protections[]: 0 0 0

DMA: 240*4kB 17*8kB 2*16kB 1*32kB 1*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 
0*2048kB 0*4096kB = 1224kB

Normal: 1348*4kB 46*8kB 54*16kB 6*32kB 1*64kB 0*128kB 1*256kB 1*512kB 0*1024kB 
0*2048kB 0*4096kB = 7648kB

HighMem: empty

Swap cache: add 23226854, delete 23224756, find 324015/2933249, race 2549+2365

Out of Memory: Killed process 14667 (rpm).

oom-killer: gfp_mask=0xd2

DMA per-cpu:

cpu 0 hot: low 2, high 6, batch 1

cpu 0 cold: low 0, high 2, batch 1

Normal per-cpu:

cpu 0 hot: low 30, high 90, batch 15

cpu 0 cold: low 0, high 30, batch 15

HighMem per-cpu: empty

--
cliffw



 
 Andries
 
-
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 modules query

2005-02-18 Thread Aleksey Gorelov
Hi 

-Original Message-
From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of linux lover
Sent: Friday, February 18, 2005 1:36 AM
To: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org
Subject: Kernel modules query

Hello,
I want to know can a variable be exported by a linux kernel
modules? How can i make a variable getting assigned in kernel module
available to other kernel modules?
regards,
linux.lover.

EXPORT_SYMBOL(var_name);

For example see arch/i386/kernel/time.c  jiffies_64 (2.6.10 source).

Aleks.

-
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: drivers/input/power.c is never built

2005-02-18 Thread Vojtech Pavlik
On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:

   It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
   and it will not work on i386/APM, anyway. I still believe right
   solution is to add input interface to ACPI. /proc/acpi/events needs to
   die, being replaced by input subsystem.
  
  But aren't there power events (battery low, etc) which are not
  input events?
 
 Yes, there are. They can probably stay... Or we can get battery low
 key.
 
We even have an event class for that, EV_PWR in the input subsystem.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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/


use of TASK_SIZE to determine user/kernel

2005-02-18 Thread Kumar Gala
We are looking at a 32-bit architecture implementation were we can have 
distinct address spaces for user and kernel, thus allowing 4G's for 
each.  In doing this we have come across the use of TASK_SIZE to 
determine if an address is user vs kernel (example mm/memory.c).  I'm 
wondering is it just sufficient to set TASK_SIZE to 0x?  This 
feels wrong to me, since it would imply that all the places that are 
testing will never need access to the kernel memory space.

thanks
- kumar
-
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: drivers/input/power.c is never built

2005-02-18 Thread Oliver Neukum
Am Freitag, 18. Februar 2005 18:00 schrieb Vojtech Pavlik:
 On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
 
It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
and it will not work on i386/APM, anyway. I still believe right
solution is to add input interface to ACPI. /proc/acpi/events needs to
die, being replaced by input subsystem.
   
   But aren't there power events (battery low, etc) which are not
   input events?
  
  Yes, there are. They can probably stay... Or we can get battery low
  key.
  
 We even have an event class for that, EV_PWR in the input subsystem.

Over that route we'd arrive at a situation where power management
without the input layer is impossible. Think about embedded stuff I wonder
whether this is viable.

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


Sis760 chipset support

2005-02-18 Thread Marc Cramdal
Hello,

I can't make agpgart working (even when trying the agp_try_unsupported) 
option. I have an AMD64 3000+ with a Sis760 chipset and agp doesn't seem to 
be supported : I only get this with dmesg : Linux agpgart interface v0.100 
(c) Dave Jones. That's all...

So, is Sis760 chipset supported for agpgart under linux kernel ? if not, is 
there plan to be, tweaks to do (I even tried the Sis Chipset driver 
for !x86_64 by removing this entry in KConfig ... ) ?

Marc
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Ray Bryant
Here's an interface proposal that may be a middle ground and
should satisfy both small and large system requirements:
The system call interface would be:
page_migrate(pid, va_start, va_end, count, old_node_list, new_node_list);
(e. g. same as before, but please keep reading):
The following restrictions of my original proposal would be
dropped:
(1)  va_start and va_end can span multiple vma's.  To migrate
 all pages in a process, va_start can be 0UL and va_end
 would be MAX_INT L.  (Equivalently, we could use va_start
 and length, in pages)  We would expect the normal usage
 of this call on small systems to be va_start=0, va_end=MAX_INT.
 va_start and va_end would be required to be page aligned.
(2)  There is no requirement that the pid be suspended before
 the system call is issued.  Further requirements below
 are proposed to handle the allocation of new pages while
 the migrate system call is in progress.
(3)  Mempolicy data structures will be updated to reflect the
 new node locations before any pages are migrated.  That
 way, if the process allocates new pages before the migration
 process is completed, they will be allocated on the new
 nodes.
 (An alternative:  we could require the user to update
 the NUMA API data structures to reflect the new reality
 before the page_migrate() call is issued.  This is consistent
 with item (4).  If the user doesn't do this, then
 there is no guarentee that the page migration call will
 actually be able to migrate all pages.)
 If any memory policy is DEFAULT, then the pid will need to
 be migrated to a cpu associated with  one of the new_node_list
 nodes before the page_migrate() call.  This is so new
 allocations will happen in the new_node_list and the
 migration call won't miss those pages.  The system call
 will work correctly without this, it just can't guarentee
 that it will migrate all pages from the old_nodes.
(4)  If cpusets are in use, the new_node_list must represent
 valid nodes to allocate pages from for the cpuset that
 pid is currently a member of.  This implies that the
 pid is moved from its old cpuset to a new cpuset before
 the page_migrate() call is issued.  Any nodes not part
 of the new cpu set will cause the system call to return
 with -EINVAL.
(5)  If, during the migration process, a page is to be moved to
 node N, but the alloc_pages_node() call for node N fails, then the
 page will fall over to allocation on the nearest node
 in the new_node_list; if this node is full then fall over
 to the next nearest node, etc.  If none of the nodes has
 space, then the migration system call will fail.  (Hmmm...
 would we unmigrate the pages that had been migrated
 this far??  sounds messy also, not sure what one
 would do about error reporting here so that the caller
 could take some corrective action.)
(6)  The system call is reserved to root or a pid with
 capability CAP_PAGE_MIGRATE.
(7)  Mapped files with the extended attribute MIGRATE
 set to NONE are not migrated by the system call.
 Mapped files with the extended attribute MIGRATE
 set to LIB will be handled as follows:  r/o
 mappings will not be migrated.  r/w mappings will
 be migrated.  If no MIGRATE extended attribute is available,
 then the assumtion is that the MIGRATE extended
 attribute is not set.  (Files mapped from NFS
 would always be regarded as migrateable until
 NFS gets extended attributes.)
Note that nothing here requires parsing of /proc/pid/maps,
etc.  However, very large systems may use the system call
in special ways, e. g:
(1)  They may decide to suspend processes before migration.
(2)  They may decide to optimize the migration process by
 trying to migrate large shared objects only once,
 in the sense that only one scan of a large shared
 object will be done.
Issues of complexity related to the above are reserved for
those systems who choose to use the system call in this way.
Please note, however that this is a performance optimization
that some systems MAY decide to do.  There is NO REQUIREMENT
that any user follow these steps from a correctness point of
view, the page_migrate() system call will still do the correct
thing.
Now, I know that is complicated and lot of verbage.  But this
would satisfy our requirements and I think it would satisfy
the concern that the page_migration() call was built just to
satisfy SGI requirements.
Comments, flames, suggestions, etc, as usual are all welcome.
--
---
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: Requires Windows 98 or better,
 so I installed Linux.
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of 

Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Ray Bryant
Andi Kleen wrote:
You and Robin mentioned some problems with double migration
with that, but it's still not completely clear to me what
problem you're solving here. Perhaps that needs to be reexamined.

There is one other case where Robin and I have talked about double
migration.  That is the case where the set of old nodes and new
nodes overlap.  If one is not careful, and the system call interface
is assumed to be something like:
page_migrate(pid, old_node, new_node);
then if one is not careful (and depending on what the complete list
of old_nodes and new_nodes are), then if one does something like:
page_migrate(pid, 1, 2);
page_migrate(pid, 2, 3);
then you can end up actually moving pages from node 1 to node 2,
only to move them again from node 2 to node 3.  This is another
form of double migration that we have worried about avoiding.
--
---
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: Requires Windows 98 or better,
 so I installed Linux.
---
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC 2.6.11-rc2-mm2 0/7] mm: manual page migration -- overview II

2005-02-18 Thread Ray Bryant
Andi, et al:
I see that  several messages have been sent in the interim.
I apologize for being out of sync, but today is my last
day to go skiing and it is gorgeous outside.  I'll try
to catch up and digest everthing later.
--
---
Ray Bryant
512-453-9679 (work) 512-507-7807 (cell)
[EMAIL PROTECTED] [EMAIL PROTECTED]
The box said: Requires Windows 98 or better,
 so I installed Linux.
---
-
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.11-rc3: intel8x0 alsa outputs no sound

2005-02-18 Thread Tomas Szepe
  Try muting the headphone jack sense control with alsamixer. I had the
  same problem with rc2 on my t41p, and that solved it.
 
 This doesn't help on a T40p, I'm afraid.
 No sound in 2.6.11-rc3 with snd-intel8x0.ko, worked all ok in 2.6.10.

Ok, the problem seems to be gone in 2.6.11-rc4.

-- 
Tomas Szepe [EMAIL PROTECTED]
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [patch] inotify for 2.6.11-rc3-mm2

2005-02-18 Thread Al Viro
On Fri, Feb 18, 2005 at 11:40:59AM -0500, Robert Love wrote:
 inotify, bitches

/me does pick a random function, find a race again.
 
 +/*
 + * inode_add_watch - add a watch to the given inode
 + *
 + * Callers must hold dev-lock, because we call inode_find_dev().
 + */
 +static int inode_add_watch(struct inode *inode, struct inotify_watch *watch)
[snip]
 + list_add(watch-i_list, inode-inotify_data-watches);
 ^
... and that is protected by what?
 +
 + return 0;

Fix the damn locking, already.
-
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: Bogus REPORT_LUNS responses breaks SCSI LUN detection

2005-02-18 Thread Andries Brouwer
On Sun, Feb 13, 2005 at 11:51:00PM -0500, Kurt Garloff wrote:

  SuSE 9.1
  Vendor: easyRAID Model: X16 Rev: 0001
  Type: Direct-Access ANSI SCSI revision: 03
  scsi: host 0 channel 0 id 5 lun 0x6500737952414944 has a LUN larger than 
  currently supported.
 
 Looks like random garbage.

I read e syRAID

  Kernel 2.6, unknown distro
  Vendor: transtec  Model:   Rev: 0001
  Type:   Direct-Access  ANSI SCSI revision: 03
  On host 1 channel 0 id 1 only 128 (max_scsi_report_luns) of 536870896 
  luns reported, try increasing max_scsi_report_luns.
  scsi: host 1 channel 0 id 1 lun 0x7400616e73746563 has a LUN larger than 
  currently supported.

I read t anstec

So - you might wish to investigate why the 2nd byte of easyRAID and
of transtec was zeroed, and whether contents like this was to be
expected (maybe the previous command was IDENTIFY?).

Andries
-
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: drivers/input/power.c is never built

2005-02-18 Thread Vojtech Pavlik
On Fri, Feb 18, 2005 at 06:05:12PM +0100, Oliver Neukum wrote:
 Am Freitag, 18. Februar 2005 18:00 schrieb Vojtech Pavlik:
  On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
  
 It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
 and it will not work on i386/APM, anyway. I still believe right
 solution is to add input interface to ACPI. /proc/acpi/events needs to
 die, being replaced by input subsystem.

But aren't there power events (battery low, etc) which are not
input events?
   
   Yes, there are. They can probably stay... Or we can get battery low
   key.
   
  We even have an event class for that, EV_PWR in the input subsystem.
 
 Over that route we'd arrive at a situation where power management
 without the input layer is impossible.

All you'd need is input.c. One file, approx 750 lines at the moment, a
big chunk of that can be confugured out if you don't need procfs or
hotplug.

 Think about embedded stuff I wonder whether this is viable.

On most embedded platforms you have some buttons or controls, so it's
likely you'll use input anyway.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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: [darcs-users] Re: [BK] upgrade will be needed

2005-02-18 Thread Dustin Sallings
On Feb 18, 2005, at 1:09, Andrea Arcangeli wrote:
darcs scares me a bit because it's in haskell, I don't believe very 
much
in functional languages for compute intensive stuff, ram utilization
	It doesn't sound like you've programmed in functional languages all 
that much.  While I don't have any practical experience in Haskell, I 
can say for sure that my functional code in ocaml blows my C code away 
in maintainability and performance.  Now, if I could only get it to 
dump core...

	Haskell was a draw for me.  It's very rare to find someone who 
actually knows C and can write bulletproof code in it.

On Fri, Feb 18, 2005 at 12:53:09PM +0100, Erik Bågfors wrote:
RCS/SCCS format doesn't make much sence for a changeset oriented SCM.
The advantage it will provide is that it'll be compact and a backup 
will
compress at best too. Small compressed tarballs compress very badly
instead, it wouldn't be even comparable. Once the thing is very compact
it has a better chance to fit in cache, and if it fits in cache
extracting diffs from each file will be very fast. Once it'll be 
compact
the cost of a changeset will be diminished allowing it to scale better
too.
	Then what gets transferred over the wire?  The full modified ,v file?  
Do you need a smart server to create deltas to be applied to your ,v 
files?  What do you do when someone goes in with an rcs command to 
destroy part of the history (since the storage is now mutable).

	I use both darcs and arch regularly.  darcs is a lot nicer to use from 
a human interface point of view (and the merging is really a lot 
nicer), but the nicest thing about arch is that a given commit is 
immutable.  There are no tools to modify it.  This is also why the 
crypto signature stuff was so easy to fit in.

RCS and SCCS storage throws away most of those features.
--
Dustin Sallings
-
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] relayfs redux, part 5

2005-02-18 Thread Tom Zanussi
Hi,

Here's the latest version of relayfs, with changes incorporating the
previous round of suggestions.  Thanks to Pekka Enberg and Maneesh
Soni for commenting on the previous patch.  Since there weren't any
complaints about the API last time, I went ahead and did some SMP
testing (see below) and wrote some Documentation.  The patch size
without the documentation hasn't changed much and is still about 41K.

Here's a list of the changes in this version:

- cleaned up some of the code in buffers.c and moved everything
  buffer-related there.
- got rid of the extra parameter in relay_create_entry().
- added a prev_subbuf_data param to the subbuf_start() callback.
- the subbuf_start() callback is now called for the first sub-buffer
  when a buffer is created.
- added relay_flush(), needed when closing a channel.
- added sanity checks to all the non-performance-critical API
  functions.
- some small changes needed for proper handling of the buffer-full
  condition.
- the reserved address is now passed into relay_commit() in order to
  make it easier to use.
- added kref to channel
- other random cleanup


I've done some pretty heavy pounding on this version and haven't had
much luck breaking it yet. ;-)  Using a hacked version of the kprobes
network packet tracing module, I tested it on a couple different
systems: a 4x700MHz Pentium III SMP system and a 3GHz Pentium 4 system
with hyperthreading on.

Here's a summary of the results of the test on the 4x700MHz Pentium
III system:

The following tests were run while transferring a 1 Gb test file.  All
numbers are averaged over 5 runs.

1) 5:37.58 minutes - baseline, netpktlog not inserted
2) 5:46.76 minutes - netpktlog inserted, but with empty kprobes handlers
3) 6:26.29 minutes - formatting data but no relay_write
4) 6:27.71 minutes - relay_write() with logging to disk
5) 6:27.70 minutes - relay_write() with no logging to disk

The average trace file size generated for 4), which is the only test
that generates data, was 1,154,171,258 bytes (yes, the trace file is
larger than the transferred file).

The total event count for 4) was 6,770,949 events of average length
149.

The amount of data logged in this test averaged 2.98 Mb/sec, and the
average number of events logged was 17464/sec.

Some comments:

For 2), I hadn't intended on testing the efficiency of kprobes, but
since I was there I thought I'd try replacing the handler code with
nothing but jprobes_return() and see what kind of overhead kprobes
alone introduces.  On this system, there was a small but noticeable
hit due to kprobes.  On the 3 GHz P4 system, this didn't show up in
the numbers.

For 3) nothing is being written to the relayfs channel - the main
thing going on in the kprobes handlers is the formatting of the data
using vsnprintf(), which here seems very expensive.  On the other
system tested, it was much less of a factor in the numbers.

For 4) and 5), writing to the channel using relay_write() seems to be
pretty efficient; in any case the numbers don't show a significant hit
to this system even when logging to disk.  Of course, the fact that
the numbers with and without logging to disk were essentially the same
means that the disk subsystem is pretty efficient too.  Since this
wasn't a very controlled test, I don't really trust any numbers this
close together, but using them anyway, it shows about a 0.3 - 0.4%
overhead when logging 3Mb/sec to disk on this system.  Actually, there
was one run that was 3 seconds longer than the others - if we remove
that the average time was 6:27.03 minutes, which makes it  0.2%.


Here's a summary of the results of the test on the 3GHz hyperthreading
system:

The following tests were run while transferring a 250Mb test file.  All
numbers are averaged over 3 runs.

1) 4:38.79 minutes - baseline, netpktlog not inserted
2) 4:37.73 minutes - formatting data but no relay_write
3) 4:43.70 minutes - relay_write() with logging to disk
4) 4:37.59 minutes - relay_write() with no logging to disk

The average trace file size generated for 3), which is the only test
that generates data, was 295,514,458 bytes.

The total event count for 3) was 1,683,751 events of average length
176.

The amount of data logged in this test averaged 913 Kb/sec, and the
average number of events logged was 5202/sec.

Some comments:

For 2) the kprobes cost and the cost of formatting the data doesn't
show up in the numbers at all, maybe since it's a much faster
processor.

For 3) the number basically reflects the cost of logging the trace
data to disk for this system and not the cost of relay_write(), since
as we can see from 4), if not logging to disk there's essentially no
difference between the relay_write() and no-relay_write() runs.
Again, this wasn't a controlled test, so any differences here are
definitely in the noise.

The network packet tracing module and userspace program I used for
testing can be found here (the raw test data is also included):


Re: [patch] inotify for 2.6.11-rc3-mm2

2005-02-18 Thread Robert Love
On Fri, 2005-02-18 at 17:24 +, Al Viro wrote:

 Fix the damn locking, already.

Fast as I can.

Robert Love


-
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: [ACPI] Call for help: list of machines with working S3

2005-02-18 Thread Stefan Dsinger
Am Freitag, 18. Februar 2005 14:38 schrieb Norbert Preining:
 On Fre, 18 Feb 2005, Norbert Preining wrote:
  I tried:
   2.6.11-rc3-mm2 + Xorg + DRI disabled
  and this works.
 
  I cannot enable dri/drm with the cvs version of the drm modules, because
  the drm modules do not compile for -mm kernels, since there is the patch
  for multiple agp bridges included (that's the reason why I tried -rc4

 Final observation: After patching in the changes from mm kernels for
 multiple agp bridges to the drm-source code (the patch
 drm-add-support-for-new-multiple-agp-bridge-agpgart-api.patch from the
 broken out archive) I could compile the drm-trunk-src modules.

 So now I am running with 2.6.11-rc3-mm2 + Xorg + DRI enabled (and
 working) with the drm modules from drm-trunk-module-src.

 Outcome: freeze when switching to X. As with the other modules (in fact
 I think that most of the changes to the drm stuff are included in the mm
 kernel, so this should not change anything, as mm pulls from bk-agpgart,
 bk-drm-via) a funny screen, and the CapsLock light is blinking.
Kernel panik. Can you ssh into your maschine and get a dmesg? I recommend you 
to write to the dri devs.

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


Bootsplash for 2.6.11-rc4

2005-02-18 Thread Pavel Machek
Hi!

Just in case someone is interested, this is bootsplash for 2.6.11-rc4,
taken from suse kernel. I'll probably try to modify it to work with
radeonfb.

Any ideas why bootsplash needs to hack into vesafb? It only uses
vesafb_ops to test against them before some kind of free...

Pavel

--- clean/drivers/char/keyboard.c   2005-01-22 21:24:52.0 +0100
+++ linux-suse/drivers/char/keyboard.c  2005-02-18 16:13:06.0 +0100
@@ -1058,6 +1058,15 @@
if (keycode  BTN_MISC)
printk(KERN_WARNING keyboard.c: can't emulate 
rawmode for keycode %d\n, keycode);
 
+#ifdef CONFIG_BOOTSPLASH
+   /* This code has to be redone for some non-x86 platforms */
+   if (down == 1  (keycode == 0x3c || keycode == 0x01)) {/* F2 
and ESC on PC keyboard */
+   extern int splash_verbose(void);
+   if (splash_verbose())
+   return; 
+   }   
+#endif
+
 #ifdef CONFIG_MAGIC_SYSRQ /* Handle the SysRq Hack */
if (keycode == KEY_SYSRQ  (sysrq_down || (down == 1  sysrq_alt))) {
sysrq_down = down;
--- clean/drivers/char/n_tty.c  2005-02-03 22:27:12.0 +0100
+++ linux-suse/drivers/char/n_tty.c 2005-02-18 16:13:06.0 +0100
@@ -1299,6 +1299,15 @@
tty-minimum_to_wake = (minimum - (b - buf));

if (!input_available_p(tty, 0)) {
+#ifdef CONFIG_BOOTSPLASH
+   if (file-f_dentry-d_inode-i_rdev == 
MKDEV(TTY_MAJOR,0) ||
+   file-f_dentry-d_inode-i_rdev == 
MKDEV(TTY_MAJOR,1) ||
+   file-f_dentry-d_inode-i_rdev == 
MKDEV(TTYAUX_MAJOR,0) ||
+   file-f_dentry-d_inode-i_rdev == 
MKDEV(TTYAUX_MAJOR,1)) {
+   extern int splash_verbose(void);
+   (void)splash_verbose();
+   }
+#endif
if (test_bit(TTY_OTHER_CLOSED, tty-flags)) {
retval = -EIO;
break;
--- clean/drivers/char/vt.c 2005-01-12 11:07:39.0 +0100
+++ linux-suse/drivers/char/vt.c2005-02-18 16:13:06.0 +0100
@@ -3251,6 +3251,31 @@
return 0;
 }
 
+#ifdef CONFIG_BOOTSPLASH
+void con_remap_def_color(int currcons, int new_color)
+{
+   unsigned short *sbuf = screenbuf;
+   unsigned c, len = screenbuf_size  1;
+   int old_color;
+
+   if (sbuf) {
+  old_color = def_color  8;
+  new_color = 8;
+  while(len--) {
+  c = *sbuf;
+  if (((c ^ old_color)  0xf000) == 0)
+  *sbuf ^= (old_color ^ new_color)  0xf000; 
+  if (((c ^ old_color)  0x0f00) == 0)
+  *sbuf ^= (old_color ^ new_color)  0x0f00;
+  sbuf++;
+  }
+  new_color = 8;
+   }
+   def_color = color = new_color;
+   update_attr(currcons);
+}
+#endif
+
 /*
  * Visible symbols for modules
  */
--- clean/drivers/video/Kconfig 2005-02-03 22:27:18.0 +0100
+++ linux-suse/drivers/video/Kconfig2005-02-18 16:13:06.0 +0100
@@ -1140,5 +1140,9 @@
source drivers/video/backlight/Kconfig
 endif
 
+if FB
+   source drivers/video/bootsplash/Kconfig
+endif
+
 endmenu
 
--- clean/drivers/video/Makefile2005-02-03 22:27:18.0 +0100
+++ linux-suse/drivers/video/Makefile   2005-02-18 16:13:06.0 +0100
@@ -7,6 +7,7 @@
 obj-$(CONFIG_VT) += console/
 obj-$(CONFIG_LOGO)   += logo/
 obj-$(CONFIG_SYSFS)  += backlight/
+obj-$(CONFIG_BOOTSPLASH) += bootsplash/
 
 obj-$(CONFIG_FB)  += fbmem.o fbmon.o fbcmap.o fbsysfs.o 
modedb.o softcursor.o
 # Only include macmodes.o if we have FB support and are PPC
--- clean/drivers/video/console/bitblit.c   2004-12-25 13:35:01.0 
+0100
+++ linux-suse/drivers/video/console/bitblit.c  2005-02-18 16:13:06.0 
+0100
@@ -18,6 +18,9 @@
 #include linux/console.h
 #include asm/types.h
 #include fbcon.h
+#ifdef CONFIG_BOOTSPLASH
+#include ../bootsplash/bootsplash.h
+#endif
 
 /*
  * Accelerated handlers.
@@ -77,6 +80,13 @@
 {
struct fb_copyarea area;
 
+#ifdef CONFIG_BOOTSPLASH
+   if (info-splash_data) {
+   splash_bmove(info-splash_data, vc, info,
+   sy, sx, dy, dx, height, width);
+   return;
+   }
+#endif
area.sx = sx * vc-vc_font.width;
area.sy = sy * vc-vc_font.height;
area.dx = dx * vc-vc_font.width;
@@ -93,6 +103,13 @@
int bgshift = (vc-vc_hi_font_mask) ? 13 : 12;
struct fb_fillrect region;
 
+#ifdef CONFIG_BOOTSPLASH
+   if (info-splash_data) {
+   splash_clear(info-splash_data, vc, info,

RE: Problems with dma_mmap_writecombine on mach-pxa

2005-02-18 Thread Frank Buss
Russell King [EMAIL PROTECTED] wrote:

 Since we map the whole lot in one go, if you get one page, there's no
 reason why you shouldn't get the lot.  This is why I'm wondering if
 it has something to do with your other modifications.

your patch works, thanks, but only for the problem with the ignored offset, 
as expected. Now I can use the original pxafb driver, but with the same 
problem: All writes from user space in the mmap'ed region after the first 
4096 bytes are ignored.

Perhaps it is not a kernel bug, but a configuration problem with the 
platform, because it is a in-house developed platform. Now a colleague is 
working on this problem and reading a book about the Linux 2.6 kernel 
details over weekend and learning how to use the kernel debugger (until now 
we have used printk and flashing new zImages every time, which is very time 
consuming). I'll post the solution next week, if we'll found one.

-- 
Frank Buß, [EMAIL PROTECTED]
http://www.frank-buss.de, http://www.it4-systems.de

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


FROM ROBERT FONGA

2005-02-18 Thread r_fonga
ROBERT FONGA
ABIDJAN, COTE D'IVOIRE

EMAIL:[EMAIL PROTECTED]

Cher Monsieur,

Permettez-moi de vous informer de mon désir de rentre dans le rapport d'affaires
avec vous. Je sais que ce
courrier peut venir à vous comme par surprise, puisque nous ne nous connaissons
pas avant ou nous ne nous
écrivons pas avant. PRÉSENTATION: Je suis le PASCAL FONGA, 25 ans, le seul
fils de défunt M. et Mme
(FONGA). Mon père était un négociant d'or et de cacao basé au l'Accra-Ghana
et à Abidjan (Côte d'Ivoire). Il
a été empoisonné jusqu?à la mort par ses associés d'affaires au cours d?un
de leurs voyages d'affaires.
Avant la mort de mon père le 29 juin 2002, dans un hôpital privé ici à Abidjan.
Il m'a secrètement appelé
sur son chevet et m'a dit qu'il fait déposer une somme d'US$12.5m (douze
millions de cinq cents mille dollars
américains), dans une banque (Cote d?Ivoire à Abidjan) et qu'il a employé
mon nom en tant que son seul fils
en tant que proche des parents en déposant ces fonds. Il m?a également
expliqué que c'était en raison de cette richesse qu'il
a été empoisonné par ses associés d'affaires. C?est la raison pour laquelle
que je devrais chercher un
associé étranger dans un pays de mon choix où je transférerai cet argent
et l'emploierai pour le but
d'investissement tel que l'expansion de ses affaires existantes de cacao
et de gestion de biens immobiliers
d?outre-mer. J'ai fait un accord avec le directeur d'agence de la banque
locale ici sur la façon dont je
peux mieux transférer cet argent à outre-mer. S?il vous plaît, je cherche
humblement votre aide de la
manière suivante: 1. Pour m'aider à transférer ces fonds tranquillement
dans votre compte dans votre
pays. 2. Pour servir de gardien de ces fonds puisque je suis toujours à
l'université 3. Pour faire un
arrangement pour que moi et ma plus jeune s½ur puissions venir dans votre
pays pour nos études et
pour nous aider à fixer une autorisation résidentielle dans votre pays.
D'ailleurs, je suis disposé à vous
offrir tout convenu (pourcentage) de toute la somme par compensation pour
votre effort, après que le
transfert de ces fonds est réussi dans votre compte nommé d?outre-mer,
alors un certain
pourcentage sera mis de côté pour excentrer toutes les dépenses que nous
pourrons effectuer. 4 En outre, vous
pouvez indiquer votre option vers nous pour nous aider pendant que je crois
que cette transaction serait
conclue dans le temps le plus court possible. NB: Veuillez me contacter
immédiatement dès vous
recevez ce message par [EMAIL PROTECTED]

Dieu vous bénissent

ROBERT FONGA



-
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: Bogus REPORT_LUNS responses breaks SCSI LUN detection

2005-02-18 Thread Joe Krahn
Andries Brouwer wrote:
On Sun, Feb 13, 2005 at 11:51:00PM -0500, Kurt Garloff wrote:

SuSE 9.1
Vendor: easyRAID Model: X16 Rev: 0001
Type: Direct-Access ANSI SCSI revision: 03
scsi: host 0 channel 0 id 5 lun 0x6500737952414944 has a LUN larger than 
currently supported.
Looks like random garbage.

I read e syRAID

Kernel 2.6, unknown distro
Vendor: transtec  Model:   Rev: 0001
Type:   Direct-Access  ANSI SCSI revision: 03
On host 1 channel 0 id 1 only 128 (max_scsi_report_luns) of 536870896 
luns reported, try increasing max_scsi_report_luns.
scsi: host 1 channel 0 id 1 lun 0x7400616e73746563 has a LUN larger than 
currently supported.

I read t anstec
So - you might wish to investigate why the 2nd byte of easyRAID and
of transtec was zeroed, and whether contents like this was to be
expected (maybe the previous command was IDENTIFY?).
Andries
The problem arises from a bug in the underlying controller made by 
MaxTronic. The good news is that they recently released an upgraded 
firmware to fix it. And, more importantly, it is possible to set 
scsi_mod.default_dev_flags=0x4 (==BLIST_NOREPORTLUN)

I suspect that your guess of the previous command being IDENTIFY is correct.
Thanks, Joe Krahn
-
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: drivers/input/power.c is never built

2005-02-18 Thread Dmitry Torokhov
On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
 On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
 
It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
and it will not work on i386/APM, anyway. I still believe right
solution is to add input interface to ACPI. /proc/acpi/events needs to
die, being replaced by input subsystem.
  
   But aren't there power events (battery low, etc) which are not
   input events?
 
  Yes, there are. They can probably stay... Or we can get battery low
  key.
 
 We even have an event class for that, EV_PWR in the input subsystem.

I really really think this is wrong. Power management should be
possible without input layer. EV_PWR is fine for telling input devices
to do something, like enter lower power mode and for sending _some_
requests to the PM system. But input layer shoudl not be used as a
generic transport. I mean battery low, docking requests, etc has
nothing to do with input.
-- 
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/


[PATCH] 2.6.10 patch to export kallsyms_lookup_name()

2005-02-18 Thread Badari Pulavarty
Hi,

Trivial patch to export kallsyms_lookup_name() for
kprobe/jprobe module use.

Please apply. 

(BTW, I personally don't care if it should be
EXPORT_SYMBOL_GPL or EXPORT_SYMBOL).

Thanks,
Badari


--- linux-2.6.10.org/kernel/kallsyms.c  2005-02-18 11:18:54.004259856 -0800
+++ linux-2.6.10/kernel/kallsyms.c  2005-02-18 11:20:01.619980704 -0800
@@ -382,3 +382,4 @@ int __init kallsyms_init(void)
 __initcall(kallsyms_init);
 
 EXPORT_SYMBOL(__print_symbol);
+EXPORT_SYMBOL(kallsyms_lookup_name);


Re: [BK] upgrade will be needed

2005-02-18 Thread Sean
On Fri, February 18, 2005 11:27 am, Theodore Ts'o said:

 If you truly believe that BK would be able to add the value that it
 does to the kernel development process by using some other SCM as the
 master SCM, with BK being underneath, as you proposed earlier, then
 you do not understand why BK is fundamentally better than the current
 open source SCM systems that are out there.

BK already feeds patches out at the head, surely if it's as powerful as
you think, it could feed a free SCM too for your non-bk friends in the
community.

 And people *can* use the tools of their choice today.  They can use
 CVS, and diff+patch, and suffer with all of the limitations that those
 tools have today.  And for people who are doing stuff around the
 periphery, quilt is often really the best tool for them.

The situation could be improved for these other tools if there wasn't so
much BK zealotry from those that use it.

 If it's about the whole ***kernel*** development community, then it's
 pretty clear that the current system works quite well.  All of the
 complaints have been coming primarily from SCM hackers, it seems, and
 not people who truly need the power of more powerful than downloading
 the bk snapshots, using the CVS export tree, and in the case where
 they need to look at the changes in a single changeset bkbits.net.

There's no technical reason for this limitation.

 The cost of using BK seems to be primarily more theoretical, and
 ideological, than real.  It's always seems to be about someone
 kvetching that they want to use SVN and get finely grained changsets
 through SVN, and they can't.  But how often does that happen, and
 what's so painful of getting the finely grained changeset through
 bkbits.net?  Not very.  So at the end of the day, it finally boils
 down to being all about ideology, doesn't it?

No.  It's just that the cost isn't being paid by you, so you don't care.


Cheers,
Sean.


-
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, new ACPI driver] new sony_acpi driver

2005-02-18 Thread Jean Delvare
Hi Stellian,

 All right, here is a third version of the driver, which adds the
 'brightness_default' entry and rewrites a big part of the code in
 a more extensible way.

Tested, works for me (debug mode not tested).

Thanks,
-- 
Jean Delvare
-
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: drivers/input/power.c is never built

2005-02-18 Thread Vojtech Pavlik
On Fri, Feb 18, 2005 at 01:19:08PM -0500, Dmitry Torokhov wrote:
 On Fri, 18 Feb 2005 18:00:36 +0100, Vojtech Pavlik [EMAIL PROTECTED] wrote:
  On Fri, Feb 18, 2005 at 05:01:53PM +0100, Pavel Machek wrote:
  
 It has quite a lot of #ifdefs for CONFIG_APM/CONFIG_ARM/CONFIG_ACPI,
 and it will not work on i386/APM, anyway. I still believe right
 solution is to add input interface to ACPI. /proc/acpi/events needs to
 die, being replaced by input subsystem.
   
But aren't there power events (battery low, etc) which are not
input events?
  
   Yes, there are. They can probably stay... Or we can get battery low
   key.
  
  We even have an event class for that, EV_PWR in the input subsystem.
 
 I really really think this is wrong. Power management should be
 possible without input layer. EV_PWR is fine for telling input devices
 to do something, like enter lower power mode

Definitely not for this. The request to go to low power mode should come
from the other side - the bus the device lives on.

 and for sending _some_ requests to the PM system.

I don't think input devices themselves should be sending any requests to
the PM system at all, they should just pass the events to the userspace
and have that decide what to do with it.

Maybe a simple event handler like power.c for transforming key events to
power change requests for embedded systems makes sense, but normally
many more variables need to be taken into account, and thus userspace
needs to decide.

 But input layer shoudl not be used as a generic transport. I mean
 battery low, docking requests, etc has nothing to do with input.
 
Well, plugging in a power cord is a physical user action much like
closing the lid is, much like pressing the power button is, much like
pressing a key is.

I definitely wouldn't want to see input to be a generic trasport layer -
it is not. But I wouldn't be opposed to pass some of the user induced
events through it.

-- 
Vojtech Pavlik
SuSE Labs, SuSE CR
-
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.10 patch to export kallsyms_lookup_name()

2005-02-18 Thread Christoph Hellwig
On Fri, Feb 18, 2005 at 10:29:08AM -0800, Badari Pulavarty wrote:
 Hi,
 
 Trivial patch to export kallsyms_lookup_name() for
 kprobe/jprobe module use.
 
 Please apply. 
 
 (BTW, I personally don't care if it should be
 EXPORT_SYMBOL_GPL or EXPORT_SYMBOL).

Certainly should be _GPL.  And where's the example user?
-
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/


  1   2   3   >