Re: xor as a lazy comparison

2005-07-26 Thread Jan Engelhardt
  Where do we draw the line with this?  Is x *= 2 preferable to x = 2 as
  well?
 
 Depends if you want to multiply by 2 or 4 :-)

I guess I just answered my own question ;-)

To answer for x *= 2 vs x = 1:

Use * when you would logically want to do a multiplication,
 if you're working on a bitfield. It's just for keeping the code clean 
enough so that others may understand it.

In the longshot, it does not matter, as gcc will optimize out multiplication 
with powers of two to bitops.



Jan Engelhardt
-- 
| Alphagate Systems, http://alphagate.hopto.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Netlink connector

2005-07-26 Thread Thomas Graf
* Evgeniy Polyakov [EMAIL PROTECTED] 2005-07-26 08:45
 On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL PROTECTED]) 
 wrote:
  Usually netlink is easily extendable by using nested TLVs. By hiding
  this you basically remove this extensibility.
 
 Current netlink is not extensible for _many_ different users.

Patrick's key point was that by hiding some of the functionality
you remove a lot of the flexbility.

 It has only 32 sockets.

You mean MAX_LINKS? That is the current number of reserved
netlink protocols. The ethertaps are obsolete and can be
reused so we're currently using 16 out of 256 possible
protocols. If that is not enough there are ways to work
around this. However, I also see a need for a generic protocol
providing a simplified interface for small applications.
Nevertheless we should take the time and work things out on
the netlink level first, netlink has issues and we should not
work around them in a upper layer.

  But my main objection is that it sends everything to userspace even
  if noone is listening. This can't be used for things that generate
  lots of events, and also will get problematic is the number of users
  increases.
 
 It is a problem for existing netlink - either check in bind time, 
 what could be done for connector, or in socket creation time.

No, I think you are misunderstanding something. As I said, we can
easly add a function netlink_nr_subscribers(sk, groups) so the
check can be done before starting to build the message. This is
no problem, it simply didn't make sense so far because netlink
event messages were mostly used for rare events.

 Actually it is not even a problem, since checking is being done, 
 but after allocation and message filling, such check can be moved into
 cn_netlink_send() in connector, but different netlink users, 
 who prefers to use different sockets, must perform it by itself in each
 place, where skb is allocated...

Sure, which is the right thing, it makes perfect sense to check
before starting the process of building and event and sending it.

 Connector is a solution for current situation, 
 it can be deployed with few casualties.

The problem is that netlink is likely to change in order
to cope with some recent needs, e.g. ctnetlink but also other
current issues which need to be addressed.  Therefore I suggest
to build connector on top of the updated netlink so you we have
one thing less to worry about when thinking about compatibility.

 Creating a new netlink2 socket for device, which wants to replace ioctl
 controlling or broadcast it's state is a wrong way.

Slowly, we might need netlink2 _in case_ we cannot work things
out without breaking compatibility. This has nothing to do with
the connector, there are netlink users which have new needs such
as more groups, at least some of them need the flexibility of
netlink itself so we have to work things out for them.

 Different sockets/flows does not allow easy flow control.

I'm not sure what you mean.

 We have one pipe - ethernet, and many protocols inside this pipe
 with different headers - it is the same here - netlink is such a pipe,
 and with connector it allows to have different protocols in it.

At least parts of your connector is just a redudant implementation
of what netlink is already capable of doing. Sure, some of them
have issues but there is no reason to just build a new protocol on
top of another one if the protocol beneath has issues which can be
resolved.

  You still have to take care of mixed 64/32 bit environments, u64 fields
  for example are differently alligned.
 
 Connector has a size in it's header - ioctl does not.

You have exactly the same issues as netlink as soon as you transfer
structs, believe it or not.

 It does not fix the problem of skb management knowledge, which I
 described.

Yes ok, this is a different issue and as Patrick stated already
those have been mostly worked out by providing a new set of
macros. Except for a few leftovers, which will be addressed, there
is no need to call skb functions anymore. The reason the plain
skb interface was used is simply that the authors of most of the
netlink using code are in fact very familiar with the skb interface,
that's it.

  You can still built this stuff on top, but the workarounds for netlink
  limitations need to be fixed in netlink.
 
 I could not call it workaround, I think it is a management layer,
 which allows :

Listen, nobody wants to take away your baby. ;- There are some
objections of things which would rather be fixed in the netlink
layer first and the remaining part that is missing goes into the
connector. I see a lot of replicated netlink code in the connector
which is no necessary. I perfectly agree with you that we require
some form of simplified addressing and easier message handling
for simple applications but just building another layer on top
of netlink without respecting the capabilities of netlink itself
is not the way to go as I see it. For example, we'll 

Re: [PATCH] Re: itimer oddness in 2.6.12

2005-07-26 Thread Andrew Morton
George Anzinger george@mvista.com wrote:

 + while (time_before_eq(p-signal-real_timer.expires, jiffies))
 + p-signal-real_timer.expires += inc;

It gives me the creeps when I see timer code doing this, and it seems to be
done relatively frequently.

Surely it can be calculated arithmetically?  If not, are you really sure
that it is not exploitable by malicious code?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[no subject]

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


problem while executing insmod

2005-07-26 Thread deepak jose
sir/madam,

i written a module function similar to hello, world in C .i compiled
it.but when i ,m loading the module i'm getting the error that the
kernel compiled is kernel 2.4.20 whereas i'm having 2.4.20-8.
wat i have to do to load it properly without forcing it to load.
did i have to change my kernel.
please suggest me a solution without changing 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: [patch 1/2] Touchscreen support for sharp sl-5500

2005-07-26 Thread Pavel Machek
Hi!

   So, if the collie folk would like to clean their changes up and send
   them to me as the driver author, I'll see about integrating them into
   my version and we'll take it from there.
  
  Okay, will do. [Is there chance to pull your tree using git? It would
  help a bit...]
...
 However, if the UCB stuff is going to get worked on, I don't mind
 setting up, maintaining and publishing a git tree for that that,
 provided it then vanishes once merged into mainline.  That falls
 within the very limited purposes clause above.

Yes, that would help a lot, because I'd have a tree to diff against.

Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch] Fix compilation in locomo.c

2005-07-26 Thread Pavel Machek
Do not access children in struct device directly, use
device_for_each_child helper instead. It fixes compilation.

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

---
commit 3d7f15c66bc66c480d468e2c4d623949bba0d41f
tree 9734f5a58c31dade74b1b35c1ce0b0d6d44da589
parent 6cd7322dce560001570713269630390754881e5d
author [EMAIL PROTECTED](none) Tue, 26 Jul 2005 08:29:38 +0200
committer [EMAIL PROTECTED](none) Tue, 26 Jul 2005 08:29:38 +0200

 arch/arm/common/locomo.c |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/arch/arm/common/locomo.c b/arch/arm/common/locomo.c
--- a/arch/arm/common/locomo.c
+++ b/arch/arm/common/locomo.c
@@ -651,15 +651,15 @@ __locomo_probe(struct device *me, struct
return ret;
 }
 
-static void __locomo_remove(struct locomo *lchip)
+static int locomo_remove_child(struct device *dev, void *data)
 {
-   struct list_head *l, *n;
-
-   list_for_each_safe(l, n, lchip-dev-children) {
-   struct device *d = list_to_dev(l);
+   device_unregister(dev);
+   return 0;
+} 
 
-   device_unregister(d);
-   }
+static void __locomo_remove(struct locomo *lchip)
+{
+   device_for_each_child(lchip-dev, NULL, locomo_remove_child);
 
if (lchip-irq != NO_IRQ) {
set_irq_chained_handler(lchip-irq, NULL);

-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

2005-07-26 Thread Voluspa

On 2005-07-26 5:23:08 Len Brown wrote:

than C1 and the generic ACPI code doesn't support it,
then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)

The issue has made me fume enough to contemplating installing windos for
the first time in some 10 years. But I'll persevere. Will learn
ACPI-speak, read bios- and kernelcode. Then return, have no fear (even
if just to admit that the BIOS is buggy). Speaking of bugs, I was
directed, off-list, to the patch which mends your latest chip-away of
C2/C3 for many systems:

http://marc.theaimsgroup.com/?l=acpi4linuxm=112138186129178w=2

It did however not fix my K8 system.

I.e. The whole concept of ACPI is that you shoulud _not_ need
a platform specific driver to accomplish this.

Indeed. It's supposed to be some kind of neutral non-discrimatory
standard... I suppose.

Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BUG: Yamaha OPL3SA2 does not work with ALSA on 2.6 kernels.

2005-07-26 Thread Jaroslav Kysela
On Mon, 25 Jul 2005, Andrew Haninger wrote:

 Hello.
 
 I have a 5 year old Gateway Solo 2500 that is currently running Linux
 2.6.12.2. If I install ALSA and try to have alsaconf bruteforce-detect
 the OPL3SA2 sound card, it will say that it has detected it, but
 loading the modules will fail. If I install Linux 2.4 and
 recompile/rerun alsaconf, the detection works fine and the card works.
 Copying the configuration detected under 2.4 into a modprobe.conf on
 2.6 allows me to use the card in 2.6 with occasional crashes (which
 might be due to suspend2).

Please, report this problem to our bug-tracking-system:

https://bugtrack.alsa-project.org/alsa-bug

We have already two similar reports #440 and #879. Please, provide us
all info (working manual conf etc.)..

Jaroslav

-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SUSE Labs
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Netlink connector

2005-07-26 Thread Evgeniy Polyakov
On Tue, Jul 26, 2005 at 08:14:47AM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
 * Evgeniy Polyakov [EMAIL PROTECTED] 2005-07-26 08:45
  On Tue, Jul 26, 2005 at 01:46:04AM +0200, Patrick McHardy ([EMAIL 
  PROTECTED]) wrote:
   Usually netlink is easily extendable by using nested TLVs. By hiding
   this you basically remove this extensibility.
  
  Current netlink is not extensible for _many_ different users.
 
 Patrick's key point was that by hiding some of the functionality
 you remove a lot of the flexbility.
 
  It has only 32 sockets.
 
 You mean MAX_LINKS? That is the current number of reserved
 netlink protocols. The ethertaps are obsolete and can be
 reused so we're currently using 16 out of 256 possible
 protocols. If that is not enough there are ways to work
 around this. However, I also see a need for a generic protocol
 providing a simplified interface for small applications.
 Nevertheless we should take the time and work things out on
 the netlink level first, netlink has issues and we should not
 work around them in a upper layer.
 
   But my main objection is that it sends everything to userspace even
   if noone is listening. This can't be used for things that generate
   lots of events, and also will get problematic is the number of users
   increases.
  
  It is a problem for existing netlink - either check in bind time, 
  what could be done for connector, or in socket creation time.
 
 No, I think you are misunderstanding something. As I said, we can
 easly add a function netlink_nr_subscribers(sk, groups) so the
 check can be done before starting to build the message. This is
 no problem, it simply didn't make sense so far because netlink
 event messages were mostly used for rare events.

Yep.

  Actually it is not even a problem, since checking is being done, 
  but after allocation and message filling, such check can be moved into
  cn_netlink_send() in connector, but different netlink users, 
  who prefers to use different sockets, must perform it by itself in each
  place, where skb is allocated...
 
 Sure, which is the right thing, it makes perfect sense to check
 before starting the process of building and event and sending it.
 
  Connector is a solution for current situation, 
  it can be deployed with few casualties.
 
 The problem is that netlink is likely to change in order
 to cope with some recent needs, e.g. ctnetlink but also other
 current issues which need to be addressed.  Therefore I suggest
 to build connector on top of the updated netlink so you we have
 one thing less to worry about when thinking about compatibility.
 
  Creating a new netlink2 socket for device, which wants to replace ioctl
  controlling or broadcast it's state is a wrong way.
 
 Slowly, we might need netlink2 _in case_ we cannot work things
 out without breaking compatibility. This has nothing to do with
 the connector, there are netlink users which have new needs such
 as more groups, at least some of them need the flexibility of
 netlink itself so we have to work things out for them.
 
  Different sockets/flows does not allow easy flow control.
 
 I'm not sure what you mean.

Concider socket overrun - message will be dropped, 
using special flags in connector [it's size field was selected to be 4
bytes, and thus has big reserve] this subsystem can requeue message
later after timeout or something similar...

  We have one pipe - ethernet, and many protocols inside this pipe
  with different headers - it is the same here - netlink is such a pipe,
  and with connector it allows to have different protocols in it.
 
 At least parts of your connector is just a redudant implementation
 of what netlink is already capable of doing. Sure, some of them
 have issues but there is no reason to just build a new protocol on
 top of another one if the protocol beneath has issues which can be
 resolved.
 
   You still have to take care of mixed 64/32 bit environments, u64 fields
   for example are differently alligned.
  
  Connector has a size in it's header - ioctl does not.
 
 You have exactly the same issues as netlink as soon as you transfer
 structs, believe it or not.
 
  It does not fix the problem of skb management knowledge, which I
  described.
 
 Yes ok, this is a different issue and as Patrick stated already
 those have been mostly worked out by providing a new set of
 macros. Except for a few leftovers, which will be addressed, there
 is no need to call skb functions anymore. The reason the plain
 skb interface was used is simply that the authors of most of the
 netlink using code are in fact very familiar with the skb interface,
 that's it.

I saw your changes - theay are very usefull, but _only_ for sending
part. Kernel receiver still needs dequeuing, freeing and NLKMSG macros.
In first netlink days it also needed skb_recv_msg() or something
similar...

   You can still built this stuff on top, but the workarounds for netlink
   limitations need to be fixed in netlink.
  
  I could not call it 

Problem with SMP and NCCH-DL motherboard

2005-07-26 Thread Pedro Pla
Hello,

I'm running a system with an Asus NCCH-DL motherboard with dual Nocona
Xeon 3.2 GHZ cpu's, when I boot the system with a single cpu kernel with
acpi not compiled in it works fine, however when I try to boot a kernel
with smp it gives a timeout detecting the cpus and then the machine
reboots after I think trying to work out the irq tables, I say I think
because it happens so fast that I can barely see what is on the screen
before it reboots.

I've tried recompiling the kernel with many different options both in
and out and the only one that lets me boot is a single cpu without acpi,
apic and hpet, I tried googling for similar problems but haven't been
able to find anything that applies. I've also tried using an EM64T
kernel in case it had to do with the Nocona being incompatible with smp
in 32bit mode but that didn't seem to work and gave the same error.

Is it a kernel problem or a hardware issue? I tried swapping cpu's in
case one was broken but that didn't help, I also tried flashing the bios
to the latest one from Asus in case there was some issue with that but
no luck either.

Also in case this is helpful in locating the problem, when I get it to
boot a single cpu 2.6.12.1 kernel without acpi or apic I get the
following errors with the PCI:

NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf1d30, last bus=4
PCI: Using configuration type 1
SCSI subsystem initialized
PCI: Probing PCI hardware
PCI: Probing PCI hardware (bus 00)
PCI: Ignoring BAR0-3 of IDE controller :00:1f.1
Boot video device is :01:00.0
PCI: Transparent bridge - :00:1e.0
PCI: Using IRQ router PIIX/ICH [8086/25a1] at :00:1f.0
PCI: IRQ 0 for device :00:1f.1 doesn't match PIRQ mask - try
pci=usepirqmask
PCI: Found IRQ 11 for device :00:1f.1
PCI: Cannot allocate resource region 0 of device :01:00.0

Any ideas or advice would be greatly appreciated.

Best regards,
Pedro


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


[RFC][2.6.13-rc3-mm1] IRQ compression/sharing patch

2005-07-26 Thread James Cleverdon
Here's a patch that builds on Natalie Protasevich's IRQ compression 
patch and tries to work for MPS boots as well as ACPI.  It is meant for 
a 4-node IBM x460 NUMA box, which was dying because it had interrupt 
pins with GSI numbers  NR_IRQS and thus overflowed irq_desc.

The problem is that this system has 270 GSIs (which are 1:1 mapped with 
I/O APIC RTEs) and an 8-node box would have 540.  This is much bigger 
than NR_IRQS (224 for both i386 and x86_64).  Also, there aren't enough 
vectors to go around.  There are about 190 usable vectors, not counting 
the reserved ones and the unused vectors at 0x20 to 0x2F.  So, my patch 
attempts to compress the GSI range and share vectors by sharing IRQs.

Important safety note:  While the SLES 9 version of this patch works, I 
haven't been able to test the -rc3-mm1 patch enclosed.  I keep getting 
errors from the adp94xx driver.  8-(

(Sorry about doing an attachment, but KMail is steadfastly word wrapping 
inserted files.  I need to upgrade)

-- 
James Cleverdon
IBM LTC (xSeries Linux Solutions)
{jamesclv(Unix, preferred), cleverdj(Notes)} at us dot ibm dot comm
diff -pru 2.6.13-rc3-mm1/arch/i386/kernel/acpi/boot.c j13-rc3-mm1/arch/i386/kernel/acpi/boot.c
--- 2.6.13-rc3-mm1/arch/i386/kernel/acpi/boot.c	2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/i386/kernel/acpi/boot.c	2005-07-23 18:32:06.0 -0700
@@ -40,9 +40,10 @@
 
 #ifdef	CONFIG_X86_64
 
-static inline void  acpi_madt_oem_check(char *oem_id, char *oem_table_id) { }
+extern void  acpi_madt_oem_check(char *oem_id, char *oem_table_id);
 extern void __init clustered_apic_check(void);
 static inline int ioapic_setup_disabled(void) { return 0; }
+extern int gsi_irq_sharing(int gsi);
 #include asm/proto.h
 
 #else	/* X86 */
@@ -52,6 +53,10 @@ static inline int ioapic_setup_disabled(
 #include mach_mpparse.h
 #endif	/* CONFIG_X86_LOCAL_APIC */
 
+static inline int ioapic_setup_disabled(void) { return 0; }
+static inline int gsi_irq_sharing(int gsi) { return gsi; }
+
+
 #endif	/* X86 */
 
 #define BAD_MADT_ENTRY(entry, end) (	\
@@ -480,7 +485,7 @@ int acpi_gsi_to_irq(u32 gsi, unsigned in
  		*irq = IO_APIC_VECTOR(gsi);
 	else
 #endif
-		*irq = gsi;
+		*irq = gsi_irq_sharing(gsi);
 	return 0;
 }
 
diff -pru 2.6.13-rc3-mm1/arch/x86_64/Kconfig j13-rc3-mm1/arch/x86_64/Kconfig
--- 2.6.13-rc3-mm1/arch/x86_64/Kconfig	2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/x86_64/Kconfig	2005-07-22 18:34:08.0 -0700
@@ -276,13 +276,13 @@ config HAVE_DEC_LOCK
 	default y
 
 config NR_CPUS
-	int Maximum number of CPUs (2-256)
-	range 2 256
+	int Maximum number of CPUs (2-255)
+	range 2 255
 	depends on SMP
-	default 8
+	default 64
 	help
 	  This allows you to specify the maximum number of CPUs which this
-	  kernel will support. Current maximum is 256 CPUs due to
+	  kernel will support. Current maximum is 255 CPUs due to
 	  APIC addressing limits. Less depending on the hardware.
 
 	  This is purely to save memory - each supported CPU requires
diff -pru 2.6.13-rc3-mm1/arch/x86_64/kernel/genapic.c j13-rc3-mm1/arch/x86_64/kernel/genapic.c
--- 2.6.13-rc3-mm1/arch/x86_64/kernel/genapic.c	2005-07-12 21:46:46.0 -0700
+++ j13-rc3-mm1/arch/x86_64/kernel/genapic.c	2005-07-22 18:34:08.0 -0700
@@ -103,3 +103,19 @@ void send_IPI_self(int vector)
 {
 	__send_IPI_shortcut(APIC_DEST_SELF, vector, APIC_DEST_PHYSICAL);
 }
+
+/*
+ * Check the APIC IDs in MADT table header and choose the APIC mode.
+ */
+void acpi_madt_oem_check(char *oem_id, char *oem_table_id)
+{
+	/* May need to check OEM strings in the future. */
+}
+
+/*
+ * Check the IDs in MPS header and choose the APIC mode.
+ */
+void mps_oem_check(struct mp_config_table *mpc, char *oem, char *productid)
+{
+	/* May need to check OEM strings in the future. */
+}
diff -pru 2.6.13-rc3-mm1/arch/x86_64/kernel/io_apic.c j13-rc3-mm1/arch/x86_64/kernel/io_apic.c
--- 2.6.13-rc3-mm1/arch/x86_64/kernel/io_apic.c	2005-07-22 18:32:35.0 -0700
+++ j13-rc3-mm1/arch/x86_64/kernel/io_apic.c	2005-07-23 18:32:40.0 -0700
@@ -56,7 +56,7 @@ int nr_ioapic_registers[MAX_IO_APICS];
  * Rough estimation of how many shared IRQs there are, can
  * be changed anytime.
  */
-#define MAX_PLUS_SHARED_IRQS NR_IRQS
+#define MAX_PLUS_SHARED_IRQS NR_IRQ_VECTORS
 #define PIN_MAP_SIZE (MAX_PLUS_SHARED_IRQS + NR_IRQS)
 
 /*
@@ -84,6 +84,7 @@ int vector_irq[NR_VECTORS] = { [0 ... NR
 	int pin;			\
 	struct irq_pin_list *entry = irq_2_pin + irq;			\
 	\
+	BUG_ON(irq = NR_IRQS);		\
 	for (;;) {			\
 		unsigned int reg;	\
 		pin = entry-pin;	\
@@ -126,6 +127,8 @@ static void set_ioapic_affinity_irq(unsi
 }
 #endif
 
+static u8 gsi_2_irq[NR_IRQ_VECTORS] = { [0 ... NR_IRQ_VECTORS-1] = 0xFF };
+
 /*
  * The common case is 1:1 IRQ-pin mappings. Sometimes there are
  * shared ISA-space IRQs, so we have to support them. We are super
@@ -136,6 +139,7 @@ static void add_pin_to_irq(unsigned int 
 	static int first_free_entry = NR_IRQS;

Re: [PATCH] add NULL short circuit to fb_dealloc_cmap()

2005-07-26 Thread Geert Uytterhoeven
On Sun, 17 Jul 2005, Jon Smirl wrote:
 On 7/17/05, Geert Uytterhoeven [EMAIL PROTECTED] wrote:
  
   struct fb_super_cmap {
  struct fb_cmap cmap;
  __u16 red[255];
  __u16 blue[255];
  __u16 green[255];
  __u16 transp[255];
^^^
  I assume you meant 256?
  
   }
  
   Then adjust the code as need. Have the embedded cmap struct point to
   the fields in the super_cmap and the drivers don't have to be changed.
  
  What if your colormap has more than 256 entries?
 
 I meant 256. Does any hardware exist that takes more that 256 entries? 

1024 was quite common on high-end graphics hardware.

 They are __u16 values but I have never seen hardware that take more
 that __u8 either.

10 bit was quite common on high-end graphics hardware.

IIRC, DEC TGA can do at least one of them.

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] ucb1x00: driver model fixes

2005-07-26 Thread Pavel Machek
This fixes u32 vs. pm_message_t confusion and uses cleaner
try_to_freeze() [fixing compilation as a side-effect on newer
kernels.]

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

--- linux-rmk.clean//drivers/misc/mcp.h 2005-07-26 09:15:05.0 +0200
+++ linux-rmk/drivers/misc/mcp.h2005-07-26 08:46:03.0 +0200
@@ -45,7 +45,7 @@
struct device_driver drv;
int (*probe)(struct mcp *);
void (*remove)(struct mcp *);
-   int (*suspend)(struct mcp *, u32);
+   int (*suspend)(struct mcp *, pm_message_t);
int (*resume)(struct mcp *);
 };
 
--- linux-rmk.clean//drivers/misc/ucb1x00-ts.c  2005-07-26 09:15:19.0 
+0200
+++ linux-rmk/drivers/misc/ucb1x00-ts.c 2005-07-26 08:46:56.0 +0200
@@ -253,8 +253,7 @@
timeout = HZ / 100;
}
 
-   if (tsk-flags  PF_FREEZE)
-   refrigerator();
+   try_to_freeze();
 
schedule_timeout(timeout);
if (signal_pending(tsk))

-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] kill bio-bi_set

2005-07-26 Thread Jens Axboe
On Tue, Jul 26 2005, Peter Osterlund wrote:
 Jens Axboe [EMAIL PROTECTED] writes:
 
  On Sat, Jul 23 2005, Peter Osterlund wrote:
   Jens Axboe [EMAIL PROTECTED] writes:
   
Dunno why I didn't notice before, but -bi_set is totally unnecessary
bloat of struct bio. Just define a proper destructor for the bio and it
already knows what bio_set it belongs too.
   
   This causes crashes on my computer.
  
  Did I neglect to mention it was untested? :)
 ...
  Thanks, I'll go over these and submit a fixed version.
 
 I fixed this myself. The patch below is tested with dm-crypt on top of
 pktcdvd on top of usb-storage, and worked fine in my tests.

Thanks! I was travelling, so I didn't get to it myself.

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


[RFC] fix compilation in mcp-core.c

2005-07-26 Thread Pavel Machek
Hi!

I had to do this to get mcp-core to compile, but it feels wrong. Where
do I get device_unregister_wait?
Pavel


diff --git a/drivers/misc/mcp-core.c b/drivers/misc/mcp-core.c
--- a/drivers/misc/mcp-core.c
+++ b/drivers/misc/mcp-core.c
@@ -198,7 +198,7 @@ int mcp_host_register(struct mcp *mcp, s
 
 void mcp_host_unregister(struct mcp *mcp)
 {
-   device_unregister_wait(mcp-attached_device);
+   device_unregister(mcp-attached_device);
 }
 
 int mcp_driver_register(struct mcp_driver *mcpdrv)

-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: seeing minute plus hangs during boot - 2.6.12 and 2.6.13

2005-07-26 Thread Andrew Morton
Francisco Figueiredo Jr. [EMAIL PROTECTED] wrote:

 Indeed udev update solved my problem with preparing system to use udev
  hang. It now works like a charm. I had 030 version too.
 
  Only the mounting filesystem hangs persists :(

Please use ALT-SYSRQ-T to generate an all-task backtrace, then send it to the
list.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] ucb1x00: touchscreen cleanups

2005-07-26 Thread Pavel Machek
These are small ucb1x00-ts cleanups, as suggested by Vojtech, Dmitri
and the lists.

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

Cleanups suggested by Dmitri, Vojtech and lists.

---
commit 79c98a2279c45098d102ba69ecf940c00da3dfee
tree f15a3d27de9a84694f4588374a5e383938866a54
parent 080578bff89927c0f5aeddd588bc2f5f7373f232
author [EMAIL PROTECTED](none) Tue, 26 Jul 2005 09:44:33 +0200
committer [EMAIL PROTECTED](none) Tue, 26 Jul 2005 09:44:33 +0200

 drivers/misc/ucb1x00-ts.c |   87 -
 1 files changed, 23 insertions(+), 64 deletions(-)

diff --git a/drivers/misc/ucb1x00-ts.c b/drivers/misc/ucb1x00-ts.c
--- a/drivers/misc/ucb1x00-ts.c
+++ b/drivers/misc/ucb1x00-ts.c
@@ -1,7 +1,8 @@
 /*
- *  linux/drivers/misc/ucb1x00-ts.c
+ *  Touchscreen driver for UCB1x00-based touchscreens
  *
  *  Copyright (C) 2001 Russell King, All Rights Reserved.
+ *  Copyright (C) 2005 Pavel Machek
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2 as
@@ -30,6 +31,7 @@
 #include linux/device.h
 #include linux/suspend.h
 #include linux/slab.h
+#include linux/kthread.h
 
 #include asm/dma.h
 #include asm/semaphore.h
@@ -42,10 +44,7 @@ struct ucb1x00_ts {
struct ucb1x00  *ucb;
 
wait_queue_head_t   irq_wait;
-   struct semaphoresem;
-   struct completion   init_exit;
struct task_struct  *rtask;
-   int use_count;
u16 x_res;
u16 y_res;
 
@@ -55,20 +54,6 @@ struct ucb1x00_ts {
 
 static int adcsync;
 
-static inline void ucb1x00_ts_evt_add(struct ucb1x00_ts *ts, u16 pressure, u16 
x, u16 y)
-{
-   input_report_abs(ts-idev, ABS_X, x);
-   input_report_abs(ts-idev, ABS_Y, y);
-   input_report_abs(ts-idev, ABS_PRESSURE, pressure);
-   input_sync(ts-idev);
-}
-
-static inline void ucb1x00_ts_event_release(struct ucb1x00_ts *ts)
-{
-   input_report_abs(ts-idev, ABS_PRESSURE, 0);
-   input_sync(ts-idev);
-}
-
 /*
  * Switch to interrupt mode.
  */
@@ -176,12 +161,6 @@ static int ucb1x00_thread(void *_ts)
DECLARE_WAITQUEUE(wait, tsk);
int valid;
 
-   ts-rtask = tsk;
-
-   daemonize(ktsd);
-   /* only want to receive SIGKILL */
-   allow_signal(SIGKILL);
-
/*
 * We could run as a real-time thread.  However, thus far
 * this doesn't seem to be necessary.
@@ -189,12 +168,10 @@ static int ucb1x00_thread(void *_ts)
 // tsk-policy = SCHED_FIFO;
 // tsk-rt_priority = 1;
 
-   complete(ts-init_exit);
-
valid = 0;
 
add_wait_queue(ts-irq_wait, wait);
-   for (;;) {
+   while (!kthread_should_stop()) {
unsigned int x, y, p, val;
signed long timeout;
 
@@ -212,10 +189,7 @@ static int ucb1x00_thread(void *_ts)
ucb1x00_ts_mode_int(ts);
ucb1x00_adc_disable(ts-ucb);
 
-   set_task_state(tsk, TASK_UNINTERRUPTIBLE);
-   schedule_timeout(HZ / 100);
-   if (signal_pending(tsk))
-   break;
+   msleep(10);
 
ucb1x00_enable(ts-ucb);
val = ucb1x00_reg_read(ts-ucb, UCB_TS_CR);
@@ -231,7 +205,8 @@ static int ucb1x00_thread(void *_ts)
 * spit out a pen off sample here.
 */
if (valid) {
-   ucb1x00_ts_event_release(ts);
+   input_report_abs(ts-idev, ABS_PRESSURE, 0);
+   input_sync(ts-idev);
valid = 0;
}
 
@@ -245,7 +220,10 @@ static int ucb1x00_thread(void *_ts)
 * to do any filtering they please.
 */
if (!ts-restart) {
-   ucb1x00_ts_evt_add(ts, p, x, y);
+   input_report_abs(ts-idev, ABS_X, x);
+   input_report_abs(ts-idev, ABS_Y, y);
+   input_report_abs(ts-idev, ABS_PRESSURE, p);
+   input_sync(ts-idev);
valid = 1;
}
 
@@ -256,14 +234,12 @@ static int ucb1x00_thread(void *_ts)
try_to_freeze();
 
schedule_timeout(timeout);
-   if (signal_pending(tsk))
-   break;
}
 
remove_wait_queue(ts-irq_wait, wait);
 
ts-rtask = NULL;
-   complete_and_exit(ts-init_exit, 0);
+   return 0;
 }
 
 /*
@@ -282,14 +258,7 @@ static int ucb1x00_ts_open(struct input_
struct ucb1x00_ts *ts = (struct ucb1x00_ts *)idev;
int ret = 0;
 
-   if (down_interruptible(ts-sem))
-   return -EINTR;
-
-   if (ts-use_count++ != 0)
-   goto 

Re: [patch] ucb1x00: touchscreen cleanups

2005-07-26 Thread Mark Underwood
Hi Pavel,

I am in the process of porting Linux 2.6.11.5 to the
Helio PDA (MIPS R3912 based) and if I remember
correctly it is using a UCB1x00 (or Toshiba clone).
Please could you make sure your patches will work
across arch. Now I have my kernel up and running (well
mainly falling :-() my next task is to get write the
frame buffer driver and then look at the UCB1x00 as I
need it for sound and touch screen. So in a day or two
I will start to try to integrate your work into my
kernel.

Best Regards,

Mark

--- Pavel Machek [EMAIL PROTECTED] wrote:

 These are small ucb1x00-ts cleanups, as suggested by
 Vojtech, Dmitri
 and the lists.
 
 Signed-off-by: Pavel Machek [EMAIL PROTECTED]
 
 Cleanups suggested by Dmitri, Vojtech and lists.
 
 ---
 commit 79c98a2279c45098d102ba69ecf940c00da3dfee
 tree f15a3d27de9a84694f4588374a5e383938866a54
 parent 080578bff89927c0f5aeddd588bc2f5f7373f232
 author [EMAIL PROTECTED](none) Tue, 26 Jul 2005 09:44:33
 +0200
 committer [EMAIL PROTECTED](none) Tue, 26 Jul 2005
 09:44:33 +0200
 
  drivers/misc/ucb1x00-ts.c |   87
 -
  1 files changed, 23 insertions(+), 64 deletions(-)
 
 diff --git a/drivers/misc/ucb1x00-ts.c
 b/drivers/misc/ucb1x00-ts.c
 --- a/drivers/misc/ucb1x00-ts.c
 +++ b/drivers/misc/ucb1x00-ts.c
 @@ -1,7 +1,8 @@
  /*
 - *  linux/drivers/misc/ucb1x00-ts.c
 + *  Touchscreen driver for UCB1x00-based
 touchscreens
   *
   *  Copyright (C) 2001 Russell King, All Rights
 Reserved.
 + *  Copyright (C) 2005 Pavel Machek
   *
   * This program is free software; you can
 redistribute it and/or modify
   * it under the terms of the GNU General Public
 License version 2 as
 @@ -30,6 +31,7 @@
  #include linux/device.h
  #include linux/suspend.h
  #include linux/slab.h
 +#include linux/kthread.h
  
  #include asm/dma.h
  #include asm/semaphore.h
 @@ -42,10 +44,7 @@ struct ucb1x00_ts {
   struct ucb1x00  *ucb;
  
   wait_queue_head_t   irq_wait;
 - struct semaphoresem;
 - struct completion   init_exit;
   struct task_struct  *rtask;
 - int use_count;
   u16 x_res;
   u16 y_res;
  
 @@ -55,20 +54,6 @@ struct ucb1x00_ts {
  
  static int adcsync;
  
 -static inline void ucb1x00_ts_evt_add(struct
 ucb1x00_ts *ts, u16 pressure, u16 x, u16 y)
 -{
 - input_report_abs(ts-idev, ABS_X, x);
 - input_report_abs(ts-idev, ABS_Y, y);
 - input_report_abs(ts-idev, ABS_PRESSURE,
 pressure);
 - input_sync(ts-idev);
 -}
 -
 -static inline void ucb1x00_ts_event_release(struct
 ucb1x00_ts *ts)
 -{
 - input_report_abs(ts-idev, ABS_PRESSURE, 0);
 - input_sync(ts-idev);
 -}
 -
  /*
   * Switch to interrupt mode.
   */
 @@ -176,12 +161,6 @@ static int ucb1x00_thread(void
 *_ts)
   DECLARE_WAITQUEUE(wait, tsk);
   int valid;
  
 - ts-rtask = tsk;
 -
 - daemonize(ktsd);
 - /* only want to receive SIGKILL */
 - allow_signal(SIGKILL);
 -
   /*
* We could run as a real-time thread.  However,
 thus far
* this doesn't seem to be necessary.
 @@ -189,12 +168,10 @@ static int ucb1x00_thread(void
 *_ts)
  //   tsk-policy = SCHED_FIFO;
  //   tsk-rt_priority = 1;
  
 - complete(ts-init_exit);
 -
   valid = 0;
  
   add_wait_queue(ts-irq_wait, wait);
 - for (;;) {
 + while (!kthread_should_stop()) {
   unsigned int x, y, p, val;
   signed long timeout;
  
 @@ -212,10 +189,7 @@ static int ucb1x00_thread(void
 *_ts)
   ucb1x00_ts_mode_int(ts);
   ucb1x00_adc_disable(ts-ucb);
  
 - set_task_state(tsk, TASK_UNINTERRUPTIBLE);
 - schedule_timeout(HZ / 100);
 - if (signal_pending(tsk))
 - break;
 + msleep(10);
  
   ucb1x00_enable(ts-ucb);
   val = ucb1x00_reg_read(ts-ucb, UCB_TS_CR);
 @@ -231,7 +205,8 @@ static int ucb1x00_thread(void
 *_ts)
* spit out a pen off sample here.
*/
   if (valid) {
 - ucb1x00_ts_event_release(ts);
 + input_report_abs(ts-idev, ABS_PRESSURE, 0);
 + input_sync(ts-idev);
   valid = 0;
   }
  
 @@ -245,7 +220,10 @@ static int ucb1x00_thread(void
 *_ts)
* to do any filtering they please.
*/
   if (!ts-restart) {
 - ucb1x00_ts_evt_add(ts, p, x, y);
 + input_report_abs(ts-idev, ABS_X, x);
 + input_report_abs(ts-idev, ABS_Y, y);
 + input_report_abs(ts-idev, ABS_PRESSURE, p);
 + input_sync(ts-idev);
   valid = 1;
   }
  
 @@ -256,14 +234,12 @@ static int 

Re: [patch] ucb1x00: touchscreen cleanups

2005-07-26 Thread Pavel Machek
Hi!

 I am in the process of porting Linux 2.6.11.5 to the
 Helio PDA (MIPS R3912 based) and if I remember
 correctly it is using a UCB1x00 (or Toshiba clone).
 Please could you make sure your patches will work
 across arch. Now I have my kernel up and running (well
 mainly falling :-() my next task is to get write the
 frame buffer driver and then look at the UCB1x00 as I
 need it for sound and touch screen. So in a day or two
 I will start to try to integrate your work into my
 kernel.

Well, without MIPS PDA to test on No, I do not think I broke
anything... but you'll have to ensure testing yourself.
Pavel
-- 
teflon -- maybe it is a trademark, but it should not be.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[patch 0/6] remove PageReserved

2005-07-26 Thread Nick Piggin

Hi Andrew,

If you're feeling like -mm is getting too stable, then you might
consider giving these patches a spin? (unless anyone else raises
an objection).

Ben thought I should get moving with them soon.

Not much change from last time. A bit of ppc64 input from Ben,
and some rmap.c input from Hugh. Boots and runs on a few machines
I have lying around here.

The only remaining places that *test* PageReserved are swsusp, a
trivial useage in drivers/char/agp/amd64-agp.c, and arch/ code.

Most of the arch code is just reserved memory reporting, which
isn't very interesting and could easily be removed. Some arch users
are a bit more subtle, however they *should not* break, because all
the places that set and clear PageReserved are basically intact.

We can phase PageReserved out of the tree completely when the core
becomes stable.

Now the main problems we might have are the introduction of some
tighter checks introduced by this patchset - for example 'bad_page'
is triggered on PG_reserved.

The other thing is - MAP_PRIVATE of VM_RESERVED regions becomes
disallowed. Any program that attempts such a thing prints a warning.
Hugh has some code which handles this case but he suggested that we
should first see whether it is even required.

Any thoughts? Comments?

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 


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


PROBLEM: UHCI_HCD misses SETUP_TD (First != element) after firmware upload

2005-07-26 Thread Giedrius Liubavičius

Hi there,
   I've got to setup D-Link DSL200i
   Kernel: 2.6.11.12
   Slackware 10.1.0
   Aditional software user: eagle-usb.org or atm.eagle-usb.org
   Problem: on my own computer, everything works fine (USB HUB 2.0,
Intel chipset, UHCI)
   On this one - only when on high load
   I tried to play with delays in various functions of uhci_hcd.c -
sometimes it helps
   If I change uhci_result_control ending:
   td= list_entry(tmp,..) to td=list_entry(head-next,..) -
setup passes

   USB device: 0x1110:0x9010 - without firmware, 0x1110:0x900f - with
firmware
   eagle usb module uploads firmware and initiates a reset. This is
where I get to the TD selection problem.
   More details on dlink.log

hub 1-0:1.0: state 5 ports 2 chg  evt 0002
uhci_hcd :00:14.2: port 1 portsc 0883,00
hub 1-0:1.0: over-current change on port 1
hub 1-0:1.0: port 1, status 0101, change 0009, 12 Mb/s
uhci_hcd :00:14.2: wakeup_hc
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
usb 1-1: new full speed USB device using uhci_hcd and address 5
uhci_hcd :00:14.2: uhci_result_control: failed with status 44
[c5102240] link (051021b2) element (04548040)
  0: [c4548040] link (04548080) e0 Stalled CRC/Timeo Length=7 MaxLen=7 DT0 
EndPt=0 Dev=0, PID=2d(SETUP) (buf=07d0cce0)
  1: [c4548080] link (045480c0) e3 SPD Active Length=0 MaxLen=3f DT1 EndPt=0 
Dev=0, PID=69(IN) (buf=071c83e0)
  2: [c45480c0] link (0001) e3 IOC Active Length=0 MaxLen=7ff DT1 EndPt=0 
Dev=0, PID=e1(OUT) (buf=)

usb 1-1: device descriptor read/64, error -71
usb 1-1: new device strings: Mfr=0, Product=0, SerialNumber=0
DEV: registering device: ID = '1-1'
usb 1-1: hotplug
PM: Adding info for usb:1-1
bus usb: add device 1-1
bound device '1-1' to driver 'usb'
usb 1-1: adding 1-1:1.0 (config #1, interface 0)
DEV: registering device: ID = '1-1:1.0'
usb 1-1:1.0: hotplug
PM: Adding info for usb:1-1:1.0
bus usb: add device 1-1:1.0
ueagle-atm 1-1:1.0: usb_probe_interface
ueagle-atm 1-1:1.0: usb_probe_interface - got id
usb 1-1: [ueagle-atm] ADSL device founded vid (0X1110) pid (0X9010) 
usb 1-1: reset full speed USB device using uhci_hcd and address 5
usb 1-1: [ueagle-atm] pre-firmware device, uploading firmware
CLASS: registering class device: ID = '1-1'
class_hotplug - name = 1-1
class_hotplug - hotplug() returned -19
class_hotplug - name = 1-1
CLASS: Unregistering class device. ID = '1-1'
class_hotplug - name = 1-1
device class '1-1': release.
usb 1-1: [ueagle-atm] firmware uploaded
bound device '1-1:1.0' to driver 'ueagle-atm'
hub 1-0:1.0: state 5 ports 2 chg  evt 0002
hub 1-0:1.0: state 5 ports 2 chg  evt 0002
uhci_hcd :00:14.2: port 1 portsc 008a,00
hub 1-0:1.0: port 1, status 0100, change 0003, 12 Mb/s
usb 1-1: USB disconnect, address 5
usb 1-1: usb_disable_device nuking all URBs
usb 1-1: unregistering interface 1-1:1.0
bus usb: remove device 1-1:1.0
PM: Removing info for usb:1-1:1.0
usb 1-1:1.0: hotplug
usb 1-1: unregistering device
DEV: Unregistering device. ID = '1-1'
bus usb: remove device 1-1
PM: Removing info for usb:1-1
usb 1-1: hotplug
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x100
hub 1-0:1.0: state 5 ports 2 chg  evt 0002
uhci_hcd :00:14.2: port 1 portsc 0093,00
hub 1-0:1.0: port 1, status 0101, change 0001, 12 Mb/s
hub 1-0:1.0: debounce: port 1: total 100ms stable 100ms status 0x101
usb 1-1: new full speed USB device using uhci_hcd and address 6
usb 1-1: skipped 2 descriptors after interface
usb 1-1: new device strings: Mfr=0, Product=2, SerialNumber=3
usb 1-1: default language 0x0409
usb 1-1: Product: ADSL-USB Modem
usb 1-1: SerialNumber: 000D88E54893
DEV: registering device: ID = '1-1'
usb 1-1: hotplug
PM: Adding info for usb:1-1
bus usb: add device 1-1
bound device '1-1' to driver 'usb'
uhci_hcd :00:14.2: uhci_result_control: failed with status 44
[c5102240] link (051021e2) element (04548080)
 Element != First TD
  0: [c4548040] link (04548080) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=6, 
PID=2d(SETUP) (buf=07752620)
  1: [c4548080] link (0001) e0 IOC Stalled CRC/Timeo Length=7ff MaxLen=7ff 
DT1 EndPt=0 Dev=6, PID=69(IN) (buf=)

usb 1-1: can't set config #1, error -84
bus usb: remove device 1-1
PM: Removing info for usb:1-1
usb 1-1: hotplug
uhci_hcd :00:14.2: port 1 portsc 0895,00
usb 1-1: new full speed USB device using uhci_hcd and address 7
uhci_hcd :00:14.2: port 1 portsc 0895,00
usb 1-1: skipped 2 descriptors after interface
usb 1-1: new device strings: Mfr=0, Product=2, SerialNumber=3
usb 1-1: default language 0x0409
usb 1-1: Product: ADSL-USB Modem
usb 1-1: SerialNumber: 000D88E54893
DEV: registering device: ID = '1-1'
usb 1-1: hotplug
PM: Adding info for usb:1-1
bus usb: add device 1-1
bound device '1-1' to driver 'usb'
uhci_hcd :00:14.2: uhci_result_control: failed with status 44
[c5102240] link (051021e2) element (04548080)
 Element != First TD
  0: [c4548040] link (04548080) e3 Length=7 MaxLen=7 DT0 EndPt=0 Dev=7, 

[patch 1/6] mm: comment rmap

2005-07-26 Thread Nick Piggin

1/6

Just be clear that VM_RESERVED pages here are a bug, and the test
is not there because they are expected.

Signed-off-by: Nick Piggin [EMAIL PROTECTED]

Index: linux-2.6/mm/rmap.c
===
--- linux-2.6.orig/mm/rmap.c
+++ linux-2.6/mm/rmap.c
@@ -532,6 +532,8 @@ static int try_to_unmap_one(struct page 
 * If the page is mlock()d, we cannot swap it out.
 * If it's recently referenced (perhaps page_referenced
 * skipped over this mm) then we should reactivate it.
+*
+* Pages belonging to VM_RESERVED regions should not happen here.
 */
if ((vma-vm_flags  (VM_LOCKED|VM_RESERVED)) ||
ptep_clear_flush_young(vma, address, pte)) {


[patch 2/6] mm: micro-optimise rmap

2005-07-26 Thread Nick Piggin

2/6

Microoptimise page_add_anon_rmap. Although these expressions are used only
in the taken branch of the if() statement, the compiler can't reorder them
inside because atomic_inc_and_test is a barrier.

Signed-off-by: Nick Piggin [EMAIL PROTECTED]

Index: linux-2.6/mm/rmap.c
===
--- linux-2.6.orig/mm/rmap.c
+++ linux-2.6/mm/rmap.c
@@ -442,22 +442,23 @@ int page_referenced(struct page *page, i
 void page_add_anon_rmap(struct page *page,
struct vm_area_struct *vma, unsigned long address)
 {
-   struct anon_vma *anon_vma = vma-anon_vma;
-   pgoff_t index;
-
BUG_ON(PageReserved(page));
-   BUG_ON(!anon_vma);
 
inc_mm_counter(vma-vm_mm, anon_rss);
 
-   anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
-   index = (address - vma-vm_start)  PAGE_SHIFT;
-   index += vma-vm_pgoff;
-   index = PAGE_CACHE_SHIFT - PAGE_SHIFT;
-
if (atomic_inc_and_test(page-_mapcount)) {
-   page-index = index;
+   struct anon_vma *anon_vma = vma-anon_vma;
+   pgoff_t index;
+
+   BUG_ON(!anon_vma);
+   anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
page-mapping = (struct address_space *) anon_vma;
+
+   index = (address - vma-vm_start)  PAGE_SHIFT;
+   index += vma-vm_pgoff;
+   index = PAGE_CACHE_SHIFT - PAGE_SHIFT;
+   page-index = index;
+
inc_page_state(nr_mapped);
}
/* else checking page index and mapping is racy */


[patch 4/6] mm: remove atomic

2005-07-26 Thread Nick Piggin

4/6

OK, these first 4 patches don't have much to do with removing
PageReserved, but I put them in this series because that's how
I have them arranged.

This bitop does not need to be atomic because it is performed when
there will be no references to the page (ie. the page is being freed).

Signed-off-by: Nick Piggin [EMAIL PROTECTED]

Index: linux-2.6/mm/page_alloc.c
===
--- linux-2.6.orig/mm/page_alloc.c
+++ linux-2.6/mm/page_alloc.c
@@ -329,7 +329,7 @@ static inline void free_pages_check(cons
1  PG_writeback )))
bad_page(function, page);
if (PageDirty(page))
-   ClearPageDirty(page);
+   __ClearPageDirty(page);
 }
 
 /*
Index: linux-2.6/include/linux/page-flags.h
===
--- linux-2.6.orig/include/linux/page-flags.h
+++ linux-2.6/include/linux/page-flags.h
@@ -194,6 +194,7 @@ extern void __mod_page_state(unsigned lo
 #define SetPageDirty(page) set_bit(PG_dirty, (page)-flags)
 #define TestSetPageDirty(page) test_and_set_bit(PG_dirty, (page)-flags)
 #define ClearPageDirty(page)   clear_bit(PG_dirty, (page)-flags)
+#define __ClearPageDirty(page) __clear_bit(PG_dirty, (page)-flags)
 #define TestClearPageDirty(page) test_and_clear_bit(PG_dirty, (page)-flags)
 
 #define SetPageLRU(page)   set_bit(PG_lru, (page)-flags)


[patch 5/6] mm: remap ZERO_PAGE mappings

2005-07-26 Thread Nick Piggin

5/6

Remap ZERO_PAGE ptes when remapping memory. This is currently just an
optimisation for MIPS, which is the only architecture with multiple
zero pages - it now retains the mapping it needs for good cache performance,
and as well do_wp_page is now able to always correctly detect and
optimise zero page COW faults.

This change is required in order to be able to detect whether a pte
points to a ZERO_PAGE using only its (pte, vaddr) pair.

Signed-off-by: Nick Piggin [EMAIL PROTECTED]

Index: linux-2.6/mm/mremap.c
===
--- linux-2.6.orig/mm/mremap.c
+++ linux-2.6/mm/mremap.c
@@ -141,6 +141,10 @@ move_one_page(struct vm_area_struct *vma
if (dst) {
pte_t pte;
pte = ptep_clear_flush(vma, old_addr, src);
+   /* ZERO_PAGE can be dependant on virtual addr */
+   if (pfn_valid(pte_pfn(pte)) 
+   pte_page(pte) == ZERO_PAGE(old_addr))
+   pte = 
pte_wrprotect(mk_pte(ZERO_PAGE(new_addr), new_vma-vm_page_prot));
set_pte_at(mm, new_addr, dst, pte);
} else
error = -ENOMEM;


[patch 3/6] mm: cleanup rmap

2005-07-26 Thread Nick Piggin

3/6

Thanks to Bill Irwin for pointing this out.

Signed-off-by: Nick Piggin [EMAIL PROTECTED]

Index: linux-2.6/mm/rmap.c
===
--- linux-2.6.orig/mm/rmap.c
+++ linux-2.6/mm/rmap.c
@@ -448,16 +448,12 @@ void page_add_anon_rmap(struct page *pag
 
if (atomic_inc_and_test(page-_mapcount)) {
struct anon_vma *anon_vma = vma-anon_vma;
-   pgoff_t index;
 
BUG_ON(!anon_vma);
anon_vma = (void *) anon_vma + PAGE_MAPPING_ANON;
page-mapping = (struct address_space *) anon_vma;
 
-   index = (address - vma-vm_start)  PAGE_SHIFT;
-   index += vma-vm_pgoff;
-   index = PAGE_CACHE_SHIFT - PAGE_SHIFT;
-   page-index = index;
+   page-index = linear_page_index(vma, address);
 
inc_page_state(nr_mapped);
}


Re: [patch 0/6] remove PageReserved

2005-07-26 Thread Nick Piggin

Nick Piggin wrote:

Hi Andrew,

If you're feeling like -mm is getting too stable, then you might
consider giving these patches a spin? (unless anyone else raises
an objection).



Patches are against 2.6.13-rc3-git7

--
SUSE Labs, Novell Inc.

Send instant messages to your online friends http://au.messenger.yahoo.com 


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


Re: 2.6.13-rc3 udev/hotplug use memory after free

2005-07-26 Thread Keith Owens
On Mon, 25 Jul 2005 15:01:19 -0700, 
Andrew Morton [EMAIL PROTECTED] wrote:
Keith Owens [EMAIL PROTECTED] wrote:

 2.6.13-rc3 + kdb (which does not touch udev/hotplug) on IA64 (Altix).
  gcc version 3.3.3 (SuSE Linux).  Compiled with DEBUG_SLAB,
  DEBUG_PREEMPT, DEBUG_SPINLOCK, DEBUG_SPINLOCK_SLEEP, DEBUG_KOBJECT.
 
  There is a use after free somewhere above class_device_attr_show.

Can we obtain a backtrace for this one, Keith?  The function itself is
pretty innocuous and is used by many callers.  I'd be suspectng a bug in
the caller.

I no longer have the backtrace.  This 2.6.13-rc3 system has been booted
50+ times (ia64 MCA testing) and only once did it break.  If it recurs, I'll
do some more digging.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 6/6] mm: core remove PageReserved

2005-07-26 Thread Nick Piggin

6/6

Remove PageReserved() calls from core code by tightening VM_RESERVED
handling in mm/ to cover PageReserved functionality.

PageReserved special casing is removed from get_page and put_page.

All setting and clearning of PageReserved is retained, and it is now
flagged in the page_alloc checks to help ensure we don't introduce
any refcount based freeing of Reserved pages.

MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
deprecated. We never completely handled it correctly anyway, and is
difficult to handle nicely - difficult but not impossible, it could
be reintroduced in future if required (Hugh has a proof of concept).

Once PageReserved() calls are removed from kernel/power/swsusp.c, and
all arch/ and driver code, the Set and Clear calls, and the PG_reserved
bit can be trivially removed.

Last real user of PageReserved is swsusp, which uses PageReserved to
determine whether a struct page points to valid memory or not. This
still needs to be addressed.

Many thanks to Hugh Dickins for input.

Signed-off-by: Nick Piggin [EMAIL PROTECTED]


Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -156,7 +156,8 @@ extern unsigned int kobjsize(const void 
 
 #define VM_DONTCOPY0x0002  /* Do not copy this vma on fork */
 #define VM_DONTEXPAND  0x0004  /* Cannot expand with mremap() */
-#define VM_RESERVED0x0008  /* Don't unmap it from swap_out */
+#define VM_RESERVED0x0008  /* Pages and ptes in region aren't 
managed with regular pagecache or rmap routines */
+
 #define VM_ACCOUNT 0x0010  /* Is a VM accounted object */
 #define VM_HUGETLB 0x0040  /* Huge TLB Page VM */
 #define VM_NONLINEAR   0x0080  /* Is non-linear (remap_file_pages) */
@@ -337,7 +338,7 @@ static inline void get_page(struct page 
 
 static inline void put_page(struct page *page)
 {
-   if (!PageReserved(page)  put_page_testzero(page))
+   if (put_page_testzero(page))
__page_cache_release(page);
 }
 
@@ -711,6 +712,7 @@ void install_arg_page(struct vm_area_str
 
 int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned 
long start,
int len, int write, int force, struct page **pages, struct 
vm_area_struct **vmas);
+void print_invalid_pfn(const char *, pte_t, unsigned long, unsigned long);
 
 int __set_page_dirty_buffers(struct page *page);
 int __set_page_dirty_nobuffers(struct page *page);
Index: linux-2.6/mm/madvise.c
===
--- linux-2.6.orig/mm/madvise.c
+++ linux-2.6/mm/madvise.c
@@ -126,7 +126,7 @@ static long madvise_dontneed(struct vm_a
 unsigned long start, unsigned long end)
 {
*prev = vma;
-   if ((vma-vm_flags  VM_LOCKED) || is_vm_hugetlb_page(vma))
+   if ((vma-vm_flags  (VM_LOCKED|VM_RESERVED)) || 
is_vm_hugetlb_page(vma))
return -EINVAL;
 
if (unlikely(vma-vm_flags  VM_NONLINEAR)) {
Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -333,6 +333,21 @@ out:
 }
 
 /*
+ * This function is called to print an error when a pte in a
+ * !VM_RESERVED region is found pointing to an invalid pfn (which
+ * is an error.
+ *
+ * The calling function must still handle the error.
+ */
+void print_invalid_pfn(const char *errfunc, pte_t pte,
+   unsigned long vm_flags, unsigned long vaddr)
+{
+   printk(KERN_ERR %s: pte does not point to valid memory. 
+   process = %s, pte = %08lx, vm_flags = %lx, vaddr = %lx\n,
+   errfunc, current-comm, (long)pte_val(pte), vm_flags, vaddr);
+}
+
+/*
  * copy one vm_area from one task to the other. Assumes the page tables
  * already present in the new task to be cleared in the whole range
  * covered by this vma.
@@ -361,25 +376,29 @@ copy_one_pte(struct mm_struct *dst_mm, s
spin_unlock(mmlist_lock);
}
}
-   set_pte_at(dst_mm, addr, dst_pte, pte);
-   return;
+   goto out_set_pte;
}
 
+   /* If the region is VM_RESERVED, the mapping is not
+* mapped via rmap - duplicate the pte as is.
+*/
+   if (vm_flags  VM_RESERVED)
+   goto out_set_pte;
+
+   /* If the pte points outside of valid memory but
+* the region is not VM_RESERVED, we have a problem.
+*/
pfn = pte_pfn(pte);
-   /* the pte points outside of valid memory, the
-* mapping is assumed to be good, meaningful
-* and not mapped via rmap - duplicate the
-* mapping as is.
-*/
-   page = NULL;
-   if (pfn_valid(pfn))
-   page = pfn_to_page(pfn);
-
-   if (!page 

Re: xor as a lazy comparison

2005-07-26 Thread Bernd Petrovitsch
On Tue, 2005-07-26 at 08:07 +0200, Jan Engelhardt wrote:
[...]
 To answer for x *= 2 vs x = 1:
and x += x

 Use * when you would logically want to do a multiplication,
  if you're working on a bitfield. It's just for keeping the code clean 
 enough so that others may understand it.
 
 In the longshot, it does not matter, as gcc will optimize out multiplication 
  ^^^ the C compiler
 with powers of two to bitops.

And if the C compiler is not doing this properly, such tunings are
probably in 100%-\eps cases worthless anyway.

Bernd
-- 
Firmix Software GmbH   http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
  Embedded Linux Development and Services

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


Re: Netlink connector

2005-07-26 Thread Harald Welte
On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote:
 On Sun, 24 Jul 2005, David S. Miller wrote:
 From: Evgeniy Polyakov [EMAIL PROTECTED]
 Date: Sat, 23 Jul 2005 13:14:55 +0400
 Andrew has no objection against connector and it lives in -mm
 A patch sitting in -mm has zero significance.
 
 The significance I think is that Andrew is trying to gently encourage some 
 further progress in the area.

Patrick McHardy is currently working on some ideas on how to extend
netlink.

The fundamental problem that the connector is trying to solve:

1) provide more 'groups' (to transport more different kinds of events)
2) provide an abstract API for other kernel code, so it doesn't have to
   know anything about skb's or networking.

IMHO issue number '1' should (and can) be adressed within netlink.  Wait
for Patrick's work on this to show up on netdev.  We can then think
whether the connctor API (or something similar) can be put on top of it.

-- 
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/

  Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed.-- Paul Vixie


pgpR29EQBIMUR.pgp
Description: PGP signature


[patch 6/6] mm: core remove PageReserved (take 2)

2005-07-26 Thread Nick Piggin

Nick Piggin wrote:

6/6



Actually I think Hugh gave me some feedback about the introduced
`print_invalid_pfn` function, which I ignored.

So here is patch 6 again, with print_invalid_pfn renamed invalid_pfn,
and using a macro to alleviate the requirement of passing in the
function name by hand.

Remove PageReserved() calls from core code by tightening VM_RESERVED
handling in mm/ to cover PageReserved functionality.

PageReserved special casing is removed from get_page and put_page.

All setting and clearning of PageReserved is retained, and it is now
flagged in the page_alloc checks to help ensure we don't introduce
any refcount based freeing of Reserved pages.

MAP_PRIVATE, PROT_WRITE of VM_RESERVED regions is tentatively being
deprecated. We never completely handled it correctly anyway, and is
difficult to handle nicely - difficult but not impossible, it could
be reintroduced in future if required (Hugh has a proof of concept).

Once PageReserved() calls are removed from kernel/power/swsusp.c, and
all arch/ and driver code, the Set and Clear calls, and the PG_reserved
bit can be trivially removed.

Last real user of PageReserved is swsusp, which uses PageReserved to
determine whether a struct page points to valid memory or not. This
still needs to be addressed.

Many thanks to Hugh Dickins for input.

Signed-off-by: Nick Piggin [EMAIL PROTECTED]


Index: linux-2.6/include/linux/mm.h
===
--- linux-2.6.orig/include/linux/mm.h
+++ linux-2.6/include/linux/mm.h
@@ -156,7 +156,8 @@ extern unsigned int kobjsize(const void 
 
 #define VM_DONTCOPY0x0002  /* Do not copy this vma on fork */
 #define VM_DONTEXPAND  0x0004  /* Cannot expand with mremap() */
-#define VM_RESERVED0x0008  /* Don't unmap it from swap_out */
+#define VM_RESERVED0x0008  /* Pages and ptes in region aren't 
managed with regular pagecache or rmap routines */
+
 #define VM_ACCOUNT 0x0010  /* Is a VM accounted object */
 #define VM_HUGETLB 0x0040  /* Huge TLB Page VM */
 #define VM_NONLINEAR   0x0080  /* Is non-linear (remap_file_pages) */
@@ -337,7 +338,7 @@ static inline void get_page(struct page 
 
 static inline void put_page(struct page *page)
 {
-   if (!PageReserved(page)  put_page_testzero(page))
+   if (put_page_testzero(page))
__page_cache_release(page);
 }
 
@@ -711,6 +712,9 @@ void install_arg_page(struct vm_area_str
 
 int get_user_pages(struct task_struct *tsk, struct mm_struct *mm, unsigned 
long start,
int len, int write, int force, struct page **pages, struct 
vm_area_struct **vmas);
+#define invalid_pfn(pte, vm_flags, vaddr)  \
+   __invalid_pfn(__FUNCTION__, pte, vm_flags, vaddr)
+void __invalid_pfn(const char *, pte_t, unsigned long, unsigned long);
 
 int __set_page_dirty_buffers(struct page *page);
 int __set_page_dirty_nobuffers(struct page *page);
Index: linux-2.6/mm/madvise.c
===
--- linux-2.6.orig/mm/madvise.c
+++ linux-2.6/mm/madvise.c
@@ -126,7 +126,7 @@ static long madvise_dontneed(struct vm_a
 unsigned long start, unsigned long end)
 {
*prev = vma;
-   if ((vma-vm_flags  VM_LOCKED) || is_vm_hugetlb_page(vma))
+   if ((vma-vm_flags  (VM_LOCKED|VM_RESERVED)) || 
is_vm_hugetlb_page(vma))
return -EINVAL;
 
if (unlikely(vma-vm_flags  VM_NONLINEAR)) {
Index: linux-2.6/mm/memory.c
===
--- linux-2.6.orig/mm/memory.c
+++ linux-2.6/mm/memory.c
@@ -333,6 +333,21 @@ out:
 }
 
 /*
+ * This function is called to print an error when a pte in a
+ * !VM_RESERVED region is found pointing to an invalid pfn (which
+ * is an error.
+ *
+ * The calling function must still handle the error.
+ */
+void __invalid_pfn(const char *errfunc, pte_t pte,
+   unsigned long vm_flags, unsigned long vaddr)
+{
+   printk(KERN_ERR %s: pte does not point to valid memory. 
+   process = %s, pte = %08lx, vm_flags = %lx, vaddr = %lx\n,
+   errfunc, current-comm, (long)pte_val(pte), vm_flags, vaddr);
+}
+
+/*
  * copy one vm_area from one task to the other. Assumes the page tables
  * already present in the new task to be cleared in the whole range
  * covered by this vma.
@@ -361,25 +376,29 @@ copy_one_pte(struct mm_struct *dst_mm, s
spin_unlock(mmlist_lock);
}
}
-   set_pte_at(dst_mm, addr, dst_pte, pte);
-   return;
+   goto out_set_pte;
}
 
+   /* If the region is VM_RESERVED, the mapping is not
+* mapped via rmap - duplicate the pte as is.
+*/
+   if (vm_flags  VM_RESERVED)
+   goto out_set_pte;
+
+   /* If the pte points outside of valid memory 

Re: Netlink connector

2005-07-26 Thread Evgeniy Polyakov
On Tue, Jul 26, 2005 at 04:42:14AM -0400, Harald Welte ([EMAIL PROTECTED]) 
wrote:
 On Mon, Jul 25, 2005 at 02:02:10AM -0400, James Morris wrote:
  On Sun, 24 Jul 2005, David S. Miller wrote:
  From: Evgeniy Polyakov [EMAIL PROTECTED]
  Date: Sat, 23 Jul 2005 13:14:55 +0400
  Andrew has no objection against connector and it lives in -mm
  A patch sitting in -mm has zero significance.
  
  The significance I think is that Andrew is trying to gently encourage some 
  further progress in the area.
 
 Patrick McHardy is currently working on some ideas on how to extend
 netlink.
 
 The fundamental problem that the connector is trying to solve:
 
 1) provide more 'groups' (to transport more different kinds of events)
 2) provide an abstract API for other kernel code, so it doesn't have to
know anything about skb's or networking.
 
 IMHO issue number '1' should (and can) be adressed within netlink.  Wait
 for Patrick's work on this to show up on netdev.  We can then think
 whether the connctor API (or something similar) can be put on top of it.

Fair enough.
Let's do it this way.

 -- 
 - Harald Welte [EMAIL PROTECTED] http://netfilter.org/
 
   Fragmentation is like classful addressing -- an interesting early
architectural error that shows how much experimentation was going
on while IP was being designed.-- Paul Vixie



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


serial driver help

2005-07-26 Thread Rahul Tank
hello all,
  i am a newbee trying to write a device driver for a
serial port.
 i read the /driver/char/serial.c and have got the
idea of how the gs_write works.
  however i am unable to understand how to read or
write to a serial port.

 any pointers,
  plz help

 thanks in advance.






__
Free antispam, antivirus and 1GB to save all your messages
Only in Yahoo! Mail: http://in.mail.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[PATCH -mm/-rc] fix xip sparse file handling in ext2

2005-07-26 Thread Carsten Otte
[PATCH -mm/-rc] fix xip sparse file handling in ext2
Oliver Paukstadt from our test department is testing the xip patches in
Linus' git-tree. He found a problem that shows when reading a file that
contains sparse blocks (holes) on a -o xip mounted ext2 filesystem: the
BUG_ON() in fs/ext2/xip.c:40 triggers where it should not. The problem
was introduced by a cleanup in my previous patch, this patch fixes it.

Signed-off-by: Carsten Otte [EMAIL PROTECTED]
---
diff -ruwN linux-git/fs/ext2/xip.c linux-git-xip-fixup/fs/ext2/xip.c
--- linux-git/fs/ext2/xip.c 2005-07-25 17:18:38.0 +0200
+++ linux-git-xip-fixup/fs/ext2/xip.c   2005-07-26 09:10:49.593563928 +0200
@@ -36,7 +36,7 @@
*result = tmp.b_blocknr;
 
/* did we get a sparse block (hole in the file)? */
-   if (!(*result)) {
+   if (!tmp.b_blocknr  !rc) {
BUG_ON(create);
rc = -ENODATA;
}


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


PSX Gamepad Support

2005-07-26 Thread Christoph Litters

Hello,

I have an adapter usb to psx i have tried it with 2.6.9 and it works 
perfectly with the kernel driver.
with 2.6.12 i cant get it to work and with 2.6.13-rc3 i havent seen any 
option to enable it.

could anybody help me?

Greets and thanks

c. litters

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 optimization

2005-07-26 Thread Adrian Bunk
On Tue, Jul 26, 2005 at 08:22:59AM +0300, Al Boldi wrote:
 Dr. Horst H. von Brand wrote: {
 Al Boldi [EMAIL PROTECTED] wrote:
   Adrian Bunk wrote: {
  On Fri, Jul 22, 2005 at 07:55:48PM +0100, christos gentsis wrote:
   i would like to ask if it possible to change the optimization of the 
   kernel from -O2 to -O3 :D, how can i do that? if i change it to the 
   top level Makefile does it change to all the Makefiles?
  And since it's larger, it's also slower.
  }
 
  It's faster but it's flawed.  Root-NFS boot failed!
 
 How do you know that it is faster if it is busted?
 }
 
 The -O3 compile produces a faster kernel, which seems to work perfectly,
 albeit the Root-NFS boot flaw!

How did you measure that you that your -O3 kernel isn't slower?

 Al

cu
Adrian

-- 

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

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


Re: Netlink connector

2005-07-26 Thread Harald Welte
On Mon, Jul 25, 2005 at 11:33:51PM +0400, Evgeniy Polyakov wrote:

 Netlink is transport protocol - no need to add complexity into it, 
 it must be as simple as possible and thus extensible.

yes.  but when you run into a serious addressing shortage (like the
internet does with ipv4), you develop something that provides more
addresses (such as ipv6).  That's why support for more groups than 32
(per family) is something that should be put in the netlink protocol.

I totally agree that we need a higher-level api on top of that, in order
to hide the details of the networking stack for those not interested in
it.

-- 
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/

  Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed.-- Paul Vixie


pgpyoFvK5oqLK.pgp
Description: PGP signature


Re: 2.6.13-rc3 test: finding compile errors with make randconfig

2005-07-26 Thread Adrian Bunk
On Tue, Jul 26, 2005 at 11:26:33AM +1000, Grant Coady wrote:
 On Sun, 24 Jul 2005 23:27:22 +0200, Adrian Bunk [EMAIL PROTECTED] wrote:
 
 You should edit init/Kconfig to disallow CONFIG_CLEAN_COMPILE=n, since 
 any errors you see with CONFIG_BROKEN=y aren't interesting.
 
 Straight over the top of my head yesterday :)  Is the following 
 what you had in mind?  (current script does retry if BROKEN)
... 
 -   depends on !CLEAN_COMPILE
 +   depends on !CLEAN_COMPILE  0
...

I don't know whether this will work, I was thinking about

--- linux-2.6.13-rc3-mm1/init/Kconfig.old   2005-07-26 11:47:49.0 
+0200
+++ linux-2.6.13-rc3-mm1/init/Kconfig   2005-07-26 11:48:01.0 +0200
@@ -32,7 +32,7 @@
  drivers that are currently considered to be in the alpha-test phase.
 
 config CLEAN_COMPILE
-   bool Select only drivers expected to compile cleanly if EXPERIMENTAL
+   bool
default y
help
  Select this option if you don't even want to see the option


 Thanks,
 Grant.

cu
Adrian

-- 

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

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


Re: Linux tty layer hackery: Heads up and RFC

2005-07-26 Thread Mark Underwood
Hi Rogier,

Having just written a DMA UART driver I can say this
is good news :-). Here are some things to think about:

What my driver would like to do is to handle its own
input buffers. It would pass the buffer to the tty
layer when it is full and the tty layer would pass the
buffer back once it has drained the data from it.
The problem is that I don't always receive a block
worth of characters so I also need to pass the tty
layer a buffer (which I'm still DMAing into) with a
count of how many chars there are in the buffer and a
offset of where to start from. If I can't do this then
I have to stop the DMA transfer, pass you a mostly
empty buffer with a char count, and setup DMA transfer
into another buffer. If during this I get a burst of
data I could well lose it :-(.

Best Regards,

Mark

--- Rogier Wolff [EMAIL PROTECTED] wrote:

 On Thu, Jul 21, 2005 at 06:46:32PM +0100, Alan Cox
 wrote:
  int tty_prepare_flip_string(tty, strptr, len)
  
  Adjust the buffer to allow len characters to be
 added. Returns a buffer
  pointer in strptr and the length available. This
 allows for hardware
  that needs to use functions like insl or
 mencpy_fromio.
 
 Ok, So then I start copying characters into the
 flipstring, but how do
 I say I'm done?
 
 Or is there a race between that I call
 tty_prepare_flip_string, and
 other processes start pulling my not-yet-filled
 string from the
 buffer? (Surely not!)
 
   Roger. 
 
 -- 
 ** [EMAIL PROTECTED] **
 http://www.BitWizard.nl/ ** +31-15-2600998 **
 *-- BitWizard writes Linux device drivers for any
 device you may have! --*
 Q: It doesn't work. A: Look buddy, doesn't work is
 an ambiguous statement. 
 Does it sit on the couch all day? Is it unemployed?
 Please be specific! 
 Define 'it' and what it isn't doing. -
 Adapted from lxrbot FAQ
 -
 To unsubscribe from this list: send the line
 unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at 
 http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 






___ 
Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail 
http://uk.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.

2005-07-26 Thread Stefan Seyfried
Puneet Vyas wrote:

 ide : failed opcode was : unknown
 hdc : status error: status 0x00 { }

This is _not_ an USB cd writer but an IDE drive.
You may not just pull it out.
-- 
Stefan Seyfried  \ I didn't want to write for pay. I
QA / RD Team Mobile Devices  \ wanted to be paid for what I write.
SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


[INPUT] simple question on driver initialisation.

2005-07-26 Thread moreau francis
Hi,

I'm currently developping a very simple driver for a pinpad by using
Input module. I'm using Event handler to pass events from pinpad to userland.
In this simple case, I'm wondering if I really need to initialise
phys field in in input_dev struct before calling input_register_device.
What is this field for ?

Thanks for your answers,

 Francis.






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

2005-07-26 Thread Ingo Molnar

* Andreas Steinmetz [EMAIL PROTECTED] wrote:

 RLIMIT_RTPRIO is supposed to grant non privileged users the right to 
 use SCHED_FIFO/SCHED_RR scheduling policies with priorites bounded by 
 the RLIMIT_RTPRIO value via sched_setscheduler(). This is usually used 
 by audio users.
 
 Unfortunately this is broken in 2.6.13rc3 as you can see in the 
 excerpt from sched_setscheduler below:
 
 /*
  * Allow unprivileged RT tasks to decrease priority:
  */
 if (!capable(CAP_SYS_NICE)) {
 /* can't change policy */
 if (policy != p-policy)
 return -EPERM;
 
 After the above unconditional test which causes sched_setscheduler to
 fail with no regard to the RLIMIT_RTPRIO value the following check is made:
 
/* can't increase priority */
 if (policy != SCHED_NORMAL 
 param-sched_priority  p-rt_priority 
 param-sched_priority 
 p-signal-rlim[RLIMIT_RTPRIO].rlim_cur)
 return -EPERM;
 
 Thus I do believe that the RLIMIT_RTPRIO value must be taken into 
 account for the policy check, especially as the RLIMIT_RTPRIO limit is 
 of no use without this change.
 
 The attached patch fixes this problem. I would appreciate it if the 
 fix would make it into 2.6.13.

[back from KS/OLS]

indeed. The effect of the bug is that RLIMIT_RTPRIO is completely
non-functional in 2.6.12.

Acked-by: Ingo Molnar [EMAIL PROTECTED]

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BUG: Yamaha OPL3SA2 does not work with ALSA on 2.6 kernels.

2005-07-26 Thread Andrew Haninger
On 7/26/05, Jaroslav Kysela [EMAIL PROTECTED] wrote:
 We have already two similar reports #440 and #879. Please, provide us
 all info (working manual conf etc.)..
Yes. #879 is the one that mentions that this might be a kernel bug (so
I reported it here):

I suspect this is kernel bug and it conserns ISA support.
I would be happy if you kick some kernel developers buts because they
have ignored my bugreport for quite long time now.

I don't know how correct/incorrect the above may be, but I figured it
was possible.

I'll report what I know in bug #879.

Thanks.

-Andy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: BUG: Yamaha OPL3SA2 does not work with ALSA on 2.6 kernels.

2005-07-26 Thread Andrew Haninger
On 7/26/05, Andrew Haninger [EMAIL PROTECTED] wrote:
 I'll report what I know in bug #879.
*Durr* I didn't scroll down. I've already reported my current
semi-working (works+oopses) setup in that bug report

I'm reporting this here now because of the part of that bug report
that suggests that it might actually be a kernel bug.

-Andy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Linux tty layer hackery: Heads up and RFC

2005-07-26 Thread Alan Cox
On Maw, 2005-07-26 at 10:55 +0100, Mark Underwood wrote:
 What my driver would like to do is to handle its own
 input buffers. It would pass the buffer to the tty
 layer when it is full and the tty layer would pass the

In theory you can do that already, although the locking is a bit screwed
up for it. Actually all the tty locking is broken for rx I believe.
Everyone should be holding the tty read lock when updating flip buffers
but right now we don't

 buffer back once it has drained the data from it.
 The problem is that I don't always receive a block
 worth of characters so I also need to pass the tty
 layer a buffer (which I'm still DMAing into) with a
 count of how many chars there are in the buffer and a
 offset of where to start from.

You can do this now providing you don't do it blindly from IRQ context.

From a workqueue do

struct tty_ldisc *ld = tty_ldisc_ref(tty);
int space;

if(ld == NULL)  /* Bin/defer */
return;
space = ld-receive_room(tty);
if(count  space) count = space;

ld-receive_buf(tty, charbuf, flagbuf, count);


There is a corner case if TTY_DONT_FLIP is set where you should queue
but not all drivers do this and the DONT_FLIP hack 'has to die' 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [SOLVED ?] VIA KT400 + Kernel 2.6.12 + IO-APIC + ehci_hcd = IRQ trouble

2005-07-26 Thread Michel Bouissou
Le Mardi 26 Juillet 2005 04:13, Protasevich, Natalie a écrit :
   Le Lundi 25 Juillet 2005 22:44, Alan Stern a écrit :
 
  Natalie, that's all I can think of.  Now it's up to you to
  invent a patch Michel can try out, to show just where the
  IO-APIC code is going wrong.

 I will sure try... I'm keeping an eye on your exchange don't worry :)
 just have to get done with urgent work piled up here while on my trip :
 ...

I'm afraid that I may have accidentally solved my problem ;-)

I've upgraded my Gigabyte GA7-VAXP motherboard's BIOS from release 7VAXP.F11 
to 7VAXP.F15, and it seems the problem is gone !

The strange thing is that now, cat /proc/interrupts shows that both uhci_hcd 
and ehci_hcd use the same IRQ (21) :

[EMAIL PROTECTED] etc]# cat /proc/interrupts
   CPU0
  0: 569004IO-APIC-edge  timer
  1:   2107IO-APIC-edge  i8042
  2:  0  XT-PIC  cascade
  4:   1589IO-APIC-edge  serial
  7:  2IO-APIC-edge  parport0
 14:   4615IO-APIC-edge  ide4
 15:   4624IO-APIC-edge  ide5
 16:  29033   IO-APIC-level  nvidia
 18:   7684   IO-APIC-level  eth0, eth1
 19:  28049   IO-APIC-level  ide0, ide1, ide2, ide3
 21:   7128   IO-APIC-level  ehci_hcd:usb1, uhci_hcd:usb2, uhci_hcd:usb3, 
uhci_hcd:usb4
 22:   5969   IO-APIC-level  VIA8233
NMI:  0
LOC: 568946
ERR:  0
MIS:  0

...and then, the system feels happy. I've played around with USB devices of 
all speeds in all sockets, and there are no irq 21: nobody cared! messages 
anymore...

Still, high-speed USB devices seem to work only in the motherboard integrated 
USB sockets, otherwise I get some usb 1-4: device not accepting address 26, 
error -71 messages, but this isn't an issue for me, and might be a cable 
problem as you said...

So it seems that the BIOS upgrade fixed the IRQ issue (or masked it ?).

What is weird is that, from the Gigabyte's BIOS list, I wouldn't have expected 
this upgrade to fix this, as their changelog from F11 to F15 only says:

F11: AMD Barton CPU support (2500+/2800+/3000+) 

F13: Fixed BIOS flash utility(flash8xx) can't be used issue

F14: Support new AMD Duron model8 CPU (64K L2 Cache FSB 266)

F15: Added AMD Sempron CPU support

So this BIOS upgrade was just a desperate move on my part ;-)

Well, anyway, things look much better here now...

Natalie, if you would like me to try some of your VIA patches to check them 
out on my system, I would be glad to help in my turn...

Cheers, and thanks to all of you again for all your precious help.

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


Re: [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (2/2)

2005-07-26 Thread Rafael J. Wysocki
The following patch adds basic suspend/resume support to the sk98lin
network driver.

Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

--- linux-2.6.13-rc3-git5/drivers/net/sk98lin/skge.c2005-07-23 
19:26:29.0 +0200
+++ patched/drivers/net/sk98lin/skge.c  2005-07-25 18:17:57.0 +0200
@@ -5133,6 +5133,75 @@ static void __devexit skge_remove_one(st
kfree(pAC);
 }
 
+#ifdef CONFIG_PM
+static int skge_suspend(struct pci_dev *pdev, pm_message_t state)
+{
+   struct net_device *dev = pci_get_drvdata(pdev);
+   DEV_NET *pNet = netdev_priv(dev);
+   SK_AC *pAC = pNet-pAC;
+   struct net_device *otherdev = pAC-dev[1];
+
+   if (pNet-Up) {
+   pAC-WasIfUp[0] = SK_TRUE;
+   DoPrintInterfaceChange = SK_FALSE;
+   SkDrvDeInitAdapter(pAC, 0);  /* performs SkGeClose */
+   }
+   if (otherdev != dev) {
+   pNet = netdev_priv(otherdev);
+   if (pNet-Up) {
+   pAC-WasIfUp[1] = SK_TRUE;
+   DoPrintInterfaceChange = SK_FALSE;
+   SkDrvDeInitAdapter(pAC, 1);  /* performs SkGeClose */
+   }
+   }
+
+   pci_save_state(pdev);
+   pci_enable_wake(pdev, pci_choose_state(pdev, state), 0);
+   if (pAC-AllocFlag  SK_ALLOC_IRQ) {
+   free_irq(dev-irq, dev);
+   }
+   pci_disable_device(pdev);
+   pci_set_power_state(pdev, pci_choose_state(pdev, state));
+
+   return 0;
+}
+
+static int skge_resume(struct pci_dev *pdev)
+{
+   struct net_device *dev = pci_get_drvdata(pdev);
+   DEV_NET *pNet = netdev_priv(dev);
+   SK_AC *pAC = pNet-pAC;
+   int ret;
+
+   pci_set_power_state(pdev, PCI_D0);
+   pci_restore_state(pdev);
+   pci_enable_device(pdev);
+   pci_set_master(pdev);
+   if (pAC-GIni.GIMacsFound == 2)
+   ret = request_irq(dev-irq, SkGeIsr, SA_SHIRQ, pAC-Name, dev);
+   else
+   ret = request_irq(dev-irq, SkGeIsrOnePort, SA_SHIRQ, 
pAC-Name, dev);
+   if (ret) {
+   printk(KERN_WARNING sk98lin: unable to acquire IRQ %d\n, 
dev-irq);
+   pAC-AllocFlag = ~SK_ALLOC_IRQ;
+   dev-irq = 0;
+   pci_disable_device(pdev);
+   return -EBUSY;
+   }
+
+   if (pAC-WasIfUp[0] == SK_TRUE) {
+   DoPrintInterfaceChange = SK_FALSE;
+   SkDrvInitAdapter(pAC, 0);/* first device  */
+   }
+   if (pAC-dev[1] != dev  pAC-WasIfUp[1] == SK_TRUE) {
+   DoPrintInterfaceChange = SK_FALSE;
+   SkDrvInitAdapter(pAC, 1);/* second device  */
+   }
+
+   return 0;
+}
+#endif
+
 static struct pci_device_id skge_pci_tbl[] = {
{ PCI_VENDOR_ID_3COM, 0x1700, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
{ PCI_VENDOR_ID_3COM, 0x80eb, PCI_ANY_ID, PCI_ANY_ID, 0, 0, 0 },
@@ -5158,6 +5227,8 @@ static struct pci_driver skge_driver = {
.id_table   = skge_pci_tbl,
.probe  = skge_probe_one,
.remove = __devexit_p(skge_remove_one),
+   .suspend= skge_suspend,
+   .resume = skge_resume,
 };
 
 static int __init skge_init(void)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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.13-rc3-git5: fix Bug #4416 (0/2)

2005-07-26 Thread Rafael J. Wysocki
Hi,

The following two patches are necessary to prevent my box (Asus L5D) from
hanging solid during resume from disk.

The problem is that, apparently, some out-of-order interrupts may be
generated during resume and if some drivers do not call free_irq() on
suspend, these interrupts are mishandled.  For reference please see
http://bugzilla.kernel.org/show_bug.cgi?id=4416
and
http://sourceforge.net/mailarchive/message.php?msg_id=12448907

The first patch adds free_irq() and request_irq() to the suspend and resume
routines, respectively, in the snd_intel8x0 driver.

The second one adds basic suspend/resume support to the sk98lin driver.

Please consider for applying,
Rafael


-- 
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll Alice's Adventures in Wonderland

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [INPUT] simple question on driver initialisation.

2005-07-26 Thread Vojtech Pavlik
On Tue, Jul 26, 2005 at 12:23:40PM +0200, moreau francis wrote:

 I'm currently developping a very simple driver for a pinpad by using
 Input module. I'm using Event handler to pass events from pinpad to userland.
 In this simple case, I'm wondering if I really need to initialise
 phys field in in input_dev struct before calling input_register_device.

Yes, it is required.

 What is this field for ?
 
It is intended for identifying the device based on location in the
system.

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


[PATCH] 2.6.13-rc3-git5: fix Bug #4416 (1/2)

2005-07-26 Thread Rafael J. Wysocki
The following patch adds free_irq() and request_irq() to the suspend and
resume, respectively, routines in the snd_intel8x0 driver.

Signed-off-by: Rafael J. Wysocki [EMAIL PROTECTED]

--- linux-2.6.13-rc3-git5/sound/pci/intel8x0.c  2005-07-23 19:26:43.0 
+0200
+++ patched/sound/pci/intel8x0.c2005-07-25 18:21:36.0 +0200
@@ -2373,6 +2373,8 @@ static int intel8x0_suspend(snd_card_t *
for (i = 0; i  3; i++)
if (chip-ac97[i])
snd_ac97_suspend(chip-ac97[i]);
+   if (chip-irq = 0)
+   free_irq(chip-irq, (void *)chip);
pci_disable_device(chip-pci);
return 0;
 }
@@ -2384,7 +2386,14 @@ static int intel8x0_resume(snd_card_t *c
 
pci_enable_device(chip-pci);
pci_set_master(chip-pci);
-   snd_intel8x0_chip_init(chip, 0);
+   if (request_irq(chip-irq, snd_intel8x0_interrupt, 
SA_INTERRUPT|SA_SHIRQ, card-shortname, (void *)chip)) {
+   snd_printk(unable to grab IRQ %d\n, chip-irq);
+   chip-irq = -1;
+   pci_disable_device(chip-pci);
+   return -EBUSY;
+   }
+   synchronize_irq(chip-irq);
+   snd_intel8x0_chip_init(chip, 1);
 
/* refill nocache */
if (chip-fix_nocache)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


As of 2.6.13-rc1 Fusion-MPT very slow

2005-07-26 Thread Holger Kiehl

Hello

On a four CPU Opteron with Fusion-MPT compiled in, I get the following
results (up to 2.6.13-rc3-git7) with hdparm on the first channel with
four disks:

   sdc74 MB/s
   sdd 2 MB/s
   sde 2 MB/s
   sdf 2 MB/s

On the second channel also with the same type of disks:

   sdg74 MB/s
   sdh74 MB/s
   sdi74 MB/s
   sdj74 MB/s

All disk are of the same type. Compiling Fusion-MPT as module for the
same kernel I get 74 MB/s for all eight disks. Taking kernel 2.6.12.2 and
compile it in, all eigth disks give the expected performance of 74 MB/s.
When I exchange the two cables, put the first cable on second channel and
second cable on first channel, always sdd, sde and sdf will only get
approx. 2 MB/s with any 2.6.13-* kernels.

Another problem observed with 2.6.13-rc3-git7 and Fusion-MPT compiled in
is when making a ext3 filesystem over those eight disks (software Raid10),
makes mke2fs hang for a very long time in D-state and /var/log/messages
writting a lot of these messages:

   mptscsih: ioc0:  Attempting task abort! (sc=81014ead3ac0)
   mptscsih: ioc0:  Attempting task abort! (sc=81014ead38c0)
   mptscsih: ioc0:  Attempting task abort! (sc=81014ead36c0)
   mptscsih: ioc0:  Attempting task abort! (sc=81014ead34c0)
  .
  .
  .

And finally, when I do a halt or powerdown just after all filesystems
are unmounted the fusion driver tells me that it puts the two controllers
in power save mode. Then kernel whants to flush the SCSI disks but
hangs forever. This does not happen when doing a reboot.

Holger
--

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [IBM] RE: [BUG] Fusion MPT Base Driver initialization failure wit h kdum p

2005-07-26 Thread Vivek Goyal
On Mon, Jul 25, 2005 at 03:10:33PM -0700, Andrew Morton wrote:
 Vivek Goyal [EMAIL PROTECTED] wrote:
 
   If you don't stop the DMA engines before you boot the new kernel, the
addresses they have to send data to will now be random points in that
kernel's memory, leading to potential corruption of the new kernel
image.
  
   [Copying it to fastboot and linux-kernel mailing lists]
  
   We are booting second kernel (capture kernel) from a reserved memory 
  location
   to take care of on-going DMA issues. So even if some DMA transactions are 
  going
   on after the crash they will not corrupt the new kernel.
  

The interrupt panic of the fusion is probably a symptom of this: I bet a
DMA transfer has just completed and the interrupt is to inform us of
this (however, in the new kernel we're not expecting any transfers).
  
   That might very well be the case. So driver should simply ignore the 
  interrupt
   when it is not expecting it or it should reset the device if it finds that 
   some interrupts are pending when it should not have been there.
  
   Basically it is a matter of hardening the driver so that it can handle/
   initialize the device even if the device is not in reset state. 
 
 I'd expect that a lot of these problems could be reduced by simply pausing
 for a while in the crash handler, wait for I/O to complete.
 

Andrew, We will test it out and see if it helps on some of the already
reported issues.

Thanks
Vivek
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.

2005-07-26 Thread Denis Vlasenko
On Tuesday 26 July 2005 13:15, Stefan Seyfried wrote:
 Puneet Vyas wrote:
 
  ide : failed opcode was : unknown
  hdc : status error: status 0x00 { }
 
 This is _not_ an USB cd writer but an IDE drive.
 You may not just pull it out.

Interesting how he's connecting floppy to IDE ;]
--
vda

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: PROBLEM:Machine hangs on pulling out USB cd writer on laptop.

2005-07-26 Thread Stefan Seyfried
Denis Vlasenko wrote:
 On Tuesday 26 July 2005 13:15, Stefan Seyfried wrote:
 This is _not_ an USB cd writer but an IDE drive.
 You may not just pull it out.
 
 Interesting how he's connecting floppy to IDE ;]

The connector probably has IDE and USB, the floppy is using the USB
part, the CDRW is using the IDE part of the connector.
-- 
Stefan Seyfried  \ I didn't want to write for pay. I
QA / RD Team Mobile Devices  \ wanted to be paid for what I write.
SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [INPUT] simple question on driver initialisation.

2005-07-26 Thread moreau francis
hello,

--- Vojtech Pavlik [EMAIL PROTECTED] a écrit :

  What is this field for ?
  
 It is intended for identifying the device based on location in the
 system.
 

hmm, sorry but I don't understand you. I initialised this field with
pinpad/input0 but the only place I can grep or find it, is in
/proc/bus/input/devices. I don't see how it can be used for identifiying
the device...

thanks for your time

  Francis






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

2005-07-26 Thread Paolo Ciarrocchi
2005/7/26, Ingo Molnar [EMAIL PROTECTED]:
[...]
 [back from KS/OLS]
 
 indeed. The effect of the bug is that RLIMIT_RTPRIO is completely
 non-functional in 2.6.12.
 
 Acked-by: Ingo Molnar [EMAIL PROTECTED]

Ingo, Lee, Andreas,
the patch seems to be quite simple and is a fix for a regression.
Is anybody going to FW it to the stable team ?

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


Re: 2.6.12 PREEMPT_RT PPC

2005-07-26 Thread Ingo Molnar

* john cooper [EMAIL PROTECTED] wrote:

 Ingo,
 Attached is a patch for 51-28 which brings PPC up to date for 
 2.6.12 PREEMPT_RT.  My goal was to get a more recent vintage of this 
 work building and minimally booting for PPC.  Yet this has been stable 
 even under our internal stress tests.  We now have this running on 
 8560 and 8260 PPC targets with a few others in the pipe.

great. I've applied most of your patch and have released the -51-37 
kernel. A couple of generic bits i did not apply.

 In the process of producing the patch I stumbled across a change 
 introduced in 51-15 where in the case of PREEMPT_RT it appears 
 hw_irq_controller.end() is never being called at the end of 
 do_hardirq(). This appears to be an oversight in the code and the 
 existing PPC openpic code does register a end() handler which it 
 expects to be called in order to terminate the interrupt.  Otherwise 
 interrupts at the current level are effectively disabled.

this change was fully intentional. Basically on PREEMPT_HARDIRQS, the 
'redirected' interrupt path is special already. Right now when an IRQ is 
redirected, we do the following: -ack() in the hardirq handler and no 
-end() (so we keep the interrupt masked), then the handling of the IRQ 
sometime later in its interrupt thread, and an -enable(). It's a bit 
unclean, but this results in minimal per-arch changes to the IRQ code.  
Nevertheless i have applied your change, but we need to get rid of this.

 There is also what I suspect to be some leaking of the 
 __RAW_LOCAL_ILLEGAL_MASK bit out of the local_irq*() API primitives as 
 the *flags argument. This may subsequently be used by non-local_irq*() 
 primitives and wind up unintentionally setting the 
 __RAW_LOCAL_ILLEGAL_MASK bit in the machine control register with 
 unpredictable results.

i have not applied the generic bits for this, because it should be 
solved within the raw_local_irq*() code: check for the illegal bit if 
IRQ debugging is turned on. We very much want to know about mismatched 
IRQ flags.

 Lastly there is a problem I've yet to isolate in 
 kernel/printk.c:release_console_sem() where the expansion of 
 spin_unlock_irq(logbuf_lock) generating a call to 
 __raw_local_irq_enable() will lockup console output on PPC.  In the 
 interim this has been reverted to a spin_unlock() call for the case of 
 PREEMPT_RT  PPC.

i have not applied this one either, please investigate it further, it 
ought to work.

Also, i have not applied the timer.c change yet either: what kind of bug 
are you trying to fix there?

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [INPUT] simple question on driver initialisation.

2005-07-26 Thread Vojtech Pavlik
On Tue, Jul 26, 2005 at 01:47:05PM +0200, moreau francis wrote:
 hello,
 
 --- Vojtech Pavlik [EMAIL PROTECTED] a écrit :
 
   What is this field for ?
   
  It is intended for identifying the device based on location in the
  system.
  
 
 hmm, sorry but I don't understand you. I initialised this field with
 pinpad/input0 but the only place I can grep or find it, is in
 /proc/bus/input/devices. I don't see how it can be used for identifiying
 the device...

It's also available via an ioctl() and in sysfs. This allows you to
specify in an application that you want a device plugged into a specific
port of the machine. Not many applications can use it at the moment, but
udev can use it to assign a name of the device node.

pinpad/input0 doesn't sound right. What port is your pinpad connected
to?

-- 
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.13rc3: RLIMIT_RTPRIO broken

2005-07-26 Thread Ingo Molnar

* Paolo Ciarrocchi [EMAIL PROTECTED] wrote:

 2005/7/26, Ingo Molnar [EMAIL PROTECTED]:
 [...]
  [back from KS/OLS]
  
  indeed. The effect of the bug is that RLIMIT_RTPRIO is completely
  non-functional in 2.6.12.
  
  Acked-by: Ingo Molnar [EMAIL PROTECTED]
 
 Ingo, Lee, Andreas,
 the patch seems to be quite simple and is a fix for a regression.
 Is anybody going to FW it to the stable team ?

i'd not put it into stable just yet - the fact that it has not been 
tested in 2.6.12 _at all_ up until very recently means there's little QA 
feedback. Yes, it's simple, but it also triggers something we never did 
before. 2.6.13 ought to be released soon, that should be good enough.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: Obsolete files in 2.6 tree

2005-07-26 Thread Vojtech Pavlik
On Thu, Jul 21, 2005 at 11:47:32AM +0200, Jiri Slaby wrote:

 Jiri Slaby napsal(a):
 
 Are these files obsolete and could be deleted from tree.
 Does anybody use them? Could anybody compile them?
 
 New list should be:
 drivers/char/drm/gamma_dma.c
 drivers/char/drm/gamma_drv.c
 drivers/char/scan_keyb.c
 drivers/char/scan_keyb.h

 drivers/input/power.c

This one is partly obsolete and partly a work in progress. It's not
referenced from Kconfig at the moment, but will later in time.

 drivers/isdn/hisax/elsa_ser.c
 drivers/media/video/zr36120.c
 drivers/media/video/zr36120_i2c.c
 drivers/media/video/zr36120_mem.c
 drivers/net/wan/sdladrv.c
 drivers/scsi/NCR5380.c
 drivers/scsi/NCR5380.h
 drivers/scsi/scsi_module.c
 drivers/video/pm3fb.c
 fs/befs/attribute.c
 fs/binfmt_som.c
 sound/oss/skeleton.c

-- 
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: [ACPI] Re: [PATCH] 2.6.13-rc3-git5: fix Bug #4416 (2/2)

2005-07-26 Thread Carl-Daniel Hailfinger
Rafael J. Wysocki schrieb:
 The following patch adds basic suspend/resume support to the sk98lin
 network driver.
[snipped]

The current in-kernel sk98lin driver is years behind the version
downloadable from Syskonnect. Maybe it would make sense to update
it first before applying any new patches.
http://www.syskonnect.com/support/driver/d0102_driver.html

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [INPUT] simple question on driver initialisation.

2005-07-26 Thread moreau francis
Thanks Vojtech for your answers !

--- Vojtech Pavlik [EMAIL PROTECTED] a écrit :

 It's also available via an ioctl() and in sysfs. This allows you to
 specify in an application that you want a device plugged into a specific
 port of the machine. Not many applications can use it at the moment, but
 udev can use it to assign a name of the device node.
 

hmm, how can I use ioctl to find the location device since I need the location
to pass it to ioctl ?

I can't find pinpad/input0 in sysfs, does that mean I need to add sysfs
suppport in my driver, and it's not done in input module when I register 
my input driver ?

 pinpad/input0 doesn't sound right. What port is your pinpad connected
 to?
 

Actually I'm working on an embedded system which owns a pinpad controller.
This controller is accessed by using io mem and it talks to the pinpad through
a dedicated bus. So I accessed it through io space.

thanks,

 Francis.






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Linux tty layer hackery: Heads up and RFC

2005-07-26 Thread Mark Underwood
Hi Alan,

Thanks for your help, I might give this ago once I've
fixed some flow control problems in my driver.

On a loosely related topic I have extended
serial_core.c to handle DMA UARTS (only the TX path is
effected). Once I'm happy with my changes I post a
patch.

Best Regards,

Mark

--- Alan Cox [EMAIL PROTECTED] wrote:

 On Maw, 2005-07-26 at 10:55 +0100, Mark Underwood
 wrote:
  What my driver would like to do is to handle its
 own
  input buffers. It would pass the buffer to the tty
  layer when it is full and the tty layer would pass
 the
 
 In theory you can do that already, although the
 locking is a bit screwed
 up for it. Actually all the tty locking is broken
 for rx I believe.
 Everyone should be holding the tty read lock when
 updating flip buffers
 but right now we don't
 
  buffer back once it has drained the data from it.
  The problem is that I don't always receive a block
  worth of characters so I also need to pass the tty
  layer a buffer (which I'm still DMAing into) with
 a
  count of how many chars there are in the buffer
 and a
  offset of where to start from.
 
 You can do this now providing you don't do it
 blindly from IRQ context.
 
 From a workqueue do
 
   struct tty_ldisc *ld = tty_ldisc_ref(tty);
   int space;
 
   if(ld == NULL)  /* Bin/defer */
   return;
   space = ld-receive_room(tty);
   if(count  space) count = space;
 
   ld-receive_buf(tty, charbuf, flagbuf, count);
 
 
 There is a corner case if TTY_DONT_FLIP is set where
 you should queue
 but not all drivers do this and the DONT_FLIP hack
 'has to die' 
 
 -
 To unsubscribe from this list: send the line
 unsubscribe linux-kernel in
 the body of a message to [EMAIL PROTECTED]
 More majordomo info at 
 http://vger.kernel.org/majordomo-info.html
 Please read the FAQ at  http://www.tux.org/lkml/
 




___ 
How much free photo storage do you get? Store your holiday 
snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH repost] PROT_DONTCOPY: ifiniband uverbs fork support

2005-07-26 Thread Hugh Dickins
On Mon, 25 Jul 2005, Michael S. Tsirkin wrote:
 
 This patch adds PROT_DONTCOPY to mmap and mprotect, to set VM_DONTCOPY on vma.
 This is needed for infiniband userspace i/o, where we need to protect against
   - the child process accessing the parent hardware page
   - the parent registered address (on which the driver did get_user_pages)
 getting remapped to another page by COW
 One can imagine other uses, e.g. combined with mlock for real-time or 
 security.

I don't much like it, but it does solve a real problem in an efficient way.

Partly I don't like it because of PROT_DONTCOPY itself: I'm queasy
about protection flags which are not protection flags, though I find
you're not the first to go down that road.

Is the patch tested?  I've not tried, but suspect the newflags shift
and mask won't work for it.  And I don't look forward to your adding
VM_MAYDONTCOPY - ugh!

 @@ -246,7 +246,7 @@ sys_mprotect(unsigned long start, size_t
   goto out;
   }
  
 - newflags = vm_flags | (vma-vm_flags  ~(VM_READ | VM_WRITE | 
 VM_EXEC));
 + newflags = vm_flags | (vma-vm_flags  ~(VM_READ | VM_WRITE | 
 VM_EXEC | VM_DONTCOPY));
  
   if ((newflags  ~(newflags  4))  0xf) {
   error = -EACCES;

I rather think it would all be more cleanly handled by dropping the mmap
and mprotect changes, adding an madvise instead.  Though you may object
that madvise is for optional behaviours, and this should be mandatory.

The other reason I dislike the patch is that the problem it fixes is
an old one, and I'd much rather have get_user_pages fix it for itself,
than ask the developer to do some additional magic to get around it.

But I've failed to work out a simple efficient alternative, which won't
burden the vast majority of get_user_pages usages which never hit the
issue.  So your way is probably appropriate, but I'd prefer madvise.

(Sorry, I won't be able to discuss further for a couple of days.)

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


Re: [PATCH] 1 Wire drivers illegally overload NETLINK_NFLOG

2005-07-26 Thread Harald Welte
On Sun, Jul 24, 2005 at 07:15:05PM -0700, David S. Miller wrote:
 
  I strongly disrecommend increasing NPROTO.  Maybe we should look into
  reusing NETLINK_FIREWALL (which was an old 2.2.x kernel interface).
 
 ip_queue.c still uses NETLINK_FIREWALL so we really can't use
 that.

sorry, I didn't remember that ip_queue reused the 2.2.x netlink number
:(  We should have renamed it to make it clear.

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

thanks.

-- 
- Harald Welte [EMAIL PROTECTED] http://netfilter.org/

  Fragmentation is like classful addressing -- an interesting early
   architectural error that shows how much experimentation was going
   on while IP was being designed.-- Paul Vixie


pgpHVOu8MUreE.pgp
Description: PGP signature


[no subject]

2005-07-26 Thread robertk

Hi,

I am currently using Slackware 10.1 with 2.4.29 kernel and encountered following
problem:

I use Sagem Fast 800 ADSL modem of my provider and use my linux station as a
router (iptables+masquerade). The problem is that after a few hours of working
my linux crashes with the message:



serwer login: Unable to handle kernel NULL pointer dereference at virtual
address 0020
*pde = 
0opss: 0002
CPU: 0
EIP: 0010:[c4958ca3] Not tainted
EFLAGS: 00010087
eax: c11c56 ebx:c11c56c8 ecx:c11a1604 edx: c3139e34
esi:  edi: c3139e34 ebp: c11c56dc esp: c3385f50
ds: 0018 es: 0018 ss: 0018
Process klogd (pid: 63, stackpage=c3385000)
Stack: 246  c111c5660 0001 ff80 c4958d51 c11c5660 c11c5660
c3527ee0 0401 c3385fc4 000a c0109fbd 000a c11c55660 c3385fc4
c03829a0 000a c3527ee0 c3385fc4 c010a138 000a c3385fc4  c3527ee0
Call Trace: [c4958d51] [c0109fbd] [c010a138] [c010c428]

Code: c7 46 20 98 ff ff ff 8b 43 10 8b 80 d8 00 00 00 8b 40 2c 8b
0Kernel panic: Aiee, killing interrupt handler!
In interrupt handler - not syncing

I tried rekompiling the kernel and chose MMX architekture in Processor Type and
Features - Processor Family but it did not help. I also tried different
versions of Sagem drivers but the problem is still present.

I am a newbie to linux and would be very thankful for any solutions or just
hints about solving this problem. I don't know if the problem is caused by
sagem drivers but on the second PC station (Athlon Xp2000+, 384 MB RAM, 80GB
Samsung) nothing like this happened.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [INPUT] simple question on driver initialisation.

2005-07-26 Thread Vojtech Pavlik
On Tue, Jul 26, 2005 at 02:26:02PM +0200, moreau francis wrote:
 Thanks Vojtech for your answers !
 
 --- Vojtech Pavlik [EMAIL PROTECTED] a écrit :
 
  It's also available via an ioctl() and in sysfs. This allows you to
  specify in an application that you want a device plugged into a specific
  port of the machine. Not many applications can use it at the moment, but
  udev can use it to assign a name of the device node.
  
 
 hmm, how can I use ioctl to find the location device since I need the location
 to pass it to ioctl ?
 
 I can't find pinpad/input0 in sysfs, does that mean I need to add sysfs
 suppport in my driver, and it's not done in input module when I register 
 my input driver ?

I'm sorry, I thought it's already in mainline, but that bit is still
missing from the sysfs support in input. It'll get there soon.

  pinpad/input0 doesn't sound right. What port is your pinpad connected
  to?
 
 Actually I'm working on an embedded system which owns a pinpad controller.
 This controller is accessed by using io mem and it talks to the pinpad through
 a dedicated bus. So I accessed it through io space.

In that case, you'll likely want something like io0200/input0, where
0x200 would be the io address of the device. On the other hand, if it's
really embedded and there can't be two pinpads in the system, it's not a
problem to use basically any string there, since it only needs to be
system-unique.

-- 
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 0/6] remove PageReserved

2005-07-26 Thread Kumar Gala


On Jul 26, 2005, at 3:15 AM, Nick Piggin wrote:


Hi Andrew,

If you're feeling like -mm is getting too stable, then you might
consider giving these patches a spin? (unless anyone else raises
an objection).

Ben thought I should get moving with them soon.

Not much change from last time. A bit of ppc64 input from Ben,
and some rmap.c input from Hugh. Boots and runs on a few machines
I have lying around here.

The only remaining places that *test* PageReserved are swsusp, a
trivial useage in drivers/char/agp/amd64-agp.c, and arch/ code.

Most of the arch code is just reserved memory reporting, which
isn't very interesting and could easily be removed. Some arch users
are a bit more subtle, however they *should not* break, because all
the places that set and clear PageReserved are basically intact.


What is the desired fix look like for arch users?

- 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: elvtune with 2.6 kernels (under FC3)

2005-07-26 Thread Bill Davidsen

Gaspar Bakos wrote:

Hi,

I am cc-ing this to the kernel list, a i have the suspicion that it may
be a kernel related feature.

--
I noticed that elvtune does not work on FC3 with a 2.6.12.3
(self-compiled, pristine) kernel. I also tried it with other 2.6.* kernels.

elvtune /dev/sde
ioctl get: Invalid argument

In fact, I get the same message for all disks, either those on a 3ware
controller, or SATA disks directly attached to the motherboard.
The hw is a dual opteron mb with 4Gb RAM.

Did this command become obsoleted?
Is there alternativ?


Not that I ever found. You can play with values in 
/sys/block/{device}/queue or wherever you have your sysfs mounted.

Not a great user interface, but at least you can play.

--
   -bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
 last possible moment - but no longer  -me
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 linux-2.6-block:master] overview of soon-to-be-posted patches

2005-07-26 Thread Tejun Heo
 Hello, Jens.

 I hope you had fun on your vacation and at OLS.  I'm posting 18
welcome-back patches today. :-p This mail is to show the overview of
the patches.  All patches are against master head of linux-2.6-block
tree.

patch #1: fix-elevator_find.  remove try_module_get race in
  elevator_find.
patch #2: fix-cfq_find_next_crq.  fix cfq_find_next_crq bug
  in cfq.
patch #3-7  : generic dispatch queue patchset.  implements generic
  dispatch queue.
patch #8: reimplement-elevator-switch.  reimplements elevator
  switch using generic dispatch queue.  draining isn't
  needed anymore.
patch #9-#18: ordered reimplementation patchset.  reimplements
  I/O barrier handling.

 Both generic dispatch queue patchset and ordered reimplementation
patchset were previously posted.  They are reordered (as you asked)
and I've added missing bits (all elevators are updated, docs are
updated).  Also, there were a few changes and fixes.  I'll mention
them when I post those patches.

 I've tested these changes by running parallelly...

* random raw read (concurrency 8)
* repeatedly mounting a ext3 fs with -o barrier=1, copying, syncing 
  checksumming a 128M file, and unmounting the fs.
* periodic scheduler switch (each iosched runs for 3 minutes and then
  switched to the next one)

 This test has been running for several hours without a problem and I
will keep it running for today and maybe tomorrow unless I have to use
the test machine for some other purpose.

 Thanks.

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


Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

2005-07-26 Thread Vojtech Pavlik
On Thu, Jul 21, 2005 at 08:04:48PM +0200, Voluspa wrote:
 
 I'd gladly (ehum..) redo this mind-numbingly boring test if someone can
 point me to a magic software which unleashes some untapped powersaving
 feature of the CPU.
 
 _Kernel 2.6.13-rc3 Boot to Death_:
 
 2h48m at 100 HZ
 2h48m at 250 HZ
 2h47m at 1000 HZ

Is USB loaded? It'll do 1000 interrupts per second if it is. I'm not sure if
this still is the case on 2.6.13-rc3, please check your /proc/interrupts
to see the rate at which interrupt counters are increasing.

 Acer Aspire 1520 (1524) WLMi, AMD Athlon 64 3400+ (socket 754 according
 to dmidecode-2.6). L1 64K/64K, L2 1024K, 512MB DDR RAM. Manufacturing
 date 18 March 2005. Bought 20 May 2005. Battery used to full drain ca 5
 times prior to this test (after the initial 3 charge/drains to reach its
 full potential). cat /proc/acpi/battery/BAT0/info:
 
This almost looks like a regular Athlon 64, not even the mobile version.
I wouldn't expect very big deep sleep capabilities on that one. You can
check the 

/proc/acpi/processor/CPU1/power

file for the list of C states. A normal Athlon64 will likely have only
C0. Mobile chips can go up to C4, which is really deep sleep.

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

2005-07-26 Thread Bill Davidsen

Brown, Len wrote:
On a HT system, why does ACPI recognize CPU0 and CPU1, refer 
to them as such in dmesg



This is the Linux CPU number. ie the namespace where 0
is the boot processor and the others are numbered in
the order that they were started.


and then call them CPU1 and CPU2 in 
/proc/acpi/processor?



These are arbitrary device identifiers written
by the BIOS developer and foolishly advertised
to the user by Linux.  The BIOS writer could have
also called them ABC9 and XYZ4 and it would be
equally valid.


Which explains why they are CPU1 and CPU2 on ASUS and CPU0 and CPU1 on 
another system. I was hoping I had found something for the person who 
was having problems with the P4P800 mobo, but looks like it's not here.


We're planning to get rid of all the ACPI stuff
in /proc and move to sysfs.  At that time we'll
use device identifies that are deterministic,
like cpu%d that /sys/devices/system uses today.


Whatever, it's cosmetic and there seem to be more important problems 
with APIC than /proc vs. /sys.


Thanks for the clarification.


--
   -bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
 last possible moment - but no longer  -me
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 linux-2.6-block:master] block: fix try_module_get race in elevator_find

2005-07-26 Thread Tejun Heo
 Hello, Jens.

 This patch removes try_module_get race in elevator_find.
try_module_get should always be called with the spinlock protecting
what the module init/cleanup routines register/unregister to held.  In
the case of elevators, we should be holding elv_list to avoid it going
away between spin_unlock_irq and try_module_get.

 This currently doesn't cause any problem as elevators are never
unloaded, but the fix is simple and it's always nice to be correct.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

Index: blk-fixes/drivers/block/elevator.c
===
--- blk-fixes.orig/drivers/block/elevator.c 2005-07-25 23:16:11.0 
+0900
+++ blk-fixes/drivers/block/elevator.c  2005-07-25 23:20:30.0 +0900
@@ -97,7 +97,6 @@ static struct elevator_type *elevator_fi
struct elevator_type *e = NULL;
struct list_head *entry;
 
-   spin_lock_irq(elv_list_lock);
list_for_each(entry, elv_list) {
struct elevator_type *__e;
 
@@ -108,7 +107,6 @@ static struct elevator_type *elevator_fi
break;
}
}
-   spin_unlock_irq(elv_list_lock);
 
return e;
 }
@@ -120,12 +118,15 @@ static void elevator_put(struct elevator
 
 static struct elevator_type *elevator_get(const char *name)
 {
-   struct elevator_type *e = elevator_find(name);
+   struct elevator_type *e;
 
-   if (!e)
-   return NULL;
-   if (!try_module_get(e-elevator_owner))
-   return NULL;
+   spin_lock_irq(elv_list_lock);
+
+   e = elevator_find(name);
+   if (e  !try_module_get(e-elevator_owner))
+   e = NULL;
+
+   spin_unlock_irq(elv_list_lock);
 
return e;
 }
@@ -153,11 +154,15 @@ static char chosen_elevator[16];
 
 static void elevator_setup_default(void)
 {
+   struct elevator_type *e;
+
/*
 * check if default is set and exists
 */
-   if (chosen_elevator[0]  elevator_find(chosen_elevator))
+   if (chosen_elevator[0]  (e = elevator_get(chosen_elevator))) {
+   elevator_put(e);
return;
+   }
 
 #if defined(CONFIG_IOSCHED_AS)
strcpy(chosen_elevator, anticipatory);
@@ -554,10 +559,9 @@ void elv_unregister_queue(struct request
 
 int elv_register(struct elevator_type *e)
 {
+   spin_lock_irq(elv_list_lock);
if (elevator_find(e-elevator_name))
BUG();
-
-   spin_lock_irq(elv_list_lock);
list_add_tail(e-list, elv_list);
spin_unlock_irq(elv_list_lock);
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 linux-2.6-block:master] block: fix cfq_find_next_crq

2005-07-26 Thread Tejun Heo
 Hi,

 In cfq_find_next_crq(), when determining rbnext, if
rb_next(last-rb_node) is NULL, rb_first() is used without checking
if it equals last.  If it equals last, rbnext should be NULL not last.
This bug is masked by duplicate calls to cfq_find_next_crq which ends
up clearing cfqq-next_crq as, on the second call, last isn't on rb
tree.

 This patch fixes cfq_find_next_crq() and removes extra calls to
cfq_update_next_crq().

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

Index: blk-fixes/drivers/block/cfq-iosched.c
===
--- blk-fixes.orig/drivers/block/cfq-iosched.c  2005-07-26 14:35:41.0 
+0900
+++ blk-fixes/drivers/block/cfq-iosched.c   2005-07-26 14:43:14.0 
+0900
@@ -195,7 +195,6 @@ struct cfq_rq {
 
 static struct cfq_queue *cfq_find_cfq_hash(struct cfq_data *, unsigned long);
 static void cfq_dispatch_sort(request_queue_t *, struct cfq_rq *);
-static void cfq_update_next_crq(struct cfq_rq *);
 static void cfq_put_cfqd(struct cfq_data *cfqd);
 
 /*
@@ -235,8 +234,6 @@ static void cfq_remove_merge_hints(reque
 
if (q-last_merge == crq-request)
q-last_merge = NULL;
-
-   cfq_update_next_crq(crq);
 }
 
 static inline void cfq_add_crq_hash(struct cfq_data *cfqd, struct cfq_rq *crq)
@@ -380,8 +377,11 @@ cfq_find_next_crq(struct cfq_data *cfqd,
if (!ON_RB(last-rb_node))
return NULL;
 
-   if ((rbnext = rb_next(last-rb_node)) == NULL)
+   if ((rbnext = rb_next(last-rb_node)) == NULL) {
rbnext = rb_first(cfqq-sort_list);
+   if (rbnext == last-rb_node)
+   rbnext = NULL;
+   }
 
rbprev = rb_prev(last-rb_node);
 
@@ -721,7 +721,6 @@ cfq_merged_requests(request_queue_t *q, 
}
}
 
-   cfq_update_next_crq(cnext);
cfq_remove_request(q, next);
 }
 

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 repost] PROT_DONTCOPY: ifiniband uverbs fork support

2005-07-26 Thread Michael S. Tsirkin
Hi, Hugh!
Thanks for the comments.

Quoting Hugh Dickins [EMAIL PROTECTED]:
 Subject: Re: [PATCH repost] PROT_DONTCOPY: ifiniband uverbs fork support
 
 On Mon, 25 Jul 2005, Michael S. Tsirkin wrote:
  
  This patch adds PROT_DONTCOPY to mmap and mprotect, to set VM_DONTCOPY on 
  vma.
  This is needed for infiniband userspace i/o, where we need to protect 
  against
- the child process accessing the parent hardware page
- the parent registered address (on which the driver did get_user_pages)
  getting remapped to another page by COW
  One can imagine other uses, e.g. combined with mlock for real-time or 
  security.
 
 I don't much like it, but it does solve a real problem in an efficient way.
 
 Partly I don't like it because of PROT_DONTCOPY itself: I'm queasy
 about protection flags which are not protection flags, though I find
 you're not the first to go down that road.

Yes. Compare with PROT_GROWSDOWN and such.

 Is the patch tested?  I've not tried, but suspect the newflags shift
 and mask won't work for it.

I tested this patch. I didnt test all thinkable configurations of
flags though - what do you mean by newflags shift and mask?

 And I don't look forward to your adding
 VM_MAYDONTCOPY - ugh!

We already have VM_DONTCOPY. Why would we need VM_MAYDONTCOPY and what
would it do?



  @@ -246,7 +246,7 @@ sys_mprotect(unsigned long start, size_t
  goto out;
  }
   
  -   newflags = vm_flags | (vma-vm_flags  ~(VM_READ | VM_WRITE | 
  VM_EXEC));
  +   newflags = vm_flags | (vma-vm_flags  ~(VM_READ | VM_WRITE | 
  VM_EXEC | VM_DONTCOPY));
   
  if ((newflags  ~(newflags  4))  0xf) {
  error = -EACCES;
 
 I rather think it would all be more cleanly handled by dropping the mmap
 and mprotect changes,

Well, mmap would be much better off if VM_DONTCOPY is set atomically, since
a process may fork after mmap is called but before madvise.

 adding an madvise instead.

I'm not opposed to this, on principle. But see below.

 Though you may object
 that madvise is for optional behaviours, and this should be mandatory.

What about a new system call?
Or a flag for mprotect that effectively turns it into a new system call?
Something like PROT_EXTENDED?

 The other reason I dislike the patch is that the problem it fixes is
 an old one, and I'd much rather have get_user_pages fix it for itself,

Please note that the problem this attempts to solve is not limited
to pages locked by get_user_pages: in an infiniband userspace initiator,
a hardware page is mapped into process memory and must not be inherited
by a child processes, otherwise hardware protection breaks.

 than ask the developer to do some additional magic to get around it.

 But I've failed to work out a simple efficient alternative, which won't
 burden the vast majority of get_user_pages usages which never hit the
 issue.

They dont hit it if they keep the mm semaphore, or if they only lock
pages for read.

 So your way is probably appropriate, but I'd prefer madvise.

The difficulty with changing get_user_pages, as I see it, is that
you wont be able to get away with a single DONTCOPY bit - you'll need
a full reference count for each page, no less.

 (Sorry, I won't be able to discuss further for a couple of days.)
 
 Hugh
 

Well, madvise currently cant break/merge VMAs, which is required
for VM_DONTCOPY. And it seems like making madvise do this opens
a whole cans of worms.

Hugh, so the patch is likely to be bigger in the madvise approach.
Considering this, and the fact that a full solution has to add
a flag to mmap, anyway, do you still think madvise is really the best way
to do it?


Regarding solving the problem automagically by get_user_pages:

What about a new VM_COPYONFORK flag, to trigger the old unix
behaviour of copying the vma on fork and a flag for get_user_pages that sets it?
Only users that dont keep the mm semaphore around
the get_user_pages/put_page operation would use this flag, others
would be unaffected. The flag will stay on until the VMA is destroyed.

MST


-- 
MST
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 linux-2.6-block:master 00/05] blk: generic dispatch queue

2005-07-26 Thread Tejun Heo
 Hello, Jens.

 This patchset implements generic dispatch queue.  The patches are
against the master head of linux-2.6-block tree.

 Changes from the first posting of this patchset are...

 * elevator_activate_req_fn is now called when the driver first sees
   the request (the first elv_next_request() of a request) not when
   the request is removed.  This makes iosched's accounting identical
   to before.  There should be no noticeable behavior change.
 * All ioscheds are updated
 * Doc update
 * Misc comment/code changes

 This patchset is composed of three parts.

 * Implementation of generic dispatch queue  updating individual
   elevators.
 * Move last_merge handling into generic elevator.
 * biodoc update

 Currently, each specific iosched maintains its own dispatch queue to
handle ordering, requeueing, cluster dispatching, etc...  This causes
the following problems.

 * duplicated codes
 * difficult to enforce semantics over dispatch queue (request
   ordering, requeueing, ...)
 * specific ioscheds have to deal with non-fs or ordered requests.

 With generic dispatch queue, specific ioscheds are guaranteed to be
handed only non-barrier fs requests, such that ioscheds only have to
implement ordering logic of normal fs requests.  Also, callback
invocation is stricter now.  Each fs request follows one of the
following paths.

 set_req_fn -

 i.   add_req_fn - (merged_fn -)* - dispatch_fn - activate_req_fn -
  (deactivate_req_fn - activate_req_fn -)* - completed_req_fn
 ii.  add_req_fn - (merged_fn -)* - merge_req_fn
 iii. [none]

 - put_req_fn

 Previously, elv_remove_request() and elv_completed_request() weren't
invoked for requests which are allocated outside blk layer (!rq-rl);
however, other elevator/iosched functions are called for such requests
making things a bit confusing.  As this patchset prevents non-fs
requests from going into specific ioscheds and removing the
inconsistency is necessary for implementation.  rq-rl tests in those
places are removed.

 With generic dispatch queue implemented, last_merge handling can be
moved into generic elevator proper.  The second part of this patchset
does that.  One problem this change introduces is that, noop iosched
loses its ability to merge requests (as no merging is allowed for
requests on a generic dispatch queue).  To add it back cleanly, we
need to make noop use a separate list instead of q-queue_head to keep
requests before dispatching.  I don't know how meaningful this would
be.  The change should be simple  easy.  If merging capability of
noop iosched is important, plz let me know.

[ Start of patch descriptions ]

01_blk_implement-generic-dispatch-queue.patch
: implement generic dispatch queue

Implements generic dispatch queue which can replace all
dispatch queues implemented by each iosched.  This reduces
code duplication, eases enforcing semantics over dispatch
queue, and simplifies specific ioscheds.

02_blk_generic-dispatch-queue-update-for-ioscheds.patch
: update ioscheds to use generic dispatch queue

This patch updates all four ioscheds to use generic dispatch
queue.  There's one behavior change in as-iosched.

* In as-iosched, when force dispatching
  (ELEVATOR_INSERT_BACK), batch_data_dir is reset to REQ_SYNC
  and changed_batch and new_batch are cleared to zero.  This
  prevernts AS from doing incorrect update_write_batch after
  the forced dispatched requests are finished.

03_blk_generic-last_merge-handling.patch
: move last_merge handling into generic elevator code

Currently, both generic elevator code and specific ioscheds
participate in the management and usage of last_merge.  This
and the following patches move last_merge handling into
generic elevator code.

04_blk_generic-last_merge-handling-update-for-ioscheds.patch
: remove last_merge handling from ioscheds

Remove last_merge handling from all ioscheds.  This patch
removes merging capability of noop iosched.

05_blk_update-biodoc.patch
: update biodoc

Updates biodoc to reflect changes in elevator API.

[ End of patch descriptions ]

 Thanks.

--
tejun

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


Re: [PATCH linux-2.6-block:master 01/05] blk: implement generic dispatch queue

2005-07-26 Thread Tejun Heo
01_blk_implement-generic-dispatch-queue.patch

Implements generic dispatch queue which can replace all
dispatch queues implemented by each iosched.  This reduces
code duplication, eases enforcing semantics over dispatch
queue, and simplifies specific ioscheds.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 drivers/block/elevator.c  |  242 --
 drivers/block/ll_rw_blk.c |   23 ++--
 include/linux/blkdev.h|   17 ++-
 include/linux/elevator.h  |   16 +--
 4 files changed, 201 insertions(+), 97 deletions(-)

Index: blk-fixes/drivers/block/elevator.c
===
--- blk-fixes.orig/drivers/block/elevator.c 2005-07-26 22:55:00.0 
+0900
+++ blk-fixes/drivers/block/elevator.c  2005-07-26 22:55:00.0 +0900
@@ -40,6 +40,11 @@
 static DEFINE_SPINLOCK(elv_list_lock);
 static LIST_HEAD(elv_list);
 
+static inline sector_t rq_last_sector(struct request *rq)
+{
+   return rq-sector + rq-nr_sectors;
+}
+
 /*
  * can we safely merge with this request?
  */
@@ -143,6 +148,9 @@ static int elevator_attach(request_queue
INIT_LIST_HEAD(q-queue_head);
q-last_merge = NULL;
q-elevator = eq;
+   q-last_sector = 0;
+   q-boundary_rq = NULL;
+   q-max_back_kb = 0;
 
if (eq-ops-elevator_init_fn)
ret = eq-ops-elevator_init_fn(q, eq);
@@ -225,6 +233,48 @@ void elevator_exit(elevator_t *e)
kfree(e);
 }
 
+/*
+ * Insert rq into dispatch queue of q.  Queue lock must be held on
+ * entry.  If sort != 0, rq is sort-inserted; otherwise, rq will be
+ * appended to the dispatch queue.  To be used by specific elevators.
+ */
+void elv_dispatch_insert(request_queue_t *q, struct request *rq, int sort)
+{
+   sector_t boundary;
+   unsigned max_back;
+   struct list_head *entry;
+
+   if (!sort) {
+   /* Specific elevator is performing sort.  Step away. */
+   q-last_sector = rq_last_sector(rq);
+   q-boundary_rq = rq;
+   list_add_tail(rq-queuelist, q-queue_head);
+   return;
+   }
+
+   boundary = q-last_sector;
+   max_back = q-max_back_kb * 2;
+   boundary = boundary  max_back ? boundary - max_back : 0;
+
+   list_for_each_prev(entry, q-queue_head) {
+   struct request *pos = list_entry_rq(entry);
+
+   if (pos-flags  (REQ_SOFTBARRIER|REQ_HARDBARRIER|REQ_STARTED))
+   break;
+   if (rq-sector = boundary) {
+   if (pos-sector  boundary)
+   continue;
+   } else {
+   if (pos-sector = boundary)
+   break;
+   }
+   if (rq-sector = pos-sector)
+   break;
+   }
+
+   list_add(rq-queuelist, entry);
+}
+
 int elv_merge(request_queue_t *q, struct request **req, struct bio *bio)
 {
elevator_t *e = q-elevator;
@@ -255,13 +305,7 @@ void elv_merge_requests(request_queue_t 
e-ops-elevator_merge_req_fn(q, rq, next);
 }
 
-/*
- * For careful internal use by the block layer. Essentially the same as
- * a requeue in that it tells the io scheduler that this request is not
- * active in the driver or hardware anymore, but we don't want the request
- * added back to the scheduler. Function is not exported.
- */
-void elv_deactivate_request(request_queue_t *q, struct request *rq)
+void elv_requeue_request(request_queue_t *q, struct request *rq)
 {
elevator_t *e = q-elevator;
 
@@ -269,19 +313,14 @@ void elv_deactivate_request(request_queu
 * it already went through dequeue, we need to decrement the
 * in_flight count again
 */
-   if (blk_account_rq(rq))
+   if (blk_account_rq(rq)) {
q-in_flight--;
+   if (blk_sorted_rq(rq)  e-ops-elevator_deactivate_req_fn)
+   e-ops-elevator_deactivate_req_fn(q, rq);
+   }
 
rq-flags = ~REQ_STARTED;
 
-   if (e-ops-elevator_deactivate_req_fn)
-   e-ops-elevator_deactivate_req_fn(q, rq);
-}
-
-void elv_requeue_request(request_queue_t *q, struct request *rq)
-{
-   elv_deactivate_request(q, rq);
-
/*
 * if this is the flush, requeue the original instead and drop the flush
 */
@@ -290,55 +329,89 @@ void elv_requeue_request(request_queue_t
rq = rq-end_io_data;
}
 
-   /*
-* the request is prepped and may have some resources allocated.
-* allowing unprepped requests to pass this one may cause resource
-* deadlock.  turn on softbarrier.
-*/
-   rq-flags |= REQ_SOFTBARRIER;
-
-   /*
-* if iosched has an explicit requeue hook, then use that. otherwise
-* just put the request at the front of the queue
-*/
-   if (q-elevator-ops-elevator_requeue_req_fn)

Re: [PATCH linux-2.6-block:master 04/05] blk: remove last_merge handling from ioscheds

2005-07-26 Thread Tejun Heo
04_blk_generic-last_merge-handling-update-for-ioscheds.patch

Remove last_merge handling from all ioscheds.  This patch
removes merging capability of noop iosched.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 as-iosched.c   |   35 ---
 cfq-iosched.c  |   19 +--
 deadline-iosched.c |   30 ++
 noop-iosched.c |   31 ---
 4 files changed, 7 insertions(+), 108 deletions(-)

Index: blk-fixes/drivers/block/as-iosched.c
===
--- blk-fixes.orig/drivers/block/as-iosched.c   2005-07-26 22:55:00.0 
+0900
+++ blk-fixes/drivers/block/as-iosched.c2005-07-26 22:55:01.0 
+0900
@@ -279,14 +279,6 @@ static inline void as_del_arq_hash(struc
__as_del_arq_hash(arq);
 }
 
-static void as_remove_merge_hints(request_queue_t *q, struct as_rq *arq)
-{
-   as_del_arq_hash(arq);
-
-   if (q-last_merge == arq-request)
-   q-last_merge = NULL;
-}
-
 static void as_add_arq_hash(struct as_data *ad, struct as_rq *arq)
 {
struct request *rq = arq-request;
@@ -330,7 +322,7 @@ static struct request *as_find_arq_hash(
BUG_ON(!arq-on_hash);
 
if (!rq_mergeable(__rq)) {
-   as_remove_merge_hints(ad-q, arq);
+   as_del_arq_hash(arq);
continue;
}
 
@@ -1040,7 +1032,7 @@ static void as_remove_queued_request(req
ad-next_arq[data_dir] = as_find_next_arq(ad, arq);
 
list_del_init(arq-fifo);
-   as_remove_merge_hints(q, arq);
+   as_del_arq_hash(arq);
as_del_arq_rb(ad, arq);
 }
 
@@ -1351,7 +1343,7 @@ as_add_aliased_request(struct as_data *a
/*
 * Don't want to have to handle merges.
 */
-   as_remove_merge_hints(ad-q, arq);
+   as_del_arq_hash(arq);
 }
 
 /*
@@ -1392,12 +1384,8 @@ static void as_add_request(request_queue
arq-expires = jiffies + ad-fifo_expire[data_dir];
list_add_tail(arq-fifo, ad-fifo_list[data_dir]);
 
-   if (rq_mergeable(arq-request)) {
+   if (rq_mergeable(arq-request))
as_add_arq_hash(ad, arq);
-
-   if (!ad-q-last_merge)
-   ad-q-last_merge = arq-request;
-   }
as_update_arq(ad, arq); /* keep state machine up to date */
 
} else {
@@ -1487,15 +1475,6 @@ as_merge(request_queue_t *q, struct requ
int ret;
 
/*
-* try last_merge to avoid going to hash
-*/
-   ret = elv_try_last_merge(q, bio);
-   if (ret != ELEVATOR_NO_MERGE) {
-   __rq = q-last_merge;
-   goto out_insert;
-   }
-
-   /*
 * see if the merge hash can satisfy a back merge
 */
__rq = as_find_arq_hash(ad, bio-bi_sector);
@@ -1523,9 +1502,6 @@ as_merge(request_queue_t *q, struct requ
 
return ELEVATOR_NO_MERGE;
 out:
-   if (rq_mergeable(__rq))
-   q-last_merge = __rq;
-out_insert:
if (ret) {
if (rq_mergeable(__rq))
as_hot_arq_hash(ad, RQ_DATA(__rq));
@@ -1572,9 +1548,6 @@ static void as_merged_request(request_qu
 * behind the disk head. We currently don't bother adjusting.
 */
}
-
-   if (arq-on_hash)
-   q-last_merge = req;
 }
 
 static void
Index: blk-fixes/drivers/block/cfq-iosched.c
===
--- blk-fixes.orig/drivers/block/cfq-iosched.c  2005-07-26 22:55:00.0 
+0900
+++ blk-fixes/drivers/block/cfq-iosched.c   2005-07-26 22:55:01.0 
+0900
@@ -648,8 +648,6 @@ static void cfq_remove_request(struct re
list_del_init(rq-queuelist);
cfq_del_crq_rb(crq);
cfq_del_crq_hash(crq);
-   if (rq-q-last_merge == crq-request)
-   rq-q-last_merge = NULL;
 }
 
 static int
@@ -659,12 +657,6 @@ cfq_merge(request_queue_t *q, struct req
struct request *__rq;
int ret;
 
-   ret = elv_try_last_merge(q, bio);
-   if (ret != ELEVATOR_NO_MERGE) {
-   __rq = q-last_merge;
-   goto out_insert;
-   }
-
__rq = cfq_find_rq_hash(cfqd, bio-bi_sector);
if (__rq) {
BUG_ON(__rq-sector + __rq-nr_sectors != bio-bi_sector);
@@ -685,8 +677,6 @@ cfq_merge(request_queue_t *q, struct req
 
return ELEVATOR_NO_MERGE;
 out:
-   q-last_merge = __rq;
-out_insert:
*req = __rq;
return ret;
 }
@@ -705,8 +695,6 @@ static void cfq_merged_request(request_q
cfq_update_next_crq(crq);
cfq_reposition_crq_rb(cfqq, crq);
}
-
-   q-last_merge = req;
 }
 
 static void
@@ -1127,12 +1115,8 @@ cfq_insert_request(request_queue_t *q, s
 
  

Re: [PATCH linux-2.6-block:master 03/05] blk: move last_merge handling into generic elevator code

2005-07-26 Thread Tejun Heo
03_blk_generic-last_merge-handling.patch

Currently, both generic elevator code and specific ioscheds
participate in the management and usage of last_merge.  This
and the following patches move last_merge handling into
generic elevator code.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 elevator.c |   43 ++-
 1 files changed, 18 insertions(+), 25 deletions(-)

Index: blk-fixes/drivers/block/elevator.c
===
--- blk-fixes.orig/drivers/block/elevator.c 2005-07-26 22:55:00.0 
+0900
+++ blk-fixes/drivers/block/elevator.c  2005-07-26 22:55:00.0 +0900
@@ -88,15 +88,6 @@ inline int elv_try_merge(struct request 
 }
 EXPORT_SYMBOL(elv_try_merge);
 
-inline int elv_try_last_merge(request_queue_t *q, struct bio *bio)
-{
-   if (q-last_merge)
-   return elv_try_merge(q-last_merge, bio);
-
-   return ELEVATOR_NO_MERGE;
-}
-EXPORT_SYMBOL(elv_try_last_merge);
-
 static struct elevator_type *elevator_find(const char *name)
 {
struct elevator_type *e = NULL;
@@ -244,6 +235,9 @@ void elv_dispatch_insert(request_queue_t
unsigned max_back;
struct list_head *entry;
 
+   if (q-last_merge == rq)
+   q-last_merge = NULL;
+
if (!sort) {
/* Specific elevator is performing sort.  Step away. */
q-last_sector = rq_last_sector(rq);
@@ -278,6 +272,15 @@ void elv_dispatch_insert(request_queue_t
 int elv_merge(request_queue_t *q, struct request **req, struct bio *bio)
 {
elevator_t *e = q-elevator;
+   int ret;
+
+   if (q-last_merge) {
+   ret = elv_try_merge(q-last_merge, bio);
+   if (ret != ELEVATOR_NO_MERGE) {
+   *req = q-last_merge;
+   return ret;
+   }
+   }
 
if (e-ops-elevator_merge_fn)
return e-ops-elevator_merge_fn(q, req, bio);
@@ -291,6 +294,8 @@ void elv_merged_request(request_queue_t 
 
if (e-ops-elevator_merged_fn)
e-ops-elevator_merged_fn(q, rq);
+
+   q-last_merge = rq;
 }
 
 void elv_merge_requests(request_queue_t *q, struct request *rq,
@@ -298,11 +303,10 @@ void elv_merge_requests(request_queue_t 
 {
elevator_t *e = q-elevator;
 
-   if (q-last_merge == next)
-   q-last_merge = NULL;
-
if (e-ops-elevator_merge_req_fn)
e-ops-elevator_merge_req_fn(q, rq, next);
+
+   q-last_merge = rq;
 }
 
 void elv_requeue_request(request_queue_t *q, struct request *rq)
@@ -397,6 +401,8 @@ void __elv_add_request(request_queue_t *
BUG_ON(!blk_fs_request(rq));
rq-flags |= REQ_SORTED;
q-elevator-ops-elevator_add_req_fn(q, rq);
+   if (q-last_merge == NULL  rq_mergeable(rq))
+   q-last_merge = rq;
break;
 
default:
@@ -475,9 +481,6 @@ struct request *elv_next_request(request
rq-flags |= REQ_STARTED;
}
 
-   if (rq == q-last_merge)
-   q-last_merge = NULL;
-
if (!q-boundary_rq || q-boundary_rq == rq) {
q-last_sector = rq_last_sector(rq);
q-boundary_rq = NULL;
@@ -531,16 +534,6 @@ void elv_dequeue_request(request_queue_t
 */
if (blk_account_rq(rq))
q-in_flight++;
-
-   /*
-* the main clearing point for q-last_merge is on retrieval of
-* request by driver (it calls elv_next_request()), but it _can_
-* also happen here if a request is added to the queue but later
-* deleted without ever being given to driver (merged with another
-* request).
-*/
-   if (rq == q-last_merge)
-   q-last_merge = NULL;
 }
 
 int elv_queue_empty(request_queue_t *q)

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 linux-2.6-block:master 02/05] blk: update ioscheds to use generic dispatch queue

2005-07-26 Thread Tejun Heo
02_blk_generic-dispatch-queue-update-for-ioscheds.patch

This patch updates all four ioscheds to use generic dispatch
queue.  There's one behavior change in as-iosched.

* In as-iosched, when force dispatching
  (ELEVATOR_INSERT_BACK), batch_data_dir is reset to REQ_SYNC
  and changed_batch and new_batch are cleared to zero.  This
  prevernts AS from doing incorrect update_write_batch after
  the forced dispatched requests are finished.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 as-iosched.c   |  294 ---
 cfq-iosched.c  |  358 -
 deadline-iosched.c |   95 ++
 noop-iosched.c |   17 --
 4 files changed, 218 insertions(+), 546 deletions(-)

Index: blk-fixes/drivers/block/as-iosched.c
===
--- blk-fixes.orig/drivers/block/as-iosched.c   2005-07-26 22:54:59.0 
+0900
+++ blk-fixes/drivers/block/as-iosched.c2005-07-26 22:55:00.0 
+0900
@@ -98,7 +98,6 @@ struct as_data {
 
struct as_rq *next_arq[2];  /* next in sort order */
sector_t last_sector[2];/* last REQ_SYNC  REQ_ASYNC sectors */
-   struct list_head *dispatch; /* driver dispatch queue */
struct list_head *hash; /* request hash */
 
unsigned long exit_prob;/* probability a task will exit while
@@ -239,6 +238,25 @@ static struct io_context *as_get_io_cont
return ioc;
 }
 
+static void as_put_io_context(struct as_rq *arq)
+{
+   struct as_io_context *aic;
+
+   if (unlikely(!arq-io_context))
+   return;
+
+   aic = arq-io_context-aic;
+
+   if (arq-is_sync == REQ_SYNC  aic) {
+   spin_lock(aic-lock);
+   set_bit(AS_TASK_IORUNNING, aic-state);
+   aic-last_end_request = jiffies;
+   spin_unlock(aic-lock);
+   }
+
+   put_io_context(arq-io_context);
+}
+
 /*
  * the back merge hash support functions
  */
@@ -950,23 +968,12 @@ static void as_completed_request(request
 
WARN_ON(!list_empty(rq-queuelist));
 
-   if (arq-state == AS_RQ_PRESCHED) {
-   WARN_ON(arq-io_context);
-   goto out;
-   }
-
-   if (arq-state == AS_RQ_MERGED)
-   goto out_ioc;
-
if (arq-state != AS_RQ_REMOVED) {
printk(arq-state %d\n, arq-state);
WARN_ON(1);
goto out;
}
 
-   if (!blk_fs_request(rq))
-   goto out;
-
if (ad-changed_batch  ad-nr_dispatched == 1) {
kblockd_schedule_work(ad-antic_work);
ad-changed_batch = 0;
@@ -1001,21 +1008,7 @@ static void as_completed_request(request
}
}
 
-out_ioc:
-   if (!arq-io_context)
-   goto out;
-
-   if (arq-is_sync == REQ_SYNC) {
-   struct as_io_context *aic = arq-io_context-aic;
-   if (aic) {
-   spin_lock(aic-lock);
-   set_bit(AS_TASK_IORUNNING, aic-state);
-   aic-last_end_request = jiffies;
-   spin_unlock(aic-lock);
-   }
-   }
-
-   put_io_context(arq-io_context);
+   as_put_io_context(arq);
 out:
arq-state = AS_RQ_POSTSCHED;
 }
@@ -1052,68 +1045,6 @@ static void as_remove_queued_request(req
 }
 
 /*
- * as_remove_dispatched_request is called to remove a request which has gone
- * to the dispatch list.
- */
-static void as_remove_dispatched_request(request_queue_t *q, struct request 
*rq)
-{
-   struct as_rq *arq = RQ_DATA(rq);
-   struct as_io_context *aic;
-
-   if (!arq) {
-   WARN_ON(1);
-   return;
-   }
-
-   WARN_ON(arq-state != AS_RQ_DISPATCHED);
-   WARN_ON(ON_RB(arq-rb_node));
-   if (arq-io_context  arq-io_context-aic) {
-   aic = arq-io_context-aic;
-   if (aic) {
-   WARN_ON(!atomic_read(aic-nr_dispatched));
-   atomic_dec(aic-nr_dispatched);
-   }
-   }
-}
-
-/*
- * as_remove_request is called when a driver has finished with a request.
- * This should be only called for dispatched requests, but for some reason
- * a POWER4 box running hwscan it does not.
- */
-static void as_remove_request(request_queue_t *q, struct request *rq)
-{
-   struct as_rq *arq = RQ_DATA(rq);
-
-   if (unlikely(arq-state == AS_RQ_NEW))
-   goto out;
-
-   if (ON_RB(arq-rb_node)) {
-   if (arq-state != AS_RQ_QUEUED) {
-   printk(arq-state %d\n, arq-state);
-   WARN_ON(1);
-   goto out;
-   }
-   /*
-* We'll lose the aliased request(s) here. I don't think this
-* will ever happen, but if it does, hopefully 

Re: [PATCH linux-2.6-block:master 05/05] blk: update biodoc

2005-07-26 Thread Tejun Heo
05_blk_update-biodoc.patch

Updates biodoc to reflect changes in elevator API.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 biodoc.txt |  113 -
 1 files changed, 52 insertions(+), 61 deletions(-)

Index: blk-fixes/Documentation/block/biodoc.txt
===
--- blk-fixes.orig/Documentation/block/biodoc.txt   2005-07-26 
22:54:59.0 +0900
+++ blk-fixes/Documentation/block/biodoc.txt2005-07-26 22:55:01.0 
+0900
@@ -906,9 +906,20 @@ Aside:
 
 
 4. The I/O scheduler
-I/O schedulers are now per queue. They should be runtime switchable and modular
-but aren't yet. Jens has most bits to do this, but the sysfs implementation is
-missing.
+I/O scheduler, a.k.a. elevator, is implemented in two layers.  Generic dispatch
+queue and specific I/O schedulers.  Unless stated otherwise, elevator is used
+to refer to both parts and I/O scheduler to specific I/O schedulers.
+
+Block layer implements generic dispatch queue in ll_rw_blk.c and elevator.c.
+The generic dispatch queue is responsible for properly ordering barrier
+requests, requeueing, handling non-fs requests and all other subtleties.
+
+Specific I/O schedulers are responsible for ordering normal filesystem
+requests.  They can also choose to delay certain requests to improve
+throughput or whatever purpose.  As the plural form indicates, there are
+multiple I/O schedulers.  They can be built as modules but at least one should
+be built inside the kernel.  Each queue can choose different one and can also
+change to another one dynamically.
 
 A block layer call to the i/o scheduler follows the convention elv_xxx(). This
 calls elevator_xxx_fn in the elevator switch (drivers/block/elevator.c). Oh,
@@ -921,44 +932,36 @@ keeping work.
 The functions an elevator may implement are: (* are mandatory)
 elevator_merge_fn  called to query requests for merge with a bio
 
-elevator_merge_req_fn  with another request
+elevator_merge_req_fn  called when two requests get merged. the one
+   which gets merged into the other one will be
+   never seen by I/O scheduler again. IOW, after
+   being merged, the request is gone.
 
 elevator_merged_fn called when a request in the scheduler has been
involved in a merge. It is used in the deadline
scheduler for example, to reposition the request
if its sorting order has changed.
 
-*elevator_next_req_fn  returns the next scheduled request, or NULL
-   if there are none (or none are ready).
+elevator_dispatch_fn   fills the dispatch queue with ready requests.
+   I/O schedulers are free to postpone requests by
+   not filling the dispatch queue unless @force
+   is non-zero.  Once dispatched, I/O schedulers
+   are not allowed to manipulate the requests -
+   they belong to generic dispatch queue.
 
-*elevator_add_req_fn   called to add a new request into the scheduler
+elevator_add_req_fncalled to add a new request into the scheduler
 
 elevator_queue_empty_fnreturns true if the merge queue is 
empty.
Drivers shouldn't use this, but rather check
if elv_next_request is NULL (without losing the
request if one exists!)
 
-elevator_remove_req_fn This is called when a driver claims ownership of
-   the target request - it now belongs to the
-   driver. It must not be modified or merged.
-   Drivers must not lose the request! A subsequent
-   call of elevator_next_req_fn must  return the
-   _next_ request.
-
-elevator_requeue_req_fncalled to add a request to the 
scheduler. This
-   is used when the request has alrnadebeen
-   returned by elv_next_request, but hasn't
-   completed. If this is not implemented then
-   elevator_add_req_fn is called instead.
-
 elevator_former_req_fn
 elevator_latter_req_fn These return the request before or after the
one specified in disk sort order. Used by the
block layer to find merge possibilities.
 
-elevator_completed_req_fn  called when a request is completed. This might
-   come about due to being merged with another or
-   

Re: Fw: Oops in hidinput_hid_event

2005-07-26 Thread Sergey Vlasov
On Tue, 19 Jul 2005 09:30:58 -0400 Vojtech Pavlik wrote:

 On Mon, Jul 18, 2005 at 02:16:37PM -0700, Pete Zaitcev wrote:
 
  I think this patch is rather obvious, so maybe I should ask Andrew to
  apply it to -mm for now, to get some testing. Would that help to verify
  it for acceptance?
 
 Your patch is perfectly OK, my NULL check was indeed completely wrong.
 
 I need to find out how there can be an input event happening without its
 associated input structure, though, since the oops actually reveals a
 deeper problem.

hidinput_connect() does:

for (k = HID_INPUT_REPORT; k = HID_OUTPUT_REPORT; k++)
... loop which calls hidinput_configure_usage(),
which initializes report-hidinput pointers ...

So -hidinput is getting set only for fields of input and output
reports, but the device may also support feature reports, and for their
fields -hidinput will remain NULL.  When such report is requested with
hid_submit_report(hid, report, USB_DIR_IN), the completed urb will be
handled by hid_ctrl(), which will call hid_input_report() for it; this
corresponds to the traceback in oops.

BTW, the driver requests all feature reports during initialization (in
hid_init_reports()), but it does not oops there, because
hidinput_connect() is called only later, and therefore HID_CLAIMED_INPUT
is not yet set.

However, I still don't understand where hid_submit_report() gets called
for a feature report in the reported case (hidinput_input_event() can
submit only output reports, and a call from hiddev is unlikely to be
triggered by a NumLock press).

 So that's why I didn't apply the patch yet.
 
  Begin forwarded message:
  
  Date: Tue, 28 Jun 2005 15:00:23 -0700
  From: Pete Zaitcev [EMAIL PROTECTED]
  To: [EMAIL PROTECTED]
  Cc: [EMAIL PROTECTED], linux-usb-devel@lists.sourceforge.net
  Subject: Oops in hidinput_hid_event
  
  Hi, Vojtech:
  
  Someone reported a bug in Fedora, which runs a largely unmodified upstream
  kernel in this area. Whenever the user hits a key which switches LED,
  the system oopses. Here's a trace:
  
  Unable to handle kernel NULL pointer dereference at virtual address 00c8
  EFLAGS: 00010006   (2.6.11-1.1369_FC4smp)
  EIP is at hidinput_hid_event+0x2d/0x292 

  Call Trace:   
   [c02872e0] hid_process_event+0x57/0x5f
   [c028758a] hid_input_field+0x2a2/0x2ac
   [c0287632] hid_input_report+0x9e/0xb8
   [c0287f62] hid_ctrl+0x14c/0x151
   [e0a21060] uhci_destroy_urb_priv+0xb5/0x10a [uhci_hcd]
   [c027dab5] usb_hcd_giveback_urb+0x24/0x67
   [e0a22360] uhci_finish_urb+0x2d/0x38 [uhci_hcd]
   [e0a223af] uhci_finish_completion+0x44/0x56 [uhci_hcd]
   [e0a224a2] uhci_scan_schedule+0xaa/0x13a [uhci_hcd]
   [c023413d] i8042_interrupt+0x121/0x234
   [e0a226d0] uhci_irq+0x47/0x10d [uhci_hcd]
  
  Full trace at
   https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=160709
  
  Any ideas?
  
  By the way, it seems that I see a bug in hidinput_hid_event.
  The check for NULL can never work, becaue hidinput-input
  is nonzero at all times. How about this?
  
  --- linux-2.6.12/drivers/usb/input/hid-input.c  2005-06-21 
  12:58:47.0 -0700
  +++ linux-2.6.12-lem/drivers/usb/input/hid-input.c  2005-06-28 
  14:57:22.0 -0700
  @@ -397,11 +397,12 @@
   
   void hidinput_hid_event(struct hid_device *hid, struct hid_field *field, 
  struct hid_usage *usage, __s32 value, struct pt_regs *regs)
   {
  -   struct input_dev *input = field-hidinput-input;
  +   struct input_dev *input;
  int *quirks = hid-quirks;
   
  -   if (!input)
  +   if (!field-hidinput)
  return;
  +   input = field-hidinput-input;
   
  input_regs(input, regs);
   
  
  -- Pete
  
 
 -- 
 Vojtech Pavlik
 SuSE Labs, SuSE CR


pgpnei1ldC3Fg.pgp
Description: PGP signature


[PATCH linux-2.6-block:master] reimplement elevator switch

2005-07-26 Thread Tejun Heo
 Hello, Jens.

 This patch reimplements elevator switch.  This patch assumes generic
dispatch queue patchset is applied.

 * Each request is tagged with REQ_ELVPRIV flag if it has its elevator
   private data set.
 * Requests which doesn't have REQ_ELVPRIV flag set never enter
   iosched.  They are always directly back inserted to dispatch queue.
   Of course, elevator_put_req_fn is called only for requests which
   have its REQ_ELVPRIV set.
 * Request queue maintains the current number of requests which have
   its elevator data set (elevator_set_req_fn called) in
   q-rq-elvpriv.
 * If a request queue has QUEUE_FLAG_BYPASS set, elevator private data
   is not allocated for new requests.

 To switch to another iosched, we set QUEUE_FLAG_BYPASS and wait until
elvpriv goes to zero; then, we attach the new iosched and clears
QUEUE_FLAG_BYPASS.  New implementation is much simpler and main code
paths are less cluttered, IMHO.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

Index: blk-fixes/drivers/block/elevator.c
===
--- blk-fixes.orig/drivers/block/elevator.c 2005-07-26 15:33:54.0 
+0900
+++ blk-fixes/drivers/block/elevator.c  2005-07-26 15:34:00.0 +0900
@@ -34,6 +34,7 @@
 #include linux/slab.h
 #include linux/init.h
 #include linux/compiler.h
+#include linux/delay.h
 
 #include asm/uaccess.h
 
@@ -135,13 +136,7 @@ static int elevator_attach(request_queue
memset(eq, 0, sizeof(*eq));
eq-ops = e-ops;
eq-elevator_type = e;
-
-   INIT_LIST_HEAD(q-queue_head);
-   q-last_merge = NULL;
q-elevator = eq;
-   q-last_sector = 0;
-   q-boundary_rq = NULL;
-   q-max_back_kb = 0;
 
if (eq-ops-elevator_init_fn)
ret = eq-ops-elevator_init_fn(q, eq);
@@ -190,6 +185,12 @@ int elevator_init(request_queue_t *q, ch
struct elevator_queue *eq;
int ret = 0;
 
+   INIT_LIST_HEAD(q-queue_head);
+   q-last_merge = NULL;
+   q-last_sector = 0;
+   q-boundary_rq = NULL;
+   q-max_back_kb = 0;
+
elevator_setup_default();
 
if (!name)
@@ -353,23 +354,14 @@ void __elv_add_request(request_queue_t *
q-last_sector = rq_last_sector(rq);
q-boundary_rq = rq;
}
-   }
+   } else if (!(rq-flags  REQ_ELVPRIV)  where == ELEVATOR_INSERT_SORT)
+   where = ELEVATOR_INSERT_BACK;
 
if (plug)
blk_plug_device(q);
 
rq-q = q;
 
-   if (unlikely(test_bit(QUEUE_FLAG_DRAIN, q-queue_flags))) {
-   /*
-* if drain is set, store the request locally. when the drain
-* is finished, the requests will be handed ordered to the io
-* scheduler
-*/
-   list_add_tail(rq-queuelist, q-drain_list);
-   return;
-   }
-
switch (where) {
case ELEVATOR_INSERT_FRONT:
rq-flags |= REQ_SOFTBARRIER;
@@ -675,25 +667,36 @@ EXPORT_SYMBOL_GPL(elv_unregister);
  * switch to new_e io scheduler. be careful not to introduce deadlocks -
  * we don't free the old io scheduler, before we have allocated what we
  * need for the new one. this way we have a chance of going back to the old
- * one, if the new one fails init for some reason. we also do an intermediate
- * switch to noop to ensure safety with stack-allocated requests, since they
- * don't originate from the block layer allocator. noop is safe here, because
- * it never needs to touch the elevator itself for completion events. DRAIN
- * flags will make sure we don't touch it for additions either.
+ * one, if the new one fails init for some reason.
  */
 static void elevator_switch(request_queue_t *q, struct elevator_type *new_e)
 {
-   elevator_t *e = kmalloc(sizeof(elevator_t), GFP_KERNEL);
-   struct elevator_type *noop_elevator = NULL;
-   elevator_t *old_elevator;
+   elevator_t *old_elevator, *e;
 
+   /*
+* Allocate new elevator
+*/
+   e = kmalloc(sizeof(elevator_t), GFP_KERNEL);
if (!e)
goto error;
 
/*
-* first step, drain requests from the block freelist
+* Turn on BYPASS and drain all requests w/ elevator private data
 */
-   blk_wait_queue_drained(q, 0);
+   spin_lock_irq(q-queue_lock);
+
+   set_bit(QUEUE_FLAG_BYPASS, q-queue_flags);
+
+   while (q-elevator-ops-elevator_dispatch_fn(q, 1))
+   ;
+
+   while (q-rq.elvpriv) {
+   spin_unlock_irq(q-queue_lock);
+   msleep(100);
+   spin_lock_irq(q-queue_lock);
+   }
+
+   spin_unlock_irq(q-queue_lock);
 
/*
 * unregister old elevator data
@@ -702,18 +705,6 @@ static void elevator_switch(request_queu
old_elevator = q-elevator;
 
/*
-* next step, switch to noop since it uses no private rq structures
-* 

Re: Problem with Asus P4C800-DX and P4 -Northwood-

2005-07-26 Thread Bill Davidsen

Andreas Baer wrote:




Bill Davidsen wrote:



One other oddment about this motherboard, Forgive if I have 
over-snipped this trying to make it relevant...


Andreas Baer wrote:



Willy Tarreau wrote:


On Mon, Jul 25, 2005 at 03:10:08PM +0200, Andreas Baer wrote:





There clearly is a problem on the system installed on this machine. 
You should
use strace to see what this machine does all the time, it is 
absolutely not

expected that the user/system ratios change so much between two nearly
identical systems. So there are system calls which eat all CPU. You 
may want
to try strace -Tttt on the running process during a few tens of 
seconds. I
guess you'll immediately find the culprit amongst the syscalls, and 
it might

give you a clue.





I hope you are talking about a hardware/kernel problem and not a 
software
problem, because I tried it also with LiveCD's and they showed the 
same results

on this machine.
I'm not a linux expert, that means I've never done anything like 
that before,
so it would be nice if you give me a hint what you see in this 
results. :)




Am I misreading this, or is your program doing a bunch of seeks not 
followed by an i/o operation? I would doubt that's important, but 
your vmstat showed a lot of system time, and I just wonder if 
llseek() is more expensive in Linux than Windows. Or if your code is 
such that these calls are not optimized away by gcc.



I don't know what exactly produces this _llseek calls, but I ran the 
compiled binaries on both machines (desktop + notebook) without any 
recompilation and so I think they should do the same (even if this is 
bad or not optimized), but I see a time difference of more than 2:30 
:) This _llseek calls also don't seem to be faster or slower if you 
compare the times on the notebook and the desktop. 



If the program and test data is not proprietary, would it help to have 
me run the test on my P4P800, P4-2.8, HT on, and see if that's an issue 
with your particular board or BIOS? I have the 1086 BIOS from my notes 
on that machine, I think you were running a later BIOS? 1091 or so, from 
memory?


Anyway, I would run a test that takes 3 minutes if it helps as a data point.

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

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


Re: [PATCH] 2.6.13rc3: RLIMIT_RTPRIO broken

2005-07-26 Thread Lee Revell
On Tue, 2005-07-26 at 14:06 +0200, Ingo Molnar wrote:
 i'd not put it into stable just yet - the fact that it has not been 
 tested in 2.6.12 _at all_ up until very recently means there's little
 QA feedback. Yes, it's simple, but it also triggers something we never
 did before. 2.6.13 ought to be released soon, that should be good
 enough.

Also, no distro is shipping the updated PAM, glibc, and bash packages
needed to use the new feature yet, even in their development releases.
So there would be very little point in putting this in -stable.

Lee

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


Re: [PATCH] Re: itimer oddness in 2.6.12

2005-07-26 Thread George Anzinger

Andrew Morton wrote:

George Anzinger george@mvista.com wrote:


+   while (time_before_eq(p-signal-real_timer.expires, jiffies))
+   p-signal-real_timer.expires += inc;



It gives me the creeps when I see timer code doing this, and it seems to be
done relatively frequently.

Surely it can be calculated arithmetically?  If not, are you really sure
that it is not exploitable by malicious code?


Hm.. the system only falls into a loop here if the system is loaded to 
the point where we are a jiffie or more late.  The prior code just did 
the += and called add_timer, possibly with a time in the past.  I 
suspect that way of doing this would never catch up if the user asked 
for a one jiffie repeat time.  Also, this is faster than the div, mpy if 
you are not late (or even if you are several jiffies late).


A possible alternative might be:
p-signal-real_timer.expires += inc; 
if (time_before_eq(p-signal-real_timer.expires, jiffies))
		p-signal-real_timer.expires += ((jiffies - 
p-signal-real_timer.expires + inc -1) / inc) * inc;


Both a div and a mpy in there.  I really think the while is ok, but if 
you prefer...	


The last time you questioned this sort of thing was in the code to 
correct an absolute timer.  In that case we were adjusting after a clock 
set and, yes, it was possibly exploitable (assuming you could set the 
clock).  Here we don't have that possibility, i.e. we only get into the 
loop if the system is late.

-

--
George Anzinger   george@mvista.com
HRT (High-res-timers):  http://sourceforge.net/projects/high-res-timers/
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.12 PREEMPT_RT PPC

2005-07-26 Thread K.R. Foley

Ingo Molnar wrote:

* john cooper [EMAIL PROTECTED] wrote:



Ingo,
   Attached is a patch for 51-28 which brings PPC up to date for 
2.6.12 PREEMPT_RT.  My goal was to get a more recent vintage of this 
work building and minimally booting for PPC.  Yet this has been stable 
even under our internal stress tests.  We now have this running on 
8560 and 8260 PPC targets with a few others in the pipe.



great. I've applied most of your patch and have released the -51-37 
kernel. A couple of generic bits i did not apply.




snip

On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached patch.


--
   kr
--- linux-2.6.12/drivers/char/blocker.c.orig	2005-07-26 09:32:28.0 -0500
+++ linux-2.6.12/drivers/char/blocker.c	2005-07-26 09:32:33.0 -0500
@@ -4,7 +4,6 @@
 
 #include linux/fs.h
 #include linux/miscdevice.h
-#include asm/time.h
 
 #define BLOCKER_MINOR		221
 


Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

2005-07-26 Thread Bill Davidsen

Brown, Len wrote:
 


Digging up this patch from last month regarding C2
on a AMD K7 implies
that the whole blame can be put on kernel acpi:

http://marc.theaimsgroup.com/?l=linux-kernelm=111933745131301w=2



The current Linus tree includes generic ACPI support
for deep C-states on SMP machines. (deep means higher than C1)

I don't have any problem with people having platform specific
modules to handle platform specific features.  However, if
the system really intends to support SMP ACPI C-states deeper
than C1 and the generic ACPI code doesn't support it,
then it is either a Linux/ACPI bug or a BIOS bug -- file away:-)

I.e. The whole concept of ACPI is that you shoulud _not_ need
a platform specific driver to accomplish this.


Is anyone but me interested in low power states for servers? I have 
several groups of servers which are lightly utilized for at least 12 
hours every day and on weekends. I currently use IDE drives so I can 
spin them down when idle, do logging either to a single drive or over 
the network whichever makes the most sense, and any drop in power use 
saves double, since I pay for the server power and the A/C power as well.


I haven't seen much discussion of this, but in many cases it would 
result in a saving, perhaps fairly large. Some environmental benefit as 
well, of course.


--
   -bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
 last possible moment - but no longer  -me
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] remove sound/oss/skeleton.c

2005-07-26 Thread Adrian Bunk
We do no longer need a template for OSS drivers.


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

---

 sound/oss/skeleton.c |  219 ---
 1 files changed, 219 deletions(-)

--- linux-2.6.13-rc3-mm1-full/sound/oss/skeleton.c  2005-06-17 
21:48:29.0 +0200
+++ /dev/null   2005-04-28 03:52:17.0 +0200
@@ -1,219 +0,0 @@
-/*
- * PCI sound skeleton example
- *
- * (c) 1998 Red Hat Software
- *
- * This software may be used and distributed according to the 
- * terms of the GNU General Public License, incorporated herein by 
- * reference.
- *
- * This example is designed to be built in the linux/drivers/sound
- * directory as part of a kernel build. The example is modular only
- * drop me a note once you have a working modular driver and want
- * to integrate it with the main code.
- * -- Alan [EMAIL PROTECTED]
- *
- * This is a first draft. Please report any errors, corrections or
- * improvements to me.
- */
-
-#include linux/module.h
-#include linux/delay.h
-#include linux/errno.h
-#include linux/fs.h
-#include linux/kernel.h
-#include linux/pci.h
-
-#include asm/io.h
-
-#include sound_config.h
-
-/*
- * Define our PCI vendor ID here
- */
- 
-#ifndef PCI_VENDOR_MYIDENT
-#define PCI_VENDOR_MYIDENT 0x125D
-
-/*
- * PCI identity for the card.
- */
- 
-#define PCI_DEVICE_ID_MYIDENT_MYCARD1  0x1969
-#endif
-
-#define CARD_NAME  ExampleWave 3D Pro Ultra ThingyWotsit
-
-#define MAX_CARDS  8
-
-/*
- * Each address_info object holds the information about one of
- * our card resources. In this case the MSS emulation of our
- * ficticious card. Its used to manage and attach things.
- */
- 
-static struct address_info mss_data[MAX_CARDS];
-static int cards;
-
-/*
- * Install the actual card. This is an example
- */
-
-static int mycard_install(struct pci_dev *pcidev)
-{
-   int iobase;
-   int mssbase;
-   int mpubase;
-   u8 x;
-   u16 w;
-   u32 v;
-   int i;
-   int dma;
-
-   /*
-*  Our imaginary code has its I/O on PCI address 0, a
-*  MSS on PCI address 1 and an MPU on address 2
-*
-*  For the example we will only initialise the MSS
-*/
-   
-   iobase = pci_resource_start(pcidev, 0);
-   mssbase = pci_resource_start(pcidev, 1);
-   mpubase = pci_resource_start(pcidev, 2);
-   
-   /*
-*  Reset the board
-*/
-
-   /*
-*  Wait for completion. udelay() waits in microseconds
-*/
-
-   udelay(100);
-   
-   /*
-*  Ok card ready. Begin setup proper. You might for example
-*  load the firmware here
-*/
-   
-   dma = card_specific_magic(ioaddr);
-   
-   /*
-*  Turn on legacy mode (example), There are also byte and
-*  dword (32bit) PCI configuration function calls
-*/
-
-   pci_read_config_word(pcidev, 0x40, w);
-   w=~(115);/* legacy decode on */
-   w|=(114); /* Reserved write as 1 in this case */
-   w|=(13)|(11)|(10);/* SB on , FM on, MPU on */
-   pci_write_config_word(pcidev, 0x40, w);
-   
-   /*
-*  Let the user know we found his toy.
-*/
-
-   printk(KERN_INFO Programmed CARD_NAME at 0x%X to legacy mode.\n,
-   iobase);
-   
-   /*
-*  Now set it up the description of the card
-*/
-
-   mss_data[cards].io_base = mssbase;
-   mss_data[cards].irq = pcidev-irq;
-   mss_data[cards].dma = dma;
-   
-   /*
-*  Check there is an MSS present
-*/
-
-   if(ad1848_detect(mssbase, NULL, mss_data[cards].osp)==0)
-   return 0;
-   
-   /*
-*  Initialize it
-*/
-
-   mss_data[cards].slots[3] = ad1848_init(MyCard MSS 16bit, 
-   mssbase,
-   mss_data[cards].irq,
-   mss_data[cards].dma,
-   mss_data[cards].dma,
-   0,
-   0,
-   THIS_MODULE);
-
-   cards++;
-   return 1;
-}
-
-
-/*
- * This loop walks the PCI configuration database and finds where
- * the sound cards are.
- */
- 
-int init_mycard(void)
-{
-   struct pci_dev *pcidev=NULL;
-   int count=0;
-   
-   while((pcidev = pci_find_device(PCI_VENDOR_MYIDENT, 
PCI_DEVICE_ID_MYIDENT_MYCARD1, pcidev))!=NULL)
-   {
-   if (pci_enable_device(pcidev))
-   continue;
-   count+=mycard_install(pcidev);
-   if(count)
-   return 0;
-   if(count==MAX_CARDS)
-   

[2.6 patch] include/linux/bio.h: extern inline - static inline

2005-07-26 Thread Adrian Bunk
extern inline doesn't make much sense.


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

---

 include/linux/bio.h |7 +++
 1 files changed, 3 insertions(+), 4 deletions(-)

--- linux-2.6.13-rc3-mm1-full/include/linux/bio.h.old   2005-07-26 
13:40:47.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/bio.h   2005-07-26 
13:41:13.0 +0200
@@ -314,9 +314,8 @@
  * bvec_kmap_irq and bvec_kunmap_irq!!
  *
  * This function MUST be inlined - it plays with the CPU interrupt flags.
- * Hence the `extern inline'.
  */
-extern inline char *bvec_kmap_irq(struct bio_vec *bvec, unsigned long *flags)
+static inline char *bvec_kmap_irq(struct bio_vec *bvec, unsigned long *flags)
 {
unsigned long addr;
 
@@ -332,7 +331,7 @@
return (char *) addr + bvec-bv_offset;
 }
 
-extern inline void bvec_kunmap_irq(char *buffer, unsigned long *flags)
+static inline void bvec_kunmap_irq(char *buffer, unsigned long *flags)
 {
unsigned long ptr = (unsigned long) buffer  PAGE_MASK;
 
@@ -345,7 +344,7 @@
 #define bvec_kunmap_irq(buf, flags)do { *(flags) = 0; } while (0)
 #endif
 
-extern inline char *__bio_kmap_irq(struct bio *bio, unsigned short idx,
+static inline char *__bio_kmap_irq(struct bio *bio, unsigned short idx,
   unsigned long *flags)
 {
return bvec_kmap_irq(bio_iovec_idx(bio, idx), flags);

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


Re: 2.6.13-rc3 Battery times at 100/250/1000 Hz = Zero difference

2005-07-26 Thread Voluspa
On Tue, 26 Jul 2005 15:14:39 +0200 Vojtech Pavlik wrote:
 This almost looks like a regular Athlon 64, not even the mobile
 version. I wouldn't expect very big deep sleep capabilities on that
 one. You can check the 
 
   /proc/acpi/processor/CPU1/power
 
 file for the list of C states. A normal Athlon64 will likely have only
 C0. Mobile chips can go up to C4, which is really deep sleep.

You've probably already seen that /proc/acpi/processor/CPU1/power lists
C1 only here. Ok, with your input regarding normal CPUs I'm inclined
to believe ACPI is correct in my case. Still, I'll learn/read the code.
Always have had a need to finish those long marches.

Mvh
Mats Johannesson
--
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] include/linux/dcookies.h: dummy functions must be static inline

2005-07-26 Thread Adrian Bunk
We don't want these to be global functions.


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

--- linux-2.6.13-rc3-mm1-full/include/linux/dcookies.h.old  2005-07-26 
11:15:22.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/dcookies.h  2005-07-26 
11:15:38.0 +0200
@@ -48,12 +48,12 @@
 
 #else
 
-struct dcookie_user * dcookie_register(void)
+static inline struct dcookie_user * dcookie_register(void)
 {
return NULL;
 }
 
-void dcookie_unregister(struct dcookie_user * user)
+static inline void dcookie_unregister(struct dcookie_user * user)
 {
return;
 }

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 cached memory

2005-07-26 Thread Bill Davidsen

Robert Hancock wrote:

John Pearson wrote:


Wouldn't having (practically) all your memory used for cache slow down
starting a new program? First it would have to free up that space, and 
then

put stuff in that space, taking potentially twice as long.



If the cache pages are clean (not been modified since they were read 
from the disk), then evicting that data will not take very long. If the 
program you are just starting is not in the cache, then the time taken 
to load it from disk will dwarf the time needed to evict cached pages. 
And there's also the possibility that the cache contains the data you 
are loading, which definitely will speed things up..


The problem lies with data write evicting program pages in many cases. 
You are right that they don't need to be written, but they do need to be 
read back, so when I unhide a window there's a large delay while the 
underlying program is read back in. If the pages are dirty, then there's 
the delay while they are written.


It's exactly the benefit from having cached pages which is lost.

I would love more control in this area, but short of maintaining a patch 
I don't see it happening.


--
   -bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
 last possible moment - but no longer  -me
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] extern inline - static inline

2005-07-26 Thread Adrian Bunk
extern inline doesn't make much sense.


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

---

 include/linux/reiserfs_fs.h |6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)

--- linux-2.6.13-rc3-mm1-full/include/linux/reiserfs_fs.h.old   2005-07-26 
13:42:59.0 +0200
+++ linux-2.6.13-rc3-mm1-full/include/linux/reiserfs_fs.h   2005-07-26 
13:43:37.0 +0200
@@ -2097,7 +2097,7 @@
 b_blocknr_t, int for_unformatted);
 int reiserfs_allocate_blocknrs(reiserfs_blocknr_hint_t *, b_blocknr_t *, int,
   int);
-extern inline int reiserfs_new_form_blocknrs(struct tree_balance *tb,
+static inline int reiserfs_new_form_blocknrs(struct tree_balance *tb,
 b_blocknr_t * new_blocknrs,
 int amount_needed)
 {
@@ -2113,7 +2113,7 @@
  0);
 }
 
-extern inline int reiserfs_new_unf_blocknrs(struct reiserfs_transaction_handle
+static inline int reiserfs_new_unf_blocknrs(struct reiserfs_transaction_handle
*th, struct inode *inode,
b_blocknr_t * new_blocknrs,
struct path *path, long block)
@@ -2130,7 +2130,7 @@
 }
 
 #ifdef REISERFS_PREALLOCATE
-extern inline int reiserfs_new_unf_blocknrs2(struct reiserfs_transaction_handle
+static inline int reiserfs_new_unf_blocknrs2(struct reiserfs_transaction_handle
 *th, struct inode *inode,
 b_blocknr_t * new_blocknrs,
 struct path *path, long block)

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


Re: 2.6.12 PREEMPT_RT PPC

2005-07-26 Thread Ingo Molnar

* K.R. Foley [EMAIL PROTECTED] wrote:

 snip
 
 On X86 -51-36 won't build with CONFIG_BLOCKER=Y without the attached 
 patch.

thanks. I changed the include to asm/rtc.h, this should give what PPC 
wants to have, and should work on all architectures. Released the -37 
patch.

Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: [INPUT] simple question on driver initialisation.

2005-07-26 Thread moreau francis

--- Vojtech Pavlik [EMAIL PROTECTED] a écrit :
  
  I can't find pinpad/input0 in sysfs, does that mean I need to add sysfs
  suppport in my driver, and it's not done in input module when I register 
  my input driver ?
 
 I'm sorry, I thought it's already in mainline, but that bit is still
 missing from the sysfs support in input. It'll get there soon.
 

cool.

   pinpad/input0 doesn't sound right. What port is your pinpad connected
   to?
  
  Actually I'm working on an embedded system which owns a pinpad controller.
  This controller is accessed by using io mem and it talks to the pinpad
 through
  a dedicated bus. So I accessed it through io space.
 
 In that case, you'll likely want something like io0200/input0, where
 0x200 would be the io address of the device. On the other hand, if it's
 really embedded and there can't be two pinpads in the system, it's not a
 problem to use basically any string there, since it only needs to be
 system-unique.
 

It will be the case: only one embedded pinpad in the system. So something
like kbdport/input0 should be ok...

thanks Vojtech for your time.

 Francis






___ 
Appel audio GRATUIT partout dans le monde avec le nouveau Yahoo! Messenger 
Téléchargez cette version sur http://fr.messenger.yahoo.com
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [PATCH] Remove Comtrol mail address from MAINTAINERS [next 1 address]

2005-07-26 Thread Linux Maillist
On 7/21/05, Rolf Eike Beer [EMAIL PROTECTED] wrote:
 Am Donnerstag, 21. Juli 2005 01:43 schrieb Jiri Slaby:
 Rolf Eike Beer wrotes:
 Send a patch, you know the addresses.
 
 kernel 2.6.13-rc3-git4
 
 Signed-off-by: Jiri Slaby [EMAIL PROTECTED]
 
 --- a/MAINTAINERS  2005-07-21 01:13:32.0 +0200
 +++ b/MAINTAINERS  2005-07-21 01:17:41.0 +0200
 @@ -204,8 +204,6 @@
 
   ADVANSYS SCSI DRIVER
   P:   Bob Frey
 -M:[EMAIL PROTECTED]
 -W:http://www.advansys.com/linux.html
   L:   linux-scsi@vger.kernel.org
   S:   Maintained
 
 Please do not remove this mail address until you have verified that it really
 does not exist and is not only rejected due to the broken mail setup of
 advansys.com. Removing the website is ok. The mail address you can remove is
 [EMAIL PROTECTED]

This is letter from advansys (now initio):

Hello Jiri,

The links you have are very old and no longer work. Advansys went out of
He means these two, of course:
http://www.advansys.com/linux.html
[EMAIL PROTECTED]
busness about 3 years ago.

There is no new development for linux and the Advansys products.

Regards
Dan
Initio Technical Support

So now, removing both is OK.

cjtsai@ is from driver somewhere in the tree, not from MAINTAINERS, it
was my mistake.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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: topology api confusion

2005-07-26 Thread Bill Davidsen

Matthew Dobson wrote:

Nathan Lynch wrote:


We need some clarity on how asm-generic/topology.h is intended to be
used.  I suspect that it's supposed to be unconditionally included at
the end of the architecture's topology.h so that any elements which
are undefined by the arch have sensible default definitions.  Looking
at 2.6.13-rc3, this is what ppc64, ia64, and x86_64 currently do,
however i386 does not (i386 pulls in the generic version only when
!CONFIG_NUMA).

The #ifndef guards around each element of the topology api
cannot serve their apparent intended purpose when the architecture
implements a given bit as a function instead of a macro
(e.g. cpu_to_node in ppc64):



When I originally wrote this all up, I had planned it to be used the way
i386 does: offer a full implementation of topology if appropriate, else
include the generic sane default.  It has since changed to work more like
you described: implement some (or all) of the topology functions, then
include the generic one to define any you missed.




Since ppc64 unconditionally includes asm-generic/topology.h, all uses
of cpu_to_node are preprocessed to (0).  Similar damage occurs with
every other topology function which happens to be a real function
instead of a macro.  I'm surprised my ppc64 numa systems even boot ;)

If the intent is that the architecture is free to define only a subset
of the api and include the generic header for fallback definitions,
then we need to do the #ifndef __HAVE_ARCH_FOO thing, no?  That is,
the code above would look like:



You are correct in noticing that things should (though apparently don't?)
go wonky when arches define their topology functions as *functions*, rather
than macros.  It hasn't really seemed to bite anyone yet, so I've left it
alone, though to be honest, it is as surprising to me that it works as it
is to you.  I've resisted creating #ifdef ARCH_HAVE_XXX all over the place,
though maybe it is finally time?


If I understand the problem, is it amenable to just defining the macros 
and using another name for a function? In other words, if most arch 
define xx_generic_add as a function, can you just

 #define xx_generic_add xx_local_arch_add
which would satisfy the #ifndef, allow use of a function, etc? Then 
xx_local_arch_add can be the function. Then the common include would not 
generate macros for things which exist as function.


--
   -bill davidsen ([EMAIL PROTECTED])
The secret to procrastination is to put things off until the
 last possible moment - but no longer  -me
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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   4   >