Re: [PATCH v6 04/13] pktcdvd: Switch to bio_kmalloc()
On Tue, 28 Aug 2012, Jiri Kosina wrote: On Wed, 22 Aug 2012, Tejun Heo wrote: (cc'ing Jiri, hi!) Hi there! :) On Wed, Aug 22, 2012 at 10:04:01AM -0700, Kent Overstreet wrote: This is prep work for killing bi_destructor - previously, pktcdvd had its own pkt_bio_alloc which was basically duplication bio_kmalloc(), necessitating its own bi_destructor implementation. v5: Un-reorder some functions, to make the patch easier to review Signed-off-by: Kent Overstreet CC: Peter Osterlund Apart from bio_reset() not resetting bi_end_io and bi_private, this looks fine to me but lack of testing makes me a bit hesitant to ack it. Peter doesn't want to be the maintainer of pktcdvd anymore. Maybe Jiri can be tricked into taking this one too? :) Gah, seems like the floppy saga is going to cause me some more trouble in the future ... :) Well, I definitely have hardware back at home that supports this, so I can take it. Doesn't seem to be heavy traffic code either. Peter, ok with that? Also, how was this usually fed upstream -- through Jens' tree? Yes, I am ok with that. -- Peter Osterlund - peterosterlu...@gmail.com, pete...@comhem.se http://web.comhem.se/petero2home -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.24.2: 4KSTACKS + pcdrw + dm + mount -> stack overflow: ide-cd related? dm-related?
Nix <[EMAIL PROTECTED]> writes:
> On 24 Feb 2008, [EMAIL PROTECTED] outgrape:
>
>> A loop mount/umounting a pcdrw or iso9660 (through the pktcdvd device)
>> sees a stack overflow in four or five tries. Doing the same thing with
>> the same CD in a normal non-pktcdvd-mounted drive doesn't cause a crash.
>
>> (This may or may not be PREEMPT+PREEMPT_BKL-specific: I'll try turning
>> them off tomorrow and repeating.)
>
> It is not preempt-specific, nor dm-specific. Nor it is very easy to
> capture tracebacks of: even netconsole generally gives up when faced
> with a string of recursive tracebacks blurring past forever at blinding
> speed.
>
> But while I'd normally blame pktcdvd there's only one pktcdvd function
> in these tracebacks (pkt_open) and it's not got a significant stack
> footprint.
Did you verify that with "make checkstack" or just by looking at the
source code? On my system, pkt_open() consumes 584 bytes because the
compiler decides to inline lots of functions that would not normally
be part of long call chains. The following patch fixes that problem on
my system.
> More notable is a great stack of mutual recursion between
> dm_bio_destructor() and the CDROM code: it seems to burn most of the
> stack on this sort of thrashing. Here's one of those tracebacks again:
Maybe dm_bio_destructor() is just old cruft left on the stack from
previous function calls?
From: Peter Osterlund <[EMAIL PROTECTED]>
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
drivers/block/pktcdvd.c | 16
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 674cd66..f2510e7 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -849,7 +849,7 @@ static int pkt_flush_cache(struct pktcdvd_device *pd)
/*
* speed is given as the normal factor, e.g. 4 for 4x
*/
-static int pkt_set_speed(struct pktcdvd_device *pd, unsigned write_speed,
unsigned read_speed)
+static noinline int pkt_set_speed(struct pktcdvd_device *pd, unsigned
write_speed, unsigned read_speed)
{
struct packet_command cgc;
struct request_sense sense;
@@ -1776,7 +1776,7 @@ static int pkt_get_track_info(struct pktcdvd_device *pd,
__u16 track, __u8 type,
return pkt_generic_packet(pd, &cgc);
}
-static int pkt_get_last_written(struct pktcdvd_device *pd, long *last_written)
+static noinline int pkt_get_last_written(struct pktcdvd_device *pd, long
*last_written)
{
disc_information di;
track_information ti;
@@ -1813,7 +1813,7 @@ static int pkt_get_last_written(struct pktcdvd_device
*pd, long *last_written)
/*
* write mode select package based on pd->settings
*/
-static int pkt_set_write_settings(struct pktcdvd_device *pd)
+static noinline int pkt_set_write_settings(struct pktcdvd_device *pd)
{
struct packet_command cgc;
struct request_sense sense;
@@ -1972,7 +1972,7 @@ static int pkt_writable_disc(struct pktcdvd_device *pd,
disc_information *di)
return 1;
}
-static int pkt_probe_settings(struct pktcdvd_device *pd)
+static noinline int pkt_probe_settings(struct pktcdvd_device *pd)
{
struct packet_command cgc;
unsigned char buf[12];
@@ -2071,7 +2071,7 @@ static int pkt_probe_settings(struct pktcdvd_device *pd)
/*
* enable/disable write caching on drive
*/
-static int pkt_write_caching(struct pktcdvd_device *pd, int set)
+static noinline int pkt_write_caching(struct pktcdvd_device *pd, int set)
{
struct packet_command cgc;
struct request_sense sense;
@@ -2116,7 +2116,7 @@ static int pkt_lock_door(struct pktcdvd_device *pd, int
lockflag)
/*
* Returns drive maximum write speed
*/
-static int pkt_get_max_speed(struct pktcdvd_device *pd, unsigned *write_speed)
+static noinline int pkt_get_max_speed(struct pktcdvd_device *pd, unsigned
*write_speed)
{
struct packet_command cgc;
struct request_sense sense;
@@ -2177,7 +2177,7 @@ static char us_clv_to_speed[16] = {
/*
* reads the maximum media speed from ATIP
*/
-static int pkt_media_speed(struct pktcdvd_device *pd, unsigned *speed)
+static noinline int pkt_media_speed(struct pktcdvd_device *pd, unsigned *speed)
{
struct packet_command cgc;
struct request_sense sense;
@@ -2249,7 +2249,7 @@ static int pkt_media_speed(struct pktcdvd_device *pd,
unsigned *speed)
}
}
-static int pkt_perform_opc(struct pktcdvd_device *pd)
+static noinline int pkt_perform_opc(struct pktcdvd_device *pd)
{
struct packet_command cgc;
struct request_sense sense;
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Printing to off-line printer in 2.4.0-prerelease
Tim Waugh <[EMAIL PROTECTED]> writes:
> --8SdtHY/0P4yzaavF
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
>
> On Thu, Jan 04, 2001 at 03:39:10PM +0100, Andrea Arcangeli wrote:
>
> > As noted yesterday falling into parport_write will silenty lose data when the
> > printer is off.
>
> (Actually it depends; I think FIFO/DMA paths are fine, but yes, the
> software implementation can lose data.)
On my printer (HP LJ4MP) if parport_write is called when the printer
is off, it will lose data even in DMA mode. I added printk's to verify
that when I'm sending a 176 byte file to /dev/lp0, it will be
transferred with one call to parport_pc_fifo_write_block_dma and
/proc/interrupts says that one new parport interrupt has arrived.
> > If it's not feasible to make parport_write reliable against
> > power-off printer, then I recommend to loop in interruptible mode
> > before entering the main loop (waiting the printer to power-on) like
> > in latest patch from Peter.
>
> Have I missed a patch? How do you know whether or not the printer is
> on yet?
[...]
> If this goes away:
>
> if ((status & LP_PERRORP) && !(LP_F(minor) & LP_CAREFUL))
> /* No error. */
> last = 0;
>
> then some people might not be able to print at all.
OK, how about this patch then?
--- linux-2.4.0-prerelease/drivers/char/lp.c.orig Wed Jan 3 18:48:39 2001
+++ linux-2.4.0-prerelease/drivers/char/lp.cThu Jan 4 20:34:24 2001
@@ -222,6 +222,21 @@
return error;
}
+static int lp_wait_ready(int minor)
+{
+ int error = 0;
+ do {
+ error = lp_check_status (minor);
+ if (error && (LP_F(minor) & LP_ABORT))
+ break;
+ if (signal_pending (current)) {
+ error = -EINTR;
+ break;
+ }
+ } while (error);
+ return error;
+}
+
static ssize_t lp_write(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
@@ -259,7 +274,7 @@
parport_set_timeout (lp_table[minor].dev,
lp_table[minor].timeout);
- if ((retv = lp_check_status (minor)) == 0)
+ if ((retv = lp_wait_ready (minor)) == 0)
do {
/* Write the data. */
written = parport_write (port, kbuf, copy_size);
@@ -279,9 +294,9 @@
if (copy_size > 0) {
/* incomplete write -> check error ! */
- int error = lp_check_status (minor);
+ int error = lp_wait_ready (minor);
- if (LP_F(minor) & LP_ABORT) {
+ if (error) {
if (retv == 0)
retv = error;
break;
--- linux-2.4.0-prerelease/drivers/parport/ieee1284.c.orig Wed Jan 3 18:50:02
2001
+++ linux-2.4.0-prerelease/drivers/parport/ieee1284.c Thu Jan 4 20:17:10 2001
@@ -524,7 +524,8 @@
PARPORT_STATUS_PAPEROUT,
PARPORT_STATUS_PAPEROUT);
if (r)
- DPRINTK (KERN_INFO "%s: Timeout at event 31\n");
+ DPRINTK (KERN_INFO "%s: Timeout at event 31\n",
+port->name);
port->ieee1284.phase = IEEE1284_PH_FWD_IDLE;
DPRINTK (KERN_DEBUG "%s: ECP direction: forward\n",
--- linux-2.4.0-prerelease/include/linux/lp.h.orig Thu Jan 4 00:21:15 2001
+++ linux-2.4.0-prerelease/include/linux/lp.h Thu Jan 4 20:14:17 2001
@@ -20,7 +20,7 @@
#define LP_NOPA 0x0010
#define LP_ERR 0x0020
#define LP_ABORT 0x0040
-#define LP_CAREFUL 0x0080 /* obsoleted -arca */
+#define LP_CAREFUL 0x0080
#define LP_ABORTOPEN 0x0100
#define LP_TRUST_IRQ_ 0x0200 /* obsolete */
--
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
Tim Waugh <[EMAIL PROTECTED]> writes: > On Thu, Jan 04, 2001 at 02:52:29PM +0100, Andrea Arcangeli wrote: > > > I think lp_check_status. > > Okay. So what about this patch instead? If the printer is off-line > to start with, fall into parport_write anyway (it will just time out > and return 0). If LP_ABORT is set, we return -EAGAIN. If you do this, you should probably also return -EAGAIN if the printer is out of paper, otherwise I would still lose data when the printer goes out of paper. Currently it returns -ENOSPC in this situation. I suppose the different return codes were meant as a way for user space to be able to know why printing failed, so that it could take appropriate actions, but maybe this is not used by any programs. -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
Tim Waugh <[EMAIL PROTECTED]> writes:
> On Thu, Jan 04, 2001 at 08:07:19PM +0100, Peter Osterlund wrote:
>
> > If you do this, you should probably also return -EAGAIN if the printer
> > is out of paper, otherwise I would still lose data when the printer
> > goes out of paper. Currently it returns -ENOSPC in this situation. I
> > suppose the different return codes were meant as a way for user space
> > to be able to know why printing failed, so that it could take
> > appropriate actions, but maybe this is not used by any programs.
>
> They were intended for that, yes, but it's probably better to stick
> with the 2.2 return codes. Here's a patch to do that. Look okay?
I assume you meant to return -EAGAIN, not -EIO. However, it doesn't
work if the printer is powered off and LP_ABORT is false. In that case
lp_write calls lp_check_status, which detects the error, waits 10
seconds, but then returns 0. lp_write then calls parport_write which
will happily send the data to the powered off printer, then return
success to user space and the data is lost.
>
> Tim.
> */
>
> 2001-01-04 Tim Waugh <[EMAIL PROTECTED]>
>
> * drivers/char/lp.c: Follow 2.2 behaviour more closely.
>
> --- linux-2.4.0-prerelease/drivers/char/lp.c.offline Thu Jan 4 21:13:02 2001
> +++ linux-2.4.0-prerelease/drivers/char/lp.c Thu Jan 4 21:42:19 2001
> @@ -207,7 +207,7 @@
> last = LP_POUTPA;
> printk(KERN_INFO "lp%d out of paper\n", minor);
> }
> - error = -ENOSPC;
> + error = -EIO;
> } else if (!(status & LP_PSELECD)) {
> if (last != LP_PSELECD) {
> last = LP_PSELECD;
> @@ -230,7 +230,10 @@
> if (last != 0)
> lp_error(minor);
>
> - return error;
> + if (LP_F (minor) & LP_ABORT)
> + return error;
> +
> + return 0;
> }
>
> static ssize_t lp_write(struct file * file, const char * buf,
> @@ -292,7 +295,7 @@
> /* incomplete write -> check error ! */
> int error = lp_check_status (minor);
>
> - if (LP_F(minor) & LP_ABORT) {
> + if (error) {
> if (retv == 0)
> retv = error;
> break;
--
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm (patch)
Ragnar Kjørstad <[EMAIL PROTECTED]> writes:
> If I understand the current code correctly, it works like this:
[ example deleted ]
> So we've ended up with a very silly queue
Indeed, the elevator logic is somewhat flawed. There are two problems
with the current code:
1. The test that decides if we have found a good spot to insert the
current request doesn't handle the wraparound case correctly. (The
case when the elevator reaches the end of the disk and starts over
from the beginning.)
2. If we can't find a good spot to insert the new request, we
currently insert it as early as possible in the queue. If no good
spot is found, it is more efficient and more fair to insert the new
request last in the queue.
The following patch fixes both problems. Here are the results from
'iozone 100' and Bonnie with and without this patch.
test8:
--
iozone:
4626750 bytes/second for writing the file
7431438 bytes/second for reading the file
bonnie:
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5278 60.6 7940 18.3 2876 9.7 5635 49.3 8344 16.7 179.3 2.0
test8 + modified elevator:
--
iozone:
4801172 bytes/second for writing the file
7613088 bytes/second for reading the file
bonnie:
---Sequential Output ---Sequential Input-- --Random--
-Per Char- --Block--- -Rewrite-- -Per Char- --Block--- --Seeks---
MachineMB K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU K/sec %CPU /sec %CPU
100 5727 66.6 8365 18.1 2921 9.2 5991 52.2 8171 16.0 171.0 2.0
Here is the patch:
--- linux-2.4.0-test8/drivers/block/elevator.c.orig Sun Sep 17 00:05:03 2000
+++ linux-2.4.0-test8/drivers/block/elevator.c Sun Sep 17 00:06:31 2000
@@ -34,20 +34,38 @@
struct list_head *real_head,
struct list_head *head, int orig_latency)
{
- struct list_head *entry = real_head;
- struct request *tmp;
-
- req->elevator_sequence = orig_latency;
-
- while ((entry = entry->prev) != head) {
- tmp = blkdev_entry_to_request(entry);
- if (IN_ORDER(tmp, req))
- break;
- if (!tmp->elevator_sequence)
- break;
- tmp->elevator_sequence--;
- }
- list_add(&req->queue, entry);
+ struct list_head *last = real_head->prev;
+ struct list_head *insert_after = last;
+ struct list_head *entry;
+ struct request *tmp1, *tmp2;
+
+ req->elevator_sequence = orig_latency;
+
+ if (last == head)
+ goto out;
+
+ entry = last;
+ tmp1 = blkdev_entry_to_request(entry);
+ do {
+ tmp2 = tmp1;
+ entry = entry->prev;
+ tmp1 = blkdev_entry_to_request(entry);
+ if (!tmp2->elevator_sequence)
+ break;
+ if (IN_ORDER(tmp1, tmp2) ?
+ (IN_ORDER(tmp1, req) && IN_ORDER(req, tmp2)) :
+ (IN_ORDER(tmp1, req) || IN_ORDER(req, tmp2))) {
+ insert_after = entry;
+ do {
+ entry = entry->next;
+ tmp1 = blkdev_entry_to_request(entry);
+ tmp1->elevator_sequence--;
+ } while (entry != last);
+ break;
+ }
+ } while (entry != head);
+out:
+ list_add(&req->queue, insert_after);
}
int elevator_linus_merge(request_queue_t *q, struct request **req,
--
Peter Österlund Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden Phone: +46 8 942647
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm (patch)
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> The patch is buggy for non headactive devices like SCSI and also for
> IDE while the queue is plugged.
Thanks for looking at the patch. Yes, sorry, I misunderstood the linux
linked list implementation. This is easy to fix though. See new patch
at the end.
> While the queue is plugged or with things like SCSI your logic
> change won't work because in such case if your request is lower the
> lowest in the queue, you can put it at the head of the queue and you
> have no way to know where your "tmp1" was placed so you can't make
> any assumption (that's why the current code makes sense).
I still don't think the current code makes sense. Consider what will
happen if you insert request 100, 200, 101, 201, 102, 102, ... in an
empty plugged queue. (Assume max allowed latency is 2)
queue: 100 101 102 200 103 201 104 202 105 203 204 205 ...
latency: 2 2 2 0 2 0 2 0 2 0 1 2 ...
So you end up with one seek between each request. The same thing
happens no matter how large the latency is. It just takes longer
before the behaviour starts. With the new logic you will instead get:
queue: 100 101 102 200 201 202 203 204 103 104 105 205 ...
latency: 2 2 2 0 1 2 2 2 0 1 2 2 ...
So in this case there will be 5 (2*latency+1) requests between each
seek.
The new patch will obey the latency requirement but still keep disk
seeks to a minimum. This makes it possible to use much smaller latency
values without losing streaming performance. (I used "elvtune -r 1
-w 20" and didn't notice any slowdown in iozone and Bonnie. It is
still faster than plain 2.4.0-test8)
The new patch is also not unfair to requests near the end of the disk.
The current kernel code can starve those requests a very long time if
the request queue never becomes empty.
> But I had an idea to generalize the algorithm so that we could
> optimize SCSI as well and also IDE in the plugged case: nobody
> forbid us to remeber the last position of the drive in the
> request_queue_t to still be able to know your "tmp1" that actually
> we don't know about.
Yes, that would be even better, but IMHO the new patch is already
better than what's currently in the kernel. (I don't think the
elevator code before your latency fix handled this correctly either.)
The only disadvantage I can see is that the new patch doesn't handle
consecutive insertions in O(1) time, but then again, the pre-latency
elevator code didn't do that either. Is this really important? How
long can the request queue be? Apparently we gain more by avoiding
disk seeks than we lose by wasting some CPU cycles during request
insertion.
Here is the new patch:
--- linux-2.4.0-test8/drivers/block/elevator.c.orig Sun Sep 17 00:05:03 2000
+++ linux-2.4.0-test8/drivers/block/elevator.c Sun Sep 17 20:27:48 2000
@@ -34,20 +34,55 @@
struct list_head *real_head,
struct list_head *head, int orig_latency)
{
- struct list_head *entry = real_head;
- struct request *tmp;
-
- req->elevator_sequence = orig_latency;
-
- while ((entry = entry->prev) != head) {
- tmp = blkdev_entry_to_request(entry);
- if (IN_ORDER(tmp, req))
- break;
- if (!tmp->elevator_sequence)
- break;
- tmp->elevator_sequence--;
- }
- list_add(&req->queue, entry);
+ struct list_head *last = real_head->prev;
+ struct list_head *insert_after = last;
+ struct list_head *entry;
+ struct request *tmp1, *tmp2;
+ int do_insert;
+
+ req->elevator_sequence = orig_latency;
+
+ if (last == head)
+ goto out;
+
+ entry = last;
+ tmp1 = blkdev_entry_to_request(entry);
+ do {
+ tmp2 = tmp1;
+ entry = entry->prev;
+ tmp1 = blkdev_entry_to_request(entry);
+ if (!tmp2->elevator_sequence)
+ break;
+ do_insert = 0;
+ if (entry == real_head) {
+ /*
+* Since we don't know were the disk head is
+* currently located, we can not really know
+* if the request should be inserted here. The
+* best bet is probably not to insert the
+* request here, because otherwise the
+* elevator would be unfair to sectors at the
+* end of the disk.
+*/
+ } else if (IN_ORDER(tmp1, tmp2)) {
+ if (IN_ORDER(tmp1, req) && IN_ORDER(req, tmp2))
+ do_insert = 1;
+ } else {
+ if (IN_ORDER(tmp1, req) || IN_ORDER(req, tmp2))
+ do_insert = 1;
+ }
+ if (do_insert) {
+
Re: An elevator algorithm (patch)
On Sun, 17 Sep 2000, Andrea Arcangeli wrote:
: And with the default latency values ("infinite") with the test2
: elevator if you're using scsi as your device, the patch can't make
: runtime differences either.
The test2 elevator (assuming it is the same as the test8 version) in the
infinite latency case will always send the request with the lowest sector
number to the drive. (The request queue will always be sorted, since the
elevator function degenerates to insertion sort.) Do you really suggest
that this is as good as a real elevator algorithm?
--
Peter Österlund Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden Phone: +46 8 942647
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm (patch)
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> > The only disadvantage I can see is that the new patch doesn't handle
> > consecutive insertions in O(1) time, but then again, the pre-latency
>
> We can still do that by trivially fixing a bit your code. You should first
> check if the new inserted request is over the last in the current queue before
> entering the tmp1/tmp2 logic.
Yes this can be done, but it will affect where requests are inserted.
Suppose the queue currently contains:
100 200 300 400 10 20 30
If request 150 is to be inserted, then with my previous patch it will
be inserted between 100 and 200, but with the proposed change it will
instead be inserted at the end. This is good for latency because there
will be less reordering, but potentially harmfull for streaming
performance because the total disk head traveling distance increases.
Anyway, I tested a new patch with your suggestion, and indeed this
change doesn't seem to cause too many extra seeks. I set the r/w
latencies to 1000/5000, and the iozone and Bonnie test produced almost
the same values as before.
I also noted that I could (almost) play an mp3 file with a 48Kb
buffer during "cp /dev/zero tmpfile". There is one rather large
skip a few seconds after the copy starts, but after that there are
only small occasional skips. I also ran iozone while playing the mp3,
and there were no major sound skips, and iozone only ran 7% slower
than without mpg123 running.
Thanks again for you comments. Here is the new patch:
--- linux-2.4.0-test8/drivers/block/elevator.c.orig Sun Sep 17 00:05:03 2000
+++ linux-2.4.0-test8/drivers/block/elevator.c Mon Sep 18 22:40:53 2000
@@ -34,20 +34,57 @@
struct list_head *real_head,
struct list_head *head, int orig_latency)
{
- struct list_head *entry = real_head;
- struct request *tmp;
+ struct list_head *last = real_head->prev;
+ struct list_head *insert_after = last;
+ struct list_head *entry;
+ struct request *tmp1, *tmp2;
+ int do_insert;
req->elevator_sequence = orig_latency;
- while ((entry = entry->prev) != head) {
- tmp = blkdev_entry_to_request(entry);
- if (IN_ORDER(tmp, req))
+ if (last == head)
+ goto out;
+
+ entry = last;
+ tmp1 = blkdev_entry_to_request(entry);
+ if (IN_ORDER(tmp1, req))
+ goto out;
+ do {
+ tmp2 = tmp1;
+ entry = entry->prev;
+ tmp1 = blkdev_entry_to_request(entry);
+ if (!tmp2->elevator_sequence)
break;
- if (!tmp->elevator_sequence)
+ do_insert = 0;
+ if (entry == real_head) {
+ /*
+* Since we don't know were the disk head is
+* currently located, we can not really know
+* if the request should be inserted here. The
+* best bet is probably not to insert the
+* request here, because otherwise the
+* elevator would be unfair to sectors at the
+* end of the disk.
+*/
+ } else if (IN_ORDER(tmp1, tmp2)) {
+ if (IN_ORDER(tmp1, req) && IN_ORDER(req, tmp2))
+ do_insert = 1;
+ } else {
+ if (IN_ORDER(tmp1, req) || IN_ORDER(req, tmp2))
+ do_insert = 1;
+ }
+ if (do_insert) {
+ insert_after = entry;
+ do {
+ entry = entry->next;
+ tmp1 = blkdev_entry_to_request(entry);
+ tmp1->elevator_sequence--;
+ } while (entry != last);
break;
- tmp->elevator_sequence--;
- }
- list_add(&req->queue, entry);
+ }
+ } while (entry != head);
+out:
+ list_add(&req->queue, insert_after);
}
int elevator_linus_merge(request_queue_t *q, struct request **req,
--
Peter Österlund Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden Phone: +46 8 942647
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm (patch)
Rik van Riel <[EMAIL PROTECTED]> writes:
> This is a bug in Andrea's idea. The request should only
> be inserted at the end of the list if:
>
> 1) the block numbre is bigger than head->prev (which you
>already have)
>
> AND
>
> 2) the block number is smaller than head (or head->next
>if the current request is unplugged)
The second condition is not so simple in the case of latency control.
Consider the following queue:
sector: 100 200 300 400 10 20 30
sequence: 1 1 1 1 0 1 1
In this case it would be correct to insert 150 at the end even though
it is >100, because no more requests are allowed to pass the "10"
request.
It is however possible to decide in O(1) time if the correct insertion
point is at the end of the queue. We have to keep track of the point,
p, where no more requests may pass. (10 in the example above.) The logic
would then be:
int insert_at_tail = 0;
if (IN_ORDER(p, last)) {
if (IN_ORDER(last, req) || IN_ORDER(req, p))
insert_at_tail = 1;
} else {
if (IN_ORDER(last, req) && IN_ORDER(req, p))
insert_at_tail = 1;
}
if (insert_at_tail) {
/* Do it in O(1) */
} else {
/* Do normal O(n) scan and update latencies */
}
The question is if this is worth the extra code complexity. How long
can the request queue be? Does it have a fixed upper size, or is it
limited only by available memory? If the request queue is always
short, the O(n) complexity shouldn't matter. Note that the worst case
complexity is still O(n) for all algorithms discussed so far.
--
Peter Österlund Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden Phone: +46 8 942647
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: An elevator algorithm
Jens Axboe <[EMAIL PROTECTED]> writes: > > modification Peter suggested there can be more and we should track the one > > more on the back of the queue. I don't think it's worthwhile. > > Agree, I don't think the added complexity would be worth it. So that leaves two choices: 1. Perfect elevator (CSCAN) without the O(1) optimization. (My second patch.) 2. Suboptimal elevator with the O(1) optimization. (Andrea's suggested modification to my second patch.) Since the request queue can not be very long, minimizing disk head movements ought to be more important than saving a few CPU cycles, so I vote for the first alternative. -- Peter Österlund Email: [EMAIL PROTECTED] Sköndalsvägen 35[EMAIL PROTECTED] S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919 Sweden Phone: +46 8 942647 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Printing to off-line printer in 2.4.0-prerelease
Hello,
When trying to print to an off-line printer with 2.4 kernels, the
"write" system call to /dev/lp0 stalls for 10 seconds and then returns
EIO. This has the unfortunate effect that the printout will be lost,
because the redhat print filters (in rh7) use "cat" to send data to
the printer device, and cat gives up when EIO is returned.
In 2.2 kernels, the write call waited until the printer went on-line
again.
I think the problem is that the lp_write() function in lp.c calls
lp_check_status() before starting to write to the parport, and if the
printer is not ready, it simply gives up. (The LP_ABORT flag is not
used in that case.)
The following patch makes things work for me again. The kernel keeps
generating the following debug messages until the printer becomes
ready, but that doesn't seem to cause any problems.
Jan 3 18:54:27 ppro kernel: DMA write timed out
Jan 3 18:54:37 ppro kernel: parport0: FIFO is stuck
Jan 3 18:54:37 ppro kernel: parport0: BUSY timeout (1) in compat_write_block_pio
Jan 3 18:54:37 ppro kernel: lp0 off-line
Is there a better way to fix this problem?
--- linux-2.4.0-prerelease/drivers/char/lp.c.orig Wed Jan 3 18:48:39 2001
+++ linux-2.4.0-prerelease/drivers/char/lp.cWed Jan 3 18:48:42 2001
@@ -259,7 +259,6 @@
parport_set_timeout (lp_table[minor].dev,
lp_table[minor].timeout);
- if ((retv = lp_check_status (minor)) == 0)
do {
/* Write the data. */
written = parport_write (port, kbuf, copy_size);
--- linux-2.4.0-prerelease/drivers/parport/ieee1284.c.orig Wed Jan 3 18:50:02
2001
+++ linux-2.4.0-prerelease/drivers/parport/ieee1284.c Wed Jan 3 18:50:16 2001
@@ -524,7 +524,8 @@
PARPORT_STATUS_PAPEROUT,
PARPORT_STATUS_PAPEROUT);
if (r)
- DPRINTK (KERN_INFO "%s: Timeout at event 31\n");
+ DPRINTK (KERN_INFO "%s: Timeout at event 31\n",
+port->name);
port->ieee1284.phase = IEEE1284_PH_FWD_IDLE;
DPRINTK (KERN_DEBUG "%s: ECP direction: forward\n",
--
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 03, 2001 at 07:44:19PM +0100, Peter Osterlund wrote:
> > Is there a better way to fix this problem?
>
> It looks the simpler fix to me (main loop needs someway to handle errors
> anyways) but ask Tim too.
>
> Another way to fix it is to loop in interruptible mode inside lp_error waiting
> the error to go away.
I didn't give my previous patch enough testing. It still doesn't work
if I queue a print job when my printer (HP LaserJet 4MP) is powered
off. Apparently the printer tells the computer it is OK to send data
to it when it is off.
Anyway, this new patch works for all tests I could think of. I tested
with the printer initially powered off, initially powered on but in
offline mode and initially powered on and in online mode. It also
works if I put the printer in offline mode during sending of a print
job. (tunelp -a and -o also work as expected.)
I also only get one DMA write timeout when putting the printer in
offline mode during sending, instead of repeated timeouts as I got
with the previous patch.
Here is the new patch:
--- linux-2.4.0-prerelease/drivers/char/lp.c.orig Wed Jan 3 18:48:39 2001
+++ linux-2.4.0-prerelease/drivers/char/lp.cWed Jan 3 21:41:31 2001
@@ -231,6 +231,7 @@
ssize_t retv = 0;
ssize_t written;
size_t copy_size = count;
+ int check_status;
#ifdef LP_STATS
if (jiffies-lp_table[minor].lastcall > LP_TIME(minor))
@@ -259,10 +260,26 @@
parport_set_timeout (lp_table[minor].dev,
lp_table[minor].timeout);
- if ((retv = lp_check_status (minor)) == 0)
+ check_status = 1;
do {
- /* Write the data. */
- written = parport_write (port, kbuf, copy_size);
+ int error = 0;
+ if (check_status) {
+ error = lp_check_status (minor);
+ if (error) {
+ if (LP_F(minor) & LP_ABORT) {
+ if (retv == 0)
+ retv = error;
+ break;
+ }
+ parport_yield_blocking (lp_table[minor].dev);
+ }
+ check_status = 0;
+ }
+ if (error == 0)
+ /* Write the data. */
+ written = parport_write (port, kbuf, copy_size);
+ else
+ written = 0;
if (written >= 0) {
copy_size -= written;
count -= written;
@@ -279,15 +296,7 @@
if (copy_size > 0) {
/* incomplete write -> check error ! */
- int error = lp_check_status (minor);
-
- if (LP_F(minor) & LP_ABORT) {
- if (retv == 0)
- retv = error;
- break;
- }
-
- parport_yield_blocking (lp_table[minor].dev);
+ check_status = 1;
} else if (current->need_resched)
schedule ();
--- linux-2.4.0-prerelease/drivers/parport/ieee1284.c.orig Wed Jan 3 18:50:02
2001
+++ linux-2.4.0-prerelease/drivers/parport/ieee1284.c Wed Jan 3 21:32:28 2001
@@ -524,7 +524,8 @@
PARPORT_STATUS_PAPEROUT,
PARPORT_STATUS_PAPEROUT);
if (r)
- DPRINTK (KERN_INFO "%s: Timeout at event 31\n");
+ DPRINTK (KERN_INFO "%s: Timeout at event 31\n",
+port->name);
port->ieee1284.phase = IEEE1284_PH_FWD_IDLE;
DPRINTK (KERN_DEBUG "%s: ECP direction: forward\n",
--
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: Printing to off-line printer in 2.4.0-prerelease
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Wed, Jan 03, 2001 at 10:00:59PM +0100, Peter Osterlund wrote:
> > off. Apparently the printer tells the computer it is OK to send data
> > to it when it is off.
>
> So then parport_write is probably buggy because it's losing data silenty while
> the printer is off. So the below is probably a band aid. Really some printer
> acts in a different way (see the LP_CAREFUL hack in 2.2.x) so it maybe that
> parport_write is ok on some printer and it would need something like a
> LP_CAREFUL option to work also on some other printer. Or maybe some parport
> handshake is badly designed in hardware and it cannot report errors (or maybe
> there's the hardware compatibility mode that cannot know about LP_CAREFUL to
> workaround some printer behaviour). In such case your patch is probably the
> only way to go (but almost certainly for the software compatibility mode it
> should be possible to report errors via parport_write as we do in 2.2.x).
The tunelp man-page seems to think there are printers that need the
LP_CAREFUL handling. I also noted that if I disconnect my printer from
the computer, the data will no longer be lost. Apparently the printer
confuses the parallel port when it is powered off.
> > I also only get one DMA write timeout when putting the printer in
> > offline mode during sending, instead of repeated timeouts as I got
> > with the previous patch.
>
> I see, it makes sense to try to parport_write only when errors goes away, but I
> think it's nicer to have lp_error or lp_check_status that loops internally in
> interruptible mode if LP_ABORT isn't set via lptune. probably the code should
> be restructured a bit.
What do you think about the following patch? It also works for all the
tests mentioned in my previous message.
--- linux-2.4.0-prerelease/drivers/char/lp.c.orig Wed Jan 3 18:48:39 2001
+++ linux-2.4.0-prerelease/drivers/char/lp.cThu Jan 4 00:45:52 2001
@@ -188,10 +188,7 @@
int error = 0;
unsigned int last = lp_table[minor].last_error;
unsigned char status = r_str(minor);
- if ((status & LP_PERRORP) && !(LP_F(minor) & LP_CAREFUL))
- /* No error. */
- last = 0;
- else if ((status & LP_POUTPA)) {
+ if ((status & LP_POUTPA)) {
if (last != LP_POUTPA) {
last = LP_POUTPA;
printk(KERN_INFO "lp%d out of paper\n", minor);
@@ -210,8 +207,7 @@
}
error = -EIO;
} else {
- last = 0; /* Come here if LP_CAREFUL is set and no
- errors are reported. */
+ last = 0; /* Come here if no errors are reported. */
}
lp_table[minor].last_error = last;
@@ -222,6 +218,21 @@
return error;
}
+static int lp_wait_ready(int minor)
+{
+ int error = 0;
+ do {
+ error = lp_check_status (minor);
+ if (error && (LP_F(minor) & LP_ABORT))
+ break;
+ if (signal_pending (current)) {
+ error = -EINTR;
+ break;
+ }
+ } while (error);
+ return error;
+}
+
static ssize_t lp_write(struct file * file, const char * buf,
size_t count, loff_t *ppos)
{
@@ -259,7 +270,7 @@
parport_set_timeout (lp_table[minor].dev,
lp_table[minor].timeout);
- if ((retv = lp_check_status (minor)) == 0)
+ if ((retv = lp_wait_ready (minor)) == 0)
do {
/* Write the data. */
written = parport_write (port, kbuf, copy_size);
@@ -279,9 +290,9 @@
if (copy_size > 0) {
/* incomplete write -> check error ! */
- int error = lp_check_status (minor);
+ int error = lp_wait_ready (minor);
- if (LP_F(minor) & LP_ABORT) {
+ if (error) {
if (retv == 0)
retv = error;
break;
@@ -453,10 +464,7 @@
LP_F(minor) &= ~LP_ABORTOPEN;
break;
case LPCAREFUL:
- if (arg)
- LP_F(minor) |= LP_CAREFUL;
- else
- LP_F(minor) &= ~LP_CAREFUL;
+ /* Obsolete */
break;
case LPWAIT:
LP_WAIT(minor) = arg;
--- linux-2.4.0-prerelease/drivers/parport/ieee1284.c.orig Wed Jan 3 18:50:02
2001
+++ linux-2.4.0-prerelease/drivers/parport/ieee1284.c Wed Jan 3 2
Re: Printing to off-line printer in 2.4.0-prerelease
On Thu, 4 Jan 2001, Andrea Arcangeli wrote: : I'm worried somebody needed to disable LP_CAREFUL to print, probably : it's not a big deal to keep it. I removed it because otherwise I would have had to do twice as many tests to convince myself that all combinations of flags and printer states worked correctly. I can reinsert it if you think that's necessary. But then I don't think the tunelp man page and the comments in the kernel should say that it is obsolete. I think obsolete means "you should never ever have to use this stuff". : However parport_write can still could silenty discard data, but maybe : it can't notice errors with some handshake. At least with my printer, it only discards data when it is powered off. If you power off the printer between the times when lp_wait_ready returns and parport_write is called, I think it is ok to lose data. After all, if the power off had occurred a few ms later, the data would already have been in the printer when it was powered off, and then you would have lost data anyway. : I didn't checked the details of the DMA based handshake so Tim needs : to comment if this can be considered a final/right fix (I hope it's : not ;). I don't understand the lowlevel parport details, so I can not comment on this. -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] vmfixes-2.4.0-test9-B2
Andrea Arcangeli <[EMAIL PROTECTED]> writes: > The new elevator ordering algorithm returns me much better numbers > than the CSCAN one with tiobench. Do you know why? Is it because the average seek distance becomes smaller with your algorithm? (I later realized that request merging is done before the elevator function kicks in, so your algorithm should not produce more seeks than a CSCAN algorithm. Unfortunately I didn't realize this when I wrote my CSCAN patch.) Btw, does anyone know how the seek time depends on the seek distance on modern disk hardware? -- Peter Österlund Email: [EMAIL PROTECTED] Sköndalsvägen 35[EMAIL PROTECTED] S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919 Sweden Phone: +46 8 942647 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] vmfixes-2.4.0-test9-B2
On Tue, 26 Sep 2000, Andrea Arcangeli wrote: : > smaller with your algorithm? (I later realized that request merging is : > done before the elevator function kicks in, so your algorithm should : : Not sure what you mean. There are two cases: the bh is merged, or : the bh will be queued in a new request because merging isn't possible. : : Your change deals only with the latter case and that should be : pretty orthogonal to what the merging stuff does. I previously thought that elevator_linus() was called first, and then elevator_linus_merge() was invoked to merge sequential requests before they were sent to the driver. If that had been the case, your version of elevator_linus() would have generated more seeks than CSCAN. But as I said, I was mistaken, it doesn't work that way. The elevator_linus() function is only called if merging isn't possible. Therefore, no matter what algorithm you use in elevator_linus() the total number of seeks should be the same. Therefore, if you are not trying to be fair (as CSCAN is) maybe there is an even better way to sort the requests. I think the important thing is trying to minimize the total amount of seek time. But doing that requires knowledge about how the seek time depends on the seek distance. -- Peter Österlund Email: [EMAIL PROTECTED] Sköndalsvägen 35[EMAIL PROTECTED] S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919 Sweden Phone: +46 8 942647 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.2.18pre13, drm without agp
Alan Cox <[EMAIL PROTECTED]> writes:
> 2.2.18pre2 (versus 2.2.17pre20)
>
> o AGP driver backport (XFree86, Precision
> DRM driver backport Insight, XiG, HJ Lu,
>VA Linux,
>and others)
I have a Voodoo3 2000 PCI card, but when I activate DRM without AGP,
# CONFIG_AGP is not set
CONFIG_DRM=y
CONFIG_DRM_TDFX=y
the linker complains about an undefined reference to agp_enable. The
following patch works for me, but I don't know if it is the correct
solution. (Even if it is, other drm drivers probably need similar
patches.)
This problem does not exist in 2.4.0-test8.
Here is the patch:
--- linux-2.2.18pre13/drivers/char/drm/tdfx_drv.c~ Sun Oct 1 10:46:36 2000
+++ linux-2.2.18pre13/drivers/char/drm/tdfx_drv.c Sun Oct 1 11:38:25 2000
@@ -34,12 +34,14 @@
#include "drmP.h"
#include "tdfx_drv.h"
+#if defined(CONFIG_AGP) || defined(CONFIG_AGP_MODULE)
#include
static __attribute__((unused)) void unused(void)
{
agp_enable(0);
}
+#endif
#define TDFX_NAME "tdfx"
#define TDFX_DESC "3dfx Banshee/Voodoo3+"
--
Peter Österlund Email: [EMAIL PROTECTED]
Sköndalsvägen 35[EMAIL PROTECTED]
S-128 66 Sköndal Home page: http://home1.swipnet.se/~w-15919
Sweden Phone: +46 8 942647
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/
Re: pktcddvd -> immediate crash
Soeren Sonnenburg <[EMAIL PROTECTED]> writes: > On Tue, 2005-04-05 at 18:04 +0100, Nix wrote: > > On 5 Apr 2005, Soeren Sonnenburg whispered secretively: > > > I wonder whether anyone could use the pktcddvd device without killing > > > random jobs (due to sudden out of memory or better memory leaks in > > > pktcddvd) and finally a complete freeze of the machine ? > > > > I'm using it without difficulty. > > > > > To reproduce just create an udf filesystem on some dvdrw, mount it rw > > > and copy some large file to the mount point. > > > > Well, I copied a 502Mb file to a CD/RW yesterday as part of my > > regular backups. No problems. > > > > I think we need more details (a .config would be nice, and preferably > > a cat of /proc/slabinfo and a dmesg dump when the problem starts). > > .config is attached (gzipped) and dmesg see below. unfortunately I > cannot provide a cat of /proc/slabinfo after the problem started... >From config.gz: # Linux kernel version: 2.6.11 ONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=32 # CONFIG_CDROM_PKTCDVD_WCACHE is not set > however this machine has like 1.5G mem 2G swap and was doing no serious > stuff, i.e. no high load no high memory requirements (I guess <500M) ... > pktcdvd: inserted media is DVD+RW > pktcdvd: write speed 2822kB/s > pktcdvd: 4590208kB available on disc > UDF-fs INFO UDF 0.9.8.1 (2004/29/09) Mounting volume 'LinuxUDF', timestamp > 2005/03/27 18:49 (103c) > rtc: lost some interrupts at 1024Hz. > rtc: lost some interrupts at 1024Hz. > rtc: lost some interrupts at 1024Hz. > rtc: lost some interrupts at 1024Hz. > oom-killer: gfp_mask=0xd0 > DMA per-cpu: > cpu 0 hot: low 2, high 6, batch 1 > cpu 0 cold: low 0, high 2, batch 1 > Normal per-cpu: > cpu 0 hot: low 32, high 96, batch 16 > cpu 0 cold: low 0, high 32, batch 16 > HighMem per-cpu: > cpu 0 hot: low 32, high 96, batch 16 > cpu 0 cold: low 0, high 32, batch 16 > > Free pages: 28944kB (896kB HighMem) > Active:46742 inactive:158822 dirty:666 writeback:114320 unstable:0 free:7236 > slab:18648 mapped:44732 pagetables:845 > DMA free:3960kB min:584kB low:728kB high:876kB active:1996kB inactive:1104kB > present:16384kB pages_scanned:3747 all_unreclaimable? yes > lowmem_reserve[]: 0 880 1519 > Normal free:24088kB min:32180kB low:40224kB high:48268kB active:5780kB > inactive:167540kB present:901120kB pages_scanned:29844 all_unreclaimable? no > lowmem_reserve[]: 0 0 5119 > HighMem free:896kB min:512kB low:640kB high:768kB active:179192kB > inactive:466644kB present:655344kB pages_scanned:0 all_unreclaimable? no > lowmem_reserve[]: 0 0 0 > DMA: 0*4kB 1*8kB 1*16kB 1*32kB 1*64kB 0*128kB 1*256kB 1*512kB 1*1024kB > 1*2048kB 0*4096kB = 3960kB > Normal: 0*4kB 1*8kB 1*16kB 0*32kB 0*64kB 0*128kB 2*256kB 0*512kB 1*1024kB > 1*2048kB 5*4096kB = 24088kB > HighMem: 62*4kB 7*8kB 5*16kB 0*32kB 0*64kB 0*128kB 0*256kB 1*512kB 0*1024kB > 0*2048kB 0*4096kB = 896kB > Swap cache: add 35451, delete 35184, find 371/482, race 0+0 > Free swap = 1838852kB > Total swap = 1975976kB > Out of Memory: Killed process 18330 (cat). I don't know how the OOM killer is supposed to work, but I think it's strange that it is triggered when there is 28MB RAM available and when "writeback" is 114320, which means that a lot more memory will become available by just waiting for the I/O to complete. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Apple USB Touchpad driver (new)
Stelian Pop <[EMAIL PROTECTED]> writes:
> Le lundi 11 juillet 2005 à 02:15 +0200, Peter Osterlund a écrit :
> > Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> >
> > > Using a function like
> > >
> > > return (x_old * 3 + x) / 4;
> > >
> > > eliminates the need for a FIFO, and has similar (if not better)
> > > properties to floating average, because its coefficients are
> > > [ .25 .18 .14 .10 ... ].
> >
> > Agreed.
>
> Except that this does not work well enough.
>
> There are two problems I encountered in this driver:
> * fuzz problems (keeping the finger at the same place makes the pointer
> dance around its position). This is solved by the input core's fuzz
> treatment, as I already set the fuzz to 16 in the code.
>
> * hickup problems (moving the finger generates non linear points,
> something like 1 1 1 3 3 3 4 4 4 instead of 1 1 1 2 2 3 3 4 4). And here
> the floating average approach works better than the input core's method.
> (this could probably be solved also by changing the way the absolute
> coordinate is calculated from the sensor array in atp_calculate_abs, but
> I haven't been able to find a better linear function).
It would be interesting if you could generate some debug dumps using
the "sample" line:
+ dbg_dump("sample", xy_cur);
The "accumulator" dumps are not needed, the raw data should be
enough. Including timing information would be helpful though, like
this:
--- a/drivers/usb/input/appletouch.c
+++ b/drivers/usb/input/appletouch.c
@@ -121,7 +121,7 @@ struct atp {
#define dbg_dump(msg, tab) \
if (debug > 1) {\
int i; \
- printk("appletouch: %s ", msg); \
+ printk("appletouch: %s %lld ", msg, (long long)jiffies);\
for (i = 0; i < ATP_XSENSORS + ATP_YSENSORS; i++) \
printk("%02x ", tab[i]);\
printk("\n"); \
Debug dumps for the following actions would be interesting.
1. When not touching the touchpad.
2. When trying to hold a finger on the touchpad without moving it.
3. A single finger movement. (Touch, move finger, release.)
4. A single finger touch. First a light touch, then pressing harder
and harder, to see if a reliable pressure value can be computed
from the data.
5. A two-finger touch.
> I would prefer to submit the patch myself, because as you say you cannot
> test the code and those changes are rather sensitive.
No problem, I just needed a patch when I was playing around with StGIT
and thought I might as well use a real patch.
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Apple USB Touchpad driver (new)
Stelian Pop <[EMAIL PROTECTED]> writes: > +/* > + * Smooth the data sequence by estimating the slope for the data sequence > + * [x3, x2, x1, x0] by using linear regression to fit a line to the data and > + * use the slope of the line. Taken from the synaptics X driver. > + */ This comment is not correct now that the code uses floating average instead. Maybe just remove it. The floating average calculation is much more obvious than the linear regression stuff. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: synaptics touchpad not recognized by Xorg X server with recent -mm kernels
Norbert Preining <[EMAIL PROTECTED]> writes: > Hello Peter, hi Andrew! > > Since 2.6.13-rc2-mm1 my X does not find my synaptics touchpad driver. > > With kernel 2.6.13-rc2-mm2 (same with rc2-mm1) I get from the kernel: > > Synaptics Touchpad, model: 1, fw: 5.8, id: 0x9d48b1, caps: 0x904713/0x4006 > input: SynPS/2 Synaptics TouchPad on isa0060/serio1 > > and Xorg.0.log gives: > > (II) Synaptics touchpad driver version 0.14.2 > touchpad no synaptics event device found (checked 10 nodes) > touchpad The evdev kernel module seems to be missing What's the output from "cat /proc/bus/input/devices"? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: synaptics touchpad not recognized by Xorg X server with recent -mm kernels
Norbert Preining <[EMAIL PROTECTED]> writes: > On Die, 12 Jul 2005, Peter Osterlund wrote: > > What's the output from "cat /proc/bus/input/devices"? > > bad (rc2-mm2) > $ cat /proc/bus/input/devices > I: Bus=0011 Vendor=0002 Product=0007 Version= > N: Name="SynPS/2 Synaptics TouchPad" > P: Phys=isa0060/serio1/input0 > H: Handlers=mouse0 event1 > B: EV=b > B: KEY=6420 0 7000f 0 0 0 0 0 0 0 0 > B: ABS=1103 Looks correct. My guess is that something is wrong with your device nodes. What's the output from "ls -l /dev/input/event*"? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: High irq load (Re: [PATCH] i386: Selectable Frequency of the Timer Interrupt)
Z <= 16 or HZ > 4096
+#if HZ <= 16
+# error Unsupported: HZ <= 16
#elif HZ <= 32
# define TCP_TW_RECYCLE_TICK (5+2-TCP_TW_RECYCLE_SLOTS_LOG)
#elif HZ <= 64
@@ -502,8 +502,14 @@ static __inline__ int tcp_sk_listen_hash
# define TCP_TW_RECYCLE_TICK (10+2-TCP_TW_RECYCLE_SLOTS_LOG)
#elif HZ <= 2048
# define TCP_TW_RECYCLE_TICK (11+2-TCP_TW_RECYCLE_SLOTS_LOG)
-#else
+#elif HZ <= 4096
# define TCP_TW_RECYCLE_TICK (12+2-TCP_TW_RECYCLE_SLOTS_LOG)
+#elif HZ <= 8192
+# define TCP_TW_RECYCLE_TICK (13+2-TCP_TW_RECYCLE_SLOTS_LOG)
+#elif HZ <= 16384
+# define TCP_TW_RECYCLE_TICK (14+2-TCP_TW_RECYCLE_SLOTS_LOG)
+#else
+# error Unsupported: HZ > 16384
#endif
/*
* TCP option
diff --git a/init/calibrate.c b/init/calibrate.c
--- a/init/calibrate.c
+++ b/init/calibrate.c
@@ -119,16 +119,30 @@ void __devinit calibrate_delay(void)
if (preset_lpj) {
loops_per_jiffy = preset_lpj;
+#if HZ <= 5000
printk("Calibrating delay loop (skipped)... "
"%lu.%02lu BogoMIPS preset\n",
loops_per_jiffy/(50/HZ),
(loops_per_jiffy/(5000/HZ)) % 100);
+#else
+ printk("Calibrating delay loop (skipped)... "
+ "%lu.%02lu BogoMIPS preset\n",
+ loops_per_jiffy/(50/HZ),
+ (loops_per_jiffy*(HZ/5000)) % 100);
+#endif
} else if ((loops_per_jiffy = calibrate_delay_direct()) != 0) {
printk("Calibrating delay using timer specific routine.. ");
+#if HZ <= 5000
printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
loops_per_jiffy/(50/HZ),
(loops_per_jiffy/(5000/HZ)) % 100,
loops_per_jiffy);
+#else
+ printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
+ loops_per_jiffy/(50/HZ),
+ (loops_per_jiffy*(HZ/5000)) % 100,
+ loops_per_jiffy);
+#endif
} else {
loops_per_jiffy = (1<<12);
@@ -164,10 +178,17 @@ void __devinit calibrate_delay(void)
}
/* Round the value and print it */
+#if HZ <= 5000
printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
loops_per_jiffy/(50/HZ),
(loops_per_jiffy/(5000/HZ)) % 100,
loops_per_jiffy);
+#else
+ printk("%lu.%02lu BogoMIPS (lpj=%lu)\n",
+ loops_per_jiffy/(50/HZ),
+ (loops_per_jiffy*(HZ/5000)) % 100,
+ loops_per_jiffy);
+#endif
}
}
diff --git a/kernel/Kconfig.hz b/kernel/Kconfig.hz
--- a/kernel/Kconfig.hz
+++ b/kernel/Kconfig.hz
@@ -36,6 +36,11 @@ choice
1000 HZ is the preferred choice for desktop systems and other
systems requiring fast interactive responses to events.
+ config HZ_1
+ bool "1 HZ"
+ help
+1 HZ is for testing only.
+
endchoice
config HZ
@@ -43,4 +48,5 @@ config HZ
default 100 if HZ_100
default 250 if HZ_250
default 1000 if HZ_1000
+ default 1 if HZ_1
diff --git a/kernel/timer.c b/kernel/timer.c
--- a/kernel/timer.c
+++ b/kernel/timer.c
@@ -710,7 +710,7 @@ static void second_overflow(void)
if (ltemp > (MAXPHASE / MINSEC) << SHIFT_UPDATE)
ltemp = (MAXPHASE / MINSEC) << SHIFT_UPDATE;
time_offset += ltemp;
- time_adj = -ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+ time_adj = -ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
} else {
ltemp = time_offset;
if (!(time_status & STA_FLL))
@@ -718,7 +718,7 @@ static void second_overflow(void)
if (ltemp > (MAXPHASE / MINSEC) << SHIFT_UPDATE)
ltemp = (MAXPHASE / MINSEC) << SHIFT_UPDATE;
time_offset -= ltemp;
- time_adj = ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
+ time_adj = ltemp << (SHIFT_SCALE - SHIFT_HZ - SHIFT_UPDATE);
}
/*
diff --git a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
--- a/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
+++ b/net/ipv4/netfilter/ip_conntrack_proto_tcp.c
@@ -87,7 +87,7 @@ static const char *tcp_conntrack_names[]
unsigned long ip_ct_tcp_timeout_syn_sent = 2 MINS;
unsigned long ip_ct_tcp_timeout_syn_recv = 60 SECS;
-unsigned long ip_ct_tcp_timeout_established = 5 DAYS;
+unsigned long ip_ct_tcp_timeout_established = 2 DAYS;
unsigned long ip_ct_tcp_timeout_fin_wait = 2 MINS;
unsigned long ip_ct_tcp_timeout_close_wait = 60 SECS;
unsigned long ip_ct_tcp_timeout_last_ack = 30 SECS;
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
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.
> +void bio_free(struct bio *bio, struct bio_set *bio_set)
> {
> const int pool_idx = BIO_POOL_IDX(bio);
> - struct bio_set *bs = bio->bi_set;
>
> BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
>
> - mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
> - mempool_free(bio, bs->bio_pool);
> + mempool_free(bio->bi_io_vec, fs_bio_set->bvec_pools[pool_idx]);
> + mempool_free(bio, fs_bio_set->bio_pool);
> +}
This function uses fs_bio_set instead of the function parameter
bio_set.
> @@ -171,8 +175,6 @@ struct bio *bio_alloc_bioset(unsigned in
> bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
> }
> bio->bi_io_vec = bvl;
> - bio->bi_destructor = bio_destructor;
> - bio->bi_set = bs;
> }
This change means that all code that calls bio_alloc_bioset() must now
set bi_destructor, but this is forgotten in bio_clone() in bio.c and
in split_bvec() in dm.c.
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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
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.
Signed-off-by: Jens Axboe <[EMAIL PROTECTED]>
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
drivers/md/dm-io.c |6 ++
drivers/md/dm.c |6 ++
fs/bio.c| 32 +---
include/linux/bio.h |2 +-
4 files changed, 34 insertions(+), 12 deletions(-)
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -239,6 +239,11 @@ static void vm_dp_init(struct dpages *dp
dp->context_ptr = data;
}
+static void dm_bio_destructor(struct bio *bio)
+{
+ bio_free(bio, _bios);
+}
+
/*-
* IO routines that accept a list of pages.
*---*/
@@ -263,6 +268,7 @@ static void do_region(int rw, unsigned i
bio->bi_bdev = where->bdev;
bio->bi_end_io = endio;
bio->bi_private = io;
+ bio->bi_destructor = dm_bio_destructor;
bio_set_region(bio, region);
/*
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -399,6 +399,11 @@ struct clone_info {
unsigned short idx;
};
+static void dm_bio_destructor(struct bio *bio)
+{
+ bio_free(bio, dm_set);
+}
+
/*
* Creates a little bio that is just does part of a bvec.
*/
@@ -410,6 +415,7 @@ static struct bio *split_bvec(struct bio
struct bio_vec *bv = bio->bi_io_vec + idx;
clone = bio_alloc_bioset(GFP_NOIO, 1, dm_set);
+ clone->bi_destructor = dm_bio_destructor;
*clone->bi_io_vec = *bv;
clone->bi_sector = sector;
diff --git a/fs/bio.c b/fs/bio.c
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -104,18 +104,22 @@ static inline struct bio_vec *bvec_alloc
return bvl;
}
-/*
- * default destructor for a bio allocated with bio_alloc_bioset()
- */
-static void bio_destructor(struct bio *bio)
+void bio_free(struct bio *bio, struct bio_set *bio_set)
{
const int pool_idx = BIO_POOL_IDX(bio);
- struct bio_set *bs = bio->bi_set;
BIO_BUG_ON(pool_idx >= BIOVEC_NR_POOLS);
- mempool_free(bio->bi_io_vec, bs->bvec_pools[pool_idx]);
- mempool_free(bio, bs->bio_pool);
+ mempool_free(bio->bi_io_vec, bio_set->bvec_pools[pool_idx]);
+ mempool_free(bio, bio_set->bio_pool);
+}
+
+/*
+ * default destructor for a bio allocated with bio_alloc_bioset()
+ */
+static void bio_fs_destructor(struct bio *bio)
+{
+ bio_free(bio, fs_bio_set);
}
inline void bio_init(struct bio *bio)
@@ -171,8 +175,6 @@ struct bio *bio_alloc_bioset(unsigned in
bio->bi_max_vecs = bvec_slabs[idx].nr_vecs;
}
bio->bi_io_vec = bvl;
- bio->bi_destructor = bio_destructor;
- bio->bi_set = bs;
}
out:
return bio;
@@ -180,7 +182,12 @@ out:
struct bio *bio_alloc(unsigned int __nocast gfp_mask, int nr_iovecs)
{
- return bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
+ struct bio *bio = bio_alloc_bioset(gfp_mask, nr_iovecs, fs_bio_set);
+
+ if (bio)
+ bio->bi_destructor = bio_fs_destructor;
+
+ return bio;
}
void zero_fill_bio(struct bio *bio)
@@ -276,8 +283,10 @@ struct bio *bio_clone(struct bio *bio, u
{
struct bio *b = bio_alloc_bioset(gfp_mask, bio->bi_max_vecs,
fs_bio_set);
- if (b)
+ if (b) {
+ b->bi_destructor = bio_fs_destructor;
__bio_clone(b, bio);
+ }
return b;
}
@@ -1078,6 +1087,7 @@ subsys_initcall(init_bio);
EXPORT_SYMBOL(bio_alloc);
EXPORT_SYMBOL(bio_put);
+EXPORT_SYMBOL(bio_free);
EXPORT_SYMBOL(bio_endio);
EXPORT_SYMBOL(bio_init);
EXPORT_SYMBOL(__bio_clone);
diff --git a/include/linux/bio.h b/include/linux/bio.h
--- a/include/linux/bio.h
+++ b/include/linux/bio.h
@@ -111,7 +111,6 @@ struct bio {
void*bi_private;
bio_destructor_t*bi_destructor; /* destructor */
- struct bio_set *bi_set;/* memory pools set */
};
/*
@@ -280,6 +279,7 @@ extern void bioset_fre
Re: [patch 4/8] [PATCH] Update in-kernel zlib routines
Chris Wright <[EMAIL PROTECTED]> writes: > -stable review patch. If anyone has any objections, please let us know. > -- > > a) http://sources.redhat.com/ml/bug-gnu-utils/1999-06/msg00183.html Why does this 6 year old bug have to be fixed in the 2.6.12 stable series? Doesn't the patch violate this stable series rule? - It must fix a real bug that bothers people (not a, "This could be a problem..." type thing.) Maybe the motivation was just missing from the patch description? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 SERIO_RAW config help text
Hi, The help text for SERIO_RAW refers to the wrong sysfs device node. This patch fixes it. Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]> --- linux-petero/drivers/input/serio/Kconfig |2 +- 1 files changed, 1 insertion(+), 1 deletion(-) diff -puN drivers/input/serio/Kconfig~serio-help-fix drivers/input/serio/Kconfig --- linux/drivers/input/serio/Kconfig~serio-help-fix2005-07-05 11:43:25.0 +0200 +++ linux-petero/drivers/input/serio/Kconfig2005-07-05 11:43:25.0 +0200 @@ -175,7 +175,7 @@ config SERIO_RAW allocating minor 1 (that historically corresponds to /dev/psaux) first. To bind this driver to a serio port use sysfs interface: - echo -n "serio_raw" > /sys/bus/serio/devices/serioX/driver + echo -n "serio_raw" > /sys/bus/serio/devices/serioX/drvctl To compile this driver as a module, choose M here: the module will be called serio_raw. _ -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Apple USB Touchpad driver (new)
Stelian Pop <[EMAIL PROTECTED]> writes:
> +Synaptics re-detection problems:
> +
> +
> +The synaptics X11 driver tries to re-open the touchpad input device file
> +(/dev/input/eventX) each time you change from text mode back to X11. If the
> +input device file does not exist at this precise moment, the synaptics driver
> +will give up searching for a touchpad, permanently. You will need to restart
> +X11 if you want to reissue a scan.
I think this particular problem is fixed by the following patch to the
X driver:
--- synaptics.c.old 2005-07-10 00:09:02.0 +0200
+++ synaptics.c 2005-07-10 00:09:12.0 +0200
@@ -524,6 +524,11 @@
local->fd = xf86OpenSerial(local->options);
if (local->fd == -1) {
+ xf86ReplaceStrOption(local->options, "Device", "");
+ SetDeviceAndProtocol(local);
+ local->fd = xf86OpenSerial(local->options);
+}
+if (local->fd == -1) {
xf86Msg(X_WARNING, "%s: cannot open input device\n", local->name);
return !Success;
}
> +static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact) {
I think this CodingStyle violation is quite annoying, because it
prevents emacs from finding the beginning of the function. It should
be written like this:
static int atp_calculate_abs(int *xy_sensors, int nb_sensors, int fact)
{
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Apple USB Touchpad driver (new)
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> Btw, what I don't completely understand is why you need linear
> regression, when you're not trying to detect motion or something like
> that. Basic floating average, or even simpler filtering like the input
> core uses for fuzz could work well enough I believe.
Indeed, this function doesn't make much sense:
+static inline int smooth_history(int x0, int x1, int x2, int x3)
+{
+ return x0 - ( x0 * 3 + x1 - x2 - x3 * 3 ) / 10;
+}
In the X driver, a derivative estimate is computed from the last 4
absolute positions, and in that case the least squares estimate is
given by the factors [.3 .1 -.1 -.3]. However, in this case you want
to compute an absolute position estimate from the last 4 absolute
positions, and in this case the least squares estimate is given by the
factors [.25 .25 .25 .25], ie a floating average. If the function is
changed to this:
+static inline int smooth_history(int x0, int x1, int x2, int x3)
+{
+ return (x0 + x1 + x2 + x3) / 4;
+}
the standard deviation of the noise will be reduced by a factor of 2
compared to the unfiltered values. With the old smooth_history()
function, the noise reduction will only be a factor of 1.29.
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Apple USB Touchpad driver (new)
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Sun, Jul 10, 2005 at 12:48:30AM +0200, Peter Osterlund wrote:
> > Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> >
> > > Btw, what I don't completely understand is why you need linear
> > > regression, when you're not trying to detect motion or something like
> > > that. Basic floating average, or even simpler filtering like the input
> > > core uses for fuzz could work well enough I believe.
> >
> > Indeed, this function doesn't make much sense:
> >
> > +static inline int smooth_history(int x0, int x1, int x2, int x3)
> > +{
> > + return x0 - ( x0 * 3 + x1 - x2 - x3 * 3 ) / 10;
> > +}
>
> Using a function like
>
> return (x_old * 3 + x) / 4;
>
> eliminates the need for a FIFO, and has similar (if not better)
> properties to floating average, because its coefficients are
> [ .25 .18 .14 .10 ... ].
Agreed.
> Setting
>
> absfuzz[ABS_X] = some number;
The patch already does that.
> activates the abovementioned filtering (with additional cutoff and fast
> motion compensation) directly in input.c, which should eliminate a lot
> of the code in the appletouch driver.
I took the liberty to modify the patch myself, making these changes:
* Removed the extra filtering.
* Converted the "open" counter to an "open" flag. (It is still needed
by the atp_resume() function.)
* CodingStyle fixes.
I have only compile tested this as I don't have access to the
hardware, so I don't know how well this works in practice. It's
possible that the "dev->h_count > 3" test in the old patch filtered
out spikes in the input signal.
Also, it might be a good idea to compute an ABS_PRESSURE value instead
of hardcoding it to 100. I think the psum variable in
atp_calculate_abs() can be used, possibly after rescaling.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
Documentation/input/appletouch.txt | 120 +
drivers/usb/input/Kconfig | 19 +
drivers/usb/input/Makefile |1
drivers/usb/input/appletouch.c | 461
4 files changed, 601 insertions(+), 0 deletions(-)
diff --git a/Documentation/input/appletouch.txt
b/Documentation/input/appletouch.txt
new file mode 100644
--- /dev/null
+++ b/Documentation/input/appletouch.txt
@@ -0,0 +1,120 @@
+Apple Touchpad Driver (appletouch)
+--
+ Copyright (C) 2005 Stelian Pop <[EMAIL PROTECTED]>
+
+appletouch is a Linux kernel driver for the USB touchpad found on post
+February 2005 Apple Alu Powerbooks.
+
+This driver is derived from Johannes Berg's appletrackpad driver[1], but it has
+been improved in some areas:
+ * appletouch is a full kernel driver, no userspace program is necessary
+ * appletouch can be interfaced with the synaptics X11 driver, in order
+ to have touchpad acceleration, scrolling, etc.
+
+Credits go to Johannes Berg for reverse-engineering the touchpad protocol,
+Frank Arnold for further improvements, and Alex Harper for some additional
+information about the inner workings of the touchpad sensors.
+
+Usage:
+--
+
+In order to use the touchpad in the basic mode, compile the driver and load
+the module. A new input device will be detected and you will be able to read
+the mouse data from /dev/input/mice (using gpm, or X11).
+
+In X11, you can configure the touchpad to use the synaptics X11 driver, which
+will give additional functionalities, like acceleration, scrolling etc. In
+order to do this, make sure you're using a recent version of the synaptics
+driver (tested with 0.14.2, available from [2]), and configure a new input
+device in your X11 configuration file (take a look below for an example). For
+additional configuration, see the synaptics driver documentation.
+
+ Section "InputDevice"
+ Identifier "Synaptics Touchpad"
+ Driver "synaptics"
+ Option "SendCoreEvents""true"
+ Option "Device""/dev/input/mice"
+ Option "Protocol" "auto-dev"
+ Option "LeftEdge" "0"
+ Option "RightEdge" "850"
+ Option "TopEdge" "0"
+ Option "BottomEdge""645"
+ Option "MinSpeed" "0.4"
+ Option "MaxSpeed" "1"
+ Option "AccelFactor"
local_irq_enable() in __do_softirq()?
Hi, The change "x86_64: Switch to the interrupt stack when running a softirq in local_bh ..." (ed6b676ca8b50e0b538e61c283d52fd04f007abf) contains this: --- a/kernel/softirq.c +++ b/kernel/softirq.c @@ -86,7 +86,7 @@ restart: /* Reset the pending bitmask before enabling irqs */ local_softirq_pending() = 0; - local_irq_enable(); + //local_irq_enable(); h = softirq_vec; @@ -99,7 +99,7 @@ restart: pending >>= 1; } while (pending); - local_irq_disable(); + //local_irq_disable(); pending = local_softirq_pending(); if (pending && --max_restart) Is that intentional? If so, shouldn't the code be removed instead of commented out? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
Linus Torvalds <[EMAIL PROTECTED]> writes: > On Wed, 2 Jan 2008, James Bottomley wrote: > > > Look at the taxonomy of the bug. This is the form of the error: > > > > buffer I/O error on device sr0, logical block 20304 > > attempt to access beyond end of device > > sr0: rw=0, want=81224, limit=40944 > > > > The last limit is the most suggestive, that comes straight from > > bdev->bd_inode->i_size>>9 and is supposed to be the size of the block > > device in 512 byte blocks. For a 4.7GB DVD, it's a little small. > > Nothing in the sr code sets this directly (although it does come from > > get_blkdev() for the first opener). pktcdvd does set it, though ... and > > probably wrongly if the drive in question isn't UDF formatted. pktcdvd sets it when opening the /dev/pktcdvd device, but when the drive is later opened as /dev/scd0, there is nothing that sets it back. (Btw, 40944 is possible if the disk is a CDRW that was formatted with "cdrwtool -m 10236".) The problem is that pktcdvd opens the cd device in non-blocking mode when pktsetup is run, and doesn't close it again until pktsetup -d is run. The effect is that if you meanwhile open the cd device, blkdev.c:do_open() doesn't call bd_set_size() because bdev->bd_openers is non-zero. I don't know the correct way to fix this. Maybe adding bd_set_size() to sr.c:get_sectorsize() which already does set_capacity() would work. > .. but you're ignoring the fact that if pktcdvd sets it wrong, then it > should be visible with the pre-commit kernel *also*. I can repeat this bug, both with and without the scsi patch that is claimed to make a difference, both with an external USB drive and an internal IDE drive. To repeat: 1. Start with an empty drive. 2. pktsetup 0 /dev/scd0 3. Insert a CD containing an isofs filesystem. 4. mount /dev/pktcdvd/0 /mnt/tmp 5. umount /mnt/tmp 6. Press the eject button. 7. Insert a DVD containing a non-writable filesystem. 8. mount /dev/scd0 /mnt/tmp 9. find /mnt/tmp -type f -print0 | xargs -0 sha1sum >/dev/null 10. If the DVD contains data beyond the physical size of a CD, you get I/O errors in the terminal, and dmesg reports lots of "attempt to access beyond end of device" errors. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
Linus Torvalds <[EMAIL PROTECTED]> writes:
> Does a patch like this change the behaviour you see at all?
> + bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
It does fix my scenario, with the trivial fix of adding bdev-> at the
beginning of that line, ie:
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 993f78c..a8ed344 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct file
*file, int for_part)
}
if (bdev->bd_invalidated)
rescan_partitions(bdev->bd_disk, bdev);
+ bdev->bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
}
}
bdev->bd_openers++;
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] scsi: revert "[SCSI] Get rid of scsi_cmnd->done"
On Sun, 6 Jan 2008, James Bottomley wrote:
On Sat, 2008-01-05 at 19:43 -0800, Linus Torvalds wrote:
diff --git a/fs/block_dev.c b/fs/block_dev.c
index 993f78c..6a20da9 100644
--- a/fs/block_dev.c
+++ b/fs/block_dev.c
@@ -1191,6 +1191,7 @@ static int do_open(struct block_device *bdev, struct file
*file, int for_part)
}
if (bdev->bd_invalidated)
rescan_partitions(bdev->bd_disk, bdev);
+ bd_inode->i_size = (loff_t)get_capacity(disk)<<9;
}
}
bdev->bd_openers++;
Actually, I think that code is fine ... the block size shouldn't change
across positive values of bd_openers. I think the true fix is below:
pktcdvd shouldn't be mucking with the size of the underlying CD/DVD ...
it can change its own layered device capacity, certainly, but it
shouldn't be mucking with the capacity that was already set in the
sr_probe routine. I'm in two minds as to whether the set capacity on
the underlying device should be removed as well ... I think it should,
but it is harmless as the sr_probe will also reset it.
However, I'll defer to what Al wants to do.
James
diff --git a/drivers/block/pktcdvd.c b/drivers/block/pktcdvd.c
index 3535ef8..10f3692 100644
--- a/drivers/block/pktcdvd.c
+++ b/drivers/block/pktcdvd.c
@@ -2344,7 +2344,6 @@ static int pkt_open_dev(struct pktcdvd_device *pd, int
write)
set_capacity(pd->disk, lba << 2);
set_capacity(pd->bdev->bd_disk, lba << 2);
- bd_set_size(pd->bdev, (loff_t)lba << 11);
q = bdev_get_queue(pd->bdev);
if (write) {
That code was added to fix a similar bug, see:
http://linux.derkeiler.com/Mailing-Lists/Kernel/2004-08/4288.html
Maybe that fix was wrong and should have just set bd_inode->i_size instead
of calling bd_set_size().
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: touchpad dragging problem
Miguelanxo Otero Salgueiro <[EMAIL PROTECTED]> writes: > Andrew Morton wrote: > > >Miguelanxo Otero Salgueiro <[EMAIL PROTECTED]> wrote: > > > >> I just compiled 2.6.11 from a 2.6.10 configuration for a desktop > >> machine (with kernel preemption activated). ... > >> Apart from the ALPS touchpad thing (see "2.6.11: touchpad > >> unresponsive"), the new kernel keeps: > > > >You appear to have about five bugs here. Do any of them remain in > >2.6.12-rc1? > > > Well, one thing outstands: the synaptic touchpad is now really > comfortable to use. Almost everything works, including simple and > double clicks, and scrolling. Dragging is still broken. I must note > I'm now using a synaptic Xinput driver, as suggested. What parameter settings do you use in the X driver? If you have SHMConfig enabled, you can run "synclient -l" to find out. Does increasing MaxTapTime help? > As for dragging, it was ok in 2.6.10 and previous, but currently > broken. Probably because 2.6.10 didn't have the kernel ALPS driver, so you got whatever features the firmware emulates in its PS/2 compatibility mode. With the kernel ALPS driver, the touchpad is put into "raw" mode, so you instead get whatever features the kernel or the X driver implements. Andrew Morton <[EMAIL PROTECTED]> writes: > Also, I'd consider it a regression that you had to go and find new X > drivers due to a kernel change. We shouldn't do that. The problem is that mousedev.c doesn't implement "tap and drag" emulation, so all Synaptics and ALPS touchpads that have firmware support for dragging have seen a regression compared to a 2.4 kernel. (For synaptics, the regression happened at ~2.5.7x, for ALPS it happened at 2.6.11.) The situation is the same with scroll emulation that some touchpads do in firmware. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Touchpad problems with 2.6.11-rc2
Stephane Raimbault <[EMAIL PROTECTED]> writes: > I'm using 2.6.11-rc3 + Peter's patch and xorg from Fedora Core 3, I > still have touchpad problems. > > Tapping and focus work fine with 2.6.10 and 2.6.11-rc1 but not with : > - 2.6.11-rc2 > - 2.6.11-rc3 > I read a similar report on LKML from David Ford. > Only one tap on 30 is received and focus is really strange. > > Like said in previous mails, small movements are rounded off to 0 but > the Peter Osterlund's patch resolves this problem (tested with rc3). > > Hardware > kernel: input: AlpsPS/2 ALPS TouchPad on isa0 060/serio1 > Vaio GRT916V > > In my xorg.conf : > Driver "mouse" > Option "Protocol" "IMPS/2" Does the "Enable hardware tapping for ALPS touchpads" patch help? http://marc.theaimsgroup.com/?l=linux-kernel&m=110708138225873&w=2 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
Robert Love <[EMAIL PROTECTED]> writes: > On Sun, 2005-02-06 at 22:22 +0100, Peter Osterlund wrote: > > > > > > EIP is a strncpy_from_user+0x33/0x47 > > > > > ... > > > > > Call Trace: > > > > > getname+0x69/0xa5 > > > > > sys_open+0x12/0xc6 > > > > > sysenter_past_esp+0x52/0x75 > > > > > ... > > > > > Kernel panic - not syncing: Attempted to kill init! > > > > I found the if I disable CONFIG_INOTIFY, the problem goes away. > > Weird. While we touch sys_open() with an inotify hook, we do so after > the call to getname, and we don't touch getname() or strncpy_from_user() > at all. > > I wonder if there is another bug and inotify is just affecting the > timing? Possible, but it fails every time with CONFIG_INOTIFY enabled and works every time with CONFIG_INOTIFY disabled. I added some printk's to do_getname and got this: ... Freeing unused kernel memory: 160k freed ... do_getname: init /etc/localtime do_getname: init seg:1 page:df404000 filename:455dd11f len:4096 do_getname: init /etc/localtime do_getname: init seg:1 page:df404000 filename:455dd11f len:4096 do_getname: init /etc/localtime do_getname: init seg:1 page:df404000 filename:455dd11f len:4096 do_getname: init /etc/localtime do_getname: init seg:1 page:df404000 filename: len:4096 Unable to handle kernel NULL pointer dereference at virtual address printing eip: c01d8257 *pde = Oops: [#1] PREEMPT Modules linked in: CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00010206 (2.6.11-rc3-mm1) EIP is at strncpy_from_user+0x33/0x47 eax: c14f ebx: fff2 ecx: 1000 edx: 1000 esi: edi: df404000 ebp: esp: c14f1f60 ds: 007b es: 007b ss: 0068 Process init (pid: 1, threadinfo=c14f task=dff4ba40) Stack: c14f fff4 df404000 c0166854 df404000 1000 df404000 1000 1000 0901 c14f c0158725 0002 0901 Call Trace: [] getname+0xb4/0x10f [] sys_open+0x12/0xc6 [] sysenter_past_esp+0x52/0x75 Code: 57 56 53 bb f2 ff ff ff 8b 74 24 18 8b 7c 24 14 8b 4c 24 1c 89 f2 83 c2 01 19 ed 39 50 18 83 dd 00 85 ed 75 13 89 ca 85 c9 74 0b aa 84 c0 74 03 49 75 f7 29 ca 89 d3 89 d8 5b 5e 5f 5d c3 57 do_getname: hotplug seg:1 page:dfca1000 filename:080e6770 len:4096 do_getname: hotplug /etc/hotplug.d/default/20-hal.hotplug do_getname: hotplug seg:1 page:df6d1000 filename:080e6770 len:4096 do_getname: hotplug /etc/hotplug.d/default/20-hal.hotplug Kernel panic - not syncing: Attempted to kill init! If I add this code to do_getname() + if (!filename) + return -EFAULT; the machine boots correctly, but then fails later when trying to start the X server: Unable to handle kernel paging request at virtual address 8050 printing eip: c01d840a *pde = 16fd4067 *pte = Oops: 0002 [#1] PREEMPT Modules linked in: radeon joydev mousedev nfs psmouse snd_atiixp_modem nfsd exportfs lockd parport_pc lp parport autofs4 pcmcia sunrpc ipt_LOG ipt_limit ipt_state ipt_REJECT iptable_filter ipt_MASQUERADE iptable_nat ip_tables binfmt_misc dm_mod yenta_socket rsrc_nonstatic pcmcia_core ohci_hcd ehci_hcd usbcore ide_cd cdrom CPU:0 EIP:0060:[]Not tainted VLI EFLAGS: 00013246 (2.6.11-rc3-mm1) EIP is at __copy_to_user_ll+0x3c/0x64 eax: ebx: 8050 ecx: 0002 edx: 8058 esi: e1a5cc67 edi: 8050 ebp: esp: d75e9e58 ds: 007b es: 007b ss: 0068 Process X (pid: 4757, threadinfo=d75e8000 task=d7584020) Stack: 0027 8050 e1a5cc70 c01d84ce 8050 e1a5cc67 0008 0008 d75e9ec8 e1a51140 8050 e1a5cc67 0008 d75e9f08 c01d8511 d75e9f08 bfd4a320 d7957800 bfd4a320 d75e9f08 ffea Call Trace: [] copy_to_user+0x38/0x42 [] version+0xe8/0x138 [radeon] [] copy_from_user+0x39/0x68 [] drm_setversion+0x49/0x11b [] drm_ioctl+0xeb/0x1c1 [] handle_vm86_fault+0x78f/0x909 [] handle_vm86_fault+0x78f/0x909 [] do_ioctl+0x57/0x85 [] handle_vm86_fault+0x78f/0x909 [] vfs_ioctl+0x5c/0x1c3 [] handle_vm86_fault+0x78f/0x909 [] sys_ioctl+0x3c/0x59 [] handle_vm86_fault+0x78f/0x909 [] sysenter_past_esp+0x52/0x75 [] handle_vm86_fault+0x78f/0x909 Code: 83 f9 3f 76 0c 89 f8 31 f0 85 05 80 bd 44 c0 75 28 89 c8 83 f9 07 76 17 89 f9 f7 d9 83 e1 07 29 c8 f3 a4 89 c1 c1 e9 02 83 e0 03 a5 89 c1 f3 a4 83 c4
Re: Touchpad problems with 2.6.11-rc2
Stephane Raimbault <[EMAIL PROTECTED]> writes: > > Does the "Enable hardware tapping for ALPS touchpads" patch help? > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110708138225873&w=2 > > > > Yes, works really better but the release event is sent only if I move > the pointer. It's as if I still put my finger on the touchpad. That's a different bug that has already been fixed in 2.6.11-rc3-bk6. http://linus.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED]|[EMAIL PROTECTED] -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 1/4] Make mousedev.c report all events to user space immediately
mousedev_packet() incorrectly clears list->ready when called with
"tail == head - 1". The effect is that the last mouse event from the
hardware isn't reported to user space until another hardware mouse
event arrives. This can make the left mouse button get stuck when
tapping on a touchpad. When this happens, the button doesn't unstick
until the next time you interact with the touchpad.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mousedev.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/input/mousedev.c~mousedev-ready-fix drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-ready-fix 2005-01-30
03:06:49.0 +0100
+++ linux-petero/drivers/input/mousedev.c 2005-01-30 03:06:49.0
+0100
@@ -467,10 +467,10 @@ static void mousedev_packet(struct mouse
}
if (!p->dx && !p->dy && !p->dz) {
- if (list->tail != list->head)
- list->tail = (list->tail + 1) % PACKET_QUEUE_LEN;
if (list->tail == list->head)
list->ready = 0;
+ else
+ list->tail = (list->tail + 1) % PACKET_QUEUE_LEN;
}
spin_unlock_irqrestore(&list->packet_lock, flags);
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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/4] Enable hardware tapping for ALPS touchpads
When hardware tapping is disabled on an ALPS touchpad, the touchpad
generates exactly the same data for a single tap and a fast double
tap. The effect is that the second tap in the double tap sequence is
lost.
To fix this problem, this patch enables hardware tapping and converts
the resulting tap and gesture bits to standard finger pressure values
(z), which is what mousedev.c and the userspace X driver expects.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mouse/alps.c | 53 +---
linux-petero/drivers/input/mouse/alps.h |4 ++
2 files changed, 47 insertions(+), 10 deletions(-)
diff -puN drivers/input/mouse/alps.c~alps-hwtaps drivers/input/mouse/alps.c
--- linux/drivers/input/mouse/alps.c~alps-hwtaps2005-01-30
11:22:30.0 +0100
+++ linux-petero/drivers/input/mouse/alps.c 2005-01-30 11:22:30.0
+0100
@@ -78,10 +78,12 @@ struct alps_model_info {
static void alps_process_packet(struct psmouse *psmouse, struct pt_regs *regs)
{
+ struct alps_data *priv = psmouse->private;
unsigned char *packet = psmouse->packet;
struct input_dev *dev = &psmouse->dev;
int x, y, z;
int left = 0, right = 0, middle = 0;
+ int ges, fin;
input_regs(dev, regs);
@@ -123,6 +125,27 @@ static void alps_process_packet(struct p
return;
}
+ ges = packet[2] & 1;/* gesture bit */
+ fin = packet[2] & 2;/* finger bit */
+
+ /* Convert hardware tap to a reasonable Z value */
+ if (ges && !fin)
+ z = 40;
+
+ /*
+* A "tap and drag" operation is reported by the hardware as a
transition
+* from (!fin && ges) to (fin && ges). This should be translated to the
+* sequence Z>0, Z==0, Z>0, so the Z==0 event has to be generated
manually.
+*/
+ if (ges && fin && !priv->prev_fin) {
+ input_report_abs(dev, ABS_X, x);
+ input_report_abs(dev, ABS_Y, y);
+ input_report_abs(dev, ABS_PRESSURE, 0);
+ input_report_key(dev, BTN_TOOL_FINGER, 0);
+ input_sync(dev);
+ }
+ priv->prev_fin = fin;
+
if (z > 30) input_report_key(dev, BTN_TOUCH, 1);
if (z < 25) input_report_key(dev, BTN_TOUCH, 0);
@@ -133,7 +156,6 @@ static void alps_process_packet(struct p
input_report_abs(dev, ABS_PRESSURE, z);
input_report_key(dev, BTN_TOOL_FINGER, z > 0);
- left |= (packet[2] ) & 1;
left |= (packet[3] ) & 1;
right |= (packet[3] >> 1) & 1;
if (packet[0] == 0xff) {
@@ -335,7 +357,7 @@ static int alps_reconnect(struct psmouse
return -1;
if (param[0] & 0x04)
- alps_tap_mode(psmouse, 0);
+ alps_tap_mode(psmouse, 1);
if (alps_absolute_mode(psmouse)) {
printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
@@ -351,40 +373,47 @@ static int alps_reconnect(struct psmouse
static void alps_disconnect(struct psmouse *psmouse)
{
psmouse_reset(psmouse);
+ kfree(psmouse->private);
}
int alps_init(struct psmouse *psmouse)
{
+ struct alps_data *priv;
unsigned char param[4];
int model;
+ psmouse->private = priv = kmalloc(sizeof(struct alps_data), GFP_KERNEL);
+ if (!priv)
+ goto init_fail;
+ memset(priv, 0, sizeof(struct alps_data));
+
if ((model = alps_get_model(psmouse)) < 0)
- return -1;
+ goto init_fail;
printk(KERN_INFO "ALPS Touchpad (%s) detected\n",
model == ALPS_MODEL_GLIDEPOINT ? "Glidepoint" : "Dualpoint");
if (model == ALPS_MODEL_DUALPOINT && alps_passthrough_mode(psmouse, 1))
- return -1;
+ goto init_fail;
if (alps_get_status(psmouse, param)) {
printk(KERN_ERR "alps.c: touchpad status report request
failed\n");
- return -1;
+ goto init_fail;
}
if (param[0] & 0x04) {
- printk(KERN_INFO " Disabling hardware tapping\n");
- if (alps_tap_mode(psmouse, 0))
- printk(KERN_WARNING "alps.c: Failed to disable hardware
tapping\n");
+ printk(KERN_INFO " Enabling hardware tapping\n");
+ if (alps_tap_mode(psmouse, 1))
+ printk(KERN_WARNING "alps.c: Failed to enable hardware
tapping\n");
}
if (alps_absolute_mode(psmouse)) {
printk(KERN_ERR "alps.c: Failed to enable absolute mode\n");
- return -1;
+ goto init_fail;
[PATCH 3/4] Fix "pointer jumps to corner of screen" problem on ALPS Glidepoint touchpads.
Only parse a "z == 127" packet as a relative Dualpoint stick packet if
the touchpad actually is a Dualpoint device. The Glidepoint models
don't have a stick, and can report z == 127 for a very wide finger. If
such a packet is parsed as a stick packet, the mouse pointer will
typically jump to one corner of the screen.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mouse/alps.c | 20 ++--
linux-petero/drivers/input/mouse/alps.h |1 +
2 files changed, 11 insertions(+), 10 deletions(-)
diff -puN drivers/input/mouse/alps.c~alps-glidepoint-has-no-stick
drivers/input/mouse/alps.c
--- linux/drivers/input/mouse/alps.c~alps-glidepoint-has-no-stick
2005-01-30 11:22:32.0 +0100
+++ linux-petero/drivers/input/mouse/alps.c 2005-01-30 11:22:32.0
+0100
@@ -109,7 +109,8 @@ static void alps_process_packet(struct p
y = (packet[4] & 0x7f) | ((packet[3] & 0x70)<<(7-4));
z = packet[5];
- if (z == 127) { /* DualPoint stick is relative, not absolute */
+ if ((priv->model == ALPS_MODEL_DUALPOINT) && (z == 127)) {
+ /* DualPoint stick, relative packet */
if (x > 383)
x = x - 768;
if (y > 255)
@@ -344,13 +345,13 @@ static int alps_tap_mode(struct psmouse
static int alps_reconnect(struct psmouse *psmouse)
{
- int model;
+ struct alps_data *priv = psmouse->private;
unsigned char param[4];
- if ((model = alps_get_model(psmouse)) < 0)
+ if ((priv->model = alps_get_model(psmouse)) < 0)
return -1;
- if (model == ALPS_MODEL_DUALPOINT && alps_passthrough_mode(psmouse, 1))
+ if (priv->model == ALPS_MODEL_DUALPOINT &&
alps_passthrough_mode(psmouse, 1))
return -1;
if (alps_get_status(psmouse, param))
@@ -364,7 +365,7 @@ static int alps_reconnect(struct psmouse
return -1;
}
- if (model == ALPS_MODEL_DUALPOINT && alps_passthrough_mode(psmouse, 0))
+ if (priv->model == ALPS_MODEL_DUALPOINT &&
alps_passthrough_mode(psmouse, 0))
return -1;
return 0;
@@ -380,20 +381,19 @@ int alps_init(struct psmouse *psmouse)
{
struct alps_data *priv;
unsigned char param[4];
- int model;
psmouse->private = priv = kmalloc(sizeof(struct alps_data), GFP_KERNEL);
if (!priv)
goto init_fail;
memset(priv, 0, sizeof(struct alps_data));
- if ((model = alps_get_model(psmouse)) < 0)
+ if ((priv->model = alps_get_model(psmouse)) < 0)
goto init_fail;
printk(KERN_INFO "ALPS Touchpad (%s) detected\n",
- model == ALPS_MODEL_GLIDEPOINT ? "Glidepoint" : "Dualpoint");
+ priv->model == ALPS_MODEL_GLIDEPOINT ? "Glidepoint" :
"Dualpoint");
- if (model == ALPS_MODEL_DUALPOINT && alps_passthrough_mode(psmouse, 1))
+ if (priv->model == ALPS_MODEL_DUALPOINT &&
alps_passthrough_mode(psmouse, 1))
goto init_fail;
if (alps_get_status(psmouse, param)) {
@@ -412,7 +412,7 @@ int alps_init(struct psmouse *psmouse)
goto init_fail;
}
- if (model == ALPS_MODEL_DUALPOINT && alps_passthrough_mode(psmouse, 0))
+ if (priv->model == ALPS_MODEL_DUALPOINT &&
alps_passthrough_mode(psmouse, 0))
goto init_fail;
psmouse->dev.evbit[LONG(EV_REL)] |= BIT(EV_REL);
diff -puN drivers/input/mouse/alps.h~alps-glidepoint-has-no-stick
drivers/input/mouse/alps.h
--- linux/drivers/input/mouse/alps.h~alps-glidepoint-has-no-stick
2005-01-30 11:22:32.0 +0100
+++ linux-petero/drivers/input/mouse/alps.h 2005-01-30 11:22:32.0
+0100
@@ -15,6 +15,7 @@ int alps_detect(struct psmouse *psmouse,
int alps_init(struct psmouse *psmouse);
struct alps_data {
+ int model; /* Glidepoint or Dualpoint */
int prev_fin; /* Finger bit from previous packet
*/
};
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 4/4] Add support for Synaptics touchpad scroll wheels
Some Synaptics touchpads have a middle mouse button that also works as
a scroll wheel. Scroll data is reported as packets with w == 2 and
the scroll amount in byte 1, treated as a signed character. For some
reason, the smallest possible wheel movement is reported as a scroll
amount of 4 units. This amount is typically spread out over more than
one packet, so the driver has to accumulate scroll delta values to
correctly deal with this.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mouse/synaptics.c | 28 +--
linux-petero/drivers/input/mouse/synaptics.h |2 +
2 files changed, 28 insertions(+), 2 deletions(-)
diff -puN drivers/input/mouse/synaptics.c~synaptics-scroll-wheel
drivers/input/mouse/synaptics.c
--- linux/drivers/input/mouse/synaptics.c~synaptics-scroll-wheel
2005-01-30 11:22:34.0 +0100
+++ linux-petero/drivers/input/mouse/synaptics.c2005-01-30
11:22:34.0 +0100
@@ -322,8 +322,11 @@ static void synaptics_parse_hw_state(uns
hw->left = (buf[0] & 0x01) ? 1 : 0;
hw->right = (buf[0] & 0x02) ? 1 : 0;
- if (SYN_CAP_MIDDLE_BUTTON(priv->capabilities))
+ if (SYN_CAP_MIDDLE_BUTTON(priv->capabilities)) {
hw->middle = ((buf[0] ^ buf[3]) & 0x01) ? 1 : 0;
+ if (hw->w == 2)
+ hw->scroll = (signed char)(buf[1]);
+ }
if (SYN_CAP_FOUR_BUTTON(priv->capabilities)) {
hw->up = ((buf[0] ^ buf[3]) & 0x01) ? 1 : 0;
@@ -379,6 +382,26 @@ static void synaptics_process_packet(str
synaptics_parse_hw_state(psmouse->packet, priv, &hw);
+ if (hw.scroll) {
+ priv->scroll += hw.scroll;
+
+ while (priv->scroll >= 4) {
+ input_report_key(dev, BTN_BACK, !hw.down);
+ input_sync(dev);
+ input_report_key(dev, BTN_BACK, hw.down);
+ input_sync(dev);
+ priv->scroll -= 4;
+ }
+ while (priv->scroll <= -4) {
+ input_report_key(dev, BTN_FORWARD, !hw.up);
+ input_sync(dev);
+ input_report_key(dev, BTN_FORWARD, hw.up);
+ input_sync(dev);
+ priv->scroll += 4;
+ }
+ return;
+ }
+
if (hw.z > 0) {
num_fingers = 1;
finger_width = 5;
@@ -528,7 +551,8 @@ static void set_input_params(struct inpu
if (SYN_CAP_MIDDLE_BUTTON(priv->capabilities))
set_bit(BTN_MIDDLE, dev->keybit);
- if (SYN_CAP_FOUR_BUTTON(priv->capabilities)) {
+ if (SYN_CAP_FOUR_BUTTON(priv->capabilities) ||
+ SYN_CAP_MIDDLE_BUTTON(priv->capabilities)) {
set_bit(BTN_FORWARD, dev->keybit);
set_bit(BTN_BACK, dev->keybit);
}
diff -puN drivers/input/mouse/synaptics.h~synaptics-scroll-wheel
drivers/input/mouse/synaptics.h
--- linux/drivers/input/mouse/synaptics.h~synaptics-scroll-wheel
2005-01-30 11:22:34.0 +0100
+++ linux-petero/drivers/input/mouse/synaptics.h2005-01-30
11:22:34.0 +0100
@@ -92,6 +92,7 @@ struct synaptics_hw_state {
unsigned int up:1;
unsigned int down:1;
unsigned char ext_buttons;
+ signed char scroll;
};
struct synaptics_data {
@@ -103,6 +104,7 @@ struct synaptics_data {
unsigned char pkt_type; /* packet type - old, new, etc
*/
unsigned char mode; /* current mode byte */
+ int scroll;
};
#endif /* _SYNAPTICS_H */
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Touchpad problems with 2.6.11-rc2
Pete Zaitcev <[EMAIL PROTECTED]> writes: > Since the 2.6.11-rc2, I encounter problems with touchpad and keyboard > on my laptop, Dell Lattitude D600. The following patch appears to be > the culprit: [alps touchpad detection fix patch] > Without the patch, touchpad is not detected as such. Instead, dmesg shows: > > input: PS/2 Generic Mouse on isa0060/serio1 > > With this patch, I see this: > > ALPS Touchpad (Dualpoint) detected > Disabling hardware tapping > input: AlpsPS/2 ALPS TouchPad on isa0060/serio1 > > Looks like detection is correct, however either ALPS specific code doesn't > work > right, or it sets wrong parameters, I cannot tell. Here's the list of > problems, > from worst to least annoying: I have posted 4 patches to LKML earlier today. Some of them might fix some of your problems. > - Very often, keyboard stops working after a click. Typing anything has no > effect. > However, any smallest pointer movement will restore keyboard, and then an > application receives all buffered characters. This is very bad. It would be interesting to know at which level the problem appears. Can you reproduce the problem using "xev"? If xev works as expected, the problem is possibly that the left mouse button gets stuck and stops your application from accepting keyboard input. This patch fixes the button stuck problem: [PATCH 1/4] Make mousedev.c report all events to user space immediately If the keyboard gets stuck also using "xev", the problem is at a lower level. Enable i8042_debug in drivers/input/serio/i8042.c to see if the keyboards produces any data in the stuck state. > - Double-click sometimes fails to work. I have to wait a second and retry it. > Retrying right away is likely not to work again. Probably fixed by this patch: [PATCH 2/4] Enable hardware tapping for ALPS touchpads > - Slow motion of finger produces no motion, then a jump. So, it's very hard to > target smaller UI elements and some web links. I see this too when I don't use the X touchpad driver. With the X driver there is no problem. I think the problem is that mousedev.c in the kernel has to use integer arithmetic, so probably small movements are rounded off to 0. I'll try to come up with a fix for this. > P.S. I hate the tap, so keep it disabled by default, please :-) You can disable tapping by setting the tap_time parameter for mousedev.c to 0. The default value is 200ms. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Touchpad problems with 2.6.11-rc2
Dmitry Torokhov <[EMAIL PROTECTED]> writes: > On Tue, 25 Jan 2005 11:55:20 -0800, David Brownell <[EMAIL PROTECTED]> wrote: > > The more serious one is that sometimes it seems to spontaneously emit click > > events while I'm moving finger across pad. Which means I've had to learn to > > plan my "mouse" motions to avoid areas where clicking could have bad > > effects. > > But that's not always possible ... > > That is default sensitivity not suiting your habits I think. I would > recomment trying out Synaptics X driver (which also does ALPS) so you > will be able adjust sensitivity the way you like it. I think the problem is that the tap detection in mousedev.c is very simplistic. It always generates a button click if the time between "finger down" and "finger up" is small enough, even if the finger was moved a large x/y distance. The X driver handles this with another parameter that specifies the maximum allowed distance. If the finger moved more than this distance, no button event is generated. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Touchpad problems with 2.6.11-rc2
Pete Zaitcev <[EMAIL PROTECTED]> writes:
> On 30 Jan 2005 12:10:34 +0100, Peter Osterlund <[EMAIL PROTECTED]> wrote:
>
> > > - Slow motion of finger produces no motion, then a jump. So, it's very
> > > hard to
> > > target smaller UI elements and some web links.
> >
> > I see this too when I don't use the X touchpad driver. With the X
> > driver there is no problem. I think the problem is that mousedev.c in
> > the kernel has to use integer arithmetic, so probably small movements
> > are rounded off to 0. I'll try to come up with a fix for this.
>
> Thanks for the hint. I tried various schemes and mathematical transformations
> and found one which gives unquestionably the best result, with smoothest, most
> precise and comfortable pointer movement:
Please try this patch instead. It works well with my alps touchpad. (I
don't have a synaptics touchpad.) It does the following:
* Compensates for the lack of floating point arithmetic by keeping
track of remainders from the integer divisions.
* Removes the xres/yres scaling so that you get the same speed in the
X and Y directions even if your screen is not square.
* Sets scale factors so that the speed for synaptics and alps should
be equal to each other and equal to the synaptics speed from 2.6.10.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mousedev.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff2005-02-02
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c 2005-02-02 21:42:39.0
+0100
@@ -71,6 +71,7 @@ struct mousedev {
struct mousedev_hw_data packet;
unsigned int pkt_count;
int old_x[4], old_y[4];
+ int frac_dx, frac_dy;
unsigned long touch;
};
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev
*mousedev, unsigned int code, int value)
{
- int size;
+ int size, tmp;
+#define FRACTION_DENOM 100
if (mousedev->touch) {
+ size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+ if (size == 0) size = xres;
switch (code) {
case ABS_X:
- size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
- if (size == 0) size = xres;
fx(0) = value;
- if (mousedev->pkt_count >= 2)
- mousedev->packet.dx = ((fx(0) - fx(1))
/ 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+ if (mousedev->pkt_count >= 2) {
+ tmp = ((fx(0) - fx(2)) * (250 *
FRACTION_DENOM)) / size;
+ tmp += mousedev->frac_dx;
+ mousedev->packet.dx = tmp /
FRACTION_DENOM;
+ mousedev->frac_dx = tmp -
mousedev->packet.dx * FRACTION_DENOM;
+ }
break;
case ABS_Y:
- size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
- if (size == 0) size = yres;
fy(0) = value;
- if (mousedev->pkt_count >= 2)
- mousedev->packet.dy = -((fy(0) - fy(1))
/ 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+ if (mousedev->pkt_count >= 2) {
+ tmp = -((fy(0) - fy(2)) * (250 *
FRACTION_DENOM)) / size;
+ tmp += mousedev->frac_dy;
+ mousedev->packet.dy = tmp /
FRACTION_DENOM;
+ mousedev->frac_dy = tmp -
mousedev->packet.dy * FRACTION_DENOM;
+ }
break;
}
}
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Touchpad problems with 2.6.11-rc2
Dmitry Torokhov <[EMAIL PROTECTED]> writes:
> On Wed, 02 Feb 2005 13:07:21 -0800 (PST), Peter Osterlund
> <[EMAIL PROTECTED]> wrote:
> > + if (mousedev->pkt_count >= 2) {
> > + tmp = ((fx(0) - fx(2)) * (250 *
> > FRACTION_DENOM)) / size;
> > + tmp += mousedev->frac_dx;
> > + mousedev->packet.dx = tmp /
> > FRACTION_DENOM;
> > + mousedev->frac_dx = tmp -
> > mousedev->packet.dx * FRACTION_DENOM;
> > + }
>
> What about setting scale to 256 and fractions to 128 - that should
> save some cycles? Or it will be too much?
It at least saves 32 bytes of object code. The mouse pointer speed
increase will only be 256/250, or 2.4%, so shouldn't be a problem.
Setting FRACTION_DENOM to a larger value is actually a good thing as
long as it doesn't cause arithmetic overflow.
Here is an updated patch:
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mousedev.c | 26 +-
1 files changed, 17 insertions(+), 9 deletions(-)
diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff2005-02-02
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c 2005-02-02 22:20:15.0
+0100
@@ -71,6 +71,7 @@ struct mousedev {
struct mousedev_hw_data packet;
unsigned int pkt_count;
int old_x[4], old_y[4];
+ int frac_dx, frac_dy;
unsigned long touch;
};
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev
*mousedev, unsigned int code, int value)
{
- int size;
+ int size, tmp;
+#define FRACTION_DENOM 128
if (mousedev->touch) {
+ size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+ if (size == 0) size = xres;
switch (code) {
case ABS_X:
- size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
- if (size == 0) size = xres;
fx(0) = value;
- if (mousedev->pkt_count >= 2)
- mousedev->packet.dx = ((fx(0) - fx(1))
/ 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+ if (mousedev->pkt_count >= 2) {
+ tmp = ((fx(0) - fx(2)) * (256 *
FRACTION_DENOM)) / size;
+ tmp += mousedev->frac_dx;
+ mousedev->packet.dx = tmp /
FRACTION_DENOM;
+ mousedev->frac_dx = tmp -
mousedev->packet.dx * FRACTION_DENOM;
+ }
break;
case ABS_Y:
- size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
- if (size == 0) size = yres;
fy(0) = value;
- if (mousedev->pkt_count >= 2)
- mousedev->packet.dy = -((fy(0) - fy(1))
/ 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+ if (mousedev->pkt_count >= 2) {
+ tmp = -((fy(0) - fy(2)) * (256 *
FRACTION_DENOM)) / size;
+ tmp += mousedev->frac_dy;
+ mousedev->packet.dy = tmp /
FRACTION_DENOM;
+ mousedev->frac_dy = tmp -
mousedev->packet.dy * FRACTION_DENOM;
+ }
break;
}
}
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005, Dmitry Torokhov wrote:
> On Wed, 02 Feb 2005 13:52:03 -0800 (PST), Peter Osterlund
> <[EMAIL PROTECTED]> wrote:
> >
> >if (mousedev->touch) {
> > + size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
> > + if (size == 0) size = xres;
>
> Sorry, missed this piece first time around. Since we don't want to
> rely on screen size anymore I think we should set size = 256 *
> FRACTION_DENOM / 2 if device limits are not set up to just report raw
> coords. What do you think?
I think that this case can't happen until we add support for some other
touchpad that doesn't set the absmin/absmax variables. Both alps and
synaptics currently set them.
However, the fallback value should definitely not depend on
FRACTION_DENOM, since this constant doesn't affect the mouse speed at all.
It only affects how accurately we store the fractional part of dx and dy.
Ideally FRACTION_DENOM should be as large as possible without causing
arithmetic overflow. In practice, 128 seemed to be plenty enough.
So, the fallback value should be set to the estimated absmax-absmin value
for the hypothetical future touchpad driver that also hypothetically
doesn't set this value itself. I have no idea how to estimate this value
though, which is why I just used xres. ;)
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Touchpad problems with 2.6.11-rc2
On Wed, 2 Feb 2005, Pete Zaitcev wrote:
> On 02 Feb 2005 21:57:39 +0100, Peter Osterlund <[EMAIL PROTECTED]> wrote:
>
> > Please try this patch instead. It works well with my alps touchpad. (I
> > don't have a synaptics touchpad.) It does the following:
> >
> > * Compensates for the lack of floating point arithmetic by keeping
> > track of remainders from the integer divisions.
> > * Removes the xres/yres scaling so that you get the same speed in the
> > X and Y directions even if your screen is not square.
> > * Sets scale factors so that the speed for synaptics and alps should
> > be equal to each other and equal to the synaptics speed from 2.6.10.
>
> Thanks a lot, Peter. I think I like the result even better than the one
> after the simple-minded removal that I posted. It's possible that when
> I accepted the case of (pktcount == 1) it hurt smoothness.
>
> Do you think it makes sense to zero fractions when pktcount is dropped?
In practice I don't think it will make any significant difference. What
the code should do depends on what you want to happen if you move the
mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
pixel with a second stroke. The patch I posted will move the pointer one
pixel in this case and your code will move it 0 pixels. (The X driver does
not reset the fractions, but that doesn't of course mean that it's the
only right thing to do.)
> Also, I think the extra unary minus is uncoth.
The code was written like that to emphasize the fact that X and Y use the
same formula, with the only difference that the kernel Y axis is mirrored
compared to the touchpad Y axis.
It didn't make any difference for the generated assembly code though,
using gcc 3.4.2 from Fedora Core 3.
> + enum { FRACTION_DENOM = 100 };
The enum is much nicer than my #define.
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Touchpad problems with 2.6.11-rc2
Vojtech Pavlik <[EMAIL PROTECTED]> writes:
> On Wed, Feb 02, 2005 at 11:58:05PM +0100, Peter Osterlund wrote:
>
> > In practice I don't think it will make any significant difference. What
> > the code should do depends on what you want to happen if you move the
> > mouse pointer 1/2 pixel with one finger stroke, then move it another 1/2
> > pixel with a second stroke. The patch I posted will move the pointer one
> > pixel in this case and your code will move it 0 pixels. (The X driver does
> > not reset the fractions, but that doesn't of course mean that it's the
> > only right thing to do.)
> >
> > > Also, I think the extra unary minus is uncoth.
> >
> > The code was written like that to emphasize the fact that X and Y use the
> > same formula, with the only difference that the kernel Y axis is mirrored
> > compared to the touchpad Y axis.
> >
> > It didn't make any difference for the generated assembly code though,
> > using gcc 3.4.2 from Fedora Core 3.
> >
> > > + enum { FRACTION_DENOM = 100 };
> >
> > The enum is much nicer than my #define.
>
> OK. I like this patch, too. Can you guys send me a final version
> incorporating the changes of you both for inclusion in the input tree?
Here it is, with the suggestions from Pete and Dmitry included. The
patch does the following:
* Compensates for the lack of floating point arithmetic by keeping
track of remainders from the integer divisions.
* Removes the xres/yres scaling so that you get the same speed in the
X and Y directions even if your screen is not square.
* Sets scale factors to make the speed for synaptics and alps equal to
each other and equal to the synaptics speed from 2.6.10.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/input/mousedev.c | 28 +++-
1 files changed, 19 insertions(+), 9 deletions(-)
diff -puN drivers/input/mousedev.c~mousedev-roundoff drivers/input/mousedev.c
--- linux/drivers/input/mousedev.c~mousedev-roundoff2005-02-02
20:54:23.0 +0100
+++ linux-petero/drivers/input/mousedev.c 2005-02-03 22:41:41.0
+0100
@@ -71,6 +71,7 @@ struct mousedev {
struct mousedev_hw_data packet;
unsigned int pkt_count;
int old_x[4], old_y[4];
+ int frac_dx, frac_dy;
unsigned long touch;
};
@@ -117,24 +118,31 @@ static struct mousedev mousedev_mix;
static void mousedev_touchpad_event(struct input_dev *dev, struct mousedev
*mousedev, unsigned int code, int value)
{
- int size;
+ int size, tmp;
+ enum { FRACTION_DENOM = 128 };
if (mousedev->touch) {
+ size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
+ if (size == 0) size = 256 * 2;
switch (code) {
case ABS_X:
- size = dev->absmax[ABS_X] - dev->absmin[ABS_X];
- if (size == 0) size = xres;
fx(0) = value;
- if (mousedev->pkt_count >= 2)
- mousedev->packet.dx = ((fx(0) - fx(1))
/ 2 + (fx(1) - fx(2)) / 2) * xres / (size * 2);
+ if (mousedev->pkt_count >= 2) {
+ tmp = ((value - fx(2)) * (256 *
FRACTION_DENOM)) / size;
+ tmp += mousedev->frac_dx;
+ mousedev->packet.dx = tmp /
FRACTION_DENOM;
+ mousedev->frac_dx = tmp -
mousedev->packet.dx * FRACTION_DENOM;
+ }
break;
case ABS_Y:
- size = dev->absmax[ABS_Y] - dev->absmin[ABS_Y];
- if (size == 0) size = yres;
fy(0) = value;
- if (mousedev->pkt_count >= 2)
- mousedev->packet.dy = -((fy(0) - fy(1))
/ 2 + (fy(1) - fy(2)) / 2) * yres / (size * 2);
+ if (mousedev->pkt_count >= 2) {
+ tmp = -((value - fy(2)) * (256 *
FRACTION_DENOM)) / size;
+ tmp += mousedev->frac_dy;
+ mousedev->packet.dy = tmp /
FRACTION_DENOM;
+ mousedev->frac_dy = tmp -
mousedev->packet.dy * FRACTION_DENOM;
+ }
break;
}
}
@@ -268,6 +276,8 @@ static void mousedev_touchpad_touch(stru
clear_bit(0, &mousedev_mix.packet.buttons);
Re: [PATCH 3/4] Fix "pointer jumps to corner of screen" problem on ALPS Glidepoint touchpads.
Giuseppe Bilotta <[EMAIL PROTECTED]> writes: > Peter Osterlund wrote: > > Only parse a "z == 127" packet as a relative Dualpoint stick packet if > > the touchpad actually is a Dualpoint device. The Glidepoint models > > don't have a stick, and can report z == 127 for a very wide finger. If > > such a packet is parsed as a stick packet, the mouse pointer will > > typically jump to one corner of the screen. > > I remember reading specs of a touchpad (can't remember if it > was ALPS or Synaptics) (driver) which could do "palm > detection" (basically ignoring events when a large part of the > hand accidentally touched/pressed the pad, FWICS). Some synaptics touchpads can do palm detection in firmware, but the software driver has to decide if the corresponding events shall be ignored or not. Anyway, this is unrelated to the patch. Without this patch, the packet from the touchpad will be parsed incorrectly as a very big stick motion, so a higher level driver (such as the X driver) can't really see that there might be a palm touching the pad. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Touchpad problems with 2.6.11-rc2
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote: > > > * Removes the xres/yres scaling so that you get the same speed in the > > X and Y directions even if your screen is not square. > > The old code assumed that both the pad and the screen are 4:3, not > square. It was wrong still. alps.c currently contains: psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0); input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0); input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0); Maybe it should set the ABS_Y max value to 767 in that case. --- linux/drivers/input/mouse/alps.c~ 2005-01-12 22:02:19.0 +0100 +++ linux/drivers/input/mouse/alps.c2005-02-04 07:38:12.203436768 +0100 @@ -394,7 +394,7 @@ psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0); - input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0); + input_set_abs_params(&psmouse->dev, ABS_Y, 0, 767, 0, 0); input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0); psmouse->dev.keybit[LONG(BTN_TOUCH)] |= BIT(BTN_TOUCH); -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Touchpad problems with 2.6.11-rc2
Vojtech Pavlik <[EMAIL PROTECTED]> writes: > On Fri, Feb 04, 2005 at 07:40:43AM +0100, Peter Osterlund wrote: > > Vojtech Pavlik <[EMAIL PROTECTED]> writes: > > > > > On Thu, Feb 03, 2005 at 10:54:51PM +0100, Peter Osterlund wrote: > > > > > > > * Removes the xres/yres scaling so that you get the same speed in the > > > > X and Y directions even if your screen is not square. > > > > > > The old code assumed that both the pad and the screen are 4:3, not > > > square. It was wrong still. > > > alps.c currently contains: > > > > psmouse->dev.evbit[LONG(EV_ABS)] |= BIT(EV_ABS); > > input_set_abs_params(&psmouse->dev, ABS_X, 0, 1023, 0, 0); > > input_set_abs_params(&psmouse->dev, ABS_Y, 0, 1023, 0, 0); > > input_set_abs_params(&psmouse->dev, ABS_PRESSURE, 0, 127, 0, 0); > > > > Maybe it should set the ABS_Y max value to 767 in that case. > > Yes, and no. It could have been 1023, if it was 3:4 in size, but not in > maximum values. See the real values below, though, it seems the > resolution in X and Y is indeed the same. ... > My ALPS gives values: > > X: 90-1019 > Y: 100-749 > Pressure: 0,34-108 I get similar values: X: 40 - 984 Y: 97 - 732 Z: 0, 19 - 127 > So 0-1024, 0-768, 0-127 are probably the maximum theoretical ranges, and > the rest are likely the mechanical mounting limitations of the notebook > (the ridge around the pad is not rectangular). -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1 : mount UDF CDRW stuck in D state
Laurent Riffard <[EMAIL PROTECTED]> writes: > This is kernel 2.6.11-rc3-mm1. I can't mount an UDF-formatted cdrw > in packet-writing mode. Mount process gets stuck in D state. > > Mounting and writing this media in packet-writing mode works fine > with kernel 2.6.11-rc2-mm2. I tried to repeat the problem, but I didn't get far, because I get a kernel panic right after init is started: Unable to handle kernel NULL pointer dereference at virtual address ... PREEMPT ... EIP is a strncpy_from_user+0x33/0x47 ... Call Trace: getname+0x69/0xa5 sys_open+0x12/0xc6 sysenter_past_esp+0x52/0x75 ... Kernel panic - not syncing: Attempted to kill init! -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1 : mount UDF CDRW stuck in D state
Peter Osterlund <[EMAIL PROTECTED]> writes: > Laurent Riffard <[EMAIL PROTECTED]> writes: > > > This is kernel 2.6.11-rc3-mm1. I can't mount an UDF-formatted cdrw > > in packet-writing mode. Mount process gets stuck in D state. > > > > Mounting and writing this media in packet-writing mode works fine > > with kernel 2.6.11-rc2-mm2. > > I tried to repeat the problem, but I didn't get far, because I get a > kernel panic right after init is started: I got around that by disabling preempt, radeon framebuffer, HPET timer, APIC. Don't know which one caused the panic, will track it down later. Anyway, mount hangs for me too if I use an IDE drive, both with native ide and ide-scsi emulation. It doesn't hang with a USB drive though. I verified that 2.6.11-rc3 does not have this problem. Reverting bk-ide-dev does *not* fix the problem. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1 : mount UDF CDRW stuck in D state
Andrew Morton <[EMAIL PROTECTED]> writes: > Peter Osterlund <[EMAIL PROTECTED]> wrote: > > > > Peter Osterlund <[EMAIL PROTECTED]> writes: > > > > > Laurent Riffard <[EMAIL PROTECTED]> writes: > > > > > > > This is kernel 2.6.11-rc3-mm1. I can't mount an UDF-formatted cdrw > > > > in packet-writing mode. Mount process gets stuck in D state. > > > > > > > > Mounting and writing this media in packet-writing mode works fine > > > > with kernel 2.6.11-rc2-mm2. > > > Anyway, mount hangs for me too if I use an IDE drive, both with native > > ide and ide-scsi emulation. It doesn't hang with a USB drive though. I > > verified that 2.6.11-rc3 does not have this problem. Reverting > > bk-ide-dev does *not* fix the problem. > > Bah. sysrq-T output would be helpful. I was wrong about USB, it doesn't work either. The IDE drive failed with a non-packet formatted disc, so I didn't bother to check what was inserted in the USB drive. It turned out it was empty and in that case the driver doesn't hang. Anyway, the problem is that the add-struct-request-end_io-callback patch forgot to update pktcdvd.c. This patch fixes it. It should probably be merged into the add-struct-request-end_io-callback patch, because that patch already fixes up other struct request users. Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]> --- linux-petero/drivers/block/pktcdvd.c |1 + 1 files changed, 1 insertion(+) diff -puN drivers/block/pktcdvd.c~pktcdvd-endio-fix drivers/block/pktcdvd.c --- linux/drivers/block/pktcdvd.c~pktcdvd-endio-fix 2005-02-06 08:59:16.0 +0100 +++ linux-petero/drivers/block/pktcdvd.c2005-02-06 09:01:22.0 +0100 @@ -375,6 +375,7 @@ static int pkt_generic_packet(struct pkt rq->ref_count++; rq->flags |= REQ_NOMERGE; rq->waiting = &wait; + rq->end_io = blk_end_sync_rq; elv_add_request(q, rq, ELEVATOR_INSERT_BACK, 1); generic_unplug_device(q); wait_for_completion(&wait); _ -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
Andrew Morton <[EMAIL PROTECTED]> writes: > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ It gives me a kernel panic at boot if I have CONFIG_FB_RADEON enabled. If I also have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get this output: Unable to handle kernel NULL pointer dereference at virtual address ... PREEMPT ... EIP is a strncpy_from_user+0x33/0x47 ... Call Trace: getname+0x69/0xa5 sys_open+0x12/0xc6 sysenter_past_esp+0x52/0x75 ... Kernel panic - not syncing: Attempted to kill init! If I don't have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get a screen with random junk and some blinking colored boxes, and the machine hangs. 2.6.11-rc3 doesn't have this problem. When I boot that kernel, I get these messages during boot: Feb 6 02:27:31 r3000 kernel: radeonfb: Retreived PLL infos from BIOS Feb 6 02:27:31 r3000 kernel: radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=215.00 Mhz, System=220.00 MHz Feb 6 02:27:31 r3000 kernel: radeonfb: PLL min 2 max 35000 Feb 6 02:27:31 r3000 kernel: Non-DDC laptop panel detected Feb 6 02:27:31 r3000 kernel: radeonfb: Monitor 1 type LCD found Feb 6 02:27:31 r3000 kernel: radeonfb: Monitor 2 type no found Feb 6 02:27:31 r3000 kernel: radeonfb: panel ID string: LGP Feb 6 02:27:31 r3000 kernel: radeonfb: detected LVDS panel size from BIOS: 1280x800 Feb 6 02:27:31 r3000 kernel: radeondb: BIOS provided dividers will be used Feb 6 02:27:31 r3000 kernel: radeonfb: Power Management enabled for Mobility chipsets Feb 6 02:27:31 r3000 kernel: Console: switching to colour frame buffer device 160x50 Feb 6 02:27:31 r3000 kernel: radeonfb: ATI Radeon \a DDR SGRAM 64 MB -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Sun, 2005-02-06 at 11:07 +0100, Peter Osterlund wrote: > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ > > > > It gives me a kernel panic at boot if I have CONFIG_FB_RADEON > > enabled. If I also have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get this > > output: > > > > Unable to handle kernel NULL pointer dereference at virtual address > > > > ... > > PREEMPT > > ... > > EIP is a strncpy_from_user+0x33/0x47 > > ... > > Call Trace: > > getname+0x69/0xa5 > > sys_open+0x12/0xc6 > > sysenter_past_esp+0x52/0x75 > > ... > > Kernel panic - not syncing: Attempted to kill init! > > > > If I don't have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get a screen > > with random junk and some blinking colored boxes, and the machine > > hangs. > > That's very strange... I don't see what in radeonfb could cause this. > Just in case, can you try commenting out the call to radeon_pm_init() in > radeon_base.c, see if it makes any difference (though I don't think so). No, it didn't make any difference. I added a printk to do_getname() and I see that it is called with filename==0. I disabled the framebuffer so I could boot the kernel, then wrote a small test program that does open(0, O_RDONLY). This also calls do_getname() with filename==0, but does not generate an oops. Maybe there is something wrong with exception handling that early in the boot sequence. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
Peter Osterlund <[EMAIL PROTECTED]> writes: > Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > > > On Sun, 2005-02-06 at 11:07 +0100, Peter Osterlund wrote: > > > Andrew Morton <[EMAIL PROTECTED]> writes: > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ > > > > > > It gives me a kernel panic at boot if I have CONFIG_FB_RADEON > > > enabled. If I also have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get this > > > output: > > > > > > Unable to handle kernel NULL pointer dereference at virtual > > > address > > > ... > > > PREEMPT > > > ... > > > EIP is a strncpy_from_user+0x33/0x47 > > > ... > > > Call Trace: > > > getname+0x69/0xa5 > > > sys_open+0x12/0xc6 > > > sysenter_past_esp+0x52/0x75 > > > ... > > > Kernel panic - not syncing: Attempted to kill init! > > > > > > If I don't have CONFIG_FRAMEBUFFER_CONSOLE enabled, I get a screen > > > with random junk and some blinking colored boxes, and the machine > > > hangs. > > > > That's very strange... I don't see what in radeonfb could cause this. > > Just in case, can you try commenting out the call to radeon_pm_init() in > > radeon_base.c, see if it makes any difference (though I don't think so). > > No, it didn't make any difference. I found the if I disable CONFIG_INOTIFY, the problem goes away. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Touchpad "tapping" changes in 2.6.11?
Dmitry Torokhov <[EMAIL PROTECTED]> writes: > On Mon, 07 Mar 2005 17:10:27 +0100, Henrik Persson <[EMAIL PROTECTED]> wrote: > > Dmitry Torokhov wrote: > > > On Mon, 07 Mar 2005 14:14:02 +0100, Henrik Persson <[EMAIL PROTECTED]> > > > wrote: > > > > > >>I noticed that the ALPS driver was added to 2.6.11, a thing that alot of > > >>people probably like, but since my touchpad (Acer Aspire 1300XV) worked > > >>perfectly before (like, 2.6.10) and now the ALPS driver disables > > >>'hardware tapping', wich makes it hard to tap. I commented out the > > >>disable-tapping bits in alps.c and now it's working like a charm again. > > > > > > Could you please try 2.6.11-mm1. It has bunch of Peter Osterlund's > > > patches that shoudl improve the situation with tapping. > > > > Well, -mm1 didn't quite agree with my savage gfx drivers. But I'm > > booting with psmouse.proto=exps now, and it's working the way I'm used > > to now. > > > > The Aspire 1300-series is quite different from the 1350 ones.. The > > touchpad on the 1300 will work like a charm without the synaptics driver > > (but no fancy stuff is supported, I guess). Before you could boot and be > > happy without the synaptics driver, now you probably have to install the > > synaptics driver to be happy.. Maybe that's not so good. :) > > > > Could this touchpad use the "exps" proto as default and then you could > > reconfigure if you want to use the ALPS driver..? > > We (well Peter and Vojtech mostly as I don't have ALPS touchpad in my > box) are trying to make ALPS work as it was working before even > without Synaptics X driver without any additional options, please bear > with us. I have some touchpad related patches in my tree, which I have uploaded here: http://web.telia.com/~u89404340/patches/touchpad/2.6.11/ All of these patches are already in -mm I think. > Still I think having Synaptics driver installed is the best way in the > end simply because it has a lot of knobs so one can adjust tpouchpad's > behavior to his/her liking. Maybe once distibutions start packaging > and activating it by default it will be less of an issue. Fedora Core 3 already does that if I remember correctly. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Use __init and __exit in pktcdvd
This patch adds __init and __exit annotations to the pktcdvd driver.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/drivers/block/pktcdvd.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff -puN drivers/block/pktcdvd.c~pktcdvd-module-init drivers/block/pktcdvd.c
--- linux/drivers/block/pktcdvd.c~pktcdvd-module-init 2005-03-11
22:23:57.0 +0100
+++ linux-petero/drivers/block/pktcdvd.c2005-03-11 22:23:57.0
+0100
@@ -2624,7 +2624,7 @@ static struct miscdevice pkt_misc = {
.fops = &pkt_ctl_fops
};
-static int pkt_init(void)
+static int __init pkt_init(void)
{
int ret;
@@ -2660,7 +2660,7 @@ out2:
return ret;
}
-static void pkt_exit(void)
+static void __exit pkt_exit(void)
{
remove_proc_entry("pktcdvd", proc_root_driver);
misc_deregister(&pkt_misc);
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] DVD-RAM support for pktcdvd
This patch makes it possible to use the packet writing driver with
DVD-RAM discs. The pktcdvd driver is not needed for writing to DVD-RAM
discs but it can improve write performance. Polgár István reports:
I wrote 178716Kb data to DVD-RAM without pktcdvd driver within
4.54 minutes. With pktcdvd driver it took me 2.33 minutes.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
linux-petero/Documentation/cdrom/packet-writing.txt |8
linux-petero/drivers/block/pktcdvd.c|9 +++--
2 files changed, 15 insertions(+), 2 deletions(-)
diff -puN drivers/block/pktcdvd.c~packet-dvd-ram drivers/block/pktcdvd.c
--- linux/drivers/block/pktcdvd.c~packet-dvd-ram2005-03-11
22:24:02.0 +0100
+++ linux-petero/drivers/block/pktcdvd.c2005-03-11 22:24:02.0
+0100
@@ -1421,8 +1421,8 @@ static int pkt_set_write_settings(struct
char buffer[128];
int ret, size;
- /* doesn't apply to DVD+RW */
- if (pd->mmc3_profile == 0x1a)
+ /* doesn't apply to DVD+RW or DVD-RAM */
+ if ((pd->mmc3_profile == 0x1a) || (pd->mmc3_profile == 0x12))
return 0;
memset(buffer, 0, sizeof(buffer));
@@ -1536,6 +1536,7 @@ static int pkt_good_disc(struct pktcdvd_
break;
case 0x1a: /* DVD+RW */
case 0x13: /* DVD-RW */
+ case 0x12: /* DVD-RAM */
return 0;
default:
printk("pktcdvd: Wrong disc profile (%x)\n",
pd->mmc3_profile);
@@ -1601,6 +1602,9 @@ static int pkt_probe_settings(struct pkt
case 0x13: /* DVD-RW */
printk("pktcdvd: inserted media is DVD-RW\n");
break;
+ case 0x12: /* DVD-RAM */
+ printk("pktcdvd: inserted media is DVD-RAM\n");
+ break;
default:
printk("pktcdvd: inserted media is CD-R%s\n",
di.erasable ? "W" : "");
break;
@@ -1893,6 +1897,7 @@ static int pkt_open_write(struct pktcdvd
switch (pd->mmc3_profile) {
case 0x13: /* DVD-RW */
case 0x1a: /* DVD+RW */
+ case 0x12: /* DVD-RAM */
DPRINTK("pktcdvd: write speed %ukB/s\n", write_speed);
break;
default:
diff -puN Documentation/cdrom/packet-writing.txt~packet-dvd-ram
Documentation/cdrom/packet-writing.txt
--- linux/Documentation/cdrom/packet-writing.txt~packet-dvd-ram 2005-03-11
22:24:02.0 +0100
+++ linux-petero/Documentation/cdrom/packet-writing.txt 2005-03-11
22:24:02.0 +0100
@@ -62,6 +62,14 @@ generates aligned writes.
# mount /dev/pktcdvd/dev_name /cdrom -t udf -o rw,noatime
+Packet writing for DVD-RAM media
+
+
+DVD-RAM discs are random writable, so using the pktcdvd driver is not
+necessary. However, using the pktcdvd driver can improve performance
+in the same way it does for DVD+RW media.
+
+
Notes
-
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.4 sluggish under fork load
I have noticed that 2.4.4 feels a lot less responsive than 2.4.3 under fork load. This is caused by the "run child first after fork" patch. I have tested on two different UP x86 systems running redhat 7.0. For example, when running the gcc configure script, the X mouse pointer is very jerky. The configure script itself runs approximately as fast as in 2.4.3. Another thing is that the bash loop "while true ; do /bin/true ; done" is not possible to interrupt with ctrl-c. A third thing I noticed is that starting a gnome session in redhat 7.0 takes longer. (It takes more time for the gnome splash screen to appear.) Reverting the fork patch makes all these problems go away on my machine. I'm not saying that this is necessarily a good idea, that patch might be good for other reasons. --- linux-2.4.4/kernel/fork.c~ Sat Apr 28 09:46:58 2001 +++ linux-2.4.4/kernel/fork.c Sat Apr 28 11:14:33 2001 @@ -674,9 +674,16 @@ * and then exec(). This is only important in the first timeslice. * In the long run, the scheduling behavior is unchanged. */ +#if 0 p->counter = current->counter; current->counter = 0; current->need_resched = 1; +#else + p->counter = (current->counter + 1) >> 1; + current->counter >>= 1; + if (!current->counter) + current->need_resched = 1; +#endif /* * Ok, add it to the run-queues and make it -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.4 sluggish under fork load
John Kacur <[EMAIL PROTECTED]> writes:
> >Peter Osterlund wrote:
> >>
> >> Another thing is that the bash loop "while true ; do /bin/true ; done" is
> >> not possible to interrupt with ctrl-c.
>
> >Same thing here.
>
> I'm not having any problems. Just a quick question, is everyone who is
> having a problem running with more than one cpu?
A clarification. The bash loop above doesn't cause any sluggishness on
my single cpu system. The non-working ctrl-c is probably just a bash
bug. The child process must eat some cpu time to provoke the
sluggishness, like in the following test program where the child busy
waits 100ms and then exits:
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
double childTime = 0.10;
if (argc > 1)
childTime = atof(argv[1]);
for (;;) {
int child = fork();
if (child == -1) {
printf("fork error\n");
exit(0);
} else if (child > 0) {
while (waitpid(child, NULL, 0) != child)
;
printf("."); fflush(stdout);
} else {
struct timeval tv1, tv2;
double t;
gettimeofday(&tv1, NULL);
for (;;) {
gettimeofday(&tv2, NULL);
t = (tv2.tv_sec - tv1.tv_sec) +
(tv2.tv_usec - tv1.tv_usec) / 100.0;
if (t > childTime)
break;
}
_exit(0);
}
}
return 0;
}
--
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.4 sluggish under fork load
On Sat, 28 Apr 2001, Linus Torvalds wrote:
> > Reverting the fork patch makes all these problems go away on my machine.
>
> Reverting it outright may be an acceptable approach. I'll think about
> it: the arguments _for_ the patch are true and real, and it shows up as
> real improvements on some things..
I agree with the reasoning for running the child first. Maybe the real
problem is somewhere else. I wrote two test programs to quantify the
behaviour. If I run "./fork 0.2" and "./lat 0.15" at the same time, lat
shows regular 160ms scheduling delays. (With the old fork.c the scheduling
delay is 20ms + epsilon as expected.)
Maybe some code path just forgets to reschedule?
fork.c
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
double childTime = atof(argv[1]);
for (;;) {
int child = fork();
if (child == -1) {
printf("fork error\n");
exit(0);
} else if (child > 0) {
while (waitpid(child, NULL, 0) != child)
;
printf("."); fflush(stdout);
} else {
struct timeval tv1, tv2;
double t;
gettimeofday(&tv1, NULL);
for (;;) {
gettimeofday(&tv2, NULL);
t = (tv2.tv_sec - tv1.tv_sec) +
(tv2.tv_usec - tv1.tv_usec) / 100.0;
if (t > childTime)
break;
}
_exit(0);
}
}
return 0;
}
lat.c
#include
#include
#include
#include
#include
#include
int main(int argc, char* argv[])
{
double tLimit = 0.03;
if (argc > 1)
tLimit = atof(argv[1]);
for (;;) {
struct timeval tv1, tv2;
double t;
gettimeofday(&tv1, NULL);
usleep(1);
gettimeofday(&tv2, NULL);
t = (tv2.tv_sec - tv1.tv_sec) +
(tv2.tv_usec - tv1.tv_usec) / 100.0;
if (t > tLimit)
printf("t:%g\n", t);
}
return 0;
}
--
Peter Österlund [EMAIL PROTECTED]
Sköndalsvägen 35http://home1.swipnet.se/~w-15919
S-128 66 Sköndal+46 8 942647
Sweden
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.4.4 sluggish under fork load
On Sat, 28 Apr 2001, Linus Torvalds wrote: > > could we leave it at half, but set the parent to SCHED_YIELD? > > Sounds like a good idea. Peter, how does that feel to you? I bet that I'v > enever seen it simply because all my machines are (a) much too powerful > for any reasonable use and (b) SMP. That seems to work. The scheduling delays are back to 20ms and the sluggishness feeling is gone. I wrote a simple test program to verify that the child is still scheduled before the parent, so the performance advantage should still be there. The only annoying thing is that it hides the bash bug ;) Patch below: --- linux-2.4.4.orig/kernel/fork.c Sat Apr 28 10:17:00 2001 +++ linux-2.4.4/kernel/fork.c Sun Apr 29 10:06:42 2001 @@ -666,16 +666,18 @@ p->pdeath_signal = 0; /* -* Give the parent's dynamic priority entirely to the child. The -* total amount of dynamic priorities in the system doesn't change -* (more scheduling fairness), but the child will run first, which -* is especially useful in avoiding a lot of copy-on-write faults -* if the child for a fork() just wants to do a few simple things -* and then exec(). This is only important in the first timeslice. -* In the long run, the scheduling behavior is unchanged. +* "share" dynamic priority between parent and child, thus the +* total amount of dynamic priorities in the system doesn't change, +* more scheduling fairness. The parent yields to let the child run +* first, which is especially useful in avoiding a lot of +* copy-on-write faults if the child for a fork() just wants to do a +* few simple things and then exec(). This is only important in the +* first timeslice. In the long run, the scheduling behavior is +* unchanged. */ - p->counter = current->counter; - current->counter = 0; + p->counter = (current->counter + 1) >> 1; + current->counter >>= 1; + current->policy |= SCHED_YIELD; current->need_resched = 1; /* -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.4.4 sluggish under fork load
On Mon, 30 Apr 2001, Andrea Arcangeli wrote: > please try to reproduce the bad behaviour with 2.4.4aa2. There's a bug > in the parent-timeslice patch in 2.4 that I fixed while backporting it > to 2.2aa and that I now forward ported the fix to 2.4aa. The fact > 2.4.4 gives the whole timeslice to the child just gives more light to > such bug. Unfortunately the fix doesn't apply cleanly to 2.4.4 (it's > incremental with the numa-scheduler patch) and I need to finish a few > more things before I can backport it myself. I applied the 10_parent-timeslice-5 patch to 2.4.4 and tested. (If I understood correctly, the idea of that patch is to give the remaining child time-slice back to the parent when the child exits, but only if there have been no time-slice recalculation since the child was created.) It is somewhat better than plain 2.4.4, but not much. I still see scheduling delays in the range 30-120ms when running "./fork 0.4". (fork is a program that starts a child, the child busy waits some time (0.4s) and then exits. The parent then immediately respawns another child, etc. See one of my previous messages.) -- Peter Österlund [EMAIL PROTECTED] Sköndalsvägen 35http://home1.swipnet.se/~w-15919 S-128 66 Sköndal+46 8 942647 Sweden - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Hack to get dvd-burning at 8x (instead of 3x) with ide-cd (2.6.11)
Linh Dang <[EMAIL PROTECTED]> writes: > I'd like to receive comments/guide-lines about a hack I made to the > 2.6.11 kernel to improve DVD-burning speed (using growisofs.) > > The basic idea is the 16-pages pipe between mkisofs and growisofs is > too small for DVD burning (typical 4GB of data.) > > In the hack, pipe_new will simply check for, if privileges permitted, > the enviroment variable > PIPE_MAX_ORDER to see if a (much) longer pipe is requested. > > This hack enable me to burn DVD at 8X (instead of 3X) on my old > P3-450MHz (with growisofs and mkisofs running at SCHED_FIFO.) This problem is likely caused by limited filesystem and/or hard disk performance, not a slow CPU. You don't need a kernel patch to get a bigger buffer though. See: http://article.gmane.org/gmane.comp.audio.cd-record/2253 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Logitech MX1000 Horizontal Scrolling
Jeremy Nickurak <[EMAIL PROTECTED]> writes: > On Tue, 2005-03-08 at 21:52 +0100, Vojtech Pavlik wrote: > > The problem is that the mouse really does reports all the double-button > > stuff and autorepeat, and horizontal wheel together with button press on > > wheel tilt. > > Okay, I'm playing with this under 2.6.11.4 some more, and it really > seems out of whack. The vertical cruise control buttons work properly, > with the exception of the extra button press. But the horizontal buttons > are mapping to 6/7 as non-repeat buttons, and adding simulateously the > 4/5 events auto-repeated for as long as the button is down. That is to > say, pressing the the horizontal scroll in a 2d scrolling area will > scroll *diagonally* one step, then vertically until the button is > released. Have you tried the Logitech mouse applet? http://freshmeat.net/projects/logitech_applet/ "logitech_applet --disable-cc" used to work for me when I owned an MX1000 mouse. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fix verify_command to allow burning more than 1 DVD
Michal Schmidt <[EMAIL PROTECTED]> writes:
> I use K3B with growisofs to burn DVDs. After boot I can burn a DVD as
> a normal user. But only the first one. When I want to burn another
> one, K3B complains that it is unable to prevent media removal. Then
> only root can burn DVDs.
> The bug is in the kernel in the function verify_command.
> When a process opens the DVD recorder with O_RDONLY and issues a
> command which is marked safe_for_write, this function is supposed to
> just return -EPERM and do nothing more. However, there is a bug that
> causes the command to be marked as CMD_WARNED. From now on no
> non-privileged process is able to issue this command even if it
> correctly opens the device with O_RDWR - because the command is no
> longer marked as CMD_WRITE_SAFE.
> A patch is attached.
>
> Michal
> --- linux-2.6.11-mm1/drivers/block/scsi_ioctl.c.orig 2005-01-17
> 20:42:40.0 +0100
> +++ linux-2.6.11-mm1/drivers/block/scsi_ioctl.c 2005-01-17
> 20:43:14.0 +0100
> @@ -197,9 +197,7 @@ static int verify_command(struct file *f
> if (type & CMD_WRITE_SAFE) {
> if (file->f_mode & FMODE_WRITE)
> return 0;
> - }
> -
> - if (!(type & CMD_WARNED)) {
> + } else if (!(type & CMD_WARNED)) {
> cmd_type[cmd[0]] = CMD_WARNED;
> printk(KERN_WARNING "scsi: unknown opcode 0x%02x\n", cmd[0]);
> }
That patch will not write the warning message in some cases. I think
this patch is better:
---
linux-petero/drivers/block/scsi_ioctl.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
diff -puN drivers/block/scsi_ioctl.c~scsi-filter drivers/block/scsi_ioctl.c
--- linux/drivers/block/scsi_ioctl.c~scsi-filter2005-01-18
23:38:37.966026728 +0100
+++ linux-petero/drivers/block/scsi_ioctl.c 2005-01-18 23:38:37.970026120
+0100
@@ -200,7 +200,7 @@ static int verify_command(struct file *f
}
if (!(type & CMD_WARNED)) {
- cmd_type[cmd[0]] = CMD_WARNED;
+ cmd_type[cmd[0]] |= CMD_WARNED;
printk(KERN_WARNING "scsi: unknown opcode 0x%02x\n", cmd[0]);
}
_
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 2.6.11-rc1
On Wed, 19 Jan 2005, Daniel Gryniewicz wrote: > On Wed, 2005-01-19 at 23:16 -0500, Dmitry Torokhov wrote: > > On Wednesday 19 January 2005 16:07, Daniel Gryniewicz wrote: > > > On Tue, 2005-01-11 at 21:09 -0800, Linus Torvalds wrote: > > > > Ok, the big merges after 2.6.10 are hopefully over, and 2.6.11-rc1 is > > > > out > > > > there. > > > > > > > > Peter Osterlund: > > > > o input: Add ALPS touchpad driver, driver by Neil Brown, Peter > > > > Osterlund and Dmitry Torokhov, some fixes by Vojtech Pavlik. > > > > > > 2.6.11-rc1 broke my ALPS touchpad. I have a Dell Inspiron 8600, and > > > previously, I was patching my kernels with the patch from > > > > > > Message-Id: <[EMAIL PROTECTED]> > > > Subject: [RFT/PATCH 2.6] ALPS touchpad driver > > > > > > and this worked fine. > > > > > Could you please try this patch by Peter Osterlund: > > > > http://marc.theaimsgroup.com/?l=linux-kernel&m=110513688110246&q=raw > > > > It looks like Kensington and ALPS hate each other. > > That fixed it, thanks. I hope this can make it in before 2.6.11 final, > but if it doesn't, I'll just patch it in. OK, I've got another report in private mail where this patch fixed the ALPS detection, so the score for this patch is now 3 success reports and 0 problem reports. I also think the patch should be included before 2.6.11 final. The patch is already in -mm btw, it's called alps-touchpad-detection-fix. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: pktcdvd oops
On Mon, 5 Nov 2007, Jens Axboe wrote: Hi Peter, You don't seem to have a bugzilla account, so could not reassign to you. See http://bugzilla.kernel.org/show_bug.cgi?id=9294 Problem is repeatable on my computer. It dies in __module_get() on this line: BUG_ON(module_refcount(module) == 0); I think this is because commit 7b595756ec1f49e0049a9e01a1298d53a7faaa15, which states: "Note that with this change, userland holding a sysfs node does not prevent the backing module from being unloaded." Unfortunately, I don't know how this sysfs stuff is supposed to work, and therefore don't know how to fix the problem. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: pktcdvd oops
On Tue, 6 Nov 2007, Thomas Maier wrote: Hello, have not tested it yet, but i quess, the code mentioned by Peter is in pkt_new_dev() that is called by pkt_setup_dev(): /* This is safe, since we have a reference from open(). */ __module_get(THIS_MODULE); So, now, there must be checks in every sysfs operation in the module code, to ensure that the module is still loaded? I haven't tested it either yet. What I don't understand is this: If the __module_get() is not safe because the module code could have already been unloaded, how can it possibly be made safe by adding more code to the pktcdvd module? If the module is unloaded, trying to execute its code can't be a good thing no matter what the code does. BTW: the bug report says: Steps to reproduce: modprobe pktcdvd echo 22:0 >/sys/class/pktcdvd/add Is there any module unload??? Why is the module not available after the modprobe, but the sysfs entries, generated by the module? Confused ;) I think the purpose of the BUG_ON in __module_get() is to catch cases that are unsafe, even if the call would have happened to work in this particular case. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: pktcdvd oops
On Wed, 7 Nov 2007, Tejun Heo wrote: Peter Osterlund wrote: If the __module_get() is not safe because the module code could have already been unloaded, how can it possibly be made safe by adding more code to the pktcdvd module? If the module is unloaded, trying to execute its code can't be a good thing no matter what the code does. sysfs itself is now out of module lifespan rules. sysfs callbacks are guaranteed to stay in memory while running by sysfs node removal waiting for completion of in-flight operations before returning. In pktcdvd's case, class_destroy() call in pkt_sysfs_cleanup() will wait for all in-flight sysfs r/w ops to complete. So, even while sysfs callbacks are executing, the module beneath can die but it will stay in memory till all the callbacks return. You need to test module liveness using try_module_get() (and it can fail) if you want to grab module reference from sysfs callbacks. Thanks for the explanation. Given that explanation, I think the patch is correct and it does fix the BUG on my computer. Can you please push it upstream? In any case: Acked-by: Peter Osterlund <[EMAIL PROTECTED]> -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: pktcdvd oops
On Thu, 8 Nov 2007, [EMAIL PROTECTED] wrote: tested it too, running linux 2.6.23 in a qemu instance, and the patch worked. But i would prefer to take the try_module_get() stuff into pkt_setup_dev() because it is used also in the older procfs interface. Can we run into the same problem here, means procfs holds no module references too, like sysfs now? The procfs interface can only be used to get some debug data out from the driver, not to bind the driver to a CD/DVD device, so it shouldn't be a problem. The other way to bind a device is to use the pktsetup program, which is doing ioctl calls to the driver. In that case, user space has to open the device before being able to do the ioctls, and the open call will increase the reference count. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.20-rc5: known unfixed regressions (v3) (part 2)
Adrian Bunk <[EMAIL PROTECTED]> writes: > Subject: pktcdvd fails with pata_amd > References : http://bugzilla.kernel.org/show_bug.cgi?id=7810 > Submitter : [EMAIL PROTECTED] > Status : unknown Does reverting this patch help? http://www.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=406c9b605cbc45151c03ac9a3f95e9acf050808c If not, I don't know what to suggest except "git bisect". I don't have the hardware you are using and the backtrace doesn't give any clues. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/1] 2.6.20-rc1-mm1 pktcdvd: cleanup
"Thomas Maier" <[EMAIL PROTECTED]> writes: > this is a patch to cleanup some things in the pktcdvd driver for linux 2.6.20: > > - update documentation > - removed DECLARE_BUF_AS_STRING macro This part looks good. > - use clear_bdi_congested/set_bdi_congested functions directly instead of old > wrappers I'm unsure about this one. What's the point of having the blk_clear_queue_congested()/blk_set_queue_congested() functions if they are not supposed to be used? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2.6.20-rc4
Peter Osterlund <[EMAIL PROTECTED]> writes: > Linus Torvalds <[EMAIL PROTECTED]> writes: > > > Patrick McHardy (2): > > [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore > > I get kernel panics when doing large ethernet transfers. A loop doing I also see an annoying side effect of this bug. When the panic happens, the caps lock LED starts to blink, and the kernel prints this on the console once every second (or more often, don't know exactly): printk(KERN_WARNING "atkbd.c: Spurious %s on %s. " "Some program might be trying access hardware directly.\n", data == ATKBD_RET_ACK ? "ACK" : "NAK", serio->phys); This makes the actual crash information disappear before you have a chance to read it. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2.6.20-rc4
Linus Torvalds <[EMAIL PROTECTED]> writes: > Patrick McHardy (2): > [NETFILTER]: New connection tracking is not EXPERIMENTAL anymore I get kernel panics when doing large ethernet transfers. A loop doing continuous scp transfers of some large (>100MB) files makes the kernel crash after a few minutes. scp runs on a different machine and copies data from the machine that crashes. (The first crash did not happen when scp was used, but scp is an easy way to reproduce the problem.) I've seen this crash also with 2.6.20-rc2-git-something. Previously I ran these kernels quite a lot and used a ppp link without problems. Today I started using eth0 and the crashes started to occur. I have netfilter rules for ppp0, but no rules for eth0. Earlier kernels have been working perfectly for large eth0 transfers on this machine. Hand copied data from the console: BUG: unable to handle kernel paging request at virtual address 9f5cea9f printing eip: c034c729 *pde = Ooops: [#1] PREEMPT Modules linked in: ... 8139too ... CPU: 0 EIP: 0060:[] Not tainted VLI EFALLGS: 00010206 (2.6.20-rc4 #13) EIP is at ipv4_conntrack_help+0x6b/0x83 eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 0014 esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4 ds: 007b es: 007b ss: 0068 Process swapper (pid: 0, ti=c0474000 task=c0437500 task.ti=c0474000) Stack: 0001 9f5cea37 c0463a6c c0475e1c c0471a48 c0475dfc c0308269 c0318767 0001 c0475e44 0001 c0475e44 c0471a48 c0475e2c c03083a8 df391800 c0475e1c c0318767 8000 0002 c0463a6c df391800 Call Trace: show_trace_log_lvl+0x1a/0x30 show_stack_log_lvl+0xa5/0xca show_registers+0x1e2/0x343 die+0x10b/0x228 do_page_fault+0x2b9/0x5f6 error_code+0x74/0x7c nf_iterate+0x59/0x7d nf_hook_slow+0x57/0xe1 ip_local_deliver+0x1a8/0x1ef ip_rcv+0x25b/0x4eb netif_receive_skb+0x196/0x2cc rtl8139_poll+0x309/0x4d7 net_rx_action+0xac/0x25f __do_softirq+0x5c/0xb7 do_softirq+0x4d/0x50 irq_exit+0x49/0x4b do_IRQ+0x5f/0xb3 common_interrupt+0x2e/0x34 cpu_idle+0x41/0x6a rest_init+0x37/0x3a start_kernel+0x2ba/0x385 0x0 = Code: 89 45 f0 85 c0 74 2f 8b 42 20 89 c1 2b 8a 98 00 00 00 0f b6 10 80 e2 0f 0f b6 d2 8d 14 91 0f b6 c3 89 04 24 89 f1 89 f8 8b 5d f0 53 68 83 c4 08 5b 5e 5f 5d c3 b8 01 00- 00 00 83 c4 08 5b 5e EIP: [] ipv4_conntrack_help+0x6b/0x83 SS:ESP 0068:c0475dc4 <0>Kernel panic - not syncing: Fatal exception in interrupt Network related config options (There is also some wireless stuff compiled in, but it isn't used): CONFIG_INET=y CONFIG_IP_FIB_HASH=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_NETFILTER=y CONFIG_NF_CONNTRACK_ENABLED=y CONFIG_NF_CONNTRACK_SUPPORT=y CONFIG_NF_CONNTRACK=y CONFIG_NF_CONNTRACK_MARK=y CONFIG_NF_CONNTRACK_FTP=y CONFIG_NF_CONNTRACK_H323=y CONFIG_NF_CONNTRACK_IRC=y CONFIG_NF_CONNTRACK_NETBIOS_NS=y CONFIG_NF_CONNTRACK_SIP=y CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y CONFIG_NETFILTER_XT_TARGET_CONNMARK=y CONFIG_NETFILTER_XT_TARGET_MARK=y CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y CONFIG_NETFILTER_XT_MATCH_COMMENT=y CONFIG_NETFILTER_XT_MATCH_CONNMARK=y CONFIG_NETFILTER_XT_MATCH_CONNTRACK=y CONFIG_NETFILTER_XT_MATCH_LENGTH=y CONFIG_NETFILTER_XT_MATCH_LIMIT=y CONFIG_NETFILTER_XT_MATCH_MAC=y CONFIG_NETFILTER_XT_MATCH_MARK=y CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y CONFIG_NETFILTER_XT_MATCH_REALM=y CONFIG_NETFILTER_XT_MATCH_STATE=y CONFIG_NETFILTER_XT_MATCH_STATISTIC=y CONFIG_NETFILTER_XT_MATCH_TCPMSS=y CONFIG_NF_CONNTRACK_IPV4=y CONFIG_NF_CONNTRACK_PROC_COMPAT=y CONFIG_IP_NF_IPTABLES=y CONFIG_IP_NF_MATCH_IPRANGE=y CONFIG_IP_NF_MATCH_TOS=y CONFIG_IP_NF_MATCH_RECENT=y CONFIG_IP_NF_MATCH_ECN=y CONFIG_IP_NF_MATCH_TTL=y CONFIG_IP_NF_MATCH_OWNER=y CONFIG_IP_NF_MATCH_ADDRTYPE=y CONFIG_IP_NF_FILTER=y CONFIG_IP_NF_TARGET_REJECT=y CONFIG_IP_NF_TARGET_LOG=y CONFIG_IP_NF_TARGET_TCPMSS=y CONFIG_NF_NAT=y CONFIG_NF_NAT_NEEDED=y CONFIG_IP_NF_TARGET_MASQUERADE=y CONFIG_NF_NAT_FTP=y CONFIG_NF_NAT_IRC=y CONFIG_NF_NAT_H323=y CONFIG_NF_NAT_SIP=y CONFIG_IP_NF_MANGLE=y CONFIG_IP_NF_TARGET_TOS=y CONFIG_IP_NF_TARGET_ECN=y CONFIG_NET_CLS_ROUTE=y -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2.6.20-rc4
David Miller <[EMAIL PROTECTED]> writes: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST) > > > David, there really *is* something screwy in netfilter. > > Sure, but from what I can see this bug appears unrelated to the one in > kernel bugzilla #7781 that we've been discussing the past few days. > > First of all, the nf conntrack paths won't be used by normal > users until 2.6.20-rc1 or so. The bz #7781 report is against > 2.6.19 and all those backtraces have IP conntrack in them, not > nf conntrack. > > So what are we compiling with here btw, gcc-4.1? "gcc version 4.1.1 20060525 (Red Hat 4.1.1-1)" from Fedora Core 5. That distribution has gcc32 installed too, so I'll try that compiler too and report back. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2.6.20-rc4
David Miller <[EMAIL PROTECTED]> writes: > From: Linus Torvalds <[EMAIL PROTECTED]> > Date: Sun, 7 Jan 2007 14:50:15 -0800 (PST) > > > David, there really *is* something screwy in netfilter. > > Sure, but from what I can see this bug appears unrelated to the one in > kernel bugzilla #7781 that we've been discussing the past few days. > > First of all, the nf conntrack paths won't be used by normal > users until 2.6.20-rc1 or so. The bz #7781 report is against > 2.6.19 and all those backtraces have IP conntrack in them, not > nf conntrack. > > So what are we compiling with here btw, gcc-4.1? > > I want to rule the compiler out in this and the bz #7781 case > so that we can look at the code seriously. The first crash was with gcc 4.1.1, but now I recompiled the kernel with "gcc version 3.2.3 20030502 (Red Hat Linux 3.2.3-56.fc5)" and I can still reproduce the same crash. The backtrace looks the same, although the addresses are obviously different. Some hand copied data from the oops: BUG: unable to handle kernel paging request at virtual address 1d075089 eax: cc671e5c ebx: d58569a0 ecx: d58569a0 edx: 0014 esi: 1d075021 edi: 0001 ebp: cc671df0 esp: cc671ddc ds: 007b es: 007b ss: 0068 EIP: ipv4_conntrack_help+0x8e/0x93 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 2.6.20-rc4
Patrick McHardy <[EMAIL PROTECTED]> writes: > Linus Torvalds wrote: > > On Sun, 7 Jan 2007, Peter Osterlund wrote: > > > >>I get kernel panics when doing large ethernet transfers. A loop doing > >> EFALLGS: 00010206 (2.6.20-rc4 #13) > >> EIP is at ipv4_conntrack_help+0x6b/0x83 > >> eax: c0475e44 ebx: 9f5cea37 ecx: d1dcebb0 edx: 0014 > >> esi: d1dcebb0 edi: c0475e44 ebp: c0475dd8 esp: c0475dc4 > > > > which is ipv4_conntrack_help(): > > > > return help->helper->help(pskb, > > (*pskb)->nh.raw - (*pskb)->data > > + (*pskb)->nh.iph->ihl*4, > > ct, ctinfo); > > > > and that call instruction is the one that oopses because "help->helper" is > > corrupt (it's 0x9f5cea37 - not a valid kernel pointer). > > I guess its because of an uninitialized helper field in struct > nf_conntrack_expect, which is then copied from the expectation to > the conntrack entry. > > Peter, do you have locally generated netbios ns queries on the machine > running nf_conntrack? I have samba running on both machines. I guess that generates some netbios traffic even though it isn't currently in active use. > If so, please try this patch. Thanks, the patch appears to help. The kernel has now survived much longer with this patch than it used to do without it. I will recompile with gcc 4.1.1 too just to make sure, but if you don't hear anything more from me, consider the case closed. :) -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Occational lockups during boot with post 2.6.22 kernels
Current -git kernels sometimes lock up on my computer during boot. I guess it happens about 10-20% of the time. I first saw this maybe a week ago, but never with kernels <= 2.6.22. The last reported info on the console is that named is started. SysRq-T still works and reports the non-sleeping tasks below. My guess is that wpa_supplicant and events/0 deadlock and later the named thread also hangs when it needs a deadlocked resource. I'm using the bcm43xx driver. No lockdep errors are reported before the lockup. Earlier during boot the kernel reports: Good, all 218 testcases passed! | SysRq-T output: === events/0 D 0001 0 5 2 dfe0fe64 0092 935ee27c 0001 c0345e48 935ee27c 0001 c0462fc0 0001 dcab5040 dcd44de4 dcd44da4 0246 dfe0cb90 dfe0fea0 c0345df6 0002 c0346026 dcd44dd0 dcd44dd0 dcd44dd0 dfe0cb90 Call Trace: [] __mutex_lock_slowpath+0xb2/0x2c6 [] mutex_lock+0x1c/0x1f [] ieee80211softmac_assoc_work+0x24/0x51b [ieee80211softmac] [] ieee80211softmac_assoc_notify_scan+0x13/0x15 [ieee80211softmac] [] ieee80211softmac_notify_callback+0x41/0x7a [ieee80211softmac] [] run_workqueue+0xbb/0x13d [] worker_thread+0x9a/0xf9 [] kthread+0x36/0x58 [] kernel_thread_helper+0x7/0x10 === klogd R running 0 2771 1 wpa_supplican D 0001 0 2806 1 dc309d7c 00200082 935ecce6 0001 c0138e84 935ecce6 0001 00200046 dc309dbc dcab5040 dc309db8 dc309dbc dc309db8 dcd44fd4 dc309da0 c0344f98 0001 dcfdd350 c01186cc dc309de4 dc309de4 dff61740 dcd44fd4 dc309df0 Call Trace: [] wait_for_completion+0x91/0xc8 [] flush_cpu_workqueue+0x47/0x6f [] flush_workqueue+0x1c/0x1f [] flush_scheduled_work+0xd/0xf [] ieee80211softmac_wx_set_essid+0x144/0x188 [ieee80211softmac] [] ioctl_standard_call+0x16b/0x350 [] wext_handle_ioctl+0x35b/0x3e5 [] dev_ioctl+0x322/0x33d [] sock_ioctl+0xba/0x1d8 [] do_ioctl+0x22/0x71 [] vfs_ioctl+0x55/0x28a [] sys_ioctl+0x33/0x51 [] sysenter_past_esp+0x5f/0x99 === named D 0001 0 2836 2834 dbdc5e70 00200082 960324f3 0001 c0345e48 960324f3 0001 c0462fc0 0001 dd0d6300 c0454e20 c0454de0 00200246 c1694fd0 dbdc5eac c0345df6 0002 c0346026 c0454e0c c0454e0c c0454e0c c1694fd0 Call Trace: [] __mutex_lock_slowpath+0xb2/0x2c6 [] mutex_lock+0x1c/0x1f [] rtnl_lock+0xd/0xf [] dev_ioctl+0xb2/0x33d [] sock_ioctl+0xba/0x1d8 [] do_ioctl+0x22/0x71 [] vfs_ioctl+0x55/0x28a [] sys_ioctl+0x33/0x51 [] sysenter_past_esp+0x5f/0x99 -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PKTCDVD related bugzilla bugs
On Mon, 2 Jul 2007, Tejun Heo wrote: Hello, it's me again. We have another bug which reportedly is related to pktcdvd. Please respond. http://bugzilla.kernel.org/show_bug.cgi?id=7547 http://bugzilla.kernel.org/show_bug.cgi?id=7805 The problem is that when you run pktsetup, the driver will open the cdrom device and keep it open. A very long time ago, the driver didn't do that, but that caused other problems, see for example: http://herbie.ucs.indiana.edu/hypermail/linux/kernel/0407.0/0761.html I don't know how to fix these problems in the kernel, but I know that an old idea from Jens Axboe was to merge pktsetup and mount in user space so that pktsetup only needs to run when you are actually going to use packet writing. -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Improve error recovery in serial mouse driver
If bytes get lost in the communication with a serial mouse using the
MS protocol, the kernel driver could do a better job getting back in
sync. The first byte in a packet has bit 6 set, and no other bytes
have that bit set. Therefore, if a byte is received with bit 6 cleared
when the driver thinks it is at byte 0 in the packet, the driver thinks
wrong and the byte should just be ignored.
This fix prevents spurious left/right button events when the serial
communication is disturbed by a CPU-hungry real-time process.
Signed-off-by: Peter Osterlund <[EMAIL PROTECTED]>
---
drivers/input/mouse/sermouse.c |1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/drivers/input/mouse/sermouse.c b/drivers/input/mouse/sermouse.c
index a85d747..24bed4b 100644
--- a/drivers/input/mouse/sermouse.c
+++ b/drivers/input/mouse/sermouse.c
@@ -108,6 +108,7 @@ static void sermouse_process_ms(struct sermouse *sermouse,
signed char data)
signed char *buf = sermouse->buf;
if (data & 0x40) sermouse->count = 0;
+ else if (sermouse->count == 0) return;
switch (sermouse->count) {
--
Peter Osterlund - [EMAIL PROTECTED]
http://web.telia.com/~u89404340
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Fix sudden warps in mousedev
On Mon, 26 Mar 2007, Dmitry Torokhov wrote: On Monday 26 March 2007 17:42, Pete Zaitcev wrote: I don't think that you need to concern yourself with this too much at present. If X11 people (e.g. Kristian) present evidence that kernel fails to deliver an event, then we'll look at it. However it might help if evtest continued to work when X11 reads from /dev/input/eventN. It was an unpleasant surprise that it doesn't. The driver grabs tochpad with EVIOCGRAB ioctl to prevent input events from bveing delivered to X through /dev/input/mice which is still in whidespread use. That's why evtest does not work. We could as Peter (CCed) to implement an option to turn off grabbing so users who don't use mousedev multiplexor can use evtest and other commands. That sounds like a useful option. Implemented in my git tree: git clone http://web.telia.com/~u89404340/touchpad/synaptics/.git -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Null pointer dereference in fs/open.c
On Mon, 23 Apr 2007, Andrew Morton wrote: Try this: --- a/drivers/block/pktcdvd.c~packet-fix-error-handling +++ a/drivers/block/pktcdvd.c @@ -777,7 +777,8 @@ static int pkt_generic_packet(struct pkt rq->cmd_flags |= REQ_QUIET; blk_execute_rq(rq->q, pd->bdev->bd_disk, rq, 0); - ret = rq->errors; + if (rq->errors) + ret = -EIO; out: blk_put_request(rq); return ret; _ The packet driver was assuming that request.errors is an errno, but it isn't - it's some sort of diagnostic bitfield thing. Now why would the packet driver have though that? Let's go read the comments: ... Well there's your root cause right there. I don't know why this wasn't oopsing in eariler kernels. Perhaps something else is broken. Please test this urgently. The code used to return -EIO until commit 406c9b605cbc45151c03ac9a3f95e9acf050808c, which was commited 2007-01-05, so that would explain why older kernels didn't crash. What the heck _is_ in request.errors? According to linux/Documentation/block/request.txt, it is an error counter. The info in that text file would probably do a lot more good as comments in the structure definition though. Should the packet driver even be looking at it? I think so. How else is it supposed to know if the request failed? -- Peter Osterlund - [EMAIL PROTECTED] http://web.telia.com/~u89404340 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
