All of lore.kernel.org
 help / color / mirror / Atom feed
* Re: CSCAN I/O scheduler for 2.6.10 kernel
From: Vishal Patil @ 2006-04-09 16:55 UTC (permalink / raw)
  To: Antonio Vargas; +Cc: Bill Davidsen, Linux Kernel Mailing List
In-Reply-To: <4745278c0604050646n668bc9fy2b8c18462439ae5d@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 2723 bytes --]

I am attaching the CSCAN scheduler patch for 2.6.16.2 kernel.

- Vishal

On 4/5/06, Vishal Patil <vishpat@gmail.com> wrote:
> The two queues are used for sorting purposes ONLY. There is the
> dispatch queue to which the requests are moved from one of the queues
> and the request is processes of the dispatch queue.
>
> Example:
>
> Current request  = 40
> Q1 = 55 58 67 72
> Q2 = 10 23 38
>
> Assuming no other request arrives, these will be pushed on the
> dispatch queue in the following order
> 55 58 67 72 10 23 38
>
> I hope this clears things up.
>
> Also I have found that the patch that I had submitted earlier has few
> bugs in it. I am going to fix those and then submit a patch for 2.6.16
> Thanks.
>
>
> - Vishal
>
>
>
> On 4/5/06, Antonio Vargas <windenntw@gmail.com> wrote:
> > On 4/4/06, Vishal Patil <vishpat@gmail.com> wrote:
> > > In that case it would be a normal elevator algorithm and that has a
> > > possiblity of starving the requests at one end of the disk.
> > >
> > > - Vishal
> > >
> > > On 4/4/06, Bill Davidsen <davidsen@tmr.com> wrote:
> > > > Vishal Patil wrote:
> > > > > Maintain two queues which will be sorted in ascending order using Red
> > > > > Black Trees. When a disk request arrives and if the block number it
> > > > > refers to is greater than the block number of the current request
> > > > > being served add (merge) it to the first sorted queue or else add
> > > > > (merge) it to the second sorted queue. Keep on servicing the requests
> > > > > from the first request queue until it is empty after which switch over
> > > > > to the second queue and now reverse the roles of the two queues.
> > > > > Simple and Sweet. Many thanks for the awesome block I/O layer in the
> > > > > 2.6 kernel.
> > > > >
> > > > Why both queues sorting in ascending order? I would think that one
> > > > should be in descending order, which would reduce the seek distance
> > > > between the last i/o on one queue and the first on the next.
> > > >
> >
> > But, if there are two queues, one which is being processed and other
> > which gets the new requests (and the corresponding queue switch when
> > the current is empty), then there is no way to get starved when they
> > are sorted in opposite order.
> >
> >
> > --
> > Greetz, Antonio Vargas aka winden of network
> >
> > http://wind.codepixel.com/
> > windNOenSPAMntw@gmail.com
> > thesameasabove@amigascne.org
> >
> > Every day, every year
> > you have to work
> > you have to study
> > you have to scene.
> >
>
>
> --
> Every passing minute is another chance to turn it all around.
>


--
Every passing minute is another chance to turn it all around.

[-- Attachment #2: cscan-2.6.16.2-patch --]
[-- Type: application/octet-stream, Size: 11599 bytes --]

diff -urN linux-2.6.16.2/block/cscan.c linux-2.6.16.2-cscan/block/cscan.c
--- linux-2.6.16.2/block/cscan.c	1969-12-31 19:00:00.000000000 -0500
+++ linux-2.6.16.2-cscan/block/cscan.c	2006-04-09 10:24:52.000000000 -0400
@@ -0,0 +1,338 @@
+/*
+ * elevator cscan
+ */
+#include <linux/blkdev.h>
+#include <linux/elevator.h>
+#include <linux/bio.h>
+#include <linux/module.h>
+#include <linux/init.h>
+
+#define RQ_DATA(rq) ((struct cscan_request *) (rq)->elevator_private)
+
+#define RB_NONE         (2)
+#define RB_EMPTY(root)  ((root)->rb_node == NULL)
+#define ON_RB(node)     ((node)->rb_color != RB_NONE)
+#define RB_CLEAR(node)  ((node)->rb_color = RB_NONE)
+#define rb_entry_crq(node)      rb_entry((node), struct cscan_request, rb_node)
+#define DRQ_RB_ROOT(cd, crq)    (&(cd)->sort_list[rq_data_dir((crq)->request)])
+#define rq_rb_key(rq)           (rq)->sector
+
+
+struct cscan_data {
+        struct rb_root sort_list[2];
+        unsigned int count[2];
+        
+        sector_t last_sector;
+        unsigned int first;
+        mempool_t * crq_pool;
+};
+
+struct cscan_request {
+        struct rb_node rb_node;
+        sector_t rb_key;
+        unsigned int queue_id;
+
+        struct request * request;
+};
+
+static kmem_cache_t *crq_pool;
+
+/*
+ *      Searching/Sorting routines
+ */
+static struct cscan_request *
+__rb_insert_request(struct rb_root * root, struct cscan_request * crq) 
+{
+        struct rb_node **p = &root->rb_node;
+        struct rb_node *parent = NULL;
+        struct cscan_request * __crq;
+        
+         while(*p) {
+                parent = *p;
+                __crq = rb_entry(parent,struct cscan_request,rb_node);
+
+                if(crq->rb_key < __crq->rb_key) {
+                        p = &(*p)->rb_left;
+                } else if(crq->rb_key > __crq->rb_key) {
+                        p = &(*p)->rb_right;
+                } else {
+                        return __crq;
+                }
+        }
+        rb_link_node(&crq->rb_node,parent,p);
+        return NULL;
+} 
+
+static inline struct
+cscan_request * rb_insert_request(struct rb_root * root, 
+                                     struct cscan_request * crq)
+{
+        struct cscan_request * ret;
+        if((ret = __rb_insert_request(root,crq)))
+                goto out;
+        rb_insert_color(&crq->rb_node,root);
+out:
+        return ret;
+}
+
+static inline struct
+cscan_request * rb_find_request(struct rb_root * root, long key) 
+{
+        struct rb_node * n = root->rb_node;
+        struct cscan_request * crq;
+
+        while(n) 
+        {
+                crq = rb_entry(n,struct cscan_request,rb_node);
+
+                if (key > crq->rb_key) {
+                        n = n->rb_right;
+                } else if (key < crq->rb_key) {
+                        n = n->rb_left;
+                } else {
+                        return crq;
+                }
+        }
+        return NULL;
+}
+static void 
+cscan_remove_request(struct cscan_data * cd, struct cscan_request * crq) 
+{
+        rb_erase(&crq->rb_node, &cd->sort_list[crq->queue_id]);
+        RB_CLEAR(&crq->rb_node);
+        cd->count[crq->queue_id]--;
+}
+
+static void
+cscan_add_crq_rb(struct cscan_data * cd, struct cscan_request * crq) 
+{
+        crq->rb_key = rq_rb_key(crq->request);
+        rb_insert_request(&cd->sort_list[crq->queue_id],crq);
+        cd->count[crq->queue_id]++;
+}
+
+static void 
+cscan_merged_requests(request_queue_t *q, struct request *rq,
+				 struct request *next)
+{
+	struct cscan_data *cd = q->elevator->elevator_data;
+        struct cscan_request * crq;        
+        crq = RQ_DATA(rq);
+
+        cscan_remove_request(cd,crq);
+}
+
+static int 
+cscan_dispatch(request_queue_t *q, int force)
+{
+	struct cscan_data *cd = q->elevator->elevator_data;
+        struct rb_root * root = NULL;
+
+        if(rb_first(&cd->sort_list[cd->first])) {
+               root = &cd->sort_list[cd->first]; 
+        } else if(rb_first(&cd->sort_list[1 - cd->first])) {
+                root = &cd->sort_list[1 - cd->first]; 
+                cd->first = 1 - cd->first; 
+        }
+
+	if (root) {
+		struct cscan_request *crq;
+                struct request * rq;
+                
+		crq = rb_entry_crq(rb_first(root));
+                rq = crq->request;
+                cscan_remove_request(cd,crq);
+                cd->last_sector = rq->sector + rq->nr_sectors;
+		elv_dispatch_sort(q, rq);
+		return 1;
+	}
+	return 0;
+}
+
+static void 
+cscan_add_request(request_queue_t *q, struct request *rq)
+{
+	struct cscan_data *cd = q->elevator->elevator_data;
+        struct cscan_request * crq;        
+        
+        crq = RQ_DATA(rq);
+        if(rq->sector > cd->last_sector) 
+                crq->queue_id = cd->first;
+        else 
+                crq->queue_id = 1 - cd->first;
+        cscan_add_crq_rb(cd,crq);                                 
+}
+
+static int 
+cscan_queue_empty(request_queue_t *q)
+{
+	struct cscan_data *cd = q->elevator->elevator_data;
+
+        return ((rb_first(&cd->sort_list[cd->first]) == NULL) && 
+                (rb_first(&cd->sort_list[1 - cd->first]) == NULL));
+}
+
+static struct request *
+cscan_former_request(request_queue_t *q, struct request *rq)
+{
+	struct cscan_data *cd = q->elevator->elevator_data;
+        struct cscan_request * crq = RQ_DATA(rq); 
+       
+        if((crq->queue_id == cd->first) && (rb_prev(&crq->rb_node) == NULL))
+                return NULL;
+        
+        if( (crq->queue_id == (1 - cd->first)) && 
+                                (rb_prev(&crq->rb_node) == NULL)){
+                if(rb_last(&cd->sort_list[cd->first])){
+                	crq = rb_entry_crq(rb_last(
+                                &cd->sort_list[cd->first]));
+                        return crq->request;                                
+                } else {
+                        return NULL;
+                }
+        }            
+        
+        return rb_entry_crq(rb_prev(&crq->rb_node))->request;
+}
+
+static struct request *
+cscan_latter_request(request_queue_t *q, struct request *rq)
+{
+	struct cscan_data *cd = q->elevator->elevator_data;
+        struct cscan_request * crq = RQ_DATA(rq); 
+       
+        if((crq->queue_id == (1 - cd->first)) && 
+                                (rb_next(&crq->rb_node) == NULL))
+                return NULL;
+        
+        if( (crq->queue_id == cd->first) && 
+                                (rb_next(&crq->rb_node) == NULL)){
+                if(rb_first(&cd->sort_list[1 - cd->first])){
+                	crq = rb_entry_crq(rb_first(
+                                &cd->sort_list[1 - cd->first]));
+                        return crq->request;                                
+                } else {
+                        return NULL;
+                }
+        }            
+        
+        return rb_entry_crq(rb_next(&crq->rb_node))->request;
+
+}
+
+static void 
+cscan_put_request(request_queue_t *q, struct request * rq) 
+{
+        struct cscan_data * cd = q->elevator->elevator_data;
+        struct cscan_request *crq = RQ_DATA(rq);
+
+        mempool_free(crq,cd->crq_pool);
+        rq->elevator_private = NULL;
+}
+
+static int
+cscan_set_request(request_queue_t *q, struct request *rq, struct bio *bio,
+                     gfp_t gfp_mask)
+{
+        struct cscan_data * cd = q->elevator->elevator_data;
+        struct cscan_request * crq;
+        
+        crq = mempool_alloc(cd->crq_pool,gfp_mask);
+        if(crq) {
+                memset(crq,0,sizeof(*crq));
+                RB_CLEAR(&crq->rb_node);
+                crq->request = rq;
+                rq->elevator_private = crq;
+                return 0;
+        }
+        return 1;
+}
+
+
+static int 
+cscan_init_queue(request_queue_t *q, elevator_t *e)
+{
+	struct cscan_data *cd;
+        int i = 0;
+
+	cd = kmalloc(sizeof(*cd), GFP_KERNEL);
+	if (!cd)
+		return -ENOMEM;
+                
+        cd->first = 0;
+        cd->last_sector = 0;
+        for(i=0;i<2;i++) {
+                cd->sort_list[i] = RB_ROOT;
+                cd->count[i]     = 0;
+        }
+	e->elevator_data = cd;
+
+        cd->crq_pool = mempool_create(BLKDEV_MIN_RQ,mempool_alloc_slab,
+                        mempool_free_slab,crq_pool);
+
+       if(!cd->crq_pool) {
+                kfree(cd);
+                return -ENOMEM;
+       }
+	return 0;
+}
+
+static void 
+cscan_exit_queue(elevator_t *e)
+{
+	struct cscan_data *cd = e->elevator_data;
+
+        BUG_ON(rb_first(&cd->sort_list[cd->first]) != NULL);
+        BUG_ON(rb_first(&cd->sort_list[1 - cd->first]) != NULL);
+
+	kfree(cd);
+}
+
+static struct elevator_type elevator_cscan = {
+	.ops = {
+		.elevator_merge_req_fn		= cscan_merged_requests,
+		.elevator_dispatch_fn		= cscan_dispatch,
+		.elevator_add_req_fn		= cscan_add_request,
+		.elevator_queue_empty_fn	= cscan_queue_empty,
+		.elevator_former_req_fn		= cscan_former_request,
+		.elevator_latter_req_fn		= cscan_latter_request,
+                .elevator_set_req_fn            = cscan_set_request,
+                .elevator_put_req_fn            = cscan_put_request,
+		.elevator_init_fn		= cscan_init_queue,
+		.elevator_exit_fn		= cscan_exit_queue,
+	},
+	.elevator_name = "cscan",
+	.elevator_owner = THIS_MODULE,
+};
+
+static int __init 
+cscan_init(void)
+{
+        int ret;
+
+        crq_pool = kmem_cache_create("cscan_crq", sizeof(struct cscan_request),
+                                     0, 0, NULL, NULL);
+        if (!crq_pool)
+                 return -ENOMEM;
+
+        ret = elv_register(&elevator_cscan);
+        if(ret)
+                kmem_cache_destroy(crq_pool);
+        
+        return ret;
+}
+
+static void __exit 
+cscan_exit(void)
+{
+        kmem_cache_destroy(crq_pool);
+	elv_unregister(&elevator_cscan);
+}
+
+module_init(cscan_init);
+module_exit(cscan_exit);
+
+
+MODULE_AUTHOR("Vishal Patil");
+MODULE_LICENSE("GPL");
+MODULE_DESCRIPTION("CSCAN I/O scheduler");
diff -urN linux-2.6.16.2/block/Kconfig.iosched linux-2.6.16.2-cscan/block/Kconfig.iosched
--- linux-2.6.16.2/block/Kconfig.iosched	2006-04-07 12:56:47.000000000 -0400
+++ linux-2.6.16.2-cscan/block/Kconfig.iosched	2006-04-09 10:25:07.000000000 -0400
@@ -11,6 +11,19 @@
 	  that do their own scheduling and require only minimal assistance from
 	  the kernel.
 
+config IOSCHED_CSCAN
+	bool
+	default y
+	---help---
+        CSCAN I/O scheduler. Maintain two queues which will be sorted in
+        ascending order using Red Black Trees. When a disk request arrives and
+        if the block number it refers to is greater than the block number of the
+        current request being served add (merge) it to the first sorted queue or
+        else add (merge) it to the second sorted queue. Keep on servicing the
+        requests from the first request queue until it is empty after which
+        switch over to the second queue and now reverse the roles of the two
+        queues
+
 config IOSCHED_AS
 	tristate "Anticipatory I/O scheduler"
 	default y
diff -urN linux-2.6.16.2/block/Makefile linux-2.6.16.2-cscan/block/Makefile
--- linux-2.6.16.2/block/Makefile	2006-04-07 12:56:47.000000000 -0400
+++ linux-2.6.16.2-cscan/block/Makefile	2006-04-09 10:24:58.000000000 -0400
@@ -5,6 +5,7 @@
 obj-y	:= elevator.o ll_rw_blk.o ioctl.o genhd.o scsi_ioctl.o
 
 obj-$(CONFIG_IOSCHED_NOOP)	+= noop-iosched.o
+obj-$(CONFIG_IOSCHED_CSCAN)	+= cscan.o
 obj-$(CONFIG_IOSCHED_AS)	+= as-iosched.o
 obj-$(CONFIG_IOSCHED_DEADLINE)	+= deadline-iosched.o
 obj-$(CONFIG_IOSCHED_CFQ)	+= cfq-iosched.o


^ permalink raw reply

* [ALSA - driver 0001934]: make problem
From: bugtrack @ 2006-04-09 16:56 UTC (permalink / raw)
  To: alsa-devel


A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1934> 
======================================================================
Reported By:                kvo
Assigned To:                perex
======================================================================
Project:                    ALSA - driver
Issue ID:                   1934
Category:                   0_compilation problem_!!!
Reproducibility:            always
Severity:                   block
Priority:                   normal
Status:                     assigned
Distribution:               RHEL4 Update 3
Kernel Version:             2.6.9-34.EL
======================================================================
Date Submitted:             03-17-2006 12:19 CET
Last Modified:              04-09-2006 18:56 CEST
======================================================================
Summary:                    make problem
Description: 
./configure works OK. running make give error during compilation: module
'include/asound.h' (line 210) has some 'typedef' that doesn't match with
(probably) OS include. As a result, compilation stops and driver can not
be produced.
======================================================================

----------------------------------------------------------------------
 kvo - 03-25-06 22:19 
----------------------------------------------------------------------
I sent config.log (I did´t see any strange things in it). Recently I
compiled wireless driver for the same system and everything went smoothly,
so, compression isn´t a reason, most probably.

----------------------------------------------------------------------
 kvo - 04-09-06 18:56 
----------------------------------------------------------------------
I sent an additional information (see attached info.zip). I used 1.0.11rc4
tarball for these data.

  1. File ´1´ is my ´configure´ results.
  2. File ´2´ -- ´make´ results.
  3. ´config.log'
  4. File ´gfp.h´, has been taken from the kernel source tree.

  I have found that ´typedef gfp_t´ differs between distributive version
and inside of ALSA files. So, I think, it is the source of problem. Last
time I recompiled ALSA with 2.6.9-22.0.2.EL kernel and it was OK, but now
...

Issue History
Date Modified  Username       Field                    Change              
======================================================================
03-17-06 12:19 kvo            New Issue                                    
03-17-06 12:19 kvo            Distribution              => RHEL4 Update 3  
03-17-06 12:19 kvo            Kernel Version            => 2.6.9-34.EL     
03-17-06 12:25 tiwai          Note Added: 0008643                          
03-19-06 22:26 kvo            Note Added: 0008697                          
03-21-06 17:33 tiwai          Note Added: 0008749                          
03-25-06 20:47 kvo            File Added: config.log                       
03-25-06 22:19 kvo            Note Added: 0008952                          
04-09-06 18:47 kvo            File Added: info.zip                         
04-09-06 18:56 kvo            Note Added: 0009181                          
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* Re: [2.6 patch] drivers/char/random.c: unexport secure_ipv6_port_ephemeral
From: Matt Mackall @ 2006-04-09 16:56 UTC (permalink / raw)
  To: Adrian Bunk; +Cc: Andrew Morton, linux-kernel, netdev
In-Reply-To: <20060409155822.GI8454@stusta.de>

On Sun, Apr 09, 2006 at 05:58:22PM +0200, Adrian Bunk wrote:
> This patch removes the unused EXPORT_SYMBOL(secure_ipv6_port_ephemeral).

> Signed-off-by: Adrian Bunk <bunk@stusta.de>
Acked-by: Matt Mackall <mpm@selenic.com>

Adrian appears to be correct that this doesn't break modular ipv6.
-- 
Mathematics is the supreme nostalgia of our time.

^ permalink raw reply

* [Patch] Wrong out of range check in drivers/char/applicom.c
From: Eric Sesterhenn @ 2006-04-09 17:06 UTC (permalink / raw)
  To: LKML; +Cc: dwmw2

hi,

this fixes coverity bug id #469. The out of range check didnt
work as intended, as seen by the printk(), which states that 
boardno has to be 1 <= boardno <= MAX_BOARD.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>

--- linux-2.6.17-rc1/drivers/char/applicom.c.orig	2006-04-09 18:57:29.000000000 +0200
+++ linux-2.6.17-rc1/drivers/char/applicom.c	2006-04-09 18:57:55.000000000 +0200
@@ -142,7 +142,7 @@ static int ac_register_board(unsigned lo
 	if (!boardno)
 		boardno = readb(loc + NUMCARD_OWNER_TO_PC);
 
-	if (!boardno && boardno > MAX_BOARD) {
+	if (!boardno || boardno > MAX_BOARD) {
 		printk(KERN_WARNING "Board #%d (at 0x%lx) is out of range (1 <= x <= %d).\n",
 		       boardno, physloc, MAX_BOARD);
 		return 0;



^ permalink raw reply

* Re: Black box flight recorder for Linux
From: James Courtier-Dutton @ 2006-04-09 17:09 UTC (permalink / raw)
  To: JustFillBug; +Cc: linux-kernel
In-Reply-To: <slrne3ge8n.ps.mozbugbox@mozbugbox.somehost.org>

JustFillBug wrote:
> On 2006-04-08, James Courtier-Dutton <James@superbug.co.uk> wrote:
>> Andi Kleen wrote:
>>> Reset button is like a cold boot and it generally ends up with cleared 
>>> RAM.
>>>
>> Thank you. That saved me 30mins hacking. :-)
>>
> 
> How about Magic sysRq reboot? 
> 

Another alternative is that the motherboard in question has a PS2 mouse 
port, but not RS232 serial port.
Can I connect the PS2 ports of two PCs together and get the console 
working through that?

James

^ permalink raw reply

* Re: Linux 2.6.17-rc1: /sbin/iptables does not find kernel netfilter
From: Ville Herva @ 2006-04-09 17:10 UTC (permalink / raw)
  To: Nix; +Cc: Patrick McHardy, linux-kernel, netfilter
In-Reply-To: <87hd52g065.fsf@hades.wkstn.nix>

On Sun, Apr 09, 2006 at 05:53:54PM +0100, you [Nix] wrote:
> On Sun, 09 Apr 2006, Patrick McHardy murmured woefully:
> >> I cetainly did. A simple `make oldconfig' ends up zapping pretty much
> >> all the old iptables CONFIG_ options, so you end up with not much of
> >> iptables or netfilter left.
> > 
> > But it does show you all the new options. Admittedly, it would
> > have been better to automatically select the new options when
> > needed, but probably not worth changing it now, it has been
> > like this for two releases I think.
> 
> Oh, yes, it did, and I thought they were userspace-matching related and
> left them off. The real problem is that oldconfig doesn't mention when
> options you *had* enabled disappear.

Likewise for me.

Perhaps iptables could point to a document or a webpage (in case kernel is newer
than the userspace iptables, and has introduced new requirements) that lists
the kernel options that need to be enabled, instead of saying 

 failed iptables v1.3.5: can't initialize iptables table filter: iptables
 who? (do you need to insmod?)

Such verbosity might not be unixy, but during Old Unix times, thousands of people
weren't following -rc kernels...


-- v -- 

v@iki.fi

^ permalink raw reply

* Re: [RFH] Exploration of an alternative diff_delta() algorithm
From: Nicolas Pitre @ 2006-04-09 17:14 UTC (permalink / raw)
  To: Peter Eriksen; +Cc: git
In-Reply-To: <20060409143117.GA23908@erlang.gbar.dtu.dk>

On Sun, 9 Apr 2006, Peter Eriksen wrote:

> Greetings Gitlings,
> 
> I've been trying to implement an alternative algorithm
> for diff_delta().  I'm getting close to something that
> works, but now I'm stuck!  I think it has something to
> do with pack-objects.c, but I'm not sure.  Here's the
> first test that fails:
> 
> *** t5500-fetch-pack.sh ***
> * FAIL 1: 1st pull
>         git-fetch-pack -v .. B A > log.txt 2>&1
> * FAIL 2: fsck
>         git-fsck-objects --full > fsck.txt 2>&1
> * FAIL 3: new object count after 1st pull
>         test 33 = 0
> * FAIL 4: minimal count
>         test 33 = 0
> * FAIL 5: repack && prune-packed in client
>         (git-repack && git-prune-packed)2>>log.txt
> *   ok 5: 2nd pull
> *   ok 6: fsck
> * FAIL 7: new object count after 2nd pull
>         test 192 = 198
> * FAIL 8: minimal count
>         test 192 = 198
> * FAIL 9: repack && prune-packed in client
>         (git-repack && git-prune-packed)2>>log.txt
> *   ok 9: 3rd pull
> *   ok 10: fsck
> * FAIL 11: new object count after 3rd pull
>         test 3 = 228
> * FAIL 12: minimal count
>         test 3 = 30
> * failed 8 among 12 test(s)
> 
> I've been looking all around the current diff_delta(), and I
> can't see, what I'm missing.  Any ideas?  The file is meant to
> replace the current diff-delta.c.

Nothing outside diff-delta.c and patch-delta.c is aware of the delta 
data format.  So if your version is meant to be a transparent 
replacement then it should pass all tests.  If it doesn't then it is 
broken.

To help you play around you could try the test-delta utility (make 
test-delta to build it).

So:

	test-delta -d file1 file2 delta_file
	test-delta -p file1 delta_file file3
	cmp file2 file3

You should always have file3 identical to file2.


Nicolas

^ permalink raw reply

* [Patch] Overrun in cdrom/aztcd.c
From: Eric Sesterhenn @ 2006-04-09 17:16 UTC (permalink / raw)
  To: LKML

hi,

this fixes coverity bug id #473.
After the for loop i==16 if we dont find a cdrom. So we should
check for i==16 first before checking the array element.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>

--- linux-2.6.17-rc1/drivers/cdrom/aztcd.c.orig	2006-04-09 19:09:24.000000000 +0200
+++ linux-2.6.17-rc1/drivers/cdrom/aztcd.c	2006-04-09 19:09:49.000000000 +0200
@@ -1763,7 +1763,7 @@ static int __init aztcd_init(void)
 				release_region(azt_port, 4);
 			}
 		}
-		if ((azt_port_auto[i] == 0) || (i == 16)) {
+		if ((i == 16) || (azt_port_auto[i] == 0)) {
 			printk(KERN_INFO "aztcd: no AZTECH CD-ROM drive found\n");
 			return -EIO;
 		}



^ permalink raw reply

* [Xenomai-core] GDB 6.x + simulator
From: Philippe Gerum @ 2006-04-09 17:17 UTC (permalink / raw)
  To: xenomai


The following patch enables GDB 6.x for the simulator. Please give this
a try if you happen to use the Xenosim. TIA,

--- sim/scope/gdbhelper.cc	(revision 904)
+++ sim/scope/gdbhelper.cc	(working copy)
@@ -423,6 +423,8 @@

      char *ibuf = gdb_ibuf.gets(), *estart = gdb_ibuf.gets();

+    Tcl_ResetResult(tclInterp);
+
      for (;;)
  	{
  	if (*ibuf == '\0' || *ibuf == '\n')
@@ -504,7 +506,7 @@
  		// the contents of the log did not match anything known to
  		// the caller. We cannot return -1, which value is reserved
  		// to indicate that the connection with GDB has been lost.
-		
+
  		Tcl_AppendElement(tclInterp,CString(rc2 ? rc2 : nre).gets());
  		Tcl_AppendElement(tclInterp,matched);
  		Tcl_AppendElement(tclInterp,Tcl_DStringValue(&gdb_ilog));
Index: sim/scope/tcl/gdb.tcl
===================================================================
--- sim/scope/tcl/gdb.tcl	(revision 904)
+++ sim/scope/tcl/gdb.tcl	(working copy)
@@ -850,8 +850,10 @@
  	regexp "\[^\"\]+.(\[^\"\]+).*" $matched mvar curfocus
      }

-    # query stack information
-    set rl [gdb:command where ls]
+    # query stack information -- auto-limit to the inner last 32
+    # frames in order to work-around the issue GDB 6.x has with
+    # ucontext(2) driven co-routines.
+    set rl [gdb:command "where 32" ls]
      set stackinfo [lindex $rl 2]

      if {$stackinfo == {}} {

-- 

Philippe.


^ permalink raw reply

* net interface renaming issue (+fix?)
From: Thomas de Grenier de Latour @ 2006-04-09 17:21 UTC (permalink / raw)
  To: linux-hotplug

Hi,

I'm running Gentoo Linux, a 2.6.16-ck kernel, and udev-0.89-r2, and 
have had hard time with network interfaces renaming through udev 
rules. The first thing i've tried were rules like this one:

SUBSYSTEM="net", KERNEL="eth*", SYSFS{address}="00:0d:60:12:75:0a", NAME="lan"

Plus this one from the standard early rules:

ACTION="add", SUBSYSTEM="net", WAIT_FOR_SYSFS="address"

It doesn't work when i "modprobe e1000" (my ethernet driver):
...
udevd[21612]: udev_event_run: seq 956 forked, pid [21816], 'add' 'net', 0 seconds old
udevd-event[21816]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
udevd-event[21816]: udev_rules_get_name: no node name set, will use kernel name 'eth0'
...
But if i later do a "echo add > /sys/class/net/eth0/uevent", then 
interface is properly renamed. It also works fine if i start with
the module initialy not loaded, and then trigger the uevent on the
corresponding pci device (will load the module, etc.)


Then i've tried replacing the address match by DRIVER="e1000", with
no more success.  But i've  noticed something interesting in debug 
output, when the rule matcher walks up in parent devices to check 
the driver:
% grep -i driver /var/tmp/udev-net-debug.log
...
udevd-event[18411]: match_key: key DRIVER value='e1000'
udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
udevd-event[18411]: match_key: DRIVER is false
udevd-event[18411]: sysfs_device_get: add to cache 'devpath=/devices/pci0000:00/0000:00:1e.0/0000:02:01.0', subsystem='pci', driver=''
udevd-event[18411]: match_key: key DRIVER value='e1000' 
udevd-event[18411]: match_key: match DRIVER 'e1000' <-> '' 
udevd-event[18411]: match_key: DRIVER is false
...
This is weird, because if i latter look in /sys, the "driver" links
are here. Which made me think it was a race, so i've added this rule:

ACTION="add", SUBSYSTEM="net", WAIT_FOR_SYSFS="device/driver"

And it fixed the problem:
...
udevd[21612]: udev_event_run: seq 950 forked, pid [21790], 'add' 'net', 0 seconds old
udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
udevd-event[21790]: wait_for_sysfs: wait for '/sys/class/net/eth0/device/driver' for 20 mseconds
udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/device/driver' appeared after 1 loops
udevd-event[21790]: udev_rules_get_name: rule applied, 'eth0' becomes 'lan'
udevd-event[21790]: rename_net_if: changing net interface name from 'eth0' to 'lan'
udevd-event[21790]: udev_add_device: renamed netif to 'lan'
...

It also fixes the problem with using a SYSFS{address} match btw.
With no such wait, i can see in debug that "address" is found in sysfs,
but with no value:
...
udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
udevd-event[21977]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
udevd-event[21977]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
...
Whereas with the wait-for-driver trick, i can see it read with a 
useful value:
...
udevd-event[21954]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
udevd-event[21954]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
udevd-event[21954]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
udevd-event[21954]: sysfs_attr_get_value: cache '/sys/class/net/eth0/address' with value '00:0d:60:12:75:0a'
...

So i wonder, maybe such a rule should be added to the standard early
ones? It should maybe use more checks though, to be sure there is
actually a driver to wait. Something like ENV{PHYSDEVPATH}="?*" 
and/or ENV{PHYSDEVDRIVER}="?*".

Btw, using ENV{PHYSDEVDRIVER}="e1000" in my renaming rule was working
fine, with no trick (this variables are correctly set, like 'udevmonitor 
--env' shows).


So, what do you think, does such a rule makes sense?
Or is "address" being added to sysfs with no useful value yet the real
issue, and my rule only an ugly workround?


Thanks,

-- 
TGL.


-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid\x110944&bid$1720&dat\x121642
_______________________________________________
Linux-hotplug-devel mailing list  http://linux-hotplug.sourceforge.net
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

^ permalink raw reply

* [KJ] [PATCH 2.6.17-rc1-mm2] net: cleanup CONFIG_PCI from dgrs.c
From: Richard Knutsson @ 2006-04-09 17:23 UTC (permalink / raw)
  To: kernel-janitors

From: Richard Knutsson <ricknu-0@student.ltu.se>

Removed (I believe) unnecessary CONFIG_PCI and an ugly (previous patch 
of mine) empty struct if !CONFIG_PCI.

Compiled tested, with and without an "#undef CONFIG_PCI" in dgrs.c, with 
no warnings/errors.

Signed-off-by: Richard Knutsson <ricknu-0@student.ltu.se>
---

 dgrs.c |    8 +-------
 1 files changed, 1 insertion(+), 7 deletions(-)

diff -Narup a/drivers/net/dgrs.c b/drivers/net/dgrs.c
--- a/drivers/net/dgrs.c	2006-04-09 15:47:43.000000000 +0200
+++ b/drivers/net/dgrs.c	2006-04-09 18:22:12.000000000 +0200
@@ -121,11 +121,11 @@ typedef unsigned int bool;
 #include "dgrs_asstruct.h"
 #include "dgrs_bcomm.h"
 
-#ifdef CONFIG_PCI
 static struct pci_device_id dgrs_pci_tbl[] = {
 	{ SE6_PCI_VENDOR_ID, SE6_PCI_DEVICE_ID, PCI_ANY_ID, PCI_ANY_ID, },
 	{ }			/* Terminating entry */
 };
+#ifdef CONFIG_PCI
 MODULE_DEVICE_TABLE(pci, dgrs_pci_tbl);
 #endif
 
@@ -1381,7 +1381,6 @@ static void __devexit dgrs_remove(struct
 	}
 }
 
-#ifdef CONFIG_PCI
 static int __init dgrs_pci_probe(struct pci_dev *pdev,
 				 const struct pci_device_id *ent)
 {
@@ -1458,9 +1457,6 @@ static struct pci_driver dgrs_pci_driver
 	.probe = dgrs_pci_probe,
 	.remove = __devexit_p(dgrs_pci_remove),
 };
-#else
-static struct pci_driver dgrs_pci_driver = {};
-#endif
 
 
 #ifdef CONFIG_EISA
@@ -1608,9 +1604,7 @@ static void __exit dgrs_cleanup_module (
 #ifdef CONFIG_EISA
 	eisa_driver_unregister (&dgrs_eisa_driver);
 #endif
-#ifdef CONFIG_PCI
 	pci_unregister_driver (&dgrs_pci_driver);
-#endif
 }
 
 module_init(dgrs_init_module);


_______________________________________________
Kernel-janitors mailing list
Kernel-janitors@lists.osdl.org
https://lists.osdl.org/mailman/listinfo/kernel-janitors

^ permalink raw reply

* Re: RT task scheduling
From: Darren Hart @ 2006-04-09 17:25 UTC (permalink / raw)
  To: Ingo Molnar
  Cc: linux-kernel, Thomas Gleixner, Stultz, John, Peter Williams,
	Siddha, Suresh B, Nick Piggin
In-Reply-To: <20060409131649.GA19082@elte.hu>

On Sunday 09 April 2006 06:16, Ingo Molnar wrote:
> * Darren Hart <darren@dvhart.com> wrote:
> > My last mail specifically addresses preempt-rt, but I'd like to know
> > people's thoughts regarding this issue in the mainline kernel.  Please
> > see my previous post "realtime-preempt scheduling - rt_overload
> > behavior" for a testcase that produces unpredictable scheduling
> > results.
>
> thanks for the testcase! It indeed triggered a bug in the -rt tree's
> "RT-overload" balancing feature. The nature of the bug made it trigger
> much less likely on 2-way boxes (where i do most of my -rt testing),
> probably that's why it didnt get discovered before. I've uploaded the
> -rt14 tree with this bug fixed - does it fix the failures for you?

I ran the test 100 times, no failures!  Looks good to me.

# for ((i=0;i<100;i++)); do ./sched_football 4 10 | grep "Final ball position" 
| tee sched_football_ball.log; sleep 1; done
Final ball position: 0
...
Final ball position: 0

Looking at the patch, it looks like the problem was a race on the runqueue 
lock - when we called double_runqueue_lock(a,b) we risked dropping the lock 
on b, giving another CPU opportunity to grab it and pull our next task.  The 
API change to double_runqueue_lock() and checking the new return code in 
balance_rt_tasks() is what fixed the issue.  Is that accurate?

I was doing some testing to see why the RT tasks don't appear to be evenly 
distributed across the CPUs (in my earlier post using the output 
of /proc/stat).  I was wondering if the load_balancing code might be 
interfering with the balance_rt_tasks() code.  Should the normal 
load_balancer even touch RT tasks in the presence of balance_rt_tasks() ?  
I'm thinking not.

Thanks,

--
Darren Hart
IBM Linux Technology Center
Realtime Linux Team
Phone: 503 578 3185
  T/L: 775 3185

^ permalink raw reply

* [ALSA - driver 0001968]: ews88mt does not work with the terratec mic8/2 module
From: bugtrack @ 2006-04-09 17:29 UTC (permalink / raw)
  To: alsa-devel


A NOTE has been added to this issue.
======================================================================
<https://bugtrack.alsa-project.org/alsa-bug/view.php?id=1968> 
======================================================================
Reported By:                jewi
Assigned To:                
======================================================================
Project:                    ALSA - driver
Issue ID:                   1968
Category:                   PCI - ice1712
Reproducibility:            always
Severity:                   feature
Priority:                   normal
Status:                     new
Distribution:               debian unstable
Kernel Version:             2.6.15
======================================================================
Date Submitted:             03-27-2006 11:42 CEST
Last Modified:              04-09-2006 19:29 CEST
======================================================================
Summary:                    ews88mt does not work with the terratec mic8/2
module
Description: 
Is it possible to get the ews88mt pci card working with the mic8/2 module
(http://audioen.terratec.net/modules.php?op=modload&name=News&file=article&sid=2)?

When I load the ice1712 driver I get the following error message:
AK4524 chip select failed, check cable to the front module.

I have this setup at home and hope I can post all the required
information.
Thanks for help.
======================================================================

----------------------------------------------------------------------
 jewi - 04-09-06 19:29 
----------------------------------------------------------------------
I have some additional information that might be helpful:

The mic8 module is shipped together with the ews88mt pci card. I found an
old win98 hd and check that my setup works with Win. So there is no
problem with not connected cables or broken hardware.

The kernel messages are a bit more comprehensive than mentioned above.
When I load the snd-ice1712 module I get the following:

kernel: ACPI: PCI Interrupt 0000:00:09.0[A] -> Link [LNKD] -> GSI 11
(level, ow) -> IRQ 11
kernel: AK4524 chip select failed, check cable to the front module
kernel: ACPI: PCI interrupt for device 0000:00:09.0 disabled
kernel: ICE1712: probe of 0000:00:09.0 failed with error -5

The module is loaded but there is no soundcard in /proc/asound/cards

I found out that forcing the module to take a ews88d card I can see a
soundcard in /proc/asound/cards and the 3.5mm jack works on the ews88mt
works. But I don't get usefull input from the 8 analog inputs.

Is there anyone who has an idea what I can do to get things working?

Thanks for help

Issue History
Date Modified  Username       Field                    Change              
======================================================================
03-27-06 11:42 jewi           New Issue                                    
03-27-06 11:42 jewi           Distribution              => debian unstable 
03-27-06 11:42 jewi           Kernel Version            => 2.6.15          
04-09-06 19:29 jewi           Note Added: 0009183                          
======================================================================




-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642

^ permalink raw reply

* [Patch] Overrun in drivers/scsi/sim710.c
From: Eric Sesterhenn @ 2006-04-09 17:30 UTC (permalink / raw)
  To: LKML

hi,

this fixes coverity bug id #480.
Since id_array is declared as id_array[MAX_SLOTS],
the check for i>MAX_SLOTS is obviously false.

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>

--- linux-2.6.17-rc1/drivers/scsi/sim710.c.orig	2006-04-09 19:25:13.000000000 +0200
+++ linux-2.6.17-rc1/drivers/scsi/sim710.c	2006-04-09 19:27:07.000000000 +0200
@@ -75,7 +75,7 @@ param_setup(char *str)
 		else if(!strncmp(pos, "id:", 3)) {
 			if(slot == -1) {
 				printk(KERN_WARNING "sim710: Must specify slot for id parameter\n");
-			} else if(slot > MAX_SLOTS) {
+			} else if(slot >= MAX_SLOTS) {
 				printk(KERN_WARNING "sim710: Illegal slot %d for id %d\n", slot, val);
 			} else {
 				id_array[slot] = val;



^ permalink raw reply

* [linux-lvm] can't use swap after switch to LVM
From: Joel Uckelman @ 2006-04-09 17:31 UTC (permalink / raw)
  To: linux-lvm

I just switched my desktop FC5 system from using software RAID over regular
partitions to using software RAID over LVM; everything works fine, except
I can't enable my swap.

On boot, I get the following messages:

   device-mapper: device 9:1 too small for target
   device-mapper: dm-linear: Device lookup failed
   device-mapper: error adding target to table
   .
   .
   .
   Unable to find swap-space signature

My swap volume is listed like this in my /etc/fstab:

   /dev/VolGroup00/LogVol01 swap swap defaults 0 0

If I try to format the swap volume, mkswap tells me that it's too small:

   # mkswap /dev/mapper/VolGroup00-LogVol01
   mkswap: error: swap area needs to be at least 40kB

But 'lvm lvs' reports that's it's 1GB:

   LogVol01 VolGroup00 -wi-d-     1.00G

I've tried deleting and recreating the swap volume:

   # lvm lvremove VolGroup00/LogVol01
   # lvm lvcreate -L 1024M -n LogVol01 VolGroup00
   device-mapper: reload ioctl failed: Invalid argument
   Failed to activate new LV.

Does anyone have an idea of what's going wrong here?

-- 
J.

^ permalink raw reply

* Re: [RFH] Exploration of an alternative diff_delta() algorithm
From: Peter Eriksen @ 2006-04-09 17:34 UTC (permalink / raw)
  To: git
In-Reply-To: <Pine.LNX.4.64.0604091307460.2215@localhost.localdomain>

On Sun, Apr 09, 2006 at 01:14:31PM -0400, Nicolas Pitre wrote:
...
> Nothing outside diff-delta.c and patch-delta.c is aware of the delta 
> data format.  So if your version is meant to be a transparent 
> replacement then it should pass all tests.  If it doesn't then it is 
> broken.
> 
> To help you play around you could try the test-delta utility (make 
> test-delta to build it).
> 
> So:
> 
> 	test-delta -d file1 file2 delta_file
> 	test-delta -p file1 delta_file file3
> 	cmp file2 file3

My tests of these kinds doesn't show any errors.  Though, if file2 is
empty, test-delta writes: "file2: Invalid argument".

Peter

^ permalink raw reply

* Re: 2.4.32: unresolved symbol unregister_qdisc
From: George P Nychis @ 2006-04-09 17:37 UTC (permalink / raw)
  To: Randy.Dunlap; +Cc: davem, linux-kernel, netdev
In-Reply-To: <20060408163743.c59d6e59.rdunlap@xenotime.net>

Thanks for the help.

Here is the makefile:
http://rafb.net/paste/results/auchPH75.html

And here is the full errors I receive:
http://rafb.net/paste/results/Qplpqw74.html

Greatly appreciate it

- George


> On Sat, 8 Apr 2006 19:18:47 -0400 (EDT) George P Nychis wrote:
> 
>> Yeah, this module is unfortunately not under the GPL, it was made for
>> research and i am not the author, I was only given the code for my own
>> research.
>> 
>> I enabled that support in the kernel, and then tried to recompile and
>> get tons of errors/warnings... so maybe I am missing something else to
>> be enabled in the kernel... here are a few examples of errors: 
>> /usr/include/linux/skbuff.h:30:26: net/checksum.h: No such file or
>> directory /usr/include/asm/irq.h:16:25: irq_vectors.h: No such file or
>> directory /usr/include/linux/irq.h:72: error: `NR_IRQS' undeclared here
>> (not in a function) /usr/include/asm/hw_irq.h:28: error:
>> `NR_IRQ_VECTORS' undeclared here (not in a function)
>> 
>> I think those are the top most errors, so if i can fix those hopefully
>> the rest shall vanish!
> 
> Looks like a Makefile problem then.  Can you post the Makefile? Hopefully
> it is using a Makefile and not just an elaborate gcc command line.
> 
> [and please don't top-post]
> 
>> - George
>> 
>> 
>>> From: "George P Nychis" <gnychis@cmu.edu> Date: Sat, 8 Apr 2006
>>> 18:47:34 -0400 (EDT)
>>> 
>>>> Hey,
>>>> 
>>>> I have a kernel module that uses unregister_qdisc and
>>>> register_qdisc, whenever i try to insert the module I get: 
>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
>>>> unregister_qdisc /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: 
>>>> /lib/modules/2.4.32/kernel/net/sched/sch_xcp.o: unresolved symbol 
>>>> register_qdisc
>>>> 
>>>> Am i missing some sort of support in the kernel?
>>> 
>>> Make sure CONFIG_NET_SCHED is enabled and that you compiled your
>>> module against that kernel.
>>> 
>>> Where does this sch_xcp come from?  It's not in the vanilla sources.
>>> 
>>> Also, please direct networking questions to the
>>> netdev@vger.kernel.org mailing list which I have added to the CC:.
> 
> --- ~Randy
> 
> 


-- 


^ permalink raw reply

* Re: [RFH] Exploration of an alternative diff_delta() algorithm
From: Nicolas Pitre @ 2006-04-09 17:40 UTC (permalink / raw)
  To: Peter Eriksen; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604091307460.2215@localhost.localdomain>

On Sun, 9 Apr 2006, Nicolas Pitre wrote:

> On Sun, 9 Apr 2006, Peter Eriksen wrote:
> 
> > Greetings Gitlings,
> > 
> > I've been trying to implement an alternative algorithm
> > for diff_delta().  I'm getting close to something that
> > works, but now I'm stuck!
> 
> Nothing outside diff-delta.c and patch-delta.c is aware of the delta 
> data format.  So if your version is meant to be a transparent 
> replacement then it should pass all tests.  If it doesn't then it is 
> broken.
> 
> To help you play around you could try the test-delta utility (make 
> test-delta to build it).
> 
> So:
> 
> 	test-delta -d file1 file2 delta_file
> 	test-delta -p file1 delta_file file3
> 	cmp file2 file3
> 
> You should always have file3 identical to file2.

Out of curiosity I just tried your diff-delta version with test-delta 
and it produced a segmentation fault on the first attempt.

It also has lots of compilation warnings.


Nicolas

^ permalink raw reply

* Re: [RFH] Exploration of an alternative diff_delta() algorithm
From: Nicolas Pitre @ 2006-04-09 17:45 UTC (permalink / raw)
  To: Peter Eriksen; +Cc: git
In-Reply-To: <20060409173409.GB23908@erlang.gbar.dtu.dk>

On Sun, 9 Apr 2006, Peter Eriksen wrote:

> On Sun, Apr 09, 2006 at 01:14:31PM -0400, Nicolas Pitre wrote:
> ...
> > Nothing outside diff-delta.c and patch-delta.c is aware of the delta 
> > data format.  So if your version is meant to be a transparent 
> > replacement then it should pass all tests.  If it doesn't then it is 
> > broken.
> > 
> > To help you play around you could try the test-delta utility (make 
> > test-delta to build it).
> > 
> > So:
> > 
> > 	test-delta -d file1 file2 delta_file
> > 	test-delta -p file1 delta_file file3
> > 	cmp file2 file3
> 
> My tests of these kinds doesn't show any errors. 

Try this with the README file from the git source tree:

	sed s/git/GIT/g < ./README > /tmp/README.mod
	test-delta -d ./README /tmp/README.mod /tmp/README.delta
	[BOOM!]

> Though, if file2 is empty, test-delta writes: "file2: Invalid 
> argument".

We never delta against or towards empty files.


Nicolas

^ permalink raw reply

* [2.6 patch] dvb/bt8xx/bt878.c: don't export static variables
From: Adrian Bunk @ 2006-04-09 17:48 UTC (permalink / raw)
  To: v4l-dvb-maintainer; +Cc: linux-kernel

Static variables mustn't be EXPORT_SYMBOL'ed.

Signed-off-by: Adrian Bunk <bunk@stusta.de>

---

 drivers/media/dvb/bt8xx/bt878.c |    2 --
 1 file changed, 2 deletions(-)

--- linux-2.6.17-rc1-mm2-full/drivers/media/dvb/bt8xx/bt878.c.old	2006-04-09 18:43:28.000000000 +0200
+++ linux-2.6.17-rc1-mm2-full/drivers/media/dvb/bt8xx/bt878.c	2006-04-09 18:44:26.000000000 +0200
@@ -54,26 +54,24 @@
 static unsigned int bt878_verbose = 1;
 static unsigned int bt878_debug;
 
 module_param_named(verbose, bt878_verbose, int, 0444);
 MODULE_PARM_DESC(verbose,
 		 "verbose startup messages, default is 1 (yes)");
 module_param_named(debug, bt878_debug, int, 0644);
 MODULE_PARM_DESC(debug, "Turn on/off debugging, default is 0 (off).");
 
 int bt878_num;
 struct bt878 bt878[BT878_MAX];
 
-EXPORT_SYMBOL(bt878_debug);
-EXPORT_SYMBOL(bt878_verbose);
 EXPORT_SYMBOL(bt878_num);
 EXPORT_SYMBOL(bt878);
 
 #define btwrite(dat,adr)    bmtwrite((dat), (bt->bt878_mem+(adr)))
 #define btread(adr)         bmtread(bt->bt878_mem+(adr))
 
 #define btand(dat,adr)      btwrite((dat) & btread(adr), adr)
 #define btor(dat,adr)       btwrite((dat) | btread(adr), adr)
 #define btaor(dat,mask,adr) btwrite((dat) | ((mask) & btread(adr)), adr)
 
 #if defined(dprintk)
 #undef dprintk


^ permalink raw reply

* [Patch] Overrun in drivers/char/mwave/mwavedd.c
From: Eric Sesterhenn @ 2006-04-09 17:49 UTC (permalink / raw)
  To: LKML

hi,

this fixes coverity id #489.
Since the last element in the array is always ARRAY_SIZE-1
we have to check for ipcnum >= ARRAY_SIZE()

Signed-off-by: Eric Sesterhenn <snakebyte@gmx.de>

--- linux-2.6.17-rc1/drivers/char/mwave/mwavedd.c.orig	2006-04-09 19:45:54.000000000 +0200
+++ linux-2.6.17-rc1/drivers/char/mwave/mwavedd.c	2006-04-09 19:46:07.000000000 +0200
@@ -271,7 +271,7 @@ static int mwave_ioctl(struct inode *ino
 				ipcnum,
 				pDrvData->IPCs[ipcnum].usIntCount);
 	
-			if (ipcnum > ARRAY_SIZE(pDrvData->IPCs)) {
+			if (ipcnum >= ARRAY_SIZE(pDrvData->IPCs)) {
 				PRINTK_ERROR(KERN_ERR_MWAVE
 						"mwavedd::mwave_ioctl:"
 						" IOCTL_MW_REGISTER_IPC:"



^ permalink raw reply

* Re: [RFH] Exploration of an alternative diff_delta() algorithm
From: Peter Eriksen @ 2006-04-09 17:53 UTC (permalink / raw)
  To: git
In-Reply-To: <Pine.LNX.4.64.0604091333140.2215@localhost.localdomain>

On Sun, Apr 09, 2006 at 01:40:14PM -0400, Nicolas Pitre wrote:
...
> Out of curiosity I just tried your diff-delta version with test-delta 
> and it produced a segmentation fault on the first attempt.

Yes, I get that too with your README example.

> It also has lots of compilation warnings.

Hm, I don't get any warnings.  Would you mind pasting them, so I
can see what it's about?

At least now I have one segmentation fault to work on.  
Thanks.

Peter

^ permalink raw reply

* Re: [Xenomai-core] Proposal to use buildbot for Xenomai
From: Philippe Gerum @ 2006-04-09 17:55 UTC (permalink / raw)
  To: niklaus.giger; +Cc: xenomai
In-Reply-To: <200604072337.48181.niklaus.giger@domain.hid>

Niklaus Giger wrote:
> Hi everybody
> 
> If you point your browser at http://ngiger.dyndns.org/buildbot/ (with ending 
> slash please), you will find a first prototype of the continuos integration 
> tool buildbot (http://buildbot.sourceforge.net/)
> 

Great stuff.

> It proves that it possible to automatically retrieve each revison of the 
> Xenomai and compile it for (at the moment) two targets, a stock PPC and a 
> custom PPC405 board (cross-compiling).
> 
> At the moment it already is useful for me, but I would like to ask your 
> opinion about its usefulness. Would this be useful for you too? Do you have a 
> special target to propose (other architectures, other target like skins, all 
> xenomai components as modules/built-ins, mvm simulator)?
> 

With the growing number of supported archs, not to speak of the two 
major kernel versions supported (2.4/2.6) for some of them, a tool 
providing continuous integration is clearly extremely useful, since it's 
now virtually impossible for all developers to systematically check 
their work against all possible arch/config combinations.

Additionally, setting up a build slave for any particular arch of 
interest is something users wanting to contribute back could do rather 
easily, and specifically companies who happen to be happy Xenomai users.

AFAIC, the upside would be to be able to produce performance numbers 
after the builds by running regression tests, so that we could evaluate 
the impact of core changes almost immediately.

-- 

Philippe.


^ permalink raw reply

* Re: net interface renaming issue (+fix?)
From: Sergey Vlasov @ 2006-04-09 17:56 UTC (permalink / raw)
  To: Thomas de Grenier de Latour; +Cc: Linux-hotplug-devel, netdev
In-Reply-To: <20060409192140.73644723@eusebe>

[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]

On Sun, 9 Apr 2006 19:21:40 +0200 Thomas de Grenier de Latour wrote:

> Hi,
> 
> I'm running Gentoo Linux, a 2.6.16-ck kernel, and udev-0.89-r2, and 
> have had hard time with network interfaces renaming through udev 
> rules. The first thing i've tried were rules like this one:
> 
> SUBSYSTEM=="net", KERNEL=="eth*", SYSFS{address}=="00:0d:60:12:75:0a", NAME="lan"
> 
> Plus this one from the standard early rules:
> 
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address"
> 
> It doesn't work when i "modprobe e1000" (my ethernet driver):
> ...
> udevd[21612]: udev_event_run: seq 956 forked, pid [21816], 'add' 'net', 0 seconds old
> udevd-event[21816]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21816]: udev_rules_get_name: no node name set, will use kernel name 'eth0'
> ...
> But if i later do a "echo add > /sys/class/net/eth0/uevent", then 
> interface is properly renamed. It also works fine if i start with
> the module initialy not loaded, and then trigger the uevent on the
> corresponding pci device (will load the module, etc.)
> 
> 
> Then i've tried replacing the address match by DRIVER=="e1000", with
> no more success.  But i've  noticed something interesting in debug 
> output, when the rule matcher walks up in parent devices to check 
> the driver:
> % grep -i driver /var/tmp/udev-net-debug.log
> ...
> udevd-event[18411]: match_key: key DRIVER value='e1000'
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
> udevd-event[18411]: match_key: DRIVER is false
> udevd-event[18411]: sysfs_device_get: add to cache 'devpath=/devices/pci0000:00/0000:00:1e.0/0000:02:01.0', subsystem='pci', driver=''
> udevd-event[18411]: match_key: key DRIVER value='e1000' 
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> '' 
> udevd-event[18411]: match_key: DRIVER is false
> ...
> This is weird, because if i latter look in /sys, the "driver" links
> are here. Which made me think it was a race, so i've added this rule:
> 
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="device/driver"
> 
> And it fixed the problem:
> ...
> udevd[21612]: udev_event_run: seq 950 forked, pid [21790], 'add' 'net', 0 seconds old
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21790]: wait_for_sysfs: wait for '/sys/class/net/eth0/device/driver' for 20 mseconds
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/device/driver' appeared after 1 loops
> udevd-event[21790]: udev_rules_get_name: rule applied, 'eth0' becomes 'lan'
> udevd-event[21790]: rename_net_if: changing net interface name from 'eth0' to 'lan'
> udevd-event[21790]: udev_add_device: renamed netif to 'lan'
> ...
> 
> It also fixes the problem with using a SYSFS{address} match btw.
> With no such wait, i can see in debug that "address" is found in sysfs,
> but with no value:
> ...
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21977]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> ...
> Whereas with the wait-for-driver trick, i can see it read with a 
> useful value:
> ...
> udevd-event[21954]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21954]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: cache '/sys/class/net/eth0/address' with value '00:0d:60:12:75:0a'
> ...
> 
> So i wonder, maybe such a rule should be added to the standard early
> ones? It should maybe use more checks though, to be sure there is
> actually a driver to wait. Something like ENV{PHYSDEVPATH}=="?*" 
> and/or ENV{PHYSDEVDRIVER}=="?*".
> 
> Btw, using ENV{PHYSDEVDRIVER}=="e1000" in my renaming rule was working
> fine, with no trick (this variables are correctly set, like 'udevmonitor 
> --env' shows).
> 
> 
> So, what do you think, does such a rule makes sense?
> Or is "address" being added to sysfs with no useful value yet the real
> issue, and my rule only an ugly workround?

(quoting the whole message for netdev)

Apparently there is a race there.  The "add" uevent for /class/net/eth0
is emitted by class_device_register(), which is called by
netdev_register_sysfs().  Class device attributes (like "address") are
also added by class_device_register() (really class_device_add(), which
is invoked from there), but this is done before generating the uevent,
so at the first glance there is no race here (and waiting for "address"
is unnecessary).  However, show_address() does not output anything
unless dev->reg_state == NETREG_REGISTERED - and this state is set by
netdev_run_todo() only after netdev_register_sysfs() returns, so in the
meantime (while netdev_register_sysfs() is busy adding the "statistics"
attribute group) some process may see an empty "address" attribute.

Waiting for "device/driver" ensures that udevd continues to process the
uevent only after the probe function completes, which ensures completion
of the registration (netdev_run_todo() is invoked by rtnl_unlock() at
the end of register_netdev() and processes all pending requests).

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply

* Re: net interface renaming issue (+fix?)
From: Sergey Vlasov @ 2006-04-09 17:56 UTC (permalink / raw)
  To: Thomas de Grenier de Latour; +Cc: Linux-hotplug-devel, netdev
In-Reply-To: <20060409192140.73644723@eusebe>

[-- Attachment #1: Type: text/plain, Size: 5493 bytes --]

On Sun, 9 Apr 2006 19:21:40 +0200 Thomas de Grenier de Latour wrote:

> Hi,
> 
> I'm running Gentoo Linux, a 2.6.16-ck kernel, and udev-0.89-r2, and 
> have had hard time with network interfaces renaming through udev 
> rules. The first thing i've tried were rules like this one:
> 
> SUBSYSTEM=="net", KERNEL=="eth*", SYSFS{address}=="00:0d:60:12:75:0a", NAME="lan"
> 
> Plus this one from the standard early rules:
> 
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="address"
> 
> It doesn't work when i "modprobe e1000" (my ethernet driver):
> ...
> udevd[21612]: udev_event_run: seq 956 forked, pid [21816], 'add' 'net', 0 seconds old
> udevd-event[21816]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21816]: udev_rules_get_name: no node name set, will use kernel name 'eth0'
> ...
> But if i later do a "echo add > /sys/class/net/eth0/uevent", then 
> interface is properly renamed. It also works fine if i start with
> the module initialy not loaded, and then trigger the uevent on the
> corresponding pci device (will load the module, etc.)
> 
> 
> Then i've tried replacing the address match by DRIVER=="e1000", with
> no more success.  But i've  noticed something interesting in debug 
> output, when the rule matcher walks up in parent devices to check 
> the driver:
> % grep -i driver /var/tmp/udev-net-debug.log
> ...
> udevd-event[18411]: match_key: key DRIVER value='e1000'
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> ''
> udevd-event[18411]: match_key: DRIVER is false
> udevd-event[18411]: sysfs_device_get: add to cache 'devpath=/devices/pci0000:00/0000:00:1e.0/0000:02:01.0', subsystem='pci', driver=''
> udevd-event[18411]: match_key: key DRIVER value='e1000' 
> udevd-event[18411]: match_key: match DRIVER 'e1000' <-> '' 
> udevd-event[18411]: match_key: DRIVER is false
> ...
> This is weird, because if i latter look in /sys, the "driver" links
> are here. Which made me think it was a race, so i've added this rule:
> 
> ACTION=="add", SUBSYSTEM=="net", WAIT_FOR_SYSFS="device/driver"
> 
> And it fixed the problem:
> ...
> udevd[21612]: udev_event_run: seq 950 forked, pid [21790], 'add' 'net', 0 seconds old
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/address' appeared after 0 loops
> udevd-event[21790]: wait_for_sysfs: wait for '/sys/class/net/eth0/device/driver' for 20 mseconds
> udevd-event[21790]: wait_for_sysfs: file '/sys/class/net/eth0/device/driver' appeared after 1 loops
> udevd-event[21790]: udev_rules_get_name: rule applied, 'eth0' becomes 'lan'
> udevd-event[21790]: rename_net_if: changing net interface name from 'eth0' to 'lan'
> udevd-event[21790]: udev_add_device: renamed netif to 'lan'
> ...
> 
> It also fixes the problem with using a SYSFS{address} match btw.
> With no such wait, i can see in debug that "address" is found in sysfs,
> but with no value:
> ...
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21977]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21977]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> ...
> Whereas with the wait-for-driver trick, i can see it read with a 
> useful value:
> ...
> udevd-event[21954]: sysfs_attr_get_value: open '/class/net/eth0'/'address'
> udevd-event[21954]: sysfs_attr_get_value: new uncached attribute '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: add to cache '/sys/class/net/eth0/address'
> udevd-event[21954]: sysfs_attr_get_value: cache '/sys/class/net/eth0/address' with value '00:0d:60:12:75:0a'
> ...
> 
> So i wonder, maybe such a rule should be added to the standard early
> ones? It should maybe use more checks though, to be sure there is
> actually a driver to wait. Something like ENV{PHYSDEVPATH}=="?*" 
> and/or ENV{PHYSDEVDRIVER}=="?*".
> 
> Btw, using ENV{PHYSDEVDRIVER}=="e1000" in my renaming rule was working
> fine, with no trick (this variables are correctly set, like 'udevmonitor 
> --env' shows).
> 
> 
> So, what do you think, does such a rule makes sense?
> Or is "address" being added to sysfs with no useful value yet the real
> issue, and my rule only an ugly workround?

(quoting the whole message for netdev)

Apparently there is a race there.  The "add" uevent for /class/net/eth0
is emitted by class_device_register(), which is called by
netdev_register_sysfs().  Class device attributes (like "address") are
also added by class_device_register() (really class_device_add(), which
is invoked from there), but this is done before generating the uevent,
so at the first glance there is no race here (and waiting for "address"
is unnecessary).  However, show_address() does not output anything
unless dev->reg_state == NETREG_REGISTERED - and this state is set by
netdev_run_todo() only after netdev_register_sysfs() returns, so in the
meantime (while netdev_register_sysfs() is busy adding the "statistics"
attribute group) some process may see an empty "address" attribute.

Waiting for "device/driver" ensures that udevd continues to process the
uevent only after the probe function completes, which ensures completion
of the registration (netdev_run_todo() is invoked by rtnl_unlock() at
the end of register_netdev() and processes all pending requests).

[-- Attachment #2: Type: application/pgp-signature, Size: 190 bytes --]

^ permalink raw reply


This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.