Re: New SCM and commit list
Linus Torvalds wrote: On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote: If yes, then I would appreciate if you could either keep the same list, or if you want to change the list name, keep the subscriber list so those of us who actually archive it don't miss anything ;) I didn't even set up the list. I think it's Bottomley. I'm cc'ing him just so that he sees the message, but I don't actually expect him to do anything about it. I'm not even ready to start _testing_ real merges yet. When you think kernel.org and BitKeeper, think either me or David Woodhouse. :) DaveM / Matti(?) manage the lists ([EMAIL PROTECTED]), but largely just create them on request from others, and make sure they continue to work. But I hope that I can get non-conflicting merges done fairly soon, and maybe I can con James or Jeff or somebody to try out GIT then... I don't mind being a guinea pig as long as someone else does the hard work of finding a new way to merge :) Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.12-rc1-mm4] fork_connector: add a fork connector
I based my listen program on the fclisten.c posted by Kaigai Kohei
with my own modification. Unfortunately i lost my test machine in the
lab. I will recreate the listen program Monday. The original listener
did not validate sequence number. It also prints length of data and
sequence number of every message it receives. My listener prints
only out-of-sequence error messages.
The fork generator fork-test.c was yours? I called it fork-test
and let it run continuously in while-loop:
# while 1
# ./fork-test 1000
# sleep 1
# end
I let it do 10,000,000 times of fork continuously while the system
is running AIM7 and/or ubench.
The original fclisten.c and fork-test.c are attached for your reference.
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 20:31:20 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
With the patch you provide to me, i did not see the bugcheck
at cn_queue_wrapper() at the console.
Unmatched sequence number messages still happened. We expect
to lose packets under system stressed situation, but i still
observed duplicate messages, which concerned me.
What tool and what version do you use
as message generator and receiver?
Thanks,
- jay
Evgeniy Polyakov
Only failure makes us experts. -- Theo de Raadt
#include
#include
#include
#include
#include
#include
#include
void usage(){
puts("usage: fclisten ");
puts(" Default -> listening fork-connector");
puts(" on -> fork-connector Enable");
puts(" off -> fork-connector Disable");
exit(0);
}
#define MODE_LISTEN (1)
#define MODE_ENABLE (2)
#define MODE_DISABLE (3)
struct cb_id
{
__u32 idx;
__u32 val;
};
struct cn_msg
{
struct cb_idid;
__u32 seq;
__u32 ack;
__u32 len;/* Length of the following data */
__u8data[0];
};
int main(int argc, char *argv[]){
char buf[4096];
int mode, sockfd, len;
struct sockaddr_nl ad;
struct nlmsghdr *hdr = (struct nlmsghdr *)buf;
struct cn_msg *msg = (struct cn_msg *)(buf+sizeof(struct nlmsghdr));
switch(argc){
case 1:
mode = MODE_LISTEN;
break;
case 2:
if (strcasecmp("on",argv[1])==0) {
mode = MODE_ENABLE;
}else if (strcasecmp("off",argv[1])==0){
mode = MODE_DISABLE;
}else{
usage();
}
break;
default:
usage();
break;
}
if( (sockfd=socket(PF_NETLINK, SOCK_RAW, NETLINK_NFLOG)) < 0 ){
fprintf(stderr, "Fault on socket().\n");
return( 1 );
}
ad.nl_family = AF_NETLINK;
ad.nl_pad = 0;
ad.nl_pid = getpid();
ad.nl_groups = CN_IDX_FORK;
if( bind(sockfd, (struct sockaddr *), sizeof(ad)) ){
fprintf(stderr, "Fault on bind to netlink.\n");
return( 2 );
}
if (mode==MODE_LISTEN) {
while(-1){
len = recvfrom(sockfd, buf, 4096, 0, NULL, NULL);
printf("%d-byte recv Seq=%d\n", len, hdr->nlmsg_seq);
}
}else{
ad.nl_family = AF_NETLINK;
ad.nl_pad = 0;
ad.nl_pid = 0;
ad.nl_groups = 1;
hdr->nlmsg_len = sizeof(struct nlmsghdr) + sizeof(struct cn_msg) +
sizeof(int);
hdr->nlmsg_type = 0;
hdr->nlmsg_flags = 0;
hdr->nlmsg_seq = 0;
hdr->nlmsg_pid = getpid();
msg->id.idx = 0xfeed;
msg->id.val = 0xbeef;
msg->seq = msg->ack = 0;
msg->len = sizeof(int);
if (mode==MODE_ENABLE){
(*(int *)(msg->data)) = 1;
} else {
(*(int *)(msg->data)) = 0;
}
sendto(sockfd, buf, sizeof(struct nlmsghdr)+sizeof(struct
cn_msg)+sizeof(int),
0, (struct sockaddr *), sizeof(ad));
}
}
#include
#include
int main(int argc, char *argv[])
{
int pid;
int i = 0, max = 10;
struct timeval tv0, tv1;
struct timezone tz;
long diff;
if (argc >= 2)
max = atoi(argv[1]);
signal(SIGCHLD, SIG_IGN);
gettimeofday(, );
while (i++ < max) {
pid = fork();
if (pid == 0) {
sleep(1);
exit (0);
}
}
gettimeofday(, );
diff = (tv1.tv_sec - tv0.tv_sec)*100 + (tv1.tv_usec - tv0.tv_usec);
printf("Average per process fork+exit time is %ld usecs [diff=%lu,
max=%d].\n", diff/max, diff, max);
return 0;
}
Re: [Fwd: Re: connector is missing in 2.6.12-rc2-mm1]
On Sun, Apr 10, 2005 at 09:27:27PM +0200, Thomas Graf ([EMAIL PROTECTED]) wrote:
> * jamal <[EMAIL PROTECTED]> 2005-04-10 10:39
> > Please crosspost on netdev - you should know that by now;->
> >
> > I actually disagreee with Herbert on this. Theres definetely good
> > need to have a more usable messaging system that rides on top of
> > netlink. It is not that netlink cant be extended (I actually think thats
> > a separate topic)
>
> I find it quite easy already but I guess a few macros would improve
> it even more. The routing attribute macros could be made generic to
> so can benefit from the advanages of TLVs.
>
> Evgeniy, Sorry for not having time earlier to give your patch a
> review. I'm not yet through completely and won't comment on the
> overall architecture until I have understood it all.
>
> diff -Nru /tmp/empty/cn_queue.c linux-2.6/drivers/connector/cn_queue.c
> --- /tmp/empty/cn_queue.c 1970-01-01 03:00:00.0 +0300
> +++ linux-2.6/drivers/connector/cn_queue.c 2004-09-24 00:01:00.0
> +int cn_queue_add_callback(struct cn_queue_dev *dev, struct cn_callback *cb)
> +{
> + struct cn_callback_entry *cbq, *n, *__cbq;
> + int found = 0;
> +
> + cbq = cn_queue_alloc_callback_entry(cb);
> + if (!cbq)
> + return -ENOMEM;
> +
> + atomic_inc(>refcnt);
> + cbq->pdev = dev;
> +
> + spin_lock(>queue_lock);
> + list_for_each_entry_safe(__cbq, n, >queue_list, callback_entry) {
>
> Why _safe? There is no way a entry can be removed here.
No particular reason - it easier to copy-paste it from other line :)
> + if (cn_cb_equal(&__cbq->cb->id, >id)) {
> + found = 1;
> + break;
> + }
> + }
> diff -Nru /tmp/empty/connector.c linux-2.6/drivers/connector/connector.c
> --- /tmp/empty/connector.c 1970-01-01 03:00:00.0 +0300
> +++ linux-2.6/drivers/connector/connector.c 2004-09-24 00:01:00.0
> +void cn_netlink_send(struct cn_msg *msg, u32 __groups)
> +{
> + struct cn_callback_entry *n, *__cbq;
> + unsigned int size;
> + struct sk_buff *skb;
> + struct nlmsghdr *nlh;
> + struct cn_msg *data;
> + struct cn_dev *dev =
> + u32 groups = 0;
> + int found = 0;
> +
> + if (!__groups)
> + {
> + spin_lock(>cbdev->queue_lock);
> + list_for_each_entry_safe(__cbq, n, >cbdev->queue_list,
> callback_entry) {
>
> Same here
>
> + if (cn_cb_equal(&__cbq->cb->id, >id)) {
> + found = 1;
> + groups = __cbq->group;
> + }
> + }
> + spin_unlock(>cbdev->queue_lock);
> +
> + if (!found) {
> + printk(KERN_ERR "Failed to find multicast netlink
> group for callback[0x%x.0x%x]. seq=%u\n",
> + msg->id.idx, msg->id.val, msg->seq);
> + return;
> + }
> + }
> + else
> + groups = __groups;
> +
> + size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> +
> + skb = alloc_skb(size, GFP_ATOMIC);
> + if (!skb) {
> + printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> size);
> + return;
> + }
> +
> + nlh = NLMSG_PUT(skb, 0, msg->seq, NLMSG_DONE, size - sizeof(*nlh));
>
> This is not correct, what happens is:
> size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> --> align(hdr)+align(data)
> size - sizeof(*nlh)
> --> (align(hdr)-hdr)+align(data)
> NLMSG_PUT pads again to get to the end of the data block (NLMSG_LENGTH)
> --> align(hdr)+(align(hdr)-hdr)+align(data)
>
> At the moment align(hdr) == hdr since nlmsghdr is already aligned
> but this might change and your code will break.
As far as I remember, header is always supposed to be aligned properly
"by design", so it even could be nonaligned here.
--
Evgeniy Polyakov ( s0mbre )
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
> Btw, does anybody have strong opinions on the license? I didn't put in a > COPYING file exactly because I was torn between GPLv2 and OSL2.1. I think GPLv2 would create the least amount of objection in the community, so I'd probably want to go with that. Nur Hussein - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Kprobes: Multiple probes feature at given address
On Fri, Apr 08, 2005 at 08:17:46PM +0530, Prasanna S Panchamukhi wrote:
[..]
> Assumption : If a user has already inserted a probe using old
> register_kprobe()
> routine, and later wants to insert another probe at the same address using
> register_multiprobe() routine, then register_multiprobe() will return EEXIST.
> This can be avoided by renaming the interface routines.
>
I am not sure if systemTap can tolerate this resitriction.
(Pls look for more comments below)
> Signed-off-by: Prasanna S Panchamukhi <[EMAIL PROTECTED]>
>
>
> ---
>
> linux-2.6.12-rc2-prasanna/include/linux/kprobes.h | 30
> linux-2.6.12-rc2-prasanna/kernel/kprobes.c| 164
> ++
> 2 files changed, 194 insertions(+)
>
> diff -puN kernel/kprobes.c~kprobes-layered-multiple-handlers kernel/kprobes.c
> --- linux-2.6.12-rc2/kernel/kprobes.c~kprobes-layered-multiple-handlers
> 2005-04-08 16:39:05.0 +0530
> +++ linux-2.6.12-rc2-prasanna/kernel/kprobes.c2005-04-08
> 19:23:11.0 +0530
> @@ -27,6 +27,9 @@
> * interface to access function arguments.
> * 2004-Sep Prasanna S Panchamukhi <[EMAIL PROTECTED]> Changed Kprobes
> * exceptions notifier to be first on the priority list.
> + * 2005-AprilPrasanna S Panchamukhi <[EMAIL PROTECTED]> Added
> multiple
> + * handlers feature as an addon interface over existing kprobes
> + * interface.
> */
> #include
> #include
> @@ -44,6 +47,7 @@ static struct hlist_head kprobe_table[KP
>
> unsigned int kprobe_cpu = NR_CPUS;
> static DEFINE_SPINLOCK(kprobe_lock);
> +static DEFINE_RWLOCK(multiprobe_lock);
>
> /* Locks kprobe: irqs must be disabled */
> void lock_kprobes(void)
> @@ -116,6 +120,164 @@ void unregister_kprobe(struct kprobe *p)
> spin_unlock_irqrestore(_lock, flags);
> }
>
> +
> +/* common kprobes pre handler that gets control when the registered probe
> + * gets fired. This routines is wrapper over the inserted multiple handlers
> + * at a given address and calls individual handlers.
> + */
> +int comm_pre_handler(struct kprobe *p, struct pt_regs *regs)
> +{
> + struct active_probe *ap;
> + struct hlist_node *node;
> + struct hlist_head *head;
> +
> + read_lock(_lock);
> + ap = container_of(p, struct active_probe, comm_probe);
> + head = >head;
> + hlist_for_each(node, head) {
> + struct multiprobe *mp =
> + hlist_entry(node, struct multiprobe, hlist);
> + if (mp->kp.pre_handler)
> + mp->kp.pre_handler(>kp, regs);
> + }
> + read_unlock(_lock);
> + return 0;
> +}
> +
> +/* common kprobes post handler that gets control when the registered probe
> + * gets fired. This routines is wrapper over the insereted multiple handlers
> + * at a given address and calls individual handlers.
> + */
> +void comm_post_handler(struct kprobe *p, struct pt_regs *regs,
> + unsigned long flags)
> +{
> + struct active_probe *ap;
> + struct hlist_node *node;
> + struct hlist_head *head;
> +
> + read_lock(_lock);
> + ap = container_of(p, struct active_probe, comm_probe);
> + head = >head;
> + hlist_for_each(node, head) {
> + struct multiprobe *mp =
> + hlist_entry(node, struct multiprobe, hlist);
> + if (mp->kp.post_handler)
> + mp->kp.post_handler(>kp, regs, flags);
> + }
> + read_unlock(_lock);
> + return;
> +}
> +
> +/* common kprobes fault handler that gets control when the registered probe
> + * gets fired. This routines is wrapper over the inserted multiple handlers
> + * at a given address and calls individual handlers.
> + */
> +int comm_fault_handler(struct kprobe *p, struct pt_regs *regs, int trapnr)
> +{
> + struct active_probe *ap;
> + struct hlist_node *node;
> + struct hlist_head *head;
> +
> + read_lock(_lock);
> + ap = container_of(p, struct active_probe, comm_probe);
> + head = >head;
> + hlist_for_each(node, head) {
> + struct multiprobe *mp =
> + hlist_entry(node, struct multiprobe, hlist);
> + if (mp->kp.fault_handler)
> + mp->kp.fault_handler(>kp, regs, trapnr);
> + }
> + read_unlock(_lock);
> + return 1;
> +}
> +
> +/* New interface to support multiple handlers feature without even changing a
> + * single line of exiting kprobes interface and data structures. This
> routines
> + * accepts pointer to multiprobe structure, user has to allocate
> + * multiprobe structure and pass the pointer. This routine basically checks
> + * and registers the kprobes common handlers if the user is inserting a probe
> + * for the first time and saves the references to individual kprobes
> handlers.
> + * On subsequent call to this routine to insert multiple handler at the same
> + *
Re: 2.6.12-rc2-mm1
On Mon, Apr 11, 2005 at 01:00:53AM +0200, Pavel Machek wrote: > > No, XFS is my root filesystem. :( (Now that I think about it, would > > modularizing XFS and using an initrd be OK?) > > Yes, loading xfs from initrd should help. [At least it did during > suse9.3 testing.] Once I modularized xfs and switched to using an initrd, the problem disappeared. I just noticed a difference between the kernel messages with XFS built-in and with it modularized. I'm having trouble putting my finger on it; it seems like the screen gets cleared at some point during resume, and with XFS built-in, it starts reading the data from swap *after* the screen gets cleared. In contrast, if the enable-initrd patch is removed or XFS is modularized, it reads in from swap *before* the screen gets cleared. Or something like that. I'll see if I can get anything more detailed & useful with a serial console... Failing that, I'll try a camcorder or digital camera and transcribe from that. -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
$B"!$*;n$72<$5$$"!(B
$BB>$N%5%$%H$H$N0c$$$rBN83$7$F2<$5$$!*(B $B(Bhttp://www.getluck.net/ $B4JC1A`:n$G4JC1EPO?!*(B $B!!??7u$J=P2q$$$O$3$3$+$i(B $B!!(B $B=i$a$F$NJ}$OL5NA%(%s%H%j!<$+$i$I$&$>(B $B(Bhttp://www.getluck.net/ $B"(GIhttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: formatting CD-RW locks the system
Stas Sergeev wrote: OK, I'll try cdrecord too, thanks. But there might be a bug in the kernel if the system literally dies with the cdrwtool. If the format is being done as a single blocking ATAPI command, then that will definitely block any other accesses on the same IDE channel, at least - that's just the way IDE works. That shouldn' have an effect on other IDE channels though.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH scsi-misc-2.6 02/04] scsi: make scsi_queue_insert() use blk_requeue_request()
02_scsi_REQ_SPECIAL_semantic_scsi_queue_insert.patch
scsi_queue_insert() used to use blk_insert_request() for
requeueing requests. This behavior depends on the unobvious
behavior of blk_insert_request() setting REQ_SPECIAL and
REQ_SOFTBARRIER when requeueing. This patch makes
scsi_queue_insert() use blk_requeue_request() and explicitly
set REQ_SOFTBARRIER. As REQ_SPECIAL now means special
requests, the flag is not set on requeue.
Note that scsi_queue_insert() now calls scsi_run_queue()
itself, and the prototype of the function is added right above
scsi_queue_insert(). This is temporary, as later requeue path
consolidation patchset removes scsi_queue_insert(). By adding
temporary prototype, we can do away with unnecessary changes.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_lib.c | 24 ++--
1 files changed, 14 insertions(+), 10 deletions(-)
Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c 2005-04-11
12:27:07.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c 2005-04-11 12:27:07.0
+0900
@@ -96,6 +96,8 @@ int scsi_insert_special_req(struct scsi_
return 0;
}
+static void scsi_run_queue(struct request_queue *q);
+
/*
* Function:scsi_queue_insert()
*
@@ -119,6 +121,8 @@ int scsi_queue_insert(struct scsi_cmnd *
{
struct Scsi_Host *host = cmd->device->host;
struct scsi_device *device = cmd->device;
+ struct request_queue *q = device->request_queue;
+ unsigned long flags;
SCSI_LOG_MLQUEUE(1,
printk("Inserting command %p into mlqueue\n", cmd));
@@ -154,17 +158,17 @@ int scsi_queue_insert(struct scsi_cmnd *
scsi_device_unbusy(device);
/*
-* Insert this command at the head of the queue for it's device.
-* It will go before all other commands that are already in the queue.
-*
-* NOTE: there is magic here about the way the queue is plugged if
-* we have no outstanding commands.
-*
-* Although this *doesn't* plug the queue, it does call the request
-* function. The SCSI request function detects the blocked condition
-* and plugs the queue appropriately.
+* Requeue the command. Turn on REQ_SOFTBARRIER to prevent
+* other requests from passing this request.
*/
- blk_insert_request(device->request_queue, cmd->request, 1, cmd, 1);
+ cmd->request->flags |= REQ_SOFTBARRIER;
+
+ spin_lock_irqsave(q->queue_lock, flags);
+ blk_requeue_request(q, cmd->request);
+ spin_unlock_irqrestore(q->queue_lock, flags);
+
+ scsi_run_queue(q);
+
return 0;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH scsi-misc-2.6 03/04] scsi: make scsi_requeue_request() use blk_requeue_request()
03_scsi_REQ_SPECIAL_semantic_scsi_requeue_command.patch
scsi_requeue_request() used to use blk_insert_request() for
requeueing requests. This behavior depends on the unobvious
behavior of blk_insert_request() setting REQ_SPECIAL and
REQ_SOFTBARRIER when requeueing. This patch makes
scsi_requeue_request() use blk_requeue_request() and
explicitly set REQ_SOFTBARRIER. As REQ_SPECIAL now means
special requests, the flag is not set on requeue.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_lib.c |8 +++-
1 files changed, 7 insertions(+), 1 deletion(-)
Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c 2005-04-11
12:27:07.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c 2005-04-11 12:27:08.0
+0900
@@ -483,8 +483,14 @@ static void scsi_run_queue(struct reques
*/
static void scsi_requeue_command(struct request_queue *q, struct scsi_cmnd
*cmd)
{
+ unsigned long flags;
+
cmd->request->flags &= ~REQ_DONTPREP;
- blk_insert_request(q, cmd->request, 1, cmd, 1);
+ cmd->request->flags |= REQ_SOFTBARRIER;
+
+ spin_lock_irqsave(q->queue_lock, flags);
+ blk_requeue_request(q, cmd->request);
+ spin_unlock_irqrestore(q->queue_lock, flags);
scsi_run_queue(q);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH scsi-misc-2.6 04/04] scsi: remove requeue feature from blk_insert_request()
04_scsi_blk_insert_request_no_requeue.patch
blk_insert_request() has a unobivous feature of requeuing a
request setting REQ_SPECIAL|REQ_SOFTBARRIER. SCSI midlayer
was the only user and as previous patches removed the usage,
remove the feature from blk_insert_request(). Only special
requests should be queued with blk_insert_request(). All
requeueing should go through blk_requeue_request().
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
drivers/block/ll_rw_blk.c | 20 ++--
drivers/block/paride/pd.c |2 +-
drivers/block/sx8.c |4 ++--
drivers/scsi/scsi_lib.c |2 +-
include/linux/blkdev.h|2 +-
5 files changed, 11 insertions(+), 19 deletions(-)
Index: scsi-reqfn-export/drivers/block/ll_rw_blk.c
===
--- scsi-reqfn-export.orig/drivers/block/ll_rw_blk.c2005-04-11
12:25:15.0 +0900
+++ scsi-reqfn-export/drivers/block/ll_rw_blk.c 2005-04-11 12:27:08.0
+0900
@@ -2028,7 +2028,6 @@ EXPORT_SYMBOL(blk_requeue_request);
* @rq:request to be inserted
* @at_head: insert request at head or tail of queue
* @data: private data
- * @reinsert: true if request it a reinsertion of previously processed one
*
* Description:
*Many block devices need to execute commands asynchronously, so they don't
@@ -2043,8 +2042,9 @@ EXPORT_SYMBOL(blk_requeue_request);
*host that is unable to accept a particular command.
*/
void blk_insert_request(request_queue_t *q, struct request *rq,
- int at_head, void *data, int reinsert)
+ int at_head, void *data)
{
+ int where = at_head ? ELEVATOR_INSERT_FRONT : ELEVATOR_INSERT_BACK;
unsigned long flags;
/*
@@ -2061,20 +2061,12 @@ void blk_insert_request(request_queue_t
/*
* If command is tagged, release the tag
*/
- if (reinsert)
- blk_requeue_request(q, rq);
- else {
- int where = ELEVATOR_INSERT_BACK;
+ if (blk_rq_tagged(rq))
+ blk_queue_end_tag(q, rq);
- if (at_head)
- where = ELEVATOR_INSERT_FRONT;
+ drive_stat_acct(rq, rq->nr_sectors, 1);
+ __elv_add_request(q, rq, where, 0);
- if (blk_rq_tagged(rq))
- blk_queue_end_tag(q, rq);
-
- drive_stat_acct(rq, rq->nr_sectors, 1);
- __elv_add_request(q, rq, where, 0);
- }
if (blk_queue_plugged(q))
__generic_unplug_device(q);
else
Index: scsi-reqfn-export/drivers/block/paride/pd.c
===
--- scsi-reqfn-export.orig/drivers/block/paride/pd.c2005-04-11
12:25:15.0 +0900
+++ scsi-reqfn-export/drivers/block/paride/pd.c 2005-04-11 12:27:08.0
+0900
@@ -723,7 +723,7 @@ static int pd_special_command(struct pd_
rq.ref_count = 1;
rq.waiting =
rq.end_io = blk_end_sync_rq;
- blk_insert_request(disk->gd->queue, , 0, func, 0);
+ blk_insert_request(disk->gd->queue, , 0, func);
wait_for_completion();
rq.waiting = NULL;
if (rq.errors)
Index: scsi-reqfn-export/drivers/block/sx8.c
===
--- scsi-reqfn-export.orig/drivers/block/sx8.c 2005-04-11 12:25:15.0
+0900
+++ scsi-reqfn-export/drivers/block/sx8.c 2005-04-11 12:27:08.0
+0900
@@ -614,7 +614,7 @@ static int carm_array_info (struct carm_
spin_unlock_irq(>lock);
DPRINTK("blk_insert_request, tag == %u\n", idx);
- blk_insert_request(host->oob_q, crq->rq, 1, crq, 0);
+ blk_insert_request(host->oob_q, crq->rq, 1, crq);
return 0;
@@ -653,7 +653,7 @@ static int carm_send_special (struct car
crq->msg_bucket = (u32) rc;
DPRINTK("blk_insert_request, tag == %u\n", idx);
- blk_insert_request(host->oob_q, crq->rq, 1, crq, 0);
+ blk_insert_request(host->oob_q, crq->rq, 1, crq);
return 0;
}
Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c 2005-04-11
12:27:08.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c 2005-04-11 12:27:08.0
+0900
@@ -92,7 +92,7 @@ int scsi_insert_special_req(struct scsi_
*/
sreq->sr_request->flags &= ~REQ_DONTPREP;
blk_insert_request(sreq->sr_device->request_queue, sreq->sr_request,
- at_head, sreq, 0);
+ at_head, sreq);
return 0;
}
Index: scsi-reqfn-export/include/linux/blkdev.h
===
--- scsi-reqfn-export.orig/include/linux/blkdev.h 2005-04-11
12:25:15.0 +0900
+++
Re: [PATCH scsi-misc-2.6 01/04] scsi: replace REQ_SPECIAL with REQ_SOFTBARRIER in scsi_init_io()
01_scsi_REQ_SPECIAL_semantic_scsi_init_io.patch
scsi_init_io() used to set REQ_SPECIAL when it fails sg
allocation before requeueing the request by returning
BLKPREP_DEFER. REQ_SPECIAL is being updated to mean special
requests and we need to set REQ_SOFTBARRIER for half-prepp'ed
requests. So, replace REQ_SPECIAL with REQ_SOFTBARRIER.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
scsi_lib.c |2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c 2005-04-11
12:27:07.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c 2005-04-11 12:27:07.0
+0900
@@ -936,7 +936,7 @@ static int scsi_init_io(struct scsi_cmnd
*/
sgpnt = scsi_alloc_sgtable(cmd, GFP_ATOMIC);
if (unlikely(!sgpnt)) {
- req->flags |= REQ_SPECIAL;
+ req->flags |= REQ_SOFTBARRIER;
return BLKPREP_DEFER;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 scsi-misc-2.6 00/04] scsi: clear REQ_SPECIAL/REQ_SOFTBARRIER usages
Hello, James. This patchset is split up of REQ_SPECIAL update patches (#01-02) of previous patchset posted on March 31. Explicit setting of REQ_SOFTBARRIER in scsi_init_io() is added. This patchset makes REQ_SPECIAL mean that the request is a special request and REQ_SOFTBARRIER setting explicit. Previously, REQ_SPECIAL duplicately meant the request has been prepp'ed by SCSI midlayer and/or the request is a special request. This left special requests handling in the midlayer subtley inconsistent. Also, the setting of REQ_SPECIAL was done by the block layer using blk_insert_request() mostly but sometimes by the SCSI midlayer (when returning BLK_PREP_DEFER from scsi_prep_fn()). blk_insert_request() was used for two different purposes. * enqueue special requests * turn on REQ_SPECIAL|REQ_SOFTBARRIER and call blk_requeue_request(). The second somewhat unobvious feature of blk_insert_request() is used only by SCSI midlayer and SCSI midlayer depended on it to set REQ_SOFTBARRIER. Unfortunately, when the SCSI midlayer sets REQ_SPECIAL explicitly (sg allocation failure path) it didn't set REQ_SOFTBARRIER, creating a *highly* unlikely but still existing dead lock condition caused by allowing reorder of a request which has its cmd allocated. IMHO, this proves the subtlety of current situation. This patch makes SCSI midlayer use blk_requeue_request() for reqeueuing and setting of REQ_SOFTBARRIER explicit. To prevent more misuses, the last patch in this patchset remove requeue feature from blk_insert_request(). Requeueing should be done with blk_requeue_request() not blk_insert_request(). [ Start of patch descriptions ] 01_scsi_REQ_SPECIAL_semantic_scsi_init_io.patch : replace REQ_SPECIAL with REQ_SOFTBARRIER in scsi_init_io() scsi_init_io() used to set REQ_SPECIAL when it fails sg allocation before requeueing the request by returning BLKPREP_DEFER. REQ_SPECIAL is being updated to mean special requests and we need to set REQ_SOFTBARRIER for half-prepp'ed requests. So, replace REQ_SPECIAL with REQ_SOFTBARRIER. 02_scsi_REQ_SPECIAL_semantic_scsi_queue_insert.patch : make scsi_queue_insert() use blk_requeue_request() scsi_queue_insert() used to use blk_insert_request() for requeueing requests. This behavior depends on the unobvious behavior of blk_insert_request() setting REQ_SPECIAL and REQ_SOFTBARRIER when requeueing. This patch makes scsi_queue_insert() use blk_requeue_request() and explicitly set REQ_SOFTBARRIER. As REQ_SPECIAL now means special requests, the flag is not set on requeue. Note that scsi_queue_insert() now calls scsi_run_queue() itself, and the prototype of the function is added right above scsi_queue_insert(). This is temporary, as later requeue path consolidation patchset removes scsi_queue_insert(). By adding temporary prototype, we can do away with unnecessary changes. 03_scsi_REQ_SPECIAL_semantic_scsi_requeue_command.patch : make scsi_requeue_request() use blk_requeue_request() scsi_requeue_request() used to use blk_insert_request() for requeueing requests. This behavior depends on the unobvious behavior of blk_insert_request() setting REQ_SPECIAL and REQ_SOFTBARRIER when requeueing. This patch makes scsi_requeue_request() use blk_requeue_request() and explicitly set REQ_SOFTBARRIER. As REQ_SPECIAL now means special requests, the flag is not set on requeue. 04_scsi_blk_insert_request_no_requeue.patch : remove requeue feature from blk_insert_request() blk_insert_request() has a unobivous feature of requeuing a request setting REQ_SPECIAL|REQ_SOFTBARRIER. SCSI midlayer was the only user and as previous patches removed the usage, remove the feature from blk_insert_request(). Only special requests should be queued with blk_insert_request(). All requeueing should go through blk_requeue_request(). [ End of patch descriptions ] This patchset completes preparation for scsi_request_fn() reimplementation patchset. As it seemed better to clear up requeue paths inside scsi_request_fn() first, requeue path consolidation patchset follows scsi_request_fn() reimplementation patchset. Thanks a lot. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU
On Sun, 10 Apr 2005 12:47:42 -0400 Derek Cheung wrote:
| Enclosed please find the updated patch that incorporates changes for all
| the comments I received.
(yes, almost all)
| The volatile declaration in the m528xsim.h is needed because the
| declaration refers to the ColdFire 5282 register mapping. The volatile
| declaration is actually not needed in my I2C driver but someone may
| include the m528xsim.h file in his/her applications and we need to force
| the compiler not to do any optimization on the register mapping.
Did you also send it to the I2C mailing list like Greg asked you to do?
More comments:
diffstat summary, like so, would be nice:
drivers/i2c/busses/Kconfig | 10
drivers/i2c/busses/Makefile |2
drivers/i2c/busses/i2c-mcf5282.c | 419 +++
drivers/i2c/busses/i2c-mcf5282.h | 46
include/asm-m68knommu/m528xsim.h | 42 +++
5 files changed, 519 insertions(+)
+ int i, len, rc = 0;
+u8 rxData, tempRxData[2];
Use tabs, not spaces. Happens other places too.
+switch (size) {
+case I2C_SMBUS_QUICK:
Don't need to indent case statements... (repeating myself).
+case I2C_SMBUS_PROC_CALL:
+ /* dev_info(>dev, "size =
+ I2C_SMBUS_PROC_CALL \n"); */
No break needed here ?
+ case I2C_SMBUS_WORD_DATA:
+ if (rc < 0)
+ return -1;
+ else
+ return 0;
There are several of these. Why not just return rc ?
Kconfig says that the module (if selected) will be called
i2c-mcf5282lite, but Makefile builds
+obj-$(CONFIG_I2C_MCF5282LITE) += i2c-mcf5282.o
(i.e., no "lite").
---
~Randy
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: New SCM and commit list
On Sun, 2005-04-10 at 16:26 -0700, Linus Torvalds wrote: > On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote: > > If yes, then I would appreciate if you could either keep the same list, > > or if you want to change the list name, keep the subscriber list so > > those of us who actually archive it don't miss anything ;) > > I didn't even set up the list. I think it's Bottomley. I'm cc'ing him just > so that he sees the message, but I don't actually expect him to do > anything about it. I'm not even ready to start _testing_ real merges yet. > But I hope that I can get non-conflicting merges done fairly soon, and > maybe I can con James or Jeff or somebody to try out GIT then... Not guilty. If I remember correctly, the list was set up by the vger list maintainers (davem and company). It was tied to a trigger in one of your trees (which I think Larry did). It shouldn't be too difficult to add to git ... it just means traversing all the added patches on a merge and sending out mail. I can try out your source control tools ... I have some rc fixes ready ... when you're ready to try out merges... James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] zero disk pages used by swsusp on resume
On Sun, Apr 10, 2005 at 10:14:55PM +0200, Pavel Machek wrote: > Hi! > > > > Oliver Neukum wrote: > > > > What is the point in doing so after they've rested on the disk for ages? > > > > > > The point is not physical access to the disk but data gathering after > > > resume or reboot. > > > > After resume or reboot normal access control mechanisms will work > > again. Those who can read a swap partition under normal circumstances > > can also read /dev/kmem. It seems to me like you are putting an extra > > lock on a window on the third floor while leaving the front door open. > > Andreas is right, his patches are needed. > > Currently, if your laptop is stolen after resume, they can still data > in swsusp image. > > Zeroing the swsusp pages helps a lot here, because at least they are > not getting swsusp image data without heavy tools. [Or think root > compromise month after you used swsusp.] > > Encrypting swsusp image is of course even better, because you don't > have to write large ammounts of zeros to your disks during resume ;-). How does zeroing help if they steal the laptop? The data is there, they can just pull the hard disk out and mirror it before they boot. The only way to improve security here is to encrypt it. Zeroing will help some if they compromise root later, but I doubt that's really worth it considering you're screwed after a root compromise anyway. -J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: formatting CD-RW locks the system
Hello. Alistair John Strachan wrote: You probably don't have DMA enabled on the drive. Please check this. It looks enabled. And even if it didn't, such a behaviour would still be strange. # hdparm -v /dev/cdrom /dev/cdrom: HDIO_GET_MULTCOUNT failed: Invalid argument IO_support = 1 (32-bit) unmaskirq= 1 (on) using_dma= 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead= 256 (on) HDIO_GETGEO failed: Invalid argument CDRW formatting works fine here with cdrecord blank=all OK, I'll try cdrecord too, thanks. But there might be a bug in the kernel if the system literally dies with the cdrwtool. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
How to access a kernel module function
Hi all, If i am writing a module and after compilation i am loading it. After that suppose i want to access few of the funtions in the module then how is it possible(i am not creating a device using mknode for the module). is it necessary that to access a kernel module function we need to create a node or device. if its not necessary then how can i access my module's function from user program. Karthik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-11, at 04:26, Miles Bader wrote: Marcin Dalecki <[EMAIL PROTECTED]> writes: Better don't waste your time with looking at Arch. Stick with patches you maintain by hand combined with some scripts containing a list of apply commands and you should be still more productive then when using Arch. Arch has its problems, but please lay off the uninformed flamebait (the "issues" you complain about are so utterly minor as to be laughable). I wish you a lot of laughter after replying to an already 3 days old message, which was my final on Arch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ANNOUNCE] git-pasky-0.2
On Mon, 11 Apr 2005, Petr Baudis wrote: > Hello, > > here goes git-pasky-0.2, my set of patches and scripts upon > Linus' git, aimed at human usability and to an extent a SCM-like usage. Incidentally, the git-pasky-base tarball you have up has its checked-out tree partway between 0.1 and 0.2, and doesn't compile. (The included HEAD version in .dircache is fine, if the user has some way to bootstrap) -Daniel *This .sig left intentionally blank* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: > > Well that's the problem. While copyright law does permit > > you to restrict > > the right to create derivative works, it doesn't permit you to > > restrict the > > distribution of lawfully created derivative works to licensees of the > > original work. As far as I know, no law has ever granted this right to > > copyright holders and no court has ever recognized this right. And I've > > looked. Courts have specifically recognized the absence of this right. > The GPL is very clear in its implementation: it grants wider permission > to create derivative works than to distribute them, implementing its > "virality" in terms of restrictions on distribution, not creation. It doesn't even need to do this. First sale grants the right to use a work one lawfully possesses. One cannot "use" the Linux kernel source without compiling it. So one doesn't need the GPL to create at least some derivative works. > So, > it seems that you're claiming that the GPL is broken or unenforcable in > some aspects. (If you're not, I'd like to know where I'm confused.) > If that's the case, it's a claim I'm not qualified to debate, but would > be interested in hearing the FSF's response. It has always been the FSF's position that you don't need to agree to the GPL to use the covered work. One cannot use the Linux kernel without compiling it and linking it. One cannot use a library without creating a work that uses the library, including the header files, and compiling/linking to form a result. So you can *create* a broad array of derivative works without invoking the GPL's restrictions (under first sale and how source code is ordinarily used). The argument that you cannot distribute a derived work unless the GPL says you can *because* you must have agreed to the GPL in order to lawfully create the derivative work is pure bunk. I don't know that the FSF relies upon the argument, however, it came up in this thread, which is why I refuted it (at least four times now). ;) DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> > The GPL applies to distributing a Linux binary I just made even > > though nobody ever chose to apply the GPL to the binary I just made > > only because the binary I just made is a derivative work of the > > Linux kernel, and the authors of that work chose to apply the GPL to > > it. > How can the binary be a derivative work when it does *not* contain > firmware, but suddenly cease to be a derivative work if one *does* > add firmware into it? Because, the argument would go, the binary with the firmware linked in is not a work, it is two works that are aggregated because there's a license boundary between them. The argument would be that the binary with the firmware is *a* *derivative* *work* of the Linux kernel source. The "a" is a critical part of the argument that cannot be omitted. Showing that the linked binary was two works would be sufficient to significantly weaken the argument that it can't be distributed. You can't argue that only the GPL gives you the right to distribute the result, regardless of what it is, because there are other sources of such rights. These include fair use, first sale, and the fact that the law does not create a special right to restrict the distribution of lawfully-created derivative works (to licensees of the original work). My point is not simply that the question of whether or not linking creates a single work that is a derivative work of all the things linked is important to the question of whether you can distribute GPL'd works linked with non-GPL'd works. And the standard is copyright law, not what the GPL says. (Though that's also important, because then you would have even more rights.) DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: easy softball jiffies quest(ion)
philip dahlquist wrote: hi, i'm on a quest to get access to jiffies in user space so i can write a simple stepper motor driver program. i co-opted the "#includes" list from alessandro rubini's jit.c file from "linux device drivers" to write jfi.c. That's not going to work, jiffies is an internal kernel value, you can't access it from userspace. What do you need jiffies for to do this? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: very high temperatures in Asus notebook
Zé wrote: I would like to understand why using linux, my notebook gets much higher temperatures than using windows, in linux i get about 67º celcius grades. Im pasting here the sensors output: ]# sensors it87-isa-0800 Adapter: ISA adapter VCore 1: +0.00 V (min = +1.42 V, max = +1.57 V) ALARM VCore 2: +0.00 V (min = +2.40 V, max = +2.61 V) ALARM +3.3V: +0.00 V (min = +3.14 V, max = +3.46 V) ALARM +5V: +0.00 V (min = +4.76 V, max = +5.24 V) ALARM +12V: +0.00 V (min = +11.39 V, max = +12.61 V) ALARM -12V: -27.36 V (min = -12.63 V, max = -11.41 V) ALARM -5V: -13.64 V (min = -5.26 V, max = -4.77 V) ALARM Stdby: +0.00 V (min = +4.76 V, max = +5.24 V) ALARM VBat: +3.28 V fan1: 135000 RPM (min =0 RPM, div = 2) fan2:0 RPM (min = 2657 RPM, div = 2) fan3:0 RPM (min = 2657 RPM, div = 2) M/B Temp:+67°C (low = +15°C, high = +40°C) sensor = diode CPU Temp:+67°C (low = +15°C, high = +45°C) sensor = diode Temp3: +67°C (low = +15°C, high = +45°C) sensor = diode I'm doubting that those temperatures are accurate, considering how screwed up all the other parameter values are.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] drivers/pnp/pnpbios/rsparser.c: fix an array overflow
On Sat, Apr 09, 2005 at 08:03:52PM +0200, Adrian Bunk wrote: > This patch fixes an array overflow found by the Coverity checker. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > Looks good. Thanks, Adam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Marcin Dalecki <[EMAIL PROTECTED]> writes: > Better don't waste your time with looking at Arch. Stick with patches > you maintain by hand combined with some scripts containing a list of > apply commands and you should be still more productive then when using > Arch. Arch has its problems, but please lay off the uninformed flamebait (the "issues" you complain about are so utterly minor as to be laughable). -Miles -- Ich bin ein Virus. Mach' mit und kopiere mich in Deine .signature. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Processes stuck on D state on Dual Opteron
On Sunday 10 April 2005 03:47, Andrew Morton wrote: > > Suggest you boot with `nmi_watchdog=0' to prevent the nmi watchdog from > cutting in during long sysrq traces. > > Also, capture the `sysrq-m' output so we can see if the thing is out of > memory. Hi Andrew, Thanks for the tip. I booted with nmi_watchdog=0 and was able to get a full sysrq-t as well as a sysrq-m. Since it might be a little too big for the list, I've put it on a text file at: http://193.136.132.235/dl145/dump1-2.6.12-rc2.txt I also made a run with the mempool-can-fail patch from Nick Piggin. With this I got some nice memory allocation errors from the md threads when the trouble started. The dump (with sysrq-t and sysrq-m included) is at: http://193.136.132.235/dl145/dump2-2.6.12-rc2-nick1.txt Let me know if you find it more convenient to send the dumps by mail or something. Hope this helps. Thanks, Claudio - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
$B"!$*;n$72<$5$$"!(B
$BB>$N%5%$%H$H$N0c$$$rBN83$7$F2<$5$$!*(B $B(Bhttp://www.getluck.net/ $B4JC1A`:n$G4JC1EPO?!*(B $B!!??7u$J=P2q$$$O$3$3$+$i(B $B!!(B $B=i$a$F$NJ}$OL5NA%(%s%H%j!<$+$i$I$&$>(B $B(Bhttp://www.getluck.net/ $B"(GIhttp://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] git-pasky-0.2
Hello, here goes git-pasky-0.2, my set of patches and scripts upon Linus' git, aimed at human usability and to an extent a SCM-like usage. If you already have a previous git-pasky version, just git pull pasky to get it. Otherwise, you can get it from: http://pasky.or.cz/~pasky/dev/git/ Please see the README there and/or the parent post for detailed instructions. You can find the changes from the last announcement in the ChangeLog (releases have separate commits so you can find them easily; they are also tagged for purpose of diffing etc). This is release contains mostly bugfixes, performance enhancements (especially w.r.t. git diff), and some merges with Linus (except for diff-tree, where I merged only the new output format). New features are trivial - support for tagging and short SHA1 ids; you can use only the start of the SHA1 hash long enough to be unambiguous. My immediate plan is implementing git merge, which I will do tommorow, if noone will do it before that is. ;-) Any feedback/opinions/suggestions/patches (especially patches) are welcome. Have fun, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: increasing scsi_max_sg / max_segments for scsi writes/reads
On Sat, 9 Apr 2005 19:35:52 -0700 (PDT) sai narasimhamurthy wrote: | Hi, | I had posted a question on increasing the scsi | read/write sectors per command. I figured out some of | the things, but many questions still exist. | | I was wondering why the maximum writes I could get | from a single scsi write command could never exceed | 204 | 4096B segments . I traced it to : | | static const int scsi_max_sg = PAGE_SIZE / | sizeof(struct scatterlist) | | in scsi_merge.c .(which amounts to 204) | | Is this the limit of the maximum blocks we can | read/write through a single scsi command, atleast for | the given kernel (2.4.29) ? How can I increase | it?? | | I am on a P3 Dell poweredgde 2400 . Did you read the comment immediately above that calculation? /* * scsi_malloc() can only dish out items of PAGE_SIZE or less, so we cannot * build a request that requires an sg table allocation of more than that. */ so scsi_malloc() would need some reworking to handle more. OTOH, it appears that this is all removed in 2.6.10++, so moving to 2.6.recent is probably your best choice. --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: non-free firmware in kernel modules, aggregation and unclear copyright notice.
On Sun, Apr 10, 2005 at 01:18:11PM -0700, David Schwartz wrote: > Well that's the problem. While copyright law does permit you to restrict > the right to create derivative works, it doesn't permit you to restrict the > distribution of lawfully created derivative works to licensees of the > original work. As far as I know, no law has ever granted this right to > copyright holders and no court has ever recognized this right. And I've > looked. Courts have specifically recognized the absence of this right. The GPL is very clear in its implementation: it grants wider permission to create derivative works than to distribute them, implementing its "virality" in terms of restrictions on distribution, not creation. So, it seems that you're claiming that the GPL is broken or unenforcable in some aspects. (If you're not, I'd like to know where I'm confused.) If that's the case, it's a claim I'm not qualified to debate, but would be interested in hearing the FSF's response. -- Glenn Maynard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: formatting CD-RW locks the system
On Sunday 10 April 2005 16:36, Alistair John Strachan wrote: >On Sunday 10 Apr 2005 19:29, you wrote: >> Hello. >> >> I am trying to format the CD-RW disc >> on my NEC ND-3520A DVD writer, and the >> results are completely unexpected: I do >> cdrwtool -d /dev/cdrom -q >> It proceeds with the formatting, but >> while it does so, the system is pretty >> much dead. It can do some trivial tasks >> like the console switching, but as soon >> as it comes to any disc I/O, the processes >> are hanging. After the formatting is done, >> the system is back alive. That reminds me >> formatting the floppies under DOS in those >> ancient times, with the only difference >> that formatting a floppy takes ~2 minutes, >> while formatting a CD-RW takes ~20 minutes, >> which is not good at all. >> Is this something known or a bug? >> I tried that on a 2.6.11-rc3-mm2 and >> on a 2.6.12-rc1 kernels. >> >> Also, is there any way to use the >> packet writing with the CD-R/DVD-R discs, >> or is it supposed to work only with the >> -RW discs? > >You probably don't have DMA enabled on the drive. Please check this. > >CDRW formatting works fine here with cdrecord blank=all Excuse me, but did I miss a major left turn in the operations of a disk control system here someplace? Every disk system I have ever delt with, has as a default, (and I've walked around in a couple of them at the assembly language level) the assumption that if track 0 is to be formatted, then the whole device is assumed to be needing formatted, and every filesystem I've ever screwed with will do exactly that. Often, but not always, that can actually be offloaded to the device itself if its smart enough, and the operating system itself can go on about its business, whether its you composing a letter to your aunt Tilly or whatever. IDE/ATAPI drives have been cheerfully ignoreing format messages from the OS now for what, 12 years now unless backed up by super secret code word access to such builtin functions of the drive, only possessed by the factory technicians who do have the tools to control the track spaceings and data densities on the surfaces etc etc? Scsi drives have been reporting the success of the formatting operation in just a few milliseconds for even longer simply because they take care of their own errors long before the os is aware the drive may be having problems? The last time I formatted a scsi drive under nitros9, the format took 10 milliseconds, but the logical installation of the filesystem took another 3 hours, mainly because nitros9 uses a 256 byte sector. Its possible the cd-rw folks seem to have fallen off the wagon here, but really, a disk operating system (and the average cd-rw or dvd-rw drive should be capable of doing that with no further intervention from the OS itself unless you want some sort of a non-standard formatting done as in the nitros0 situation. Are the firmwares of modern cd/dvd writers actualy dumb enough they need the OS's help for that? If the answer is yes, lord help us. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.34% setiathome rank, not too shabby for a WV hillbilly Yahoo.com and AOL/TW attorneys please note, additions to the above message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: [ANNOUNCE] git-pasky-0.1
On Mon, 11 Apr 2005, Petr Baudis wrote: > > Dear diary, on Sun, Apr 10, 2005 at 10:38:11PM CEST, I got a letter > where Linus Torvalds <[EMAIL PROTECTED]> told me that... > ..snip.. > > Can you pull my current repo, which has "diff-tree -R" that does what the > > name suggests, and which should be faster than the 0.48 sec you see.. > > Am I just missing something, or your diff-tree doesn't handle > added/removed directories? You're not missing anything, I did it that way on purpose. I thought it would be easier to do the expansion in the caller (who knows what it is they want to do with the end result). But now that I look at merging, I realize that was actually the wrong thing to do. A merge algorithm definitely wants to see the expanded tree, since it will compare/join several of the diff-tree output things. So I'll either fix it or decide to just go with your version instead. I'm not overly proud. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
I see. It just need some basic set operation (+, -, and)
and some way to select a set:
sha5--->
/
/
sha1-->sha2-->sha3--
\/
\ /
>sha4
list sha1 # all the file list in changeset sha1
# {sha1}
list sha1,sha1 # same as above
list sha1,sha2 # all the file list in between changeset sha1
# and changeset sha2
# {sha1, sha2} in example
list sha1,sha3 # {sha1, sha2, sha3, sha4}
list sha1,any # all the change set reachable from sha1.
{sha1, ... sha5, ...}
new sha1,sha2 # all the new file add between in sha1, sha2 (+)
changed sha1,sha2 # add the changed file between sha1, sha2 (>) (<)
deleted sha1,sha2 # add the deleted file between sha1, sha2(-)
before time # all the file before time
aftertime # all the file after time
So in my example, the file I want to delete is :
{list hack1, base}+ {list hack2, base} ... {list hack6, base} \
- [list official_merge, base ]
On Sun, Apr 10, 2005 at 04:21:08PM -0700, Linus Torvalds wrote:
>
>
> > the official tree. It is more for my local version control.
>
> I have a plan. Namely to have a "list-needed" command, which you give one
> commit, and a flag implying how much "history" you want (*), and then it
> spits out all the sha1 files it needs for that history.
>
> Then you delete all the other ones from your SHA1 archive (easy enough to
> do efficiently by just sorting the two lists: the list of "needed" files
> and the list of "available" files).
>
> Script that, and call the command "prune-tree" or something like that, and
> you're all done.
>
> (*) The amount of history you want might be "none", which is to say that
> you don't want to go back in time, so you want _just_ the list of tree and
> blob objects associated with that commit.
That will be {list head}
>
> Or you might want a "linear" history, which would be the longest path
> through the parent changesets to the root.
That will be {list head,root}
>
> Or you might want "all", which would follow all parents and all trees.
That will be {list any, root}
>
> Or you might want to prune the history tree by date - "give me all
> history, but cut it off when you hit a parent that was done more than 6
> months ago".
That is {after -6month }
>
> This "list-needed" thing is not just for pruning history either. If you
> have a local tree "x", and you want to figure out how much of it you need
> to send to somebody else who has an older tree "y", then what you'd do is
> basically "list-needed x" and remove the set of "list-needed y". That
> gives you the answer to the question "what's the minimum set of sha1 files
> I need to send to the other guy so that he can re-create my top-of-tree".
>
That is {list x, any} - {list y, any}
> My second plan is to make somebody else so fired up about the problem that
> I can just sit back and take patches. That's really what I'm best at.
> Sitting here, in the (rain) on the patio, drinking a foofy tropical drink,
> and pressing the "apply" button. Then I take all the credit for my
> incredible work.
Sounds like a good plan.
Chris
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 10:38:11PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... ..snip.. > Can you pull my current repo, which has "diff-tree -R" that does what the > name suggests, and which should be faster than the 0.48 sec you see.. Am I just missing something, or your diff-tree doesn't handle added/removed directories? (Mine does! *hint* *hint* It also doesn't bother with dynamic allocation, but someone might consider the static path buffer ugly. Anyway, I hacked it with a plan to do a massive cleanup of the file later.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Dear diary, on Mon, Apr 11, 2005 at 02:20:52AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > Btw, does anybody have strong opinions on the license? I didn't put in a > COPYING file exactly because I was torn between GPLv2 and OSL2.1. > > I'm inclined to go with GPLv2 just because it's the most common one, but I > was wondering if anybody really had strong opinions. For example, I'd > really make it "v2 by default" like the kernel, since I'm sure v3 will be > fine, but regardless of how sure I am, I'm _not_ a gambling man. Oh, I wanted to ask about this too. I'd mostly prefer GPLv2 (I have no problem with the version restriction, I usually do it too), it's the one I'm mostly familiar with and OSL appears to be incompatible with GPL (at least FSF says so about OSL1.0), which might create various annoying issues. I hate when licenses get in my way and prevent me to possibly include some useful code. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
Scripsit "David Schwartz" <[EMAIL PROTECTED]> >> However, then you cannot legally copy it at all, because it contains >> part of the original author's copyrighted work and therefore can only >> legally be copied with the permission of the author. > The way you stop someone from distributing part of your work > is by arguing that the work they are distributing is a derivative > work of your work and they had no right to *make* it in the first > place. See, for example, Mulcahy v. Cheetah Learning. You don't need to argue that the thing being distributed is a derivative work. It is enough that it _contains_ your copyrighted work. > My point is that the reason the derivative work issue is so > important is because it's the only way (in U.S. law anyway) that the > GPL can apply to anything other than the exact thing the author > chose to apply it to. The taske of the GPL is to _give permission_ when certain conditions hold. Therefore, if the GPL does not apply yet you still need permission from the author (beacuse what you're distributing contains his work), then you do not have that permission and cannot distribute _at all_. I'm not sure whether meant instead that the original _copyright_ only influences things that are derivative works, but that would have even more bizarre consequences. > The GPL applies to distributing a Linux binary I just made even > though nobody ever chose to apply the GPL to the binary I just made > only because the binary I just made is a derivative work of the > Linux kernel, and the authors of that work chose to apply the GPL to > it. How can the binary be a derivative work when it does *not* contain firmware, but suddenly cease to be a derivative work if one *does* add firmware into it? -- Henning Makholm"Vi skal nok ikke begynde at undervise hinanden i den store regnekunst her, men jeg vil foreslå, at vi fra Kulturministeriets side sørger for at fremsende tallene og også give en beskrivelse af, hvordan man læser tallene. Tak for i dag!" - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
Linus writes: > Hey. You're welcome. Especially when you create good documentation for > this thing. Glad to be of service. Sounds like the umbrella in your foofy drink drink will come in handy - keeping off the rain. -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)
Btw, does anybody have strong opinions on the license? I didn't put in a COPYING file exactly because I was torn between GPLv2 and OSL2.1. I'm inclined to go with GPLv2 just because it's the most common one, but I was wondering if anybody really had strong opinions. For example, I'd really make it "v2 by default" like the kernel, since I'm sure v3 will be fine, but regardless of how sure I am, I'm _not_ a gambling man. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ANNOUNCE] git-pasky-0.1
On Sun, 10 Apr 2005 16:23:11 -0700 Paul Jackson wrote: | Petr wrote: | > That reminds me, is there any | > tool which will take .rej files and throw them into the file to create | > rcsmerge-like conflicts? | | Check out 'wiggle' | http://www.cse.unsw.edu.au/~neilb/source/wiggle/ or Chris Mason's 'rej' program: ftp://ftp.suse.com/pub/people/mason/rej/ --- ~Randy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: more git updates..
Dear diary, on Mon, Apr 11, 2005 at 01:14:57AM CEST, I got a letter
where Paul Jackson <[EMAIL PROTECTED]> told me that...
> Useful explanation - thanks, Linus.
>
> Is this picture and description accurate:
>
> ==
>
>
> < working directory files (foo.c) >
>^
> ^|
> | upward ops|downward ops |
> | --| |
> | checkout-cache |update-cache |
> | show-diff | v
>v
> < current directory cache (".dircache/index") >
>^
> ^|
> | upward ops|downward ops |
> | --| |
> | read-tree| write-tree |
> ||commit-tree |
>| v
>v
> < git filesystem (blobs, trees, commits: .dircache/{HEAD,objects}) >
Well, except that from purely technical standpoint commit-tree has
nothing to do in this picture - it creates new object in the git
filesystem based on its input data, but regardless to the directory
cache or current tree. It probably still belongs where it is from the
workflow standpoint, though.
..snip..
> Minor question:
>
> I must have an old version - I got 'git-0.03', but
> it doesn't have 'checkout-cache', and its 'read-tree'
> directly writes my working files.
>
> How do I get a current version? Well, one way I see,
> and that's to pick up Pasky's:
>
> http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2
>
> Perhaps that's the best way?
You can take mine, and do:
git pull pasky
git pull linus
cp .dircache/HEAD .dircache/HEAD.local
Now, your tree and git filesystem is up to date.
git track local
Now, when you do git pull pasky, your working tree will not be updated
automatically anymore.
git track linus
Now, you start tracking Linus' tree instead. Note that the initial
update will blow away the scripts in your current tree, so before you do
the last two steps you will probably want to clone the tree and set PATH
to the one still tracking me, so you get all the comfort. ;-)
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
very high temperatures in Asus notebook
I would like to understand why using linux, my notebook gets much higher temperatures than using windows, in linux i get about 67º celcius grades. For what i have compared to other notebooks, the drive made for my notebook, an Asus A2h, you can see specifications in http://www.asus.com/products/notebook/a2series/a2000h/a2000h_overview.htm I dont see other notebooks get so high temperatures like mine, and im also talking about Asus notebooks. Im pasting here the sensors output: ]# sensors it87-isa-0800 Adapter: ISA adapter VCore 1: +0.00 V (min = +1.42 V, max = +1.57 V) ALARM VCore 2: +0.00 V (min = +2.40 V, max = +2.61 V) ALARM +3.3V: +0.00 V (min = +3.14 V, max = +3.46 V) ALARM +5V: +0.00 V (min = +4.76 V, max = +5.24 V) ALARM +12V: +0.00 V (min = +11.39 V, max = +12.61 V) ALARM -12V: -27.36 V (min = -12.63 V, max = -11.41 V) ALARM -5V: -13.64 V (min = -5.26 V, max = -4.77 V) ALARM Stdby: +0.00 V (min = +4.76 V, max = +5.24 V) ALARM VBat: +3.28 V fan1: 135000 RPM (min =0 RPM, div = 2) fan2:0 RPM (min = 2657 RPM, div = 2) fan3:0 RPM (min = 2657 RPM, div = 2) M/B Temp:+67°C (low = +15°C, high = +40°C) sensor = diode CPU Temp:+67°C (low = +15°C, high = +45°C) sensor = diode Temp3: +67°C (low = +15°C, high = +45°C) sensor = diode Here is also the output of lspcidrake: ]# lspcidrake sis-agp : Silicon Integrated System|SiS 650 Host-to-PCI Bridge [BRIDGE_HOST] unknown : Silicon Integrated Systems [SiS]|5591/5592 AGP [BRIDGE_PCI] unknown : Silicon Integrated Systems [SiS]|SiS962 [MuTIOL Media IO] [BRIDGE_ISA] i2c-sis96x : Silicon Integrated System|SiS961/962 SMBus Controller [SERIAL_SMBUS] ohci1394: Silicon Integrated Systems [SiS]|OHCI Compliant FireWire Controller [SERIAL_FIREWIRE] sis5513 : Silicon Integrated Systems [SiS]|5513 [IDE] [STORAGE_IDE] slamr : Silicon Integrated System|SiS7013 56k Modem [COMMUNICATION_MODEM] snd-intel8x0: Silicon Integrated Systems [SiS]|SiS7012 PCI Audio Accelerator [MULTIMEDIA_AUDIO] usb-ohci: Silicon Integrated Systems [SiS]|7001 USB [SERIAL_USB] usb-ohci: Silicon Integrated Systems [SiS]|7001 USB [SERIAL_USB] usb-ohci: Silicon Integrated Systems [SiS]|7001 USB [SERIAL_USB] ehci-hcd: Silicon Integrated Systems [SiS]|7002 USB 2.0 Controller [SERIAL_USB] sis900 : Silicon Integrated Systems [SiS]|SiS900 10/100 Ethernet [NETWORK_ETHERNET] yenta_socket: Texas Instruments|PCI1410 PC card Cardbus Controller [BRIDGE_CARDBUS] unknown : Broadcom Corp.|BCM4301 802.11b [NETWORK_OTHER] Card:SiS 650: Silicon Integrated System|SiS650/651/740 GUI 2D/3D Accelerator [DISPLAY_VGA] hub : Linux 2.6.11-6mdk ehci_hcd|EHCI Host Controller [Hub|Unused] hub : Linux 2.6.11-6mdk ohci_hcd|OHCI Host Controller [Hub|Unused] hub : Linux 2.6.11-6mdk ohci_hcd|OHCI Host Controller [Hub|Unused] usbhid : Microsoft Corp.|Notebook Optical Mouse [Human Interface Devices|Boot Interface Subclass|Mouse] hub : Linux 2.6.11-6mdk ohci_hcd|OHCI Host Controller [Hub|Unused] Any help? -- Zé Linux user #378762 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Monday 11 April 2005 12:33 am, you wrote: [..] > Well, I followed some of the instructions to mirror the kernel tree on > svn.clkao.org/linux/cvs, and although it took around 12 hours to import > 28232 versions, I seem to have a mirror of it on my own subversion > server now. I think the svn.clkao.org mirror was taken from bkcvs... the > last log message I see is "Rev 28232 - torvalds - 2005-04-04 09:08:33" I'd love to see svk as a real choice for you guys, but I don't mind as along as I get a door open using svn/svk ;);) > I have no idea what's missing. What is everyone's favorite web frontend > to subversion? Check out ViewCVS at: http://viewcvs.sourceforge.net/ This seem widely used (not just by me ^o^). Regards, Christian Parpart. -- Netiquette: http://www.ietf.org/rfc/rfc1855.txt 01:55:08 up 18 days, 15:01, 2 users, load average: 0.27, 0.39, 0.36 pgpxCXxtEIvrr.pgp Description: PGP signature
Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Mon, Apr 11, 2005 at 01:46:50AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > > > On Mon, 11 Apr 2005, Petr Baudis wrote: > > > > (BTW, it would be useful to have a tool which just blindly takes what > > you give it on input and throws it to an object of given type; I will > > need to construct arbitrary commits during the rebuild if I'm to keep > > the correct dates.) > > Hah. That's what "COMMITTER_NAME" "COMMITTER_EMAIL" and "COMMITTER_DATE" > are there for. > > There's two things to commits: when (and by whom) it was committed to a > tree, and when the changes were really done. > > So set the COMMITTER_xxx things to the person/time you want to consider > the _original_ one, and let "commit-tree" author you as the creator of the > commit itself. The regular "ChangeLog" thing should only show the author > and original time, but it's nice to see who created the commit itself. I already use those - look at my ChangeLog. (That's because for certain reasons I'm working on git in a half-broken chrooted environment.) When rebuilding the tree from scratch, I wanted like to do it transparently - that is, so that noone could notice that I rebuilt it, since it effectively still _is_ the original tree from the data standpoint, just the history flow is actually correct this time. > Btw, the "COMMITTER_" environment variables are very confusingly > named. They actually go into the _author_ line in the commit object. I'm a > total retard, and I really don't know why I called it "COMMITTER_xxx" > instead of "AUTHOR_xxx". So, who will fix it in his tree first! ;-) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] kernel 2.6.11.6 - I2C adaptor for ColdFire 5282 CPU
"Derek Cheung" <[EMAIL PROTECTED]> wrote: > > Enclosed please find the updated patch that incorporates changes for all > the comments I received. > > The volatile declaration in the m528xsim.h is needed because the > declaration refers to the ColdFire 5282 register mapping. The volatile > declaration is actually not needed in my I2C driver but someone may > include the m528xsim.h file in his/her applications and we need to force > the compiler not to do any optimization on the register mapping. - Please reissue the changelog each time you reissue a patch. - This patch adds tons of trailing whitespace. - It breaks the x86 build. I did this: --- 25/drivers/i2c/busses/Kconfig~i2c-adaptor-for-coldfire-5282-cpu-fix 2005-04-10 16:52:08.0 -0700 +++ 25-akpm/drivers/i2c/busses/Kconfig 2005-04-10 16:52:18.0 -0700 @@ -31,7 +31,7 @@ config I2C_ALI1563 config I2C_MCF5282LITE tristate "MCF5282Lite" -depends on I2C && EXPERIMENTAL +depends on I2C && EXPERIMENTAL && PPC help If you say yes to this option, support will be included for the I2C on the ColdFire MCF5282Lite Development Board _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 11:39:02PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Sun, 10 Apr 2005, Linus Torvalds wrote: > > > > Can you pull my current repo, which has "diff-tree -R" that does what the > > name suggests, and which should be faster than the 0.48 sec you see.. > > Actually, I changed things around. Everybody hated the "<" ">" lines, so I > put a changed thing on a line of its own with a "*" instead. > > So you'd now see lines like > > *100644->100644 > 1874e031abf6631ea51cf6177b82a1e662f6183e->e8181df8499f165cacc6a0d8783be7143013d410 > CREDITS > > which means that the CREDITS file has changed, and it shows you the mode > -> mode transition (that didn't change in this case) and the sha1 -> sha1 > transition. > > So now it's always just one line per change. Firthermore, the filename is > always field 3, if you use spaces as delimeters, regardless of whether > it's a +/-/* field. That's great, just when I finally managed to properly fix the xargs boundary case in gitdiff-do (without throwing away the NUL-termination). You know how to please people! ;-) (Not that I'd have *anything* against the change. The logic is simpler and you'll be actually able to work with diff-tree a little sanely.) BTW, it is quite handy to have the entry type in the listing (guessing that from mode in the script just doesn't feel right and doing explicit cat-file kills the performance). I would also really prefer the fields separated by tabs. It looks nicer on the screen (aligned, e.g. modes and type are varsized), and is also easier to parse (cut defaults to tabs as delimiters, for example). > So let's say you want to merge two trees (dst1 and dst2) from a common > parent (src), what you would do is: > > - get the list of files to merge: > > diff-tree -R | tr '\0' '\n' > merge-files ...oh, I probably forgot to ask - why did you choose -R instead of -r? It looks rather alien to me; if it starts by 'diff', my hand writes -r without thinking. > - Which of those were changed by -> ? > > diff-tree -R | tr '\0' '\n' | join -j 3 - merge-files > > dst1-change > diff-tree -R | tr '\0' '\n' | join -j 3 - merge-files > > dst2-change > > - Which of those are common to both? Let's see what the merge list is: > > join dst1-change dst2-change > merge-list > > and hopefully you'd usually be working on a very small list of files by > then (everything else you'd just pick from one of the destination trees > directly - you've got the name, the sha-file, everything: no need to even > look at the data). Ok, this looks reasonable. (Provided that I DWYM regarding the joins.) > Does this sound sane? Pasky? Wanna try a "git merge" thing? Starting off > with the user having to tell what the common parent tree is - we can try > to do the "automatically find best common parent" crud later. THAT may be > expensive. I will definitively try "git merge", but maybe not this night anymore (it's already 1:32 here now). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: Re: [ANNOUNCE] git-pasky-0.1
On Mon, 11 Apr 2005, Petr Baudis wrote: > > (BTW, it would be useful to have a tool which just blindly takes what > you give it on input and throws it to an object of given type; I will > need to construct arbitrary commits during the rebuild if I'm to keep > the correct dates.) Hah. That's what "COMMITTER_NAME" "COMMITTER_EMAIL" and "COMMITTER_DATE" are there for. There's two things to commits: when (and by whom) it was committed to a tree, and when the changes were really done. So set the COMMITTER_xxx things to the person/time you want to consider the _original_ one, and let "commit-tree" author you as the creator of the commit itself. The regular "ChangeLog" thing should only show the author and original time, but it's nice to see who created the commit itself. I did this very much on purpose: see how I always try to attribute authorship in BK to the person who actually wrote the code. At the same time, I think it's interesting from a tracking standpoint to also see when/where that change got introduced into a tree. I _tried_ to get this right in the sparse tree conversion. I won't guarantee that it's all correct, but the top commit in the sparse tree looks like this: tree 67607f05a66e36b2f038c77cfb61350d2110f7e8 parent 9c59995fef9b52386e5f7242f44720a7aca287d7 author Christopher Li <[EMAIL PROTECTED]> Sat Apr 2 09:30:09 PST 2005 committer Linus Torvalds <[EMAIL PROTECTED]> Thu Apr 7 20:06:31 2005 ... exactly because I tracked when I committed it to the sparse tree _separately_ from tracking when it was created. So when I re-create the sparse-tree, I'll also end up re-writing the "committer" information. And that's proper. That's really saying "this sha1 object was created by Xxxx at time Xxxx". Btw, the "COMMITTER_" environment variables are very confusingly named. They actually go into the _author_ line in the commit object. I'm a total retard, and I really don't know why I called it "COMMITTER_xxx" instead of "AUTHOR_xxx". Linus "retard" Torvalds - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: How's the nforce4 support in Linux?
On Apr 6, 2005 6:02 PM, Bartlomiej Zolnierkiewicz <[EMAIL PROTECTED]> wrote:
>
> There still can be a bug in setting up DMA timings etc.
>
> It is hard to even guess as you haven't given any details about your
> system: dmesg/hdparm/lspci/config... (or I overlooked it somehow).
I sent the related dmesg lines, and my .config.
for dmesg and .config :
http://marc.theaimsgroup.com/?l=linux-kernel=79215521092=2
what part of lspci would you need ?
hdparm :
[EMAIL PROTECTED]:~$ sudo hdparm -i /dev/hda
/dev/hda:
Model=Maxtor 6Y160P0, FwRev=YAR41BW0, SerialNo=Y47J8CRE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=7936kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=268435455
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):
* signifies the current active mode
(it shows no mode... it's strange, because this drive should be nearly
the same as the following)
[EMAIL PROTECTED]:~$ sudo hdparm -i /dev/hdc
/dev/hdc:
Model=Maxtor 6Y120L0, FwRev=YAR41BW0, SerialNo=Y31LWCXE
Config={ Fixed }
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=57
BuffType=DualPortCache, BuffSize=2048kB, MaxMultSect=16, MultSect=off
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=240121728
IORDY=on/off, tPIO={min:120,w/IORDY:120}, tDMA={min:120,rec:120}
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=yes: disabled (255) WriteCache=enabled
Drive conforms to: (null):
* signifies the current active mode
[EMAIL PROTECTED]:~$ sudo hdparm -d /dev/hdc
/dev/hdc:
using_dma= 0 (off)
(Note : hdparm -i says 'udma6', and hdparm -d says 'no dma'...
Strange, isn't it ?)
> > > In my case, the driver stopped for hdb, that is my dvd-burner/player.
> > > It did nothing for hda or hdc, I had to disable DMA myself.
> > >
> > > Will I have to install Windows XP to prove ultra DMA works correctly
> > > on this setup ? I really don't hope...
>
> That would be very helpful.
I'll try that...
> Another useful thing would be to try non-nVidia motherboard
> (if you have one handy) without changing anything else.
I succesfully used these drives with another motherboard (PIIX4)
before, in udma2 mode, for years...
But first thing : I have to check if the cables are correctly plugged
in (I mean in the correct order)... I didn't have the time to do that
yet.
Thanks for your answer.
--
Julien
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: more git updates..
On Sun, 10 Apr 2005, Paul Jackson wrote: > > Useful explanation - thanks, Linus. Hey. You're welcome. Especially when you create good documentation for this thing. Because: > Is this picture and description accurate: [ deleted, but I'll probably try to put it in an explanation file somewhere ] Yes. Excellent. > Minor question: > > I must have an old version - I got 'git-0.03', but > it doesn't have 'checkout-cache', and its 'read-tree' > directly writes my working files. Yes. Crappy old tree, but it can still read my git.git directory, so you can use it to update to my current source base. However, from a usability angle, my source-base really has been concentrating _entirely_ on just the plumbing, and if you actually want a faucet or a toilet _conntected_ to the plumbing, you're better off with Pasky's tree, methinks: > How do I get a current version? Well, one way I see, > and that's to pick up Pasky's: > > http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2 > > Perhaps that's the best way? Indeed. He's got a number of shell scripts etc to automate the boring parts. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 encrypted swsusp 1/3] core functionality
The following patch adds the core functionality for the encrypted
suspend image.
--
Andreas Steinmetz SPAMmers use [EMAIL PROTECTED]
--- linux-2.6.11.2/kernel/power/swsusp.c.ast2005-04-10 14:08:55.0
+0200
+++ linux-2.6.11.2/kernel/power/swsusp.c2005-04-11 00:50:45.0
+0200
@@ -31,6 +31,9 @@
* Alex Badea <[EMAIL PROTECTED]>:
* Fixed runaway init
*
+ * Andreas Steinmetz <[EMAIL PROTECTED]>:
+ * Added encrypted suspend option
+ *
* More state savers are welcome. Especially for the scsi layer...
*
* For TODOs,FIXMEs also look in Documentation/power/swsusp.txt
@@ -72,6 +75,16 @@
#include "power.h"
+#ifdef CONFIG_SWSUSP_ENCRYPT
+#include
+#include
+#include
+#endif
+
+#define CIPHER "aes"
+#define MAXKEY 32
+#define MAXIV 32
+
/* References to section boundaries */
extern const void __nosave_begin, __nosave_end;
@@ -103,15 +116,27 @@
#define SWSUSP_SIG "S1SUSPEND"
-static struct swsusp_header {
- char reserved[PAGE_SIZE - 20 - sizeof(swp_entry_t)];
+struct swsusp_header {
+ char reserved[PAGE_SIZE - 20 - MAXKEY - MAXIV - sizeof(swp_entry_t)];
+ u8 key[MAXKEY];
+ u8 iv[MAXIV];
swp_entry_t swsusp_info;
charorig_sig[10];
charsig[10];
-} __attribute__((packed, aligned(PAGE_SIZE))) swsusp_header;
+} __attribute__((packed, aligned(PAGE_SIZE)));
+
+static union {
+ struct swsusp_header __attribute__((packed, aligned(PAGE_SIZE)))
swsusp_header;
+ u8 buffer[PAGE_SIZE] __attribute__((aligned(PAGE_SIZE)));
+} __attribute__((packed, aligned(PAGE_SIZE))) u;
static struct swsusp_info swsusp_info;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static u8 key[MAXKEY];
+static u8 iv[MAXIV];
+#endif
+
/*
* XXX: We try to keep some more pages free so that I/O operations succeed
* without paging. Might this be more?
@@ -130,22 +155,72 @@
static unsigned short swapfile_used[MAX_SWAPFILES];
static unsigned short root_swap;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)
+{
+ struct crypto_tfm *tfm;
+ int len;
+
+ tfm = crypto_alloc_tfm(CIPHER, CRYPTO_TFM_MODE_CBC);
+ if(!tfm) {
+ printk(KERN_ERR "swsusp: no tfm, suspend not possible\n");
+ return NULL;
+ }
+
+ if(sizeof(key) < crypto_tfm_alg_min_keysize(tfm)) {
+ printk("swsusp: key buffer too small, suspend not possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (sizeof(iv) < crypto_tfm_alg_ivsize(tfm)) {
+ printk("swsusp: iv buffer too small, suspend not possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ if (mode) {
+ get_random_bytes(key, MAXKEY);
+ get_random_bytes(iv, MAXIV);
+ }
+
+ len = crypto_tfm_alg_max_keysize(tfm);
+ if (len > sizeof(key))
+ len = sizeof(key);
+
+ if (crypto_cipher_setkey(tfm, key, len)) {
+ printk(KERN_ERR "swsusp: key setup failure, suspend not
possible\n");
+ crypto_free_tfm(tfm);
+ return NULL;
+ }
+
+ len = crypto_tfm_alg_blocksize(tfm);
+ crypto_cipher_set_iv(tfm, iv, len);
+
+ return tfm;
+}
+#endif
+
static int mark_swapfiles(swp_entry_t prev)
{
int error;
rw_swap_page_sync(READ,
swp_entry(root_swap, 0),
- virt_to_page((unsigned long)_header));
- if (!memcmp("SWAP-SPACE",swsusp_header.sig, 10) ||
- !memcmp("SWAPSPACE2",swsusp_header.sig, 10)) {
- memcpy(swsusp_header.orig_sig,swsusp_header.sig, 10);
- memcpy(swsusp_header.sig,SWSUSP_SIG, 10);
- swsusp_header.swsusp_info = prev;
+ virt_to_page((unsigned long)_header));
+ if (!memcmp("SWAP-SPACE",u.swsusp_header.sig, 10) ||
+ !memcmp("SWAPSPACE2",u.swsusp_header.sig, 10)) {
+ memcpy(u.swsusp_header.orig_sig,u.swsusp_header.sig, 10);
+ memcpy(u.swsusp_header.sig,SWSUSP_SIG, 10);
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ memcpy(u.swsusp_header.key, key, MAXKEY);
+ memcpy(u.swsusp_header.iv, iv, MAXIV);
+#endif
+ u.swsusp_header.swsusp_info = prev;
error = rw_swap_page_sync(WRITE,
swp_entry(root_swap, 0),
virt_to_page((unsigned long)
- _header));
+ _header));
} else {
pr_debug("swsusp: Partition is not swap space.\n");
error = -ENODEV;
@@ -294,6 +369,19 @@
int error = 0;
int i;
unsigned int mod = nr_copy_pages / 100;
+#ifdef CONFIG_SWSUSP_ENCRYPT
+ struct crypto_tfm *tfm;
+ struct scatterlist src,
Re: How's the nforce4 support in Linux?
On Apr 6, 2005 1:41 PM, Richard B. Johnson <[EMAIL PROTECTED]> wrote: > > How would you know? Windows will just run it as PIOW and be done > with it. Yes, but there's a way to know which mode you're using (maybe not precisely, but at least PIO vs DMA). > Did you ever try to copy a large file in XP? Try it. > Try the same thing in linux on the same hardware. You don't need > a stop-watch. On Win-XP, a 10 megabyte file (hardly large) takes > about 10 seconds. That's 1 megabyte/second. Linux tries to be > a bit faster. Usually, I only have Linux on any hardware I have ;) And there is no point comparing these things here... -- Julien PS: Sorry Richard, I forgot my "reply to all" button... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ANNOUNCE] git-pasky-0.1
Petr wrote: > That reminds me, is there any > tool which will take .rej files and throw them into the file to create > rcsmerge-like conflicts? Check out 'wiggle' http://www.cse.unsw.edu.au/~neilb/source/wiggle/ -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Mon, Apr 11, 2005 at 01:10:58AM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > > > On Mon, 11 Apr 2005, Petr Baudis wrote: > > > > I currently already do a merge when you track someone's source - it will > > throw away your previous HEAD record though > > Not only that, it doesn't do what I consider a "merge". > > A real merge should have two or more parents. The "commit-tree" command > already allows that: just add any arbitrary number of "-p x" > switches (well, I think I limited it to 16 parents, but that's just a > totally random number, there's nothing in the file format or anything > else that limits it). > > So while you've merged my "data", but you've not actually merged my > revision history in your tree. Well, that's exactly what I was (am) going to do. :-) That's also why I said that I (virtually) throw the local commits away now. Instead, if there were any local commits, I will do git merge: commit-tree $(write-tree) -p $local_head -p $tracked_tree Note that I will need to make this two-phase - first applying the changes, then doing the commit; between those two phases, the user should resolve potential conflicts and check if the merge went right. I think I will name the first phase git merge and the second phase will be just git commit, and I will store the merge information in .dircache/. (BTW, I think the directory name is pretty awful; what about .git/ ?) > And the reason a real merge _has_ to show both parents properly is that > unless you do that, you can never merge sanely another time without > getting lots of clashes from the previous merge. So it's important that a > merge really shows both trees it got data from. > > This is, btw, also the reason I haven't merged with your tree - I want to > get to the point where I really _can_ merge without throwing away the > information. In fact, at this point I'd rather not merge with your tree at > all, because I consider your tree to be "corrupt" thanks to lacking the > merge history. > > So you've done the data merge, but not the history merge. > > And because you didn't do the history merge, there's no way to > automatically find out what point of my tree you merged _with_. See? > > And since I have no way to see what point in time you merged with me, now > I can't generate a nice 3-way diff against the last common ancestor of > both of our trees. > > So now I can't do a three-way merge with you based on any sane ancestor, > unless I start guessing which ancestor of mine you merged with. Now, that > "guess" is easy enough to do with a project like "git" which currently has > just a few tens of commits and effectively only two parallell development > trees, but the whole point is to get to a system where that isn't true.. Well, I've wanted to get the basic things working first before doing git merge. (Especially since until recently, diff-tree was PITA to work with, and before that it didn't even exist.) If you want, I can rebuild my tree with doing the merging properly, after I have git merge working. (BTW, it would be useful to have a tool which just blindly takes what you give it on input and throws it to an object of given type; I will need to construct arbitrary commits during the rebuild if I'm to keep the correct dates.) -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: New SCM and commit list
On Mon, 11 Apr 2005, Benjamin Herrenschmidt wrote: > > Do you intend to continue posting "commited" patches to a mailing list > like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I > find this very useful, especially with the actual patch included in the > commit message (which isn't the case with most other projects CVS commit > lists, and I find that annoying). Absolutely. GIT isn't quite at the point where I can start using it yet, though. I could actually start committing patches, but I want to make sure that I can also do automated simple merges, so that there is any _point_ to doing this in the first place. My plan is to not be very good at merging (in particular, I don't see GIT resolving renames _at_all_), but my hope is that the people who used to merge with me using BK might be able to still do so using GIT, as long as we try actively to be very careful. > If yes, then I would appreciate if you could either keep the same list, > or if you want to change the list name, keep the subscriber list so > those of us who actually archive it don't miss anything ;) I didn't even set up the list. I think it's Bottomley. I'm cc'ing him just so that he sees the message, but I don't actually expect him to do anything about it. I'm not even ready to start _testing_ real merges yet. But I hope that I can get non-conflicting merges done fairly soon, and maybe I can con James or Jeff or somebody to try out GIT then... Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 encrypted swsusp 3/3] documentation
The following patch adds some information for encrypted suspend to the swsusp documentation. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] --- linux-2.6.11.2/Documentation/power/swsusp.txt.ast 2005-04-10 21:07:01.0 +0200 +++ linux-2.6.11.2/Documentation/power/swsusp.txt 2005-04-10 21:10:56.0 +0200 @@ -30,6 +30,13 @@ echo platform > /sys/power/disk; echo disk > /sys/power/state +Encrypted suspend image: + +If you want to store your suspend image encrypted with a temporary +key to prevent data gathering after resume you must compile +crypto and the aes algorithm into the kernel - modules won't work +as they cannot be loaded at resume time. + Article about goals and implementation of Software Suspend for Linux
Re: more git updates..
On Sun, 10 Apr 2005, Christopher Li wrote: > > How about deleting trees from the caches? I don't need to delete stuff from > the official tree. It is more for my local version control. I have a plan. Namely to have a "list-needed" command, which you give one commit, and a flag implying how much "history" you want (*), and then it spits out all the sha1 files it needs for that history. Then you delete all the other ones from your SHA1 archive (easy enough to do efficiently by just sorting the two lists: the list of "needed" files and the list of "available" files). Script that, and call the command "prune-tree" or something like that, and you're all done. (*) The amount of history you want might be "none", which is to say that you don't want to go back in time, so you want _just_ the list of tree and blob objects associated with that commit. Or you might want a "linear" history, which would be the longest path through the parent changesets to the root. Or you might want "all", which would follow all parents and all trees. Or you might want to prune the history tree by date - "give me all history, but cut it off when you hit a parent that was done more than 6 months ago". This "list-needed" thing is not just for pruning history either. If you have a local tree "x", and you want to figure out how much of it you need to send to somebody else who has an older tree "y", then what you'd do is basically "list-needed x" and remove the set of "list-needed y". That gives you the answer to the question "what's the minimum set of sha1 files I need to send to the other guy so that he can re-create my top-of-tree". My second plan is to make somebody else so fired up about the problem that I can just sit back and take patches. That's really what I'm best at. Sitting here, in the (rain) on the patio, drinking a foofy tropical drink, and pressing the "apply" button. Then I take all the credit for my incredible work. Hint, hint. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 encrypted swsusp 2/3] configuration
The following patch includes the necessary kernel configuration option. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] --- linux-2.6.11.2/kernel/power/Kconfig.ast 2005-04-10 20:44:48.0 +0200 +++ linux-2.6.11.2/kernel/power/Kconfig 2005-04-10 21:01:36.0 +0200 @@ -72,3 +72,14 @@ suspended image to. It will simply pick the first available swap device. +config SWSUSP_ENCRYPT + bool "Encrypt suspend image" + depends on SOFTWARE_SUSPEND && CRYPTO=y && (CRYPTO_AES=y || CRYPTO_AES_586=y) + default "" + ---help--- + To prevent data gathering from swap after resume you can encrypt + the suspend image with a temporary key that is deleted on + resume. + + Note that the temporary key is stored unencrypted on disk while the + system is suspended.
Oops in swsusp
Pavel, during testing of the encrypted swsusp_image on x86_64 I did get an Oops from time to time at memcpy+11 called from swsusp_save+1090 which turns out to be the memcpy in copy_data_pages() of swsusp.c. The Oops is caused by a NULL pointer (I don't remember if it was source or destination). This Oops seems to be unrelated to the encrypted image addition as I didn't touch any code in that area. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH encrypted swsusp 0/3] encrypted swsusp image
The following patches allow for encryption of the on-disk swsusp image to prevent data gathering of e.g. in-kernel keys or mlocked data after resume. For this purpose the aes cipher must be compiled into the kernel as module load is not possible at resume time. A random key is generated at suspend time, stored in the suspend header on disk and deleted from the header at resume time. If you don't resume a mkswap on the suspend partition will also delete the temporary key. Only the data pages are encrypted as only these may contain sensitive data. This works on my x86_64 laptop (64bit mode) and probably needs testing on other platforms. -- Andreas Steinmetz SPAMmers use [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Disc driver is module, software suspend fails
On Wed, 30 Mar 2005, Pavel Machek wrote:
> You do not want to mount journaling filesystems; they tend to write to
> disks even during read-only mounts... But doing it from initrd should
> be okay. ext2 and init=/bin/bash should do the trick, too.
I did give it a try -- successfully.
For reference I recite the original issue: the driver for my primary
disc is in the initrd, not hardwired. (It's ata_piix and friends, but
the same issue happens if you boot from RAID or other weird devices. As
modern systems tend to have a SATA disc, more and more people are
complaining on the web that software suspend has stopped working after
they upgraded their machines.) software_suspend would suspend all the
way, then immediately wake up having accomplished nothing (but broken
nothing either). In kernel 2.6.12-rc1 but not 2.6.8 it complains "can't
find swap device". If this safety check is unwisely overriden so a
suspend image is written, and you then resume (providing the device by
number), it fails to read the image using the driver which it hasn't
loaded yet.
This patch makes software_resume not a late_initcall but rather an
external subroutine similar to software_suspend, and calls it at the
beginning of mount_root (in init/do_mounts.c), just _after_ the initrd
(if any) and its driver have been seen. This buried placement is needed
because there are several flow paths that call mount_root, and otherwise
each path would need to be monkeyed with.
The initrd contents at the time of resuming are lost, but the initrd
contents at initial boot, if mounted at that time on /initrd, are still
there.
I have been running with this patch for over a week, with several
suspends per day (and much more than the usual number of reboots, due to
driver debugging). I have had only two system crashes in that time. In
one, I was trying code in ata_piix connected with ATAPI DMA that was
wrong for my kernel version, and it hung in driver initialization before
software_resume was even called. In the other, I was trying the CVS
version of X-Windows, specifically DRI. The rough edges showed clearly,
and I suspect it stored corrupt data somewhere. After reverting to the
production X-Windows I suspended, and I got a null pointer dereference
upon resuming. I suspect (but can't prove) that module reinit would
have failed exactly the same way with the original or patched calls to
software_resume. In other words, I think the patched version is doing
its part of the job perfectly.
So, what do you think? Can we bring the benefit of software suspend to
systems with SATA or RAID boot discs?
James F. Carter Voice 310 825 2897FAX 310 206 6673
UCLA-Mathnet; 6115 MSA; 405 Hilgard Ave.; Los Angeles, CA, USA 90095-1555
Email: [EMAIL PROTECTED] http://www.math.ucla.edu/~jimc (q.v. for PGP key)
Patch relative to 2.6.12-rc1
--- init/do_mounts.c.orig 2005-03-17 17:34:09.0 -0800
+++ init/do_mounts.c2005-04-01 19:29:23.0 -0800
@@ -362,6 +362,16 @@
void __init mount_root(void)
{
+#ifdef CONFIG_SOFTWARE_SUSPEND
+ /*
+* Must resume after initrd has loaded the device for the root filesys,
+* presumed same as the one with the swap partition with the resume
+* image, but before mounting anything, which resuming would smear.
+*/
+ software_resume();
+#endif
#ifdef CONFIG_ROOT_NFS
if (MAJOR(ROOT_DEV) == UNNAMED_MAJOR) {
if (mount_nfs_root())
--- include/linux/suspend.h.orig2005-03-17 17:34:07.0 -0800
+++ include/linux/suspend.h 2005-04-01 19:39:35.0 -0800
@@ -48,6 +48,7 @@
#ifdef CONFIG_PM
/* kernel/power/swsusp.c */
extern int software_suspend(void);
+extern int software_resume(void);
extern int pm_prepare_console(void);
extern void pm_restore_console(void);
@@ -58,6 +59,10 @@
printk("Warning: fake suspend called\n");
return -EPERM;
}
+static inline int software_resume(void)
+{
+ return 0;
+}
#endif
#ifdef CONFIG_SMP
--- kernel/power/disk.c.orig2005-03-26 14:16:25.0 -0800
+++ kernel/power/disk.c 2005-04-01 21:14:01.029535791 -0800
@@ -229,7 +229,7 @@
*
*/
-static int software_resume(void)
+int software_resume(void)
{
int error;
@@ -243,12 +243,15 @@
pr_debug("PM: Checking swsusp image.\n");
- if ((error = swsusp_check()))
+ if ((error = swsusp_check())) {
+ pr_debug("PM: No swsusp image, skipping.\n");
goto Done;
+ }
pr_debug("PM: Preparing processes for restore.\n");
if ((error = prepare_processes())) {
+ pr_debug("PM: Problem preparing processes, not restoring.\n");
swsusp_close();
goto Cleanup;
}
@@ -278,8 +281,6 @@
return 0;
}
-late_initcall(software_resume);
-
static char * pm_disk_modes[] = {
[PM_DISK_FIRMWARE] = "firmware",
-
To unsubscribe from this list: send the line
Re: more git updates..
Useful explanation - thanks, Linus.
Is this picture and description accurate:
==
< working directory files (foo.c) >
^
^|
| upward ops|downward ops |
| --| |
| checkout-cache |update-cache |
| show-diff | v
v
< current directory cache (".dircache/index") >
^
^|
| upward ops|downward ops |
| --| |
| read-tree| write-tree |
||commit-tree |
| v
v
< git filesystem (blobs, trees, commits: .dircache/{HEAD,objects}) >
==
The checkout-cache and show-diff ops read their meta-data from
the cache, and the actual file contents from the git filesystem.
Similary, the update-cache op writes meta-data into the cache,
and may create new files in the git filesystem.
The cache (but not the git filesystem) stores transient
information (ctime, mtime, dev, ino, uid, gid, and size)
about each working file update-cache has copied into the git
filesystem so that checkout-cache and show-diff can detect
changes in the contents of working files just from a stat,
without actually rereading the file.
In some sense, the cache holds the git filesystem inodes,
and the git filesystem holds the data blocks. Except that:
(1) the cache just holds the current "view" into the git
filesystem,
(2) objects in the filesystem have an "inode" number (their
value) that is persistent whether in view or not,
(3) objects in the filesystem are not removed just because
nothing in the cache references them,
(4) objects in the filesystem can reference other objects,
that are typically also in the filesystem, but that can
still be reliably self-identified even if found in the
wild of say one's email inbox, and
(5) the view in the directory cache can itself be made into
a filesystem object - using commit-tree.
==
Minor question:
I must have an old version - I got 'git-0.03', but
it doesn't have 'checkout-cache', and its 'read-tree'
directly writes my working files.
How do I get a current version? Well, one way I see,
and that's to pick up Pasky's:
http://pasky.or.cz/~pasky/dev/git/git-pasky-base.tar.bz2
Perhaps that's the best way?
--
I won't rest till it's the best ...
Programmer, Linux Scalability
Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373,
1.925.600.0401
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
New SCM and commit list
Hi Linus ! Do you intend to continue posting "commited" patches to a mailing list like bk scripts did to [EMAIL PROTECTED] ? As I said a while ago, I find this very useful, especially with the actual patch included in the commit message (which isn't the case with most other projects CVS commit lists, and I find that annoying). If yes, then I would appreciate if you could either keep the same list, or if you want to change the list name, keep the subscriber list so those of us who actually archive it don't miss anything ;) Thanks ! Regards, Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] radeonfb: (#2) Implement proper workarounds for PLL accesses
Benjamin Herrenschmidt a écrit : But it's not specific to X11; I've applied the patch you posted and the same symptoms occur for pure tty switching as well, the delay has decreased a bit (it's hard to measure, but around a second), but it's still rather annoying to work with. Is it distinguishable which M6 models are buggy? I'm using my X31 for about a year now and have probably made some tens of thousands of switches without lockups, so presumably not all models cause lockups. ATI hasn't been very precise about that unfortunately... In case your interested, I tried your last patch (http://lkml.org/lkml/2005/4/7/308) on top of 2.6.12-rc2-mm2 on my Radeon Mobility M6 LY. It works great. Switching was at least one second long with plain mm2. Now it's almost immediat as in Linus' kernel. No more dirty colors during the switch from X to fbcon. Not annoying at all, here. Thanks, Brice - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: [ANNOUNCE] git-pasky-0.1
On Mon, 11 Apr 2005, Petr Baudis wrote: > > I currently already do a merge when you track someone's source - it will > throw away your previous HEAD record though Not only that, it doesn't do what I consider a "merge". A real merge should have two or more parents. The "commit-tree" command already allows that: just add any arbitrary number of "-p x" switches (well, I think I limited it to 16 parents, but that's just a totally random number, there's nothing in the file format or anything else that limits it). So while you've merged my "data", but you've not actually merged my revision history in your tree. And the reason a real merge _has_ to show both parents properly is that unless you do that, you can never merge sanely another time without getting lots of clashes from the previous merge. So it's important that a merge really shows both trees it got data from. This is, btw, also the reason I haven't merged with your tree - I want to get to the point where I really _can_ merge without throwing away the information. In fact, at this point I'd rather not merge with your tree at all, because I consider your tree to be "corrupt" thanks to lacking the merge history. So you've done the data merge, but not the history merge. And because you didn't do the history merge, there's no way to automatically find out what point of my tree you merged _with_. See? And since I have no way to see what point in time you merged with me, now I can't generate a nice 3-way diff against the last common ancestor of both of our trees. So now I can't do a three-way merge with you based on any sane ancestor, unless I start guessing which ancestor of mine you merged with. Now, that "guess" is easy enough to do with a project like "git" which currently has just a few tens of commits and effectively only two parallell development trees, but the whole point is to get to a system where that isn't true.. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
In article <[EMAIL PROTECTED]> you wrote: > (I repeat the xxx in the leaf name - easier to code.) It is a bit OT, but just a note: there are file systems (hash functions) out there who dont like a lot of files named the same way. For example NTFS with the 8.3 short names. Greetings Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
On Sun, Apr 10, 2005 at 03:38:39PM -0700, Linus Torvalds wrote: > > > On Sun, 10 Apr 2005, Christopher Li wrote: > > > > BTW, one thing I learn from ext3 is that it is very useful to have some > > compatible flag for future development. I think if we want to reserve some > > room in the file format for further development of git > > Way ahead of you. > > This is (one reason) why all git objects have the type embedded inside of > them. The format of all objects is totally regular: they are all > compressed with zlib, they are all named by the sha1 file, and they all > start out with a magic header of " ". > > So if I want to create a new kind of tree object that does the same thing > as the old one but has some other layout, I'd just call it something else. > Like "dir". That was what I initially planned to do about the change to > recursive tree objects, but it turned out to actually be a lot easier to > just encode it in the old type (that way the routines that read it don't > even have to care about old/new types - it's all the same to them). Ha, that is right. You put the new type into same object trick me into thinking I have to do the same way. Totally forget I can introduce new type of objects. It is even cleaner. Cool. How about deleting trees from the caches? I don't need to delete stuff from the official tree. It is more for my local version control. Here is the usage case, - I check out the git.git. - using quilt to build my series of patches, git-hack1, git-hack2.. git-hack6. let's say those are store in git cache as well - I pick some of them come up with a clean one "submit.patch" - submit.patch get merged into official git tree. - Now I want to get rid of the hack1 to hack6, but how? One way to do it is never commit hack1 to hack6 into git or cache. They stay as quilt patches only. But it is very tempting to let quilt using git instead of the .pc/ directory, quilt can simplify as some usage case of patch and git. Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Hi! > > Can you try without XFS? > > No, XFS is my root filesystem. :( (Now that I think about it, would > modularizing XFS and using an initrd be OK?) Yes, loading xfs from initrd should help. [At least it did during suse9.3 testing.] > I'll see if I can reproduce this on one of my test boxes. I'll *try* to > get to it later today, but it's possible that I won't be able to get to > it until next Friday or Saturday. > > > I do not why it interferes, but I've seen that before on suse > > kernels... > > Have you seen it without the resume-from-initrd patch too, or only with > that patch? Only with resume-from-initrd. Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
On Sun, Apr 10, 2005 at 11:27:47PM +0200, Pavel Machek wrote: > Can you try without XFS? No, XFS is my root filesystem. :( (Now that I think about it, would modularizing XFS and using an initrd be OK?) I'll see if I can reproduce this on one of my test boxes. I'll *try* to get to it later today, but it's possible that I won't be able to get to it until next Friday or Saturday. > I do not why it interferes, but I've seen that before on suse > kernels... Have you seen it without the resume-from-initrd patch too, or only with that patch? -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
kernel-rcupdatec-make-the-exports-export_symbol_gpl.patch add-deprecated_for_modules.patch add-deprecated_for_modules-fix.patch deprecate-synchronize_kernel-gpl-replacement.patch deprecate-synchronize_kernel-gpl-replacement-fix.patch change-synchronize_kernel-to-_rcu-and-_sched.patch Please drop these patches. Using these symbols in non-GPL modules is a legal problem at least in the USA except for IBM, and all we've heard from IBM is that they are not 100% sure that there is really no binary-only module by IBM that might use these symbols. The risk of anyne using them only increases (no matter that it's marked as deprecated) as long as it's available - and nobody has until now claimed that he's actually using one pf them in a binary-only module. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] radeonfb: (#2) Implement proper workarounds for PLL accesses
> But it's not specific to X11; I've applied the patch you posted and the > same symptoms occur for pure tty switching as well, the delay has decreased > a bit (it's hard to measure, but around a second), but it's still rather > annoying to work with. > > Is it distinguishable which M6 models are buggy? I'm using my X31 for about > a year now and have probably made some tens of thousands of switches without > lockups, so presumably not all models cause lockups. ATI hasn't been very precise about that unfortunately... Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
On Sun, 10 Apr 2005, Christopher Li wrote: > > BTW, one thing I learn from ext3 is that it is very useful to have some > compatible flag for future development. I think if we want to reserve some > room in the file format for further development of git Way ahead of you. This is (one reason) why all git objects have the type embedded inside of them. The format of all objects is totally regular: they are all compressed with zlib, they are all named by the sha1 file, and they all start out with a magic header of " ". So if I want to create a new kind of tree object that does the same thing as the old one but has some other layout, I'd just call it something else. Like "dir". That was what I initially planned to do about the change to recursive tree objects, but it turned out to actually be a lot easier to just encode it in the old type (that way the routines that read it don't even have to care about old/new types - it's all the same to them). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On Thu, Apr 07, 2005 at 02:29:24PM -0400, Daniel Phillips wrote: > On Thursday 07 April 2005 14:13, Dmitry Yusupov wrote: > > On Thu, 2005-04-07 at 13:54 -0400, Daniel Phillips wrote: > > > Three years ago, there was no fully working open source distributed scm > > > code base to use as a starting point, so extending BK would have been the > > > only easy alternative. But since then the situation has changed. There > > > are now several working code bases to provide a good starting point: > > > Monotone, Arch, SVK, Bazaar-ng and others. > > > > Right. For example, SVK is pretty mature project and very close to 1.0 > > release now. And it supports all kind of merges including Cherry-Picking > > Mergeback: > > > > http://svk.elixus.org/?MergeFeatures > > So for an interim way to get the patch flow back online, SVK is ready to try > _now_, and we only need a way to import the version graph? (true/false) Well, I followed some of the instructions to mirror the kernel tree on svn.clkao.org/linux/cvs, and although it took around 12 hours to import 28232 versions, I seem to have a mirror of it on my own subversion server now. I think the svn.clkao.org mirror was taken from bkcvs... the last log message I see is "Rev 28232 - torvalds - 2005-04-04 09:08:33" I have no idea what's missing. What is everyone's favorite web frontend to subversion? I've got websvn (debian package) on there now, and it's a bit sluggish, but it seems to work. I hope to have time this week or next to actually make this machine publicly accessible. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: crash in entry.S restore_all, 2.6.12-rc2, x86, PAGEALLOC
Stas Sergeev <[EMAIL PROTECTED]> wrote: > > - p->thread.esp0 = (unsigned long) (childregs+1); > +p->thread.esp0 = (unsigned long) (childregs+1) - 8; This is utterly obscure - it needs a comment so that readers know what that "- 8" is doing there. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
Dear diary, on Sun, Apr 10, 2005 at 08:42:53PM CEST, I got a letter where Christopher Li <[EMAIL PROTECTED]> told me that... > I totally agree that odds is really really small. > That is why it is not worthy to handle the case. People hit that > can just add a new line or some thing to avoid it, if > it happen after all. > > It is the little peace of mind to know for sure that did > not happen. I am just paranoid. BTW, I've merged the check to git-pasky some time ago, you can disable it in the Makefile. It is by default on now, until someone convinces me it actually affects performance measurably. -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 10:38:11PM CEST, I got a letter where Linus Torvalds <[EMAIL PROTECTED]> told me that... > On Sun, 10 Apr 2005, Petr Baudis wrote: > > > > It turns out to be the forks for doing all the cuts and such what is > > bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about > > 15 forks per change, I guess, and for some reason cut takes a long of > > time on its own. > > Heh. > > Can you pull my current repo, which has "diff-tree -R" that does what the > name suggests, and which should be faster than the 0.48 sec you see.. Funnily enough, now after some more cache teasing it's ~0.185. Your one still ~0.17, though. :/ (That might be because of the format changes, though, since you do less printing now.) (BTW, all those measurements are done on my AMD K6 walking on 1600MHz, 512M RAM, about 200M available for caches.) Just out of interest, did you have a look at my diff-tree -r implementation and decided that you don't like it, or you weren't aware of it? I will probably take most of your diff-tree change, but I'd prefer to do the sha1->tree mapping directly in diff_tree(). > It may not matter a lot, since actually generating the diff from the file > contents is what is expensive, but remember my goal: I want the expense of > a diff-tree to be relative to the size of the diff, so that implies that > small diffs haev to be basically instantaenous. So I care. Me too, of course. > So I just tried the 2.6.7->2.6.8 diff, and for me the new recursive > "diff-tree" can generate the _list_ of files changed in zero time: > > real0m0.079s > user0m0.067s > sys 0m0.024s > > but then _doing_ the diff is pretty expensive (in this case 3800+ files > changed, so you have to unpack 7600+ objects - and even unpacking isn't > the expensive part, the expense is literally in the diff operation > itself). > > Me, the stuff I automate is the small steps. Doing a single checkin. So > that's the case I care about going fast, when a "diff-tree" will likely > have maybe five files or something. That's why I want the small > incremental cases to go fast - it it takes me a minute to generate a diff > for a _release_, that's not a big deal. I make one release every other > month, but I work with lots of small patches all the time. I see. > Anyway, with a fast diff-tree, you should be able to generate the list of > objects for a fast "merge". That's next. > > (And by "merge", I of course mean "suck". I'm talking about the old CVS > three-way merge, and you have to specify the common parent explicitly and > it won't handle any renames or any other crud. But it would get us to > something that might actually be useful for simple things. Which is why > "diff-tree" is important - it gives the information about what to tell > merge). I currently already do a merge when you track someone's source - it will throw away your previous HEAD record though, so if you committed some local changes after the previous pull, you will get orphaned commits and the changes will turn to uncommitted ones. I have some ideas regarding how to do it properly (and do any arbitrary merging, for that matter), I hope to get to it as soon as I catch up with you. :-) BTW, the three-way merge comes from RCS. That reminds me, is there any tool which will take .rej files and throw them into the file to create rcsmerge-like conflicts? Perhaps it's fault of my bad tools, but I prefer to work with the inline rejects much more to .rej files (except to actually notice the rejects). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
On Sun, Apr 10, 2005 at 01:57:33PM -0700, Linus Torvalds wrote: > > > That way of thinking really doesn't work well here. > > > > I will have to look more closely at pasky's GIT toolkit > > if I want to see an SCM style interface. > > Yes. You really should think of GIT as a filesystem, and of me as a > _systems_ person, not an SCM person. In fact, I tend to detest SCM's. I > think the reason I worked so well with BitKeeper is that Larry used to do > operating systems. He's also a systems person, not really an SCM person. > Or at least he's in between the two. > Yes, I am puzzled for a while how to use git until I realize that it is a version file system. BTW, one thing I learn from ext3 is that it is very useful to have some compatible flag for future development. I think if we want to reserve some room in the file format for further development of git, it is the right time to do it before it get bigs. e.g. an optional variable size header in "tree" including format version and capability etc. I can see the counter argument that it is not as important as a real file system because it is a lot easier bring it off line to upgrade the whole tree. One the other hand, it is almost did not cost any thing in terms of space and CPU time, most directory did not get to file system block boundary so extra few bytes is almost free. If carefully planed, it will make the future up grade of git a lot smoother. What do you think? Chris - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
Dear diary, on Mon, Apr 11, 2005 at 12:07:37AM CEST, I got a letter where "Luck, Tony" <[EMAIL PROTECTED]> told me that... ..snip.. > >Hey, I may end up being wrong, and yes, maybe I should have done a > >two-level one. The good news is that we can trivially fix it later (even > >dynamically - we can make the "sha1 object tree layout" be a per-tree > >config option, and there would be no real issue, so you could make small > >projects use a flat version and big projects use a very deep structure > >etc). You'd just have to script some renames to move the files around. > > It depends on how many eco-system shell scripts get built that need to > know about the layout ... if some shell/perl "libraries" encode this > filename layout (and people use them) ... then switching later would > indeed be painless. FWIW, my short-term plans include support for monotone-like hash ID shortening - it's enough to use the shortest leading unique part of the ID to identify the revision. I will poke to the object repository for that. I also already have Randy Dunlap's git lsobj, which will list all objects of a specified type (very useful especially when looking for orphaned commits and such rather lowlevel work). -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
>Also, I did actually debate that issue with myself, and decided that even >if we do have tons of files per directory, git doesn't much care. The >reason? Git never _searches_ for them. Assuming you have enough memory to >cache the tree, you just end up doing a "lookup", and inside the kernel >that's done using an efficient hash, which doesn't actually care _at_all_ >about how many files there are per directory. So long as the hash *is* efficient when the directory is packed full of 38 character filenames made only of [0-9a-f] ... which might not match the test cases under which the hash was picked :-) When there are some full-sized kernel git images, someone should do a sanity check. >Hey, I may end up being wrong, and yes, maybe I should have done a >two-level one. The good news is that we can trivially fix it later (even >dynamically - we can make the "sha1 object tree layout" be a per-tree >config option, and there would be no real issue, so you could make small >projects use a flat version and big projects use a very deep structure >etc). You'd just have to script some renames to move the files around. It depends on how many eco-system shell scripts get built that need to know about the layout ... if some shell/perl "libraries" encode this filename layout (and people use them) ... then switching later would indeed be painless. -Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: more git updates..
I totally agree that odds is really really small. That is why it is not worthy to handle the case. People hit that can just add a new line or some thing to avoid it, if it happen after all. It is the little peace of mind to know for sure that did not happen. I am just paranoid. Chris On Sun, Apr 10, 2005 at 12:23:52PM -0700, Paul Jackson wrote: > > Some thing like the following patch, may be turn off able. > > Take out an old envelope and compute on it the odds of this > happening. > > Say we have 10,000 kernel hackers, each producing one > new file every minute, for 100 hours a week. And we've > cloned a small army of Andrew Morton's to integrate > the resulting tsunamai of patches. And Linus is well > cared for in the state funny farm. > > What is the probability that this check will fire even > once, between now and 10 billion years from now, when > the Sun has become a red giant destroying all life on > planet Earth? > > -- > I won't rest till it's the best ... > Programmer, Linux Scalability > Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, > 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11.x: bootprompt: ALSA: no soundcard detected
Aehhm, you are completely on the wrong track! I installed 2.6.11.7 the same way I installed 2.6.11, with sound support statically included, but, though it worked fine without ACPI under 2.6.11, the same configuration under 2.6.11.7 does not work. There was no change in practise, only a change in behaviour. Dennis That means you didn't load the correct module for your soundcard. On Sun, 10 Apr 2005 10:16:49 +, Dennis Heuer <[EMAIL PROTECTED]> wrote: > This doesn't help. Alsamixer prints: > > failure in snd_ctl_open: no such device > > Dennis -- Time is what you make of it - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.1
On Sun, 10 Apr 2005, Linus Torvalds wrote: > > Can you pull my current repo, which has "diff-tree -R" that does what the > name suggests, and which should be faster than the 0.48 sec you see.. Actually, I changed things around. Everybody hated the "<" ">" lines, so I put a changed thing on a line of its own with a "*" instead. So you'd now see lines like *100644->100644 1874e031abf6631ea51cf6177b82a1e662f6183e->e8181df8499f165cacc6a0d8783be7143013d410 CREDITS which means that the CREDITS file has changed, and it shows you the mode -> mode transition (that didn't change in this case) and the sha1 -> sha1 transition. So now it's always just one line per change. Firthermore, the filename is always field 3, if you use spaces as delimeters, regardless of whether it's a +/-/* field. So let's say you want to merge two trees (dst1 and dst2) from a common parent (src), what you would do is: - get the list of files to merge: diff-tree -R | tr '\0' '\n' > merge-files - Which of those were changed by -> ? diff-tree -R | tr '\0' '\n' | join -j 3 - merge-files > dst1-change diff-tree -R | tr '\0' '\n' | join -j 3 - merge-files > dst2-change - Which of those are common to both? Let's see what the merge list is: join dst1-change dst2-change > merge-list and hopefully you'd usually be working on a very small list of files by then (everything else you'd just pick from one of the destination trees directly - you've got the name, the sha-file, everything: no need to even look at the data). Does this sound sane? Pasky? Wanna try a "git merge" thing? Starting off with the user having to tell what the common parent tree is - we can try to do the "automatically find best common parent" crud later. THAT may be expensive. (Btw, this is why I think "diff-tree" is more important than actually generating the real diff itself - the above uses diff-tree three times just to cut down to the point where _hopefully_ you don't actually need to generate very much diffs at all. So I want "diff-tree" to be really fast, even if it then can take a minute to actually generate a big diff between releases etc). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Status of new kernel.org servers
On 04.10, H. Peter Anvin wrote: > Andre Tomt wrote: > > H. Peter Anvin wrote: > > > >> For those of you that are interested... > > > > > > > > I kind of sort of miss the load and bandwidth statistics on the > > kernel.org front page. Did they just go boring now with sufficient > > hardware resources? :-) > > No; the issue there is that with multiple servers we have to change the > way they're generated and distributed. Nathan Laredo is working on > that, but it's so obviously not a high priority item. > How about a ganglia stats page ? -- J.A. Magallon \ Software is like sex: werewolf!able!es \ It's better when it's free Mandrakelinux release 10.2 (Limited Edition 2005) for i586 Linux 2.6.11-jam12 (gcc 3.4.3 (Mandrakelinux 10.2 3.4.3-7mdk)) #1 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
Hi! > (Sorry I took so long to respond. I was busy with tons of stuff > offline...) > > On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: > > Do you have XFS compiled in, by chance? > > Yes. Can you try without XFS? I do not why it interferes, but I've seen that before on suse kernels... Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Re: [ANNOUNCE] git-pasky-0.1
Dear diary, on Sun, Apr 10, 2005 at 09:13:19PM CEST, I got a letter where Willy Tarreau <[EMAIL PROTECTED]> told me that... > On Sun, Apr 10, 2005 at 08:45:22PM +0200, Petr Baudis wrote: > > > It turns out to be the forks for doing all the cuts and such what is > > bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about > > 15 forks per change, I guess, and for some reason cut takes a long of > > time on its own. > > > > I've rewritten the cuts with the use of bash arrays and other smart > > stuff. I somehow don't feel comfortable using this and prefer the > > old-fashioned ways, but it would be plain unusable without this. > > I've encountered the same problem in a config-generation script a while > ago. Fortunately, bash provides enough ways to remove most of the forks, > but the result is less portable. > > I've downloaded your code, but it does not compile here because of the > tv_nsec fields in struct stat (2.4, glibc 2.2), so I cannot use it to > get the most up to date version to take a look at the script. Basically, Ok, I decided to stop this nsec madness (since it broke show-diff anyway at least on my ext3), and you get it only if you pass -DNSEC to CFLAGS now. Hope this fixes things for you. :-) BTW, I regularly update the public copy as accessible on the web. > all the 'cut' and 'sed' can be removed, as well as the 'dirname'. You > can also call mkdir only if the dirs don't exist. I really think you > should end up with only one fork in the loop to call 'diff'. You still need to extract the file by cat-file too. ;-) And rm the files after it compares them (so that we don't fill /tmp with crap like certain awful programs like to do). But I will conditionalize the mkdir calls, thanks for the suggestion - I think that's the last bit to be squeezed from this loop (I'll yet check on the read proposal - I considered it before and turned down for some reason, can't remember why anymore, though). Thanks, -- Petr "Pasky" Baudis Stuff: http://pasky.or.cz/ 98% of the time I am right. Why worry about the other 3%. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm1
(Sorry I took so long to respond. I was busy with tons of stuff offline...) On Fri, Apr 08, 2005 at 12:33:27PM +0200, Pavel Machek wrote: > Do you have XFS compiled in, by chance? Yes. > You are not actually resuming from initrd, right? That is correct. -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] re-export cancel_rearming_delayed_workqueue
On Sun, 2005-04-10 at 21:48 +0200, Arjan van de Ven wrote: > I have absolutely no problem with such an export / unstatic if there are > users... could you just send them in one go ? Actually, no ... this is a nasty cross tree dependency. The piece of code is queued in the parisc tree, but Matthew can't really send it to Linus until the interface it uses is in the tree. It's someone else's code, I just fixed its problems. James - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ds1337 4/4
Hi Ladislav, > Driver has no chance to know about hardware design. If you want the driver to somehow interact with the battery charging register, it will have to. We just can't let the user write random value to this register. > Based on your and Jean's input, following so far sounds reasonable: > Create "charge" sysfs entry for ds1339 when it is detected. Do not > write any value to Trickle Charge register, until its value is written > to this entry. While I admit I had this in mind in the first place, the more I think of it and the less I like it. It's slightly better than changing the charging rate right when loading the driver, but that's still dangerous. Users could write a value which doesn't match the hardware design, and bad things could happen. > Agree, but with probability near the certainty I can tell that device > works a bit differently than described in datasheet. Anyway, new 100% > reliable test is done, so it could be eventually used if ds1339 > support finds its way into driver. "100% realiable" here means that it works for you, which isn't enough. At least James would have to check how it works with his DS1337, and there might be other revisions of both chips which behave differently. There might be other mostly-compatible chips in the game too. > > > Eh? Register is 8bit, that's 256 combinations. > > > > Reserved bits have fixed values that you can test for. > > Think about this register as about NVRAM address. It can have any > value, but only certain values will enable charge. Most of which nobody has any interest in writing. Some I2C devices are hard to detect and the DS1337/DS1339 are of these. We use the tricks we find. Sure, a strict check on this register might miss a DS1339, but that's better than detecting a different chip as a DS1339. > How are you using this driver? There is non-static function > ds1337_do_command which expects id. How do you know which id belongs > to which chip? I second this question, as it stroke me too. This function doesn't sound exactly usable to me. Identifying the device by bus and address would make more sense than an arbitrary id you have no way to learn about. > Do you actually have machine with more than one ds1337? > Chip has fixed address, so only one can hang on one bus (am I right?) You are. > PS. I'm sorry about some formulations I used in earlier mails. I was > overworked and tired and that affected my otherwise (hopefully) good > decorum :) I'm really happy to read this :) You are of course forgiven. We all have bad days. Back to the issue, some random thoughts summarizing my opinion: 1* Initializing the battery charge register is a firmware/bios issue, as you underlined earlier. It would make sense (and would be easier) to just ignore it at the driver level. 2* If it makes sense to stop the charge, then we should provide a simple *switch* to the user, from the default charging register value (as previously set by the firmware/bios) to 0 and back. The switch would probably be a sysfs file unless a different API already exists. 3* Having the driver write an arbitrary non-0 value to the register should not be done unless the system has been identified. I have no idea how your system can be identified (DMI?), but if it can't, then I'd better see the register ignored altogether. 4* Remember that you can always write a simple C tool relying on the i2c-dev interface to do the job. The advantage of this approach is that you can put big fat warnings and request user confirmation before any action. Hope that helps, -- Jean Delvare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: more git updates..
On Sun, 10 Apr 2005, Paul Jackson wrote: > > Ah ha - that explains the read-tree and write-tree names. > > The read-tree pulls stuff out of this file system into > your working files, clobbering local edits. This is like > the read(2) system call, which clobbers stuff in your > read buffer. Yes. Except it's a two-stage thing, where the staging area is always the "current directory cache". So a "read-tree" always reads the tree information into the directory cache, but does not actually _update_ any of the files it "caches". To do that, you need to do a "checkout-cache" phase. Similarly, "write-tree" writes the current directory cache contents into a set of tree files. But in order to have that match what is actually in your directory right now, you need to have done a "update-cache" phase before you did the "write-tree". So there is always a staging area between the "real contents" and the "written tree". > That way of thinking really doesn't work well here. > > I will have to look more closely at pasky's GIT toolkit > if I want to see an SCM style interface. Yes. You really should think of GIT as a filesystem, and of me as a _systems_ person, not an SCM person. In fact, I tend to detest SCM's. I think the reason I worked so well with BitKeeper is that Larry used to do operating systems. He's also a systems person, not really an SCM person. Or at least he's in between the two. My operations are like the "system calls". Useless on their own: they're not real applications, they're just how you read and write files in this really strange filesystem. You need to wrap them up to make them do anything sane. For example, take "commit-tree" - it really just says that "this is the new tree, and these other trees were its parents". It doesn't do any of the actual work to _get_ those trees written. So to actually do the high-level operation of a real commit, you need to first update the current directory cache to match what you want to commit (the "update-cache" phase). Then, when your directory cache matches what you want to commit (which is NOT necessarily the same thing as your actual current working area - if you don't want to commit some of the changes you have in your tree, you should avoid updating the cache with those changes), you do stage 2, ie "write-tree". That writes a tree node that describes what you want to commit. Only THEN, as phase three, do you do the "commit-tree". Now you give it the tree you want to commit (remember - that may not even match your current directory contents), and the history of how you got here (ie you tell commit what the previous commit(s) were), and the changelog. So a "commit" in SCM-speak is actually three totally separate phases in my filesystem thing, and each of the phases (except for the last "commit-tree" which is the thing that brings it all together) is actually in turn many smaller parts (ie "update-cache" may have been called hundreds of times, and "write-tree" will write several tree objects that point to each other). Similarly, a "checkout" really is about first finding the tree ID you want to check out, and then bringing it into the "directory cache" by doing a "read-tree" on it. You can then actually update the directory cache further: you might "read-tree" _another_ project, or you could decide that you want to keep one of the files you already had. So in that scneario, after doing the read-tree you'd do an "update-cache" on the file you want to keep in your current directory structure, which updates your directory cache to be a _mix_ of the original tree you now want to check out _and_ of the file you want to use from your current directory. Then doing a "checkout-cache -a" will actually do the actual checkout, and only at that point does your working directory really get changed. Btw, you don't even have to have any working directory files at all. Let's say that you have two independent trees, and you want to create a new commit that is the join of those two trees (where one of the trees take precedence). You'd do a "read-tree ", which will create a directory cache (but not check out) that is the union of the and trees ( will overrride). And then you can do a "write-tree" and commit the resulting tree - without ever having _any_ of those files checked out. Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [ANNOUNCE] git-pasky-0.1
Good lord - you don't need to use arrays for this. The old-fashioned ways have their ways. Both the 'set' command and the 'read' command can split args and assign to distinct variable names. Try something like the following: diff-tree -r $id1 $id2 | sed -e '/^/ / }' -e 's/./& /' | while read op mode1 sha1 name1 mode2 sha2 name2 do ... various common stuff ... case "$op" in "+") ... ;; "-") ... ;; "<") test $name1 = $name2 || die mismatched names label1=$(mkbanner "$loc1" $id1 "$name1" $mode1 $sha1) label2=$(mkbanner "$loc2" $id2 "$name1" $mode2 $sha2) diff -L "$label1" -L "$label2" -u "$loc1" "$loc2" ;; esac done -- I won't rest till it's the best ... Programmer, Linux Scalability Paul Jackson <[EMAIL PROTECTED]> 1.650.933.1373, 1.925.600.0401 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Re: [ANNOUNCE] git-pasky-0.1
On Sun, 10 Apr 2005, Petr Baudis wrote: > > It turns out to be the forks for doing all the cuts and such what is > bogging it down so awfully (doing diff-tree takes 0.48s ;-). I do about > 15 forks per change, I guess, and for some reason cut takes a long of > time on its own. Heh. Can you pull my current repo, which has "diff-tree -R" that does what the name suggests, and which should be faster than the 0.48 sec you see.. It may not matter a lot, since actually generating the diff from the file contents is what is expensive, but remember my goal: I want the expense of a diff-tree to be relative to the size of the diff, so that implies that small diffs haev to be basically instantaenous. So I care. So I just tried the 2.6.7->2.6.8 diff, and for me the new recursive "diff-tree" can generate the _list_ of files changed in zero time: real0m0.079s user0m0.067s sys 0m0.024s but then _doing_ the diff is pretty expensive (in this case 3800+ files changed, so you have to unpack 7600+ objects - and even unpacking isn't the expensive part, the expense is literally in the diff operation itself). Me, the stuff I automate is the small steps. Doing a single checkin. So that's the case I care about going fast, when a "diff-tree" will likely have maybe five files or something. That's why I want the small incremental cases to go fast - it it takes me a minute to generate a diff for a _release_, that's not a big deal. I make one release every other month, but I work with lots of small patches all the time. Anyway, with a fast diff-tree, you should be able to generate the list of objects for a fast "merge". That's next. (And by "merge", I of course mean "suck". I'm talking about the old CVS three-way merge, and you have to specify the common parent explicitly and it won't handle any renames or any other crud. But it would get us to something that might actually be useful for simple things. Which is why "diff-tree" is important - it gives the information about what to tell merge). Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] arch/i386/kernel/cpu/mtrr/generic.c: make generic_get_mtrr static
This patch makes a needlessly global function static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
This patch was already sent on:
- 27 Mar 2005
- 20 Mar 2005
--- linux-2.6.11-mm4-full/arch/i386/kernel/cpu/mtrr/generic.c.old
2005-03-20 19:43:46.0 +0100
+++ linux-2.6.11-mm4-full/arch/i386/kernel/cpu/mtrr/generic.c 2005-03-20
19:44:11.0 +0100
@@ -114,8 +114,8 @@
return -ENOSPC;
}
-void generic_get_mtrr(unsigned int reg, unsigned long *base,
- unsigned int *size, mtrr_type * type)
+static void generic_get_mtrr(unsigned int reg, unsigned long *base,
+unsigned int *size, mtrr_type * type)
{
unsigned int mask_lo, mask_hi, base_lo, base_hi;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: formatting CD-RW locks the system
On Sunday 10 Apr 2005 19:29, you wrote: > Hello. > > I am trying to format the CD-RW disc > on my NEC ND-3520A DVD writer, and the > results are completely unexpected: I do > cdrwtool -d /dev/cdrom -q > It proceeds with the formatting, but > while it does so, the system is pretty > much dead. It can do some trivial tasks > like the console switching, but as soon > as it comes to any disc I/O, the processes > are hanging. After the formatting is done, > the system is back alive. That reminds me > formatting the floppies under DOS in those > ancient times, with the only difference > that formatting a floppy takes ~2 minutes, > while formatting a CD-RW takes ~20 minutes, > which is not good at all. > Is this something known or a bug? > I tried that on a 2.6.11-rc3-mm2 and > on a 2.6.12-rc1 kernels. > > Also, is there any way to use the > packet writing with the CD-R/DVD-R discs, > or is it supposed to work only with the > -RW discs? You probably don't have DMA enabled on the drive. Please check this. CDRW formatting works fine here with cdrecord blank=all -- Cheers, Alistair. personal: alistair()devzero!co!uk university: s0348365()sms!ed!ac!uk student:CS/CSim Undergraduate contact:1F2 55 South Clerk Street, Edinburgh. EH8 9PP. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> On Sat, Apr 09, 2005 at 08:07:03PM -0700, David Schwartz wrote: > > The way you stop someone from distributing part of your > > work is by arguing > > that the work they are distributing is a derivative work of > > your work and > > they had no right to *make* it in the first place. See, for > > example, Mulcahy > > v. Cheetah Learning. > Er, that's one way, but not *the* way. I could grant you permission to > create derivatives of my work, but not to redistribute them. To stop you > from distributing them, I'd argue that you had no right to distribute > them--you *did* have the right to make it in the first place. You could do that be means of a contract, but I don't think you could it do by means of a copyright license. The problem is that there is no right to control the distribution of derivative works for you to withhold from me. > The GPL does this. Note GPL #2b: "any work that you distribute > or publish". > If you don't distribute or publish the derivative work, the work does not > need to be "licensed ... under the terms of this License." It > very carefully > separates the permissions granted for merely creating a derivative work, > and the permissions granted for distributing those works; if you > distribute > a linked binary in violation of the GPL, you may very well have > had permission > to make it in the first place. Yes, but this would be valid if and only if there was a right to restrict the distribution of derivative works that was recognized under copyright law. I can find no record of the existence of such a right. > (Of course, if whether the work is a derivative is in question, that would > need to be established--you would, indeed, need to argue that the > work they > are distributing is a derivative work--but you wouldn't > necessarily further > argue that they had no right to make it in the first place.) Well that's the problem. While copyright law does permit you to restrict the right to create derivative works, it doesn't permit you to restrict the distribution of lawfully created derivative works to licensees of the original work. As far as I know, no law has ever granted this right to copyright holders and no court has ever recognized this right. And I've looked. Courts have specifically recognized the absence of this right. DS - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
uitverkoop horloges
Wij hebben geheel nieuw in ons aanbod edel horloges opgenomen. Wij hebben bijna alle fantastische modelle voor u, die u zich maar wensen kunt. Alles van Bulgari, Cartier tot Chopard en Omega en Gucci uurwerken is te verkrijgen. Gesorteerd naar mannen en vrouwen uurwerken, of als geschenkbox is er ook voor u de juist. Wat is beter als geschenk dan een uurwerk dat lang mee gaat? Het is niet alleen een teken van goede smaak, maar ook een geheel persoonlijk geschenk voor uw geliefde. Direct naar de uurwerken hier. http://d.tmcnsqp.com/?3RBB58A7ZDGby3zhorp Veel winkelplezier gewenst door uw uurwerk team. Uw Albert Schmitz - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] zero disk pages used by swsusp on resume
Hi! > > Oliver Neukum wrote: > > > What is the point in doing so after they've rested on the disk for ages? > > > > The point is not physical access to the disk but data gathering after > > resume or reboot. > > After resume or reboot normal access control mechanisms will work > again. Those who can read a swap partition under normal circumstances > can also read /dev/kmem. It seems to me like you are putting an extra > lock on a window on the third floor while leaving the front door open. Andreas is right, his patches are needed. Currently, if your laptop is stolen after resume, they can still data in swsusp image. Zeroing the swsusp pages helps a lot here, because at least they are not getting swsusp image data without heavy tools. [Or think root compromise month after you used swsusp.] Encrypting swsusp image is of course even better, because you don't have to write large ammounts of zeros to your disks during resume ;-). Pavel -- Boycott Kodak -- for their patent abuse against Java. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Problem with dual pentium on hx-board and kernel 2.4.x
hello, i have problems with the new kernel on my old systems. with kernel 2.2.x it works fine, with kernel 2.4.x (last testet 2.4.29), the system hangs after some time (some minutes to some hours). on new p3-systems (also dual-systems) i don't have this problem. can you give me some help to solve this problem or i can't update this systems to newer kernel. goodby Schau auch einmal auf meine Homepage (http://go.to/dieter-ferdinand). Dort findest du Information zu Linux, Novell, Win95, WinNT, ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] zero disk pages used by swsusp on resume
Am Sonntag, 10. April 2005 21:29 schrieb Andreas Steinmetz: > Oliver Neukum wrote: > > What is the point in doing so after they've rested on the disk for ages? > > The point is not physical access to the disk but data gathering after > resume or reboot. After resume or reboot normal access control mechanisms will work again. Those who can read a swap partition under normal circumstances can also read /dev/kmem. It seems to me like you are putting an extra lock on a window on the third floor while leaving the front door open. Regards Oliver - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] git-pasky-0.1
On Sun, April 10, 2005 12:55 pm, Linus Torvalds said: > Larry was ok with the idea to make my export format actually be natively > supported by BK (ie the same way you have "bk export -tpatch"), but > Tridge wanted to instead get at the native data and be difficult about > it. As a result, I can now not only use BK any more, but we also don't > have a nice export format from BK. > > Yeah, I'm a bit bitter about it. > Linus, With all due respect, Larry could have dealt with this years ago and removed the motivation for Tridge and others to pursue reverse engineering. Instead he chose to insult and question the motives of everyone that wanted open-source access to the Linux history data. The blame for the current situation falls firmly on the choice to use a closed-source SCM for Linux and the actions of the company that owned it. Sean - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] ds1337 4/4
On Fri, Apr 08, 2005 at 06:44:53PM +0100, James Chapman wrote: > > The only reason I can think > >about is when suspending device, so it is likely pm job. /sys entry > >might help as well, but I do not see any point making driver more > >complicated and bigger just to make someone else happy. > > Why not add a new /sys entry for it? Is there a generic battery charge > control /sys API? I do not know about any and I do not think it would be usefull here. How would you convert value passed by API into register value? Driver has no chance to know about hardware design. > >Golden rule is: implement features as needed :) > > But when adding code, try to cover all reasonable cases, otherwise we'll > see patches from people trying to add platform specific ifdefs in here. I'd like to, but simply do not have enough informations to do it. In other worlds I still do not know what is reasonable here. > >>Also, arbitrarily picking one of the 6 possible charging modes just > >>because it matches your board is a bad idea. It looks like a value which > >>should be set on a per-board basis, rather than picked randomly by the > >>user, so as to avoid accidental hardware breakage. > > > > > >Well free to provide that way, so far I'm the only user so I did what is > >usefull for me [*]. Everyone is welcome to change it to more generic > >way. > > I agree with Jean. You should provide an API for this. Don't take > shortcuts just because you were the first to support the chip. It'll be > more useful to others if you provide a way to set a value per platform. That's not about taking any shortcuts, that's about finding sane API. When time shows it wrong and it will need change people will complain about compatibility. See my questions about API bellow [*]. Based on your and Jean's input, following so far sounds reasonable: Create "charge" sysfs entry for ds1339 when it is detected. Do not write any value to Trickle Charge register, until its value is written to this entry. > >I was running test overnight and didn't meet any single case when this > >happen. Perhaps device also needs to see start condition? > > Just because it runs overnight doesn't mean there's no bug. Agree, but with probability near the certainty I can tell that device works a bit differently than described in datasheet. Anyway, new 100% reliable test is done, so it could be eventually used if ds1339 support finds its way into driver. > >>Also, 0x00 is a possible value for both the seconds count and the battery > >>register, so you could miss a DS1339 at times. > >> > >>One possible check to start with would be on the value of the additional > >>register itself. It has only 7 possible values. (...) > > > > > >Eh? Register is 8bit, that's 256 combinations. > > Reserved bits have fixed values that you can test for. Think about this register as about NVRAM address. It can have any value, but only certain values will enable charge. [*] Now lets forget ds1339, there are few things I'd like to know about this driver. How are you using this driver? There is non-static function ds1337_do_command which expects id. How do you know which id belongs to which chip? Do you actually have machine with more than one ds1337? Chip has fixed address, so only one can hang on one bus (am I right?) Also it is unlikely that machine will have more that one RTC. The only exception which comes on mind are NUMA systems which have one RTC per node. Anything else? Why date format returned/expected by this driver differs from other drivers? Thanks in advance, ladis PS. I'm sorry about some formulations I used in earlier mails. I was overworked and tired and that affected my otherwise (hopefully) good decorum :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] re-export cancel_rearming_delayed_workqueue
On Sun, 2005-04-10 at 14:07 -0500, James Bottomley wrote: > This was unexported by Arjan because we have no current users. > > However, during a conversion from tasklets to workqueues of the parisc > led functions, we ran across a case where this was needed. In > particular, the open coded equivalent of > cancel_rearming_delayed_workqueue was implemented incorrectly, which is, > I think, all the evidence necessary that this is a useful API. I have absolutely no problem with such an export / unstatic if there are users... could you just send them in one go ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
