where the agpcard driver creats its device
Hi, Can anybody tell me where the agpdrivers for the corresponding cards creats its device (ie like hard disks and floppy disks devices r there is /dev likewise) in 2.6 kernel. also where the framebuffer device located in 2.6 kernels, also can we opne it and send ioctls to read or write. 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: easy softball jiffies quest(ion)
On Sat, 9 Apr 2005, philip dahlquist wrote:
> hi,
Hello,
> 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.
Now, I might be _entirely_ off-base here, but... from what I know (which
is, admittedly, less than what many others here do) jiffies are a
kernel-land concept, implemented using a kernel-land variable. The
kernel protects itself from user-land programs, so your user-land
program will never be able to access the jiffies variable directly like
that.
As far as I know, it breaks down like this: If you want jiffies, then
your code should be a kernel module. If you want your code to run in
user-land, then you have to settle for knowing the time using alarm(),
clock_gettime(), gettimeofday(), or similar system-call-based mechanism.
> this is it:
> --
> #include
> #include
> #include
> #include
>
> #include
> #include
> #include
> #include
> #include
> #include
> #include
>
> #include
>
>
> int main(void)
> {
> unsigned long j = jiffies + (50 * HZ);
> printf("start jiffies = %9li\n",jiffies);
> while(jiffies < j)
> ;
>
> printf("done jiffies = %9li\n", jiffies);
> return 0;
> }
>
> ---
> all right, you can giggle, but no laughing out loud, my kernel ego is
> nacent and fragile.
>
> when i compile it with:
>
> gcc -o jfi.x jfi.c
>
> i get a handful of errors regarding various #include statements:
> -
> jfi.c:3:31: linux/moduleparam.h: No such file or directory
> In file included from jfi.c:6:
> /usr/include/linux/time.h:10: error: syntax error before "time_t"
> /usr/include/linux/time.h:12: error: syntax error before '}' token
> /usr/include/linux/time.h:18: error: syntax error before "time_t"
> /usr/include/linux/time.h:44: error: field `it_interval' has incomplete type
> /usr/include/linux/time.h:45: error: field `it_value' has incomplete type
> /usr/include/linux/time.h:49: error: field `it_interval' has incomplete type
> /usr/include/linux/time.h:50: error: field `it_value' has incomplete type
> jfi.c:7:25: linux/timer.h: No such file or directory
> In file included from /usr/include/linux/interrupt.h:9,
> from jfi.c:12:
> /usr/include/asm/bitops.h:327:2: warning: #warning This include file is
> not available on all architectures.
> /usr/include/asm/bitops.h:328:2: warning: #warning Using kernel headers
> in userspace: atomicity not guaranteed
> In file included from jfi.c:12:
> /usr/include/linux/interrupt.h:12:25: asm/hardirq.h: No such file or directory
> /usr/include/linux/interrupt.h:13:25: asm/softirq.h: No such file or directory
>
> jfi.c: In function `main':
> jfi.c:19: error: `jiffies' undeclared (first use in this function)
> jfi.c:19: error: (Each undeclared identifier is reported only once
> jfi.c:19: error: for each function it appears in.)
> ./jfsh: line 8: jfi.x: command not found
> -
All the above errors come from the fact that you're trying to use
kernel-land include files and definitions within a user-program.
Probably not doable.
> i kind of figured you guys would know what to do. it's sort of a rarefied
> group. anyway, if you can help, i'd really appreciate it, because
> alessandro's makefile was somewhat cryptic.
>
>
> you know, the operating systems class this semester at the university
> of maryland, college park, was taught based on that new, exciting os, win xp.
> and he managed to turn a 2 day class, where a day has a lecture and a lab,
> into a 4 day affair, monday lecture, tuesday lab, wednesday lecture, thursday
> lab. i took data structures instead. i am not taking any win xp os
> class. it's linux or nothing. can you believe that, win xp?
(Keep in mind that the following is my opinion only.) I'd say that
taking a Windows class might still be educational. Operating systems are
such a thing where learning one helps you understand a great deal about
_all_ of them. If anything, it'll at least give you more educated
reasons for disliking / hating our "favorite" monopolistic company or
operating system. :-)
> one more thing, um, i'm paralyzed from the shoulders down, but i can type
> with both hands using typing aids, and i also use a kensington "expert mouse"
> trackball. i would like to write a mouse manager where i could assign
> different actions for each button, something very similar to the kensington
> interface that's available for, um, windows. i found some xwindow functions
> for button pressing events, but i don't know how to get into the mouse driver
> or button events in xwindows or gnome, etc.
Depends upon what functionality you want to have those buttons to have.
If it's
Re: Kernel SCM saga..
On Sat, 9 Apr 2005, Andrea Arcangeli wrote: > > I'm not entirely convinced wget is going to be an efficient way to > synchronize and fetch your tree I don't think it's efficient per se, but I think it's important that people can just "pass the files along". Ie it's a huge benefit if any everyday mirror script (whether rsync, wget, homebrew or whatever) will just automatically do the right thing. > Perhaps that's why you were compressing the stuff too? It sounds better > not to compress the stuff on-disk I much prefer to waste some CPU time to save disk cache. Especially since the compression is "free" if you do it early on (ie it's done only once, since the files are stable). Also, if the difference is a 1.5GB kernel repository or a 3GB kernel repository, I know which one I'll pick ;) Also, I don't want people editing repostitory files by hand. Sure, the sha1 catches it, but still... I'd rather force the low-level ops to use the proper helper routines. Which is why it's a raw zlib compressed blob, not a gzipped file. 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/
easy softball jiffies quest(ion)
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.
this is it:
--
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
int main(void)
{
unsigned long j = jiffies + (50 * HZ);
printf("start jiffies = %9li\n",jiffies);
while(jiffies < j)
;
printf("done jiffies = %9li\n", jiffies);
return 0;
}
---
all right, you can giggle, but no laughing out loud, my kernel ego is
nacent and fragile.
when i compile it with:
gcc -o jfi.x jfi.c
i get a handful of errors regarding various #include statements:
-
jfi.c:3:31: linux/moduleparam.h: No such file or directory
In file included from jfi.c:6:
/usr/include/linux/time.h:10: error: syntax error before "time_t"
/usr/include/linux/time.h:12: error: syntax error before '}' token
/usr/include/linux/time.h:18: error: syntax error before "time_t"
/usr/include/linux/time.h:44: error: field `it_interval' has incomplete type
/usr/include/linux/time.h:45: error: field `it_value' has incomplete type
/usr/include/linux/time.h:49: error: field `it_interval' has incomplete type
/usr/include/linux/time.h:50: error: field `it_value' has incomplete type
jfi.c:7:25: linux/timer.h: No such file or directory
In file included from /usr/include/linux/interrupt.h:9,
from jfi.c:12:
/usr/include/asm/bitops.h:327:2: warning: #warning This include file is
not available on all architectures.
/usr/include/asm/bitops.h:328:2: warning: #warning Using kernel headers
in userspace: atomicity not guaranteed
In file included from jfi.c:12:
/usr/include/linux/interrupt.h:12:25: asm/hardirq.h: No such file or directory
/usr/include/linux/interrupt.h:13:25: asm/softirq.h: No such file or directory
jfi.c: In function `main':
jfi.c:19: error: `jiffies' undeclared (first use in this function)
jfi.c:19: error: (Each undeclared identifier is reported only once
jfi.c:19: error: for each function it appears in.)
./jfsh: line 8: jfi.x: command not found
-
i kind of figured you guys would know what to do. it's sort of a rarefied
group. anyway, if you can help, i'd really appreciate it, because
alessandro's makefile was somewhat cryptic.
you know, the operating systems class this semester at the university
of maryland, college park, was taught based on that new, exciting os, win xp.
and he managed to turn a 2 day class, where a day has a lecture and a lab,
into a 4 day affair, monday lecture, tuesday lab, wednesday lecture, thursday
lab. i took data structures instead. i am not taking any win xp os
class. it's linux or nothing. can you believe that, win xp?
one more thing, um, i'm paralyzed from the shoulders down, but i can type
with both hands using typing aids, and i also use a kensington "expert mouse"
trackball. i would like to write a mouse manager where i could assign
different actions for each button, something very similar to the kensington
interface that's available for, um, windows. i found some xwindow functions
for button pressing events, but i don't know how to get into the mouse driver
or button events in xwindows or gnome, etc.
if somebody has a direction to go for that, that would be a big help.
thanks, or tgfl(inux),
philip dahlquist
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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!y(B10000$B1_J,L5NA!y(B
$B"#"#"#!V(B1$B1_!WJ,L5NA%]%$%s%HB#Dh%-%c%s%Z!<%se$2$^$9!*(B $B"!(B1$B1_L5NA%]%$%s%H$H?7$7$$=P2q$$(BGET$B!*"*"*"*(B http://awg.qsv20.com/?springm $B!zL5NA$GAjEvM7$Y$^$9$N$G@'Hs$*;n$72<$5$$$M"v(B $B!z;HMQ$7$F$_$F!V$3$l$O!*!W$H;W$C$FD:$$$?J}$N$_!VM-NA!W$X$*?J$_2<$5$$!#(B - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 'BUG: scheduling with irqs disabled' when umounting NFS volume
* Daniel Walker <[EMAIL PROTECTED]> wrote: > I submitted a fix for this a while ago, I think .. > interruptible_sleep_on()'s are broken .. sleep_on() is a fundamentally broken interface, it only works on UP - but there it _does_ rely on the behavior your patch removes. (i.e. disabled interrupts until we hit schedule()) the PREEMPT_RT kernel makes the limitations of sleep_on() even more apparent. The patch only removes the warning, it doesnt remove the race. To remove the race, sleep_on() usage should be converted to something else. (e.g. one of the wait_event() variants) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: HELP:porting linux PXA audio driver to RTLinux(RTLinux core driver)
On Fri, 2005-04-08 at 21:03 -0700, nobin matthew wrote: > Dear Friends, > > I am trying to port Linux PXA audio > driver to RTLinux. I am using pxa-ac7.c and > pxa-audio.c > and eliminated sound_core.c, and i will register two > device /dev/mixer and /dev/dsp to RTLinux kernel. > >The real need is, i wants to generate a sin > wave using audio codec. With in 600us DMA controller > should fill the codec FIFO, if that is not met > distortion will happen. I think normal linux > interrupts and Process scheduling may cause some > problems. > > In porting it seems difficult to port kernel > scheduling , dynamic memory allocation(for DMA) and > synchronization. This is the exact same question you posted to linux-audio-dev. And you'll get the same answer here: Don't waste your time with RTLinux. Use a recent 2.6 kernel with Ingo's realtime-preempt patches. Configure with PREEMPT_RT. This will provide deterministic, hard realtime performance for any RT constraint down to about 50 usecs. RTLinux can meet a ~15 usec RT constraint, the RT preempt kernel will be able to do this once the timer ISR is made preemptible again. RTLinux is an obsolescent product that had its place in the 2.4 era but is being superseded by a solution that's both technically superior and 100% free software. Real time preemption is the future of hard realtime on Linux. All the major real time Linux players have recognized this, even the ones who had competing solutions for 2.4 are porting their work to the 2.6 RT-preempt framework. Besides, RTLinux is a commercial product anyway. If this project requires use of RTLinux for political reasons, call your support rep. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] sched: unlocked context-switches
* Luck, Tony <[EMAIL PROTECTED]> wrote:
> >tested on x86, and all other arches should work as well, but if an
> >architecture has irqs-off assumptions in its switch_to() logic
> >it might break. (I havent found any but there may such assumptions.)
>
> The ia64_switch_to() code includes a section that can change a pinned
> MMU mapping (when the stack for the new process is in a different
> granule from the stack for the old process). [...]
thanks - updated patch below. Any other architectures that switch the
kernel stack in a nonatomic way? x86/x64 switches it atomically.
Ingo
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
--- linux/kernel/sched.c.orig
+++ linux/kernel/sched.c
@@ -222,7 +222,6 @@ struct runqueue {
unsigned long expired_timestamp;
unsigned long long timestamp_last_tick;
task_t *curr, *idle;
- struct mm_struct *prev_mm;
prio_array_t *active, *expired, arrays[2];
int best_expired_prio;
atomic_t nr_iowait;
@@ -276,71 +275,25 @@ static DEFINE_PER_CPU(struct runqueue, r
#define task_rq(p) cpu_rq(task_cpu(p))
#define cpu_curr(cpu) (cpu_rq(cpu)->curr)
-#ifndef prepare_arch_switch
-# define prepare_arch_switch(next) do { } while (0)
-#endif
-#ifndef finish_arch_switch
-# define finish_arch_switch(prev) do { } while (0)
-#endif
-
-#ifndef __ARCH_WANT_UNLOCKED_CTXSW
-static inline int task_running(runqueue_t *rq, task_t *p)
-{
- return rq->curr == p;
-}
-
-static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
-{
-}
-
-static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
-{
- spin_unlock_irq(>lock);
-}
-
-#else /* __ARCH_WANT_UNLOCKED_CTXSW */
-static inline int task_running(runqueue_t *rq, task_t *p)
+/*
+ * We can optimise this out completely for !SMP, because the
+ * SMP rebalancing from interrupt is the only thing that cares:
+ */
+static inline void set_task_on_cpu(struct task_struct *p, int val)
{
#ifdef CONFIG_SMP
- return p->oncpu;
-#else
- return rq->curr == p;
+ p->on_cpu = val;
#endif
}
-static inline void prepare_lock_switch(runqueue_t *rq, task_t *next)
+static inline int task_on_cpu(runqueue_t *rq, task_t *p)
{
#ifdef CONFIG_SMP
- /*
-* We can optimise this out completely for !SMP, because the
-* SMP rebalancing from interrupt is the only thing that cares
-* here.
-*/
- next->oncpu = 1;
-#endif
-#ifdef __ARCH_WANT_INTERRUPTS_ON_CTXSW
- spin_unlock_irq(>lock);
+ return p->on_cpu;
#else
- spin_unlock(>lock);
-#endif
-}
-
-static inline void finish_lock_switch(runqueue_t *rq, task_t *prev)
-{
-#ifdef CONFIG_SMP
- /*
-* After ->oncpu is cleared, the task can be moved to a different CPU.
-* We must ensure this doesn't happen until the switch is completely
-* finished.
-*/
- smp_wmb();
- prev->oncpu = 0;
-#endif
-#ifndef __ARCH_WANT_INTERRUPTS_ON_CTXSW
- local_irq_enable();
+ return rq->curr == p;
#endif
}
-#endif /* __ARCH_WANT_UNLOCKED_CTXSW */
/*
* task_rq_lock - lock the runqueue a given task resides on and disable
@@ -855,7 +808,7 @@ static int migrate_task(task_t *p, int d
* If the task is not on a runqueue (and not running), then
* it is sufficient to simply update the task's cpu field.
*/
- if (!p->array && !task_running(rq, p)) {
+ if (!p->array && !task_on_cpu(rq, p)) {
set_task_cpu(p, dest_cpu);
return 0;
}
@@ -885,9 +838,9 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, );
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p->array || task_running(rq, p))) {
+ if (unlikely(p->array || task_on_cpu(rq, p))) {
/* If it's preempted, we yield. It could be a while. */
- preempted = !task_running(rq, p);
+ preempted = !task_on_cpu(rq, p);
task_rq_unlock(rq, );
cpu_relax();
if (preempted)
@@ -1150,7 +1103,7 @@ static int try_to_wake_up(task_t * p, un
this_cpu = smp_processor_id();
#ifdef CONFIG_SMP
- if (unlikely(task_running(rq, p)))
+ if (unlikely(task_on_cpu(rq, p)))
goto out_activate;
new_cpu = cpu;
@@ -1311,9 +1264,7 @@ void fastcall sched_fork(task_t *p, int
#ifdef CONFIG_SCHEDSTATS
memset(>sched_info, 0, sizeof(p->sched_info));
#endif
-#if defined(CONFIG_SMP) && defined(__ARCH_WANT_UNLOCKED_CTXSW)
- p->oncpu = 0;
-#endif
+ set_task_on_cpu(p, 0);
#ifdef CONFIG_PREEMPT
/* Want to start with kernel preemption disabled. */
p->thread_info->preempt_count = 1;
@@ -1458,45 +1409,11 @@ void fastcall sched_exit(task_t * p)
}
/**
- * prepare_task_switch - prepare to switch tasks
- * @rq: the runqueue preparing to switch
- * @next: the task we are going to switch to.
-
Re: Kernel SCM saga..
Linus Torvalds wrote: > Which is why I'd love to hear from people who have actually used > various SCM's with the kernel. There's bound to be people who have > already tried. At the end of my Codecon talk, there is a performance comparison of a number of different distributed SCM's with the kernel. http://superbeast.ucsd.edu/~landry/ArX/codecon/codecon.html I develop ArX (http://www.nongnu.org/arx). You may find it of interest ;) Cheers, Walter Landry [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/
PC: 130US$ == Adobe Photoshop v7 ++ Adobe Premiere v7 ++ Adobe Illustrator v10
www.azwpdrayw3shpta.knalkoxylhe.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/
HELP:porting linux PXA audio driver to RTLinux(RTLinux core driver)
Dear Friends, I am trying to port Linux PXA audio driver to RTLinux. I am using pxa-ac7.c and pxa-audio.c and eliminated sound_core.c, and i will register two device /dev/mixer and /dev/dsp to RTLinux kernel. The real need is, i wants to generate a sin wave using audio codec. With in 600us DMA controller should fill the codec FIFO, if that is not met distortion will happen. I think normal linux interrupts and Process scheduling may cause some problems. In porting it seems difficult to port kernel scheduling , dynamic memory allocation(for DMA) and synchronization. Please help me Nobin Mathew __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
$B$h$m$7$/$G$9!y(B
$B?k$K%*!<%W%s$7$^$7$?(B(^-^) $B$*6b$,$J$$?M!"=P2q$$$?$$?M!"$$$^$^$G;E;v$N4X78$G=w$N;R$HIU$-9g$&%A%c%s%9$,>/(B $B$J$$?M!"(B $B$3$3I,8+"*(Bhttp://www.getluck.net/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
> Version from syskonnect site require only changing usage of > pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After > that everything should work fine. So I think there is no need to post my > path here but if you really whant I may do this. Whole path agains > 2.6.12-rc2 take about 1.2 MB (diffstat attached below). I agree, no need to post a whole 1.2MB patch (goodness, what's in this driver, anyway, that it would need a 1.2MB *patch*? :-)) But you seem to be saying that the driver from syskonnect (and possibly the one in 2.6.12-rc1-bk3 as well) does not work as-is, and that you have a small patch that makes it work. If so, I think it's worth posting the small patch, so other users of the device can at least get it working until syskonnect gets things squared away. My apologies if I'm misunderstanding the situation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
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.
Unmatched seq. Rcvd=79477, expected=79478 <=== duplicate
Unmatched seq. Rcvd=713823, expected=713422 * loss of 401 msgs
Unmatched seq. Rcvd=80024, expected=79901 * loss of 123 msgs
Unmatched seq. Rcvd=93632, expected=93633 <=== duplicate
Unmatched seq. Rcvd=94718, expected=93970
Unmatched seq. Rcvd=743576, expected=743502
Unmatched seq. Rcvd=123506, expected=123507 <=== duplicate
Unmatched seq. Rcvd=773753, expected=773503
Unmatched seq. Rcvd=124111, expected=123938
Unmatched seq. Rcvd=157172, expected=157173 <=== duplicate
Unmatched seq. Rcvd=813024, expected=812913 <=== duplicate
Unmatched seq. Rcvd=813024, expected=813025 <=== duplicate
Unmatched seq. Rcvd=157830, expected=157501
Unmatched seq. Rcvd=158408, expected=158145
Unmatched seq. Rcvd=813678, expected=813438
The test system was a two cpu ia64.
Thanks,
- jay
Evgeniy Polyakov wrote:
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb->len >= NLMSG_SPACE(0)) {
+if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh->nlmsg_flags & NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err < 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(, id,
Re: Kernel SCM saga..
On Fri, Apr 08, 2005 at 11:08:58PM -0400, Brian Gerst wrote: > It's my understanding that the files don't change. Only new ones are > created for each revision. I said diff between the trees, not diff between files ;). When you fetch the new changes with rsync, it'll compress better and in turn it'll be faster (assuming we're network bound and I am with 1mbit and 2.5ghz cpu), if it's rsync applying gzip to the big "combined diff between trees" instead of us compressing every single small file on disk, that won't compress anymore inside rsync. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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..
Andrea Arcangeli wrote: On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting local copy). So think "wget". I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree, its simplicitly is great though. It's a tradeoff between optimzing and re-using existing tools (like webservers). Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk, and to synchronize with a rsync-like protocol (rsync server would make it) that handles the compression in the network protocol itself, and in turn that can apply compression to a large blob (i.e. the diff between the trees), and not to the single tiny files. It's my understanding that the files don't change. Only new ones are created for each revision. -- Brian gErst - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Kernel SCM saga..
Hello,
Dear diary, on Fri, Apr 08, 2005 at 05:50:21PM CEST, I got a letter
where Linus Torvalds <[EMAIL PROTECTED]> told me that...
>
>
> On Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote:
> >
> > Here's a partial solution. It does depend on a modified version of
> > cat-file that behaves like cat. I found it easier to have cat-file
> > just dump the object indicated on stdout. Trivial patch for that is
> > included.
>
> Your trivial patch is trivially incorrect, though. First off, some files
> may be binary (and definitely are - the "tree" type object contains
> pathnames, and in order to avoid having to worry about special characters
> they are NUL-terminated), and your modified "cat-file" breaks that.
>
> Secondly, it doesn't check or print the tag.
FWIW, I made few small fixes (to prevent some trivial usage errors to
cause cache corruption) and added scripts gitcommit.sh, gitadd.sh and
gitlog.sh - heavily inspired by what already went through the mailing
list. Everything is available at http://pasky.or.cz/~pasky/dev/git/
(including .dircache, even though it isn't shown in the index), the
cumulative patch can be found below. The scripts aim to provide some
(obviously very interim) more high-level interface for git.
I'm now working on tree-diff.c which will (surprise!) produce a diff
of two trees (I'll finish it after I get some sleep, though), and then I
will probably do some dwimmy gitdiff.sh wrapper for tree-diff and
show-diff. At that point I might get my hand on some pull more kind to
local changes.
Kind regards,
Petr Baudis
diff -ruN git-0.03/gitadd.sh git-devel-clean/gitadd.sh
--- git-0.03/gitadd.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitadd.sh 2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,13 @@
+#!/bin/sh
+#
+# Add new file to a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+#
+# Takes a list of file names at the command line, and schedules them
+# for addition to the GIT repository at the next commit.
+#
+# FIXME: Those files are omitted from show-diff output!
+
+for file in "$@"; do
+ echo $file >>.dircache/add-queue
+done
diff -ruN git-0.03/gitcommit.sh git-devel-clean/gitcommit.sh
--- git-0.03/gitcommit.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitcommit.sh2005-04-09 03:17:34.220577000 +0200
@@ -0,0 +1,36 @@
+#!/bin/sh
+#
+# Commit into a GIT repository.
+# Copyright (c) Petr Baudis, 2005
+# Based on an example script fragment sent to LKML by Linus Torvalds.
+#
+# Ignores any parameters for now, excepts changelog entry on stdin.
+#
+# FIXME: Gets it wrong for filenames containing spaces.
+
+
+if [ -r .dircache/add-queue ]; then
+ mv .dircache/add-queue .dircache/add-queue-progress
+ addedfiles=$(cat .dircache/add-queue-progress)
+else
+ addedfiles=
+fi
+changedfiles=$(show-diff -s | grep -v ': ok$' | cut -d : -f 1)
+commitfiles="$addedfiles $changedfiles"
+if [ ! "$commitfiles" ]; then
+ echo 'Nothing to commit.' >&2
+ exit
+fi
+update-cache $commitfiles
+rm -f .dircache/add-queue-progress
+
+
+oldhead=$(cat .dircache/HEAD)
+treeid=$(write-tree)
+newhead=$(commit-tree $treeid -p $oldhead)
+
+if [ "$newhead" ]; then
+ echo $newhead >.dircache/HEAD
+else
+ echo "Error during commit (oldhead $oldhead, treeid $treeid)" >&2
+fi
diff -ruN git-0.03/gitlog.sh git-devel-clean/gitlog.sh
--- git-0.03/gitlog.sh 1970-01-01 01:00:00.0 +0100
+++ git-devel-clean/gitlog.sh 2005-04-09 04:28:51.227791000 +0200
@@ -0,0 +1,61 @@
+#!/bin/sh
+
+ Call this script with an object and it will produce the change
+ information for all the parents of that object
+
+ This script was originally written by Ross Vandegrift.
+# multiple parents test 1d0f4aec21e5b66c441213643426c770dc6dedc0
+# parents: ffa098b2e187b71b86a76d3cd5eb77d074a2503c
+# 6860e0d9197c7f52155466c225baf39b42d62f63
+
+# regex for parent declarations
+PARENTS="^parent [A-z0-9]{40}$"
+
+TMPCL="/tmp/gitlog.$$"
+
+# takes an object and generates the object's parent(s)
+function unpack_parents () {
+ echo "me $1"
+ echo "me $1" >>$TMPCL
+ RENTS=""
+
+ TMPCM=$(mktemp)
+ cat-file commit $1 >$TMPCM
+ while read line; do
+ if echo "$line" | egrep -q "$PARENTS"; then
+ RENTS="$RENTS "$(echo $line | sed 's/parent //g')
+ fi
+ echo $line
+ done <$TMPCM
+ rm $TMPCM
+
+ echo -e "\n--\n"
+
+ # if the last object had no parents, return
+ if [ ! "$RENTS" ]; then
+ return;
+ fi
+
+ #useful for testing
+ #echo $RENTS
+ #read
+ for i in `echo $RENTS`; do
+ # break cycles
+ if grep -q "me $i" $TMPCL; then
+ echo "Already visited $i" >&2
+ continue
+ else
+ unpack_parents $i
+ fi
Re: Kernel SCM saga..
On Fri, Apr 08, 2005 at 07:38:30PM -0400, Daniel Phillips wrote: > For the immediate future, all we need is something than can _losslessly_ > capture the new metadata that's being generated. That buys time to bring one > of the promising open source candidates up to full speed. Agreed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: const qualifiers on function returns type
Benoit Boissinot <[EMAIL PROTECTED]> wrote: > extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p); > > I was wondering what means const for a function returns type. > K doesn't say anything about this and gcc-4 warns (warning: type > qualifiers ignored on function return type) It used to be a hint that the function has no side effect nor depends on any variable besides the parameters. Calls to those functions may be cached or omitted. -- Fun things to slip into your budget Paradigm pro-activator (a whole pack) (you mean beer?) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Sat, 9 Apr 2005, Andrea Arcangeli wrote: On Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: really designed for something like a offline http grabber, in that you can just grab files purely by filename (and verify that you got them right by running sha1sum on the resulting local copy). So think "wget". I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree, its simplicitly is great though. It's a tradeoff between optimzing and re-using existing tools (like webservers). Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk, and to synchronize with a rsync-like protocol (rsync server would make it) that handles the compression in the network protocol itself, and in turn that can apply compression to a large blob (i.e. the diff between the trees), and not to the single tiny files. note that many webservers will compress the data for you on the fly as well, so there's even less need to have it pre-compressed David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Fri, Apr 08, 2005 at 05:12:49PM -0700, Linus Torvalds wrote: > really designed for something like a offline http grabber, in that you can > just grab files purely by filename (and verify that you got them right by > running sha1sum on the resulting local copy). So think "wget". I'm not entirely convinced wget is going to be an efficient way to synchronize and fetch your tree, its simplicitly is great though. It's a tradeoff between optimzing and re-using existing tools (like webservers). Perhaps that's why you were compressing the stuff too? It sounds better not to compress the stuff on-disk, and to synchronize with a rsync-like protocol (rsync server would make it) that handles the compression in the network protocol itself, and in turn that can apply compression to a large blob (i.e. the diff between the trees), and not to the single tiny files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: no need to check for NULL before calling kfree() -fs/ext2/
On Wed, 30 Mar 2005, Jesper Juhl wrote: > On Tue, 29 Mar 2005, Paul Jackson wrote: > > > Pekka wrote: > > > (4) The cleanups Jesper and others are doing are to remove the > > > _redundant_ NULL checks (i.e. it is now checked twice). > > > > Even such obvious changes as removing redundant checks doesn't > > seem to ensure a performance improvement. Jesper Juhl posted > > performance data for such changes in his microbenchmark a couple > > of days ago. > > > > As I posted then, I could swear that his numbers show: > > > > > Just looking at the third run, it seems to me that "if (likely(p)) > > > kfree(p);" beats a naked "kfree(p);" everytime, whether p is half > > > NULL's, or very few NULL's, or almost all NULL's. > > > > Twice now I have asked Jesper to explain this strange result. > > > I've been kept busy with other things for a while and haven't had the time > to reply to your emails, sorry. As I just said in another post I don't > know how valid my numbers are, but I'll try and craft a few more tests to > see if I can get some more solid results. > > > > > Maybe we should be following your good advice: > > > > > You don't know that until you profile! > > > > instead of continuing to make these code changes. > > > I'll gather some more numbers and post them along with any conclusions I > believe can be drawn from them within a day or two, untill then I'll hold > back on the patches... > Ok, I never got around to doing some more benchmarks, mainly since it seems that people converged on the oppinion that the kfree() cleanups are OK and we can fix up any regressions by inlining kfree if needed (the difference these changes make to performance seem to be small and in the noice anyway). If anyone would /like/ me to do more benchmarks, then speak up and I will do them - I guess I could also build a kernel with an inline kfree() as a comparison.. but, unless someone speaks up I'll just carry on making these kfree() cleanups and not bother with benchmarks... -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: turn kmalloc+memset(,0,) into kcalloc
On Wed, 6 Apr 2005, Jörn Engel wrote: > On Tue, 5 April 2005 22:01:49 +0200, Jesper Juhl wrote: > > On Tue, 5 Apr 2005, Roland Dreier wrote: > > > > > > or simply > > > > if (!(ptr = kcalloc(n, size, ...))) > > > > goto out; > > > > and save an additional line of screen realestate while you are at > > > it... > > > > > > No, please don't do that. The general kernel style is to avoid > > > assignments within conditionals. > > > > > It may be the prefered style to avoid assignments in conditionals, but in > > that case we have a lot of cleanup to do. What I wrote above is quite > > common in the current tree - a simple egrep -r "if\ *\(\!\(.+=" * in > > 2.6.12-rc2-mm1 will find you somewhere between 1000 and 2000 cases > > scattered all over the tree. > > > > Personally I don't see why thy should not be used. They are short, not any > > harder to read (IMHO), save screen space & are quite common in userspace > > code as well (so people should be used to seeing them). > > > > If such statements are generally frawned upon then I'd suggest an addition > > be made to Documentation/CodingStyle mentioning that fact, and I wonder if > > patches to clean up current users would be welcome? > > I _do_ change them whenever they occur in code I maintain. And each > time, it is an improvement. > > o Functional code always has the same indentation. I can mentally > ignore the error path by ignoring all indented code. Getting a > quick overview is quite nice. > > o Rather often, your preferred variant violates the 80 columns rule. > If I need the line break anyway,... > > o Keeping condition and functional code seperate avoids the Lisp-style > bracket maze. Some editors can help you here, but not needing any > help would be even better, no? > Ok, I accept those arguments, they make sense. I may still have a personal preference that differ slightly, but I see your point(s). -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: IDE CMD 64x PCI driver (BUG REPORT; CMD 648 DMA INITIALIZATION)
Quick follow up: I decided to disable the DMA controller as a near term solution. This works but it is not optimal for obvious reasons. I believe that the chipset initialization for utilizing the DMA controller is incorrectly setup, for the particular model I am using (CMD 648). I don't know when/if I will look into this further. For more information regarding my analysis of the problem refer to my first email, with the email subject as "IDE CMD 64x PCI driver." -Rob - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
On Sat, 9 Apr 2005, Adrian Bunk wrote: > On Sat, Apr 09, 2005 at 01:28:47AM +0200, Jesper Juhl wrote: > > On Fri, 8 Apr 2005, Andrew Morton wrote: > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ > > > > > > > Still doesn't build for me with my usual config (available upon request) > > unless I enable ACPI : > > > > ... > > CC arch/i386/kernel/setup.o > > arch/i386/kernel/setup.c:96: error: parse error before "acpi_sci_flags" > > arch/i386/kernel/setup.c:96: warning: type defaults to `int' in declaration > > of `acpi_sci_flags' > > arch/i386/kernel/setup.c:96: warning: data definition has no type or > > storage class > > arch/i386/kernel/setup.c: In function `parse_cmdline_early': > > arch/i386/kernel/setup.c:811: error: request for member `trigger' in > > something not a structure or union > > arch/i386/kernel/setup.c:814: error: request for member `trigger' in > > something not a structure or union > > arch/i386/kernel/setup.c:817: error: request for member `polarity' in > > something not a structure or union > > arch/i386/kernel/setup.c:820: error: request for member `polarity' in > > something not a structure or union > > make[1]: *** [arch/i386/kernel/setup.o] Error 1 > > make: *** [arch/i386/kernel] Error 2 > > This seem to be the ACPI=y, ACPI_BOOT=n errors we already saw in -mm1 Actually, I get these errors with ACPI=n, ACPI_BOOT=y, not the reverse as you say. > Len will send a patch for. > Ok, I was not aware of that, will be looking forward to it :) -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Sat, 9 Apr 2005, Marcin Dalecki wrote: On 2005-04-08, at 20:28, Jon Smirl wrote: On Apr 8, 2005 2:14 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote: How do you replicate your database incrementally? I've given you enough clues to do it for "git" in probably five lines of perl. Efficient database replication is achieved by copying the transaction logs and then replaying them. Most mid to high end databases support this. You only need to copy the parts of the logs that you don't already have. Databases supporting replication are called high end. You forgot the cats dance around the network this issue involves. And Postgres (which is Free in all senses of the word) is high end by this definition. I'm not saying that it's an efficiant thing to use for this task, but don't be fooled into thinking you need something on the price of Oracle to do this job. David Lang -- There are two ways of constructing a software design. One way is to make it so simple that there are obviously no deficiencies. And the other way is to make it so complicated that there are no obvious deficiencies. -- C.A.R. Hoare - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
On Sat, Apr 09, 2005 at 01:28:47AM +0200, Jesper Juhl wrote: > On Fri, 8 Apr 2005, Andrew Morton wrote: > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ > > > > Still doesn't build for me with my usual config (available upon request) > unless I enable ACPI : > > ... > CC arch/i386/kernel/setup.o > arch/i386/kernel/setup.c:96: error: parse error before "acpi_sci_flags" > arch/i386/kernel/setup.c:96: warning: type defaults to `int' in declaration > of `acpi_sci_flags' > arch/i386/kernel/setup.c:96: warning: data definition has no type or storage > class > arch/i386/kernel/setup.c: In function `parse_cmdline_early': > arch/i386/kernel/setup.c:811: error: request for member `trigger' in > something not a structure or union > arch/i386/kernel/setup.c:814: error: request for member `trigger' in > something not a structure or union > arch/i386/kernel/setup.c:817: error: request for member `polarity' in > something not a structure or union > arch/i386/kernel/setup.c:820: error: request for member `polarity' in > something not a structure or union > make[1]: *** [arch/i386/kernel/setup.o] Error 1 > make: *** [arch/i386/kernel] Error 2 This seem to be the ACPI=y, ACPI_BOOT=n errors we already saw in -mm1 Len will send a patch for. > Jesper Juhl 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][RFC] disable built-in modules V2
Magnus Damm <[EMAIL PROTECTED]> wrote:
>
> Say a kernel shipped with your favourite distribution crashes your
> machine during boot-up - wouldn't it be nice to be able to just
> disable the problematic module from the kernel command line instead of
Perhaps your favourite distribution could build that as a module to
start with.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] make mempool_destroy resilient against NULL pointers.
On Fri, 8 Apr 2005, Andrew Morton wrote: > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > > > > General rule (as I understand it) is that functions that free resources > > should handle being passed NULL pointers - mempool_destroy() will > > currently explode if passed a NULL pointer, the patch below makes it safe > > to pass it NULL. > > The best response to mempool_destroy(0) is an oops. There's no legitimate > reason for doing it. > Ok, ignore the patch then. -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] make mempool_destroy resilient against NULL pointers.
Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > General rule (as I understand it) is that functions that free resources > should handle being passed NULL pointers - mempool_destroy() will > currently explode if passed a NULL pointer, the patch below makes it safe > to pass it NULL. The best response to mempool_destroy(0) is an oops. There's no legitimate reason for doing 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/
[PATCH] make mempool_destroy resilient against NULL pointers.
General rule (as I understand it) is that functions that free resources
should handle being passed NULL pointers - mempool_destroy() will
currently explode if passed a NULL pointer, the patch below makes it safe
to pass it NULL.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
mempool.c |2 ++
1 files changed, 2 insertions(+)
--- linux-2.6.12-rc2-mm2-orig/mm/mempool.c 2005-04-05 21:21:56.0
+0200
+++ linux-2.6.12-rc2-mm2/mm/mempool.c 2005-04-09 03:33:58.0 +0200
@@ -176,6 +176,8 @@ EXPORT_SYMBOL(mempool_resize);
*/
void mempool_destroy(mempool_t *pool)
{
+ if (!pool)
+ return;
if (pool->curr_nr != pool->min_nr)
BUG(); /* There were outstanding elements */
free_pool(pool);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mtime attribute is not being updated on client
On Fri, 2005-04-08 at 16:54, Linda Dunaphant wrote:
>Do you think it would be better for nfs_refresh_inode() to check the mtime,
>perform the mtime update if needed, and not set the NFS_INO_INVALID_ATTR
>flag if the data_unstable flag is set? This is how nfs_update_inode()
>handles its mtime check.
Hi again Trond,
I updated my first patch to nfs_refresh_inode() to be similar to the way
nfs_update_inode() does the check and update of the mtime. nfs_refresh_inode()
now checks to see if the mtime changed, and if so, it does the update of
the mtime. It only sets NFS_INO_INVALID_ATTR if data_unstable is not set.
I temporarily added some printk's to selected functions to monitor some of
the functions called after the data write to the server occurs. With this
latest patch, the sequence that I see with the test program is now the
same as it was originally without any patch - except the mtime is has been
updated:
nfs3_xdr_writeargs
xdr_decode_fattr<--- new mtime from server
nfs_refresh_inode <--- updates mtime in inode
nfs_attribute_timeout
nfs_attribute_timeout
xdr_decode_fattr
nfs_refresh_inode
With the first patch I proposed this sequence was:
nfs3_xdr_writeargs
xdr_decode_fattr<--- new mtime from server
nfs_refresh_inode <--- NFS_INO_INVALID_ATTR set
xdr_decode_fattr
nfs_update_inode<--- updates mtime in inode
nfs_attribute_timeout
xdr_decode_fattr
Thank you for pointing out that there may be other consequences if the
NFS_INO_INVALID_ATTR is always set by nfs_refresh_inode() when the mtime
values are different. I believe this second patch fixes the original
problem without affecting any other behaviour.
Cheers,
Linda
diff -ura base/fs/nfs/inode.c new/fs/nfs/inode.c
--- base/fs/nfs/inode.c 2005-04-07 16:04:40.0 -0400
+++ new/fs/nfs/inode.c 2005-04-08 19:23:44.151698674 -0400
@@ -1176,9 +1176,17 @@
}
/* Verify a few of the more important attributes */
+ if (!timespec_equal(>i_mtime, >mtime)) {
+ memcpy(>i_mtime, >mtime, sizeof(inode->i_mtime));
+#ifdef NFS_DEBUG_VERBOSE
+ printk(KERN_DEBUG "NFS: mtime change on %s/%ld\n",
inode->i_sb->s_id, inode->i_ino);
+#endif
+ if (!data_unstable)
+ nfsi->flags |= NFS_INO_INVALID_ATTR;
+ }
+
if (!data_unstable) {
- if (!timespec_equal(>i_mtime, >mtime)
- || cur_size != new_isize)
+ if (cur_size != new_isize)
nfsi->flags |= NFS_INO_INVALID_ATTR;
} else if (S_ISREG(inode->i_mode) && new_isize > cur_size)
nfsi->flags |= NFS_INO_INVALID_ATTR;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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..
Roman Zippel wrote: Please show me how you would do a binary search with arch. I don't really like the arch model, it's far too restrictive and it's jumping through hoops to get to an acceptable speed. What I expect from a SCM is that it maintains both a version index of the directory structure and a version index of the individual files. Arch makes it especially painful to extract this data quickly. For the common cases it throws disk space at the problem and does a lot of caching, but there are still enough problems (e.g. annotate), which require scanning of lots of tarballs. bye, Roman I'm not going to defend or attack arch since I haven't used it enough. I will say that darcs largely does suffer from the same problem that you describe since its fundamental unit of storage is individual patches (though it avoids the tarball issue). This is why David Roundy has indicated his intention of eventually having a per-file cache: http://kerneltrap.org/mailarchive/1/message/24317/flat You could then make the argument that if you have a per-file representation of the history, why do you also need/want a per-patch representation as the canonical format, but that's been argued plenty on both the darcs and arch mailing lists and probably isn't worth going into here. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Phentermine CHEAPEST ON THE INTERNET
Get Popular Pain Meds Here -> http://www.glbrx.com/scripts/default.asp?idaff=92 nothanks - http://www.glbpharma.com/aldfhsdlfh.asp - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
On 2005-04-09, at 03:09, Chris Wedgwood wrote: On Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote: Yes it sucks less for this purpose. See subversion as reference. Whatever solution people come up with, ideally it should be tolerant to minor amounts of corruption (so I can recover the rest of my data if need be) and it should also have decent sanity checks to find corruption as soon as reasonable possible. Yes this is the reason subversion is moving toward an alternative back-end based on a custom DB mapped closely to the file system. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sound/oss/emu10k1: fix up warning: ignoring return value of `__copy_to_user'
Here's an attempts at fixing these warnings
sound/oss/emu10k1/cardwi.c:310: warning: ignoring return value of
`__copy_to_user', declared with attribute warn_unused_result
sound/oss/emu10k1/cardwi.c:319: warning: ignoring return value of
`__copy_to_user', declared with attribute warn_unused_result
in a sane way.
If this looks OK, then please apply, if not then comments are very
welcome.
(please keep me on CC)
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
diff -upr linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/audio.c
linux-2.6.12-rc2-mm2/sound/oss/emu10k1/audio.c
--- linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/audio.c 2005-03-02
08:37:48.0 +0100
+++ linux-2.6.12-rc2-mm2/sound/oss/emu10k1/audio.c 2005-04-09
03:02:40.0 +0200
@@ -110,13 +110,19 @@ static ssize_t emu10k1_audio_read(struct
if ((bytestocopy >= wiinst->buffer.fragment_size)
|| (bytestocopy >= count)) {
+ unsigned long residue;
bytestocopy = min_t(u32, bytestocopy, count);
- emu10k1_wavein_xferdata(wiinst, (u8 __user *)buffer,
);
-
- count -= bytestocopy;
- buffer += bytestocopy;
- ret += bytestocopy;
+ if ((residue = emu10k1_wavein_xferdata(wiinst, (u8
__user *)buffer, ))) {
+ residue = bytestocopy - residue;
+ count -= residue;
+ buffer += residue;
+ ret += residue;
+ } else {
+ count -= bytestocopy;
+ buffer += bytestocopy;
+ ret += bytestocopy;
+ }
}
if (count > 0) {
diff -upr linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.c
linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.c
--- linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.c2005-03-02
08:38:12.0 +0100
+++ linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.c 2005-04-09
03:02:06.0 +0200
@@ -304,10 +304,12 @@ void emu10k1_wavein_getxfersize(struct w
}
}
-static void copy_block(u8 __user *dst, u8 * src, u32 str, u32 len, u8 cov)
+static unsigned long copy_block(u8 __user *dst, u8 * src, u32 str, u32 len, u8
cov)
{
+ unsigned long ret = 0;
+
if (cov == 1)
- __copy_to_user(dst, src + str, len);
+ return __copy_to_user(dst, src + str, len);
else {
u8 byte;
u32 i;
@@ -316,22 +318,24 @@ static void copy_block(u8 __user *dst, u
for (i = 0; i < len; i++) {
byte = src[2 * i] ^ 0x80;
- __copy_to_user(dst + i, , 1);
+ ret += __copy_to_user(dst + i, , 1);
}
}
+
+ return ret;
}
-void emu10k1_wavein_xferdata(struct wiinst *wiinst, u8 __user *data, u32 *
size)
+unsigned long emu10k1_wavein_xferdata(struct wiinst *wiinst, u8 __user *data,
u32 * size)
{
struct wavein_buffer *buffer = >buffer;
u32 sizetocopy, sizetocopy_now, start;
- unsigned long flags;
+ unsigned long flags, ret = 0;
sizetocopy = min_t(u32, buffer->size, *size);
*size = sizetocopy;
if (!sizetocopy)
- return;
+ return 0;
spin_lock_irqsave(>lock, flags);
start = buffer->pos;
@@ -345,11 +349,12 @@ void emu10k1_wavein_xferdata(struct wiin
if (sizetocopy > sizetocopy_now) {
sizetocopy -= sizetocopy_now;
- copy_block(data, buffer->addr, start, sizetocopy_now,
buffer->cov);
- copy_block(data + sizetocopy_now, buffer->addr, 0, sizetocopy,
buffer->cov);
+ ret += copy_block(data, buffer->addr, start, sizetocopy_now,
buffer->cov);
+ ret += copy_block(data + sizetocopy_now, buffer->addr, 0,
sizetocopy, buffer->cov);
} else {
- copy_block(data, buffer->addr, start, sizetocopy, buffer->cov);
+ ret += copy_block(data, buffer->addr, start, sizetocopy,
buffer->cov);
}
+ return ret;
}
void emu10k1_wavein_update(struct emu10k1_card *card, struct wiinst *wiinst)
diff -upr linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.h
linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.h
--- linux-2.6.12-rc2-mm2-orig/sound/oss/emu10k1/cardwi.h2005-03-02
08:38:38.0 +0100
+++ linux-2.6.12-rc2-mm2/sound/oss/emu10k1/cardwi.h 2005-04-09
03:03:20.0 +0200
@@ -83,7 +83,7 @@ void emu10k1_wavein_close(struct emu10k1
void emu10k1_wavein_start(struct emu10k1_wavedevice *);
void emu10k1_wavein_stop(struct emu10k1_wavedevice *);
void emu10k1_wavein_getxfersize(struct wiinst *, u32 *);
-void emu10k1_wavein_xferdata(struct wiinst *, u8 __user *, u32 *);
+unsigned long
Re: Kernel SCM saga..
On 2005-04-08, at 20:28, Jon Smirl wrote: On Apr 8, 2005 2:14 PM, Linus Torvalds <[EMAIL PROTECTED]> wrote: How do you replicate your database incrementally? I've given you enough clues to do it for "git" in probably five lines of perl. Efficient database replication is achieved by copying the transaction logs and then replaying them. Most mid to high end databases support this. You only need to copy the parts of the logs that you don't already have. Databases supporting replication are called high end. You forgot the cats dance around the network this issue involves. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Sat, Apr 09, 2005 at 03:00:44AM +0200, Marcin Dalecki wrote: > Yes it sucks less for this purpose. See subversion as reference. Whatever solution people come up with, ideally it should be tolerant to minor amounts of corruption (so I can recover the rest of my data if need be) and it should also have decent sanity checks to find corruption as soon as reasonable possible. I've been bitten by problems that subversion didn't catch but bk did. In the subversion case by the time I noticed much data was lost and none of the subversion tools were able to recover the rest of it. In the bk case, the data-loss was almost immediately noticeable and only affected a few files making recovery much easier. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-08, at 20:14, Linus Torvalds wrote: On Fri, 8 Apr 2005, Matthias-Christian Ott wrote: Ok, but if you want to search for information in such big text files it slow, because you do linear search No I don't. I don't search for _anything_. I have my own content-addressable filesystem, and I guarantee you that it's faster than mysql, because it depends on the kernel doing the right thing (which it does). Linus Sorry but you mistake the frequently seen SQL db abuse as DATA storage for what SQL databases are good at storing: well defined RELATIONS. Sure a filesystem is for data. SQL is for relations. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
const qualifiers on function returns type
Hi, there are some function who are declared this way: include/linux/cpuset.h:21 extern const cpumask_t cpuset_cpus_allowed(const struct task_struct *p); I was wondering what means const for a function returns type. K doesn't say anything about this and gcc-4 warns (warning: type qualifiers ignored on function return type) If it is a mistake, there are a few functions who should be modified. Regards, Benoit - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-08, at 19:14, Linus Torvalds wrote: You do that with an sql database, and I'll be impressed. It's possible. But what will impress you are either the price tag the DB comes with or the hardware it runs on :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-06, at 23:13, [EMAIL PROTECTED] wrote: Linus Torvalds wrote: PS. Don't bother telling me about subversion. If you must, start reading up on "monotone". That seems to be the most viable alternative, but don't pester the developers so much that they don't get any work done. They are already aware of my problems ;) By the way, the Subversion developers have no argument with the claim that Subversion would not be the right choice for Linux kernel development. We've written an open letter entitled "Please Stop Bugging Linus Torvalds About Subversion" to explain why: http://subversion.tigris.org/subversion-linus.html Thumbs up "Subverters"! I just love you. I love your attitude toward high engineering quality. And I appreciate actually very much what you provide as software. Both: from function and in terms of quality of implementation. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-07, at 09:44, Jan Hudec wrote:
I have looked at most systems currently available. I would suggest
following for closer look on:
1) GNU Arch/Bazaar. They use the same archive format, simple, have the
concepts right. It may need some scripts or add ons. When Bazaar-NG
is ready, it will be able to read the GNU Arch/Bazaar archives so
switching should be easy.
Arch isn't a sound example of software design. Quite contrary to the
random notes posted by it's author the following issues did strike me
the time I did evaluate it:
The application (tla) claims to have "intuitive" command names. However
I didn't see that as given. Most of them where difficult to remember
and appeared to be just infantile. I stopped looking further after I
saw:
tla my-id instead of: tla user-id or oeven tla set id ...
tla make-archive instead of tla init
tla my-default-archive [EMAIL PROTECTED]
No more "My Compuer" please...
Repository addressing requires you to use informally defined
very elaborated and typing error prone conventions:
mkdir ~/{archives}
tla make-archive [EMAIL PROTECTED]
~/{archives}/2005-VersionPatrol
You notice the requirement for two commands to accomplish a single task
already
well denoted by the second command? There is more of the same at quite
a few places
when you try to use it. You notice the triple zero it didn't catch?
As an added bonus it relies on the applications named by accident
patch and diff and installed on the host in question as well as few
other as well to
operate.
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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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-08, at 18:15, Matthias-Christian Ott wrote: Linus Torvalds wrote: SQL Databases like SQLite aren't slow. But maybe a Berkeley Database v.4 is a better solution. Yes it sucks less for this purpose. See subversion as reference. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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..
Hi, On Fri, 8 Apr 2005, Tupshin Harper wrote: > > A1 -> A2 -> A3 -> B1 -> B2 > > > > This results in a simpler repository, which is more scalable and which is > > easier for users to work with (e.g. binary bug search). > > The disadvantage would be it will cause more minor conflicts, when changes > > are pulled back into the original tree, but which should be easily > > resolvable most of the time. > > > Both darcs and arch (and arch's siblings) have ways of maintaining the > complete history but speeding up operations. Please show me how you would do a binary search with arch. I don't really like the arch model, it's far too restrictive and it's jumping through hoops to get to an acceptable speed. What I expect from a SCM is that it maintains both a version index of the directory structure and a version index of the individual files. Arch makes it especially painful to extract this data quickly. For the common cases it throws disk space at the problem and does a lot of caching, but there are still enough problems (e.g. annotate), which require scanning of lots of tarballs. bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A way to smoothly overgive graphics control to an other process/program
> Is this technically feasible? It's technically pointless. Take a look at bootsplash, though. -- Måns Rullgård [EMAIL PROTECTED] Bootsplash does exactly what I was complaining about. It controls only some part of the process of *booting* into the desktop without smooth transition (though it's at least a nice toy). The rest of your answer hits me but doesn't help me a little. Sorry if I am a pointless non-geek. Dennis - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: PCI-Express not working/unuseable on Intel 925XE Chipset since 2.6.12-rc1[mm1-4]
Bjorn Helgaas wrote: > On Fri, 2005-04-01 at 21:23 +0200, Jacek Luczak wrote: > >>Michael Thonke napisał(a): >> >>>Hello Jacek, >>> >>>I finially got it working :-) my PCI-Express devices working now... >>>I grabbed the last bk-snapshot from kernel.org 2.6.12-rc1-bk3 and et volia >>>everything except the Marvell Yokon PCI-E device working. >>>I hope Andrew will look into the mm-line to find the bug? >>> >> >>I've got Marvell Yukon 88E8053 GigE and it works fine with fixed (by >>myself :]) driver from syskonnect. If you wont I may send it to you! > > > Please post your patch here and copy the maintainers: > > MARVELL YUKON / SYSKONNECT DRIVER > P: Mirko Lindner > M: [EMAIL PROTECTED] > P: Ralph Roesler > M: [EMAIL PROTECTED] > W: http://www.syskonnect.com > S: Supported > > > Hi I sent my patch to Mirko about 3 weeks ago. Mirko replied that he consider it. Since that time new version of sk98lin driver appeared. Version from syskonnect site require only changing usage of pci_dev->slot_name to pci_name(pci_dev) in skge.c and skethtool.c. After that everything should work fine. So I think there is no need to post my path here but if you really whant I may do this. Whole path agains 2.6.12-rc2 take about 1.2 MB (diffstat attached below). Jacek --- drivers/net/Kconfig | 113 - drivers/net/sk98lin/Makefile | 64 drivers/net/sk98lin/h/lm80.h |4 drivers/net/sk98lin/h/skaddr.h|4 drivers/net/sk98lin/h/skcsum.h|6 drivers/net/sk98lin/h/skdebug.h | 20 drivers/net/sk98lin/h/skdrv1st.h | 41 drivers/net/sk98lin/h/skdrv2nd.h | 978 ++--- drivers/net/sk98lin/h/skerror.h | 12 drivers/net/sk98lin/h/skgedrv.h |4 drivers/net/sk98lin/h/skgehw.h| 1377 ++--- drivers/net/sk98lin/h/skgehwt.h |4 drivers/net/sk98lin/h/skgei2c.h | 210 -- drivers/net/sk98lin/h/skgeinit.h | 369 ++- drivers/net/sk98lin/h/skgepnm2.h | 12 drivers/net/sk98lin/h/skgepnmi.h | 141 - drivers/net/sk98lin/h/skgesirq.h | 40 drivers/net/sk98lin/h/skgetwsi.h | 241 ++ drivers/net/sk98lin/h/ski2c.h | 177 - drivers/net/sk98lin/h/skqueue.h | 13 drivers/net/sk98lin/h/skrlmt.h|4 drivers/net/sk98lin/h/sktimer.h |4 drivers/net/sk98lin/h/sktwsi.h| 177 + drivers/net/sk98lin/h/sktypes.h | 62 drivers/net/sk98lin/h/skversion.h | 34 drivers/net/sk98lin/h/skvpd.h | 84 drivers/net/sk98lin/h/sky2le.h| 891 drivers/net/sk98lin/h/xmac_ii.h | 621 +++--- drivers/net/sk98lin/sk98lin.txt | 203 +- drivers/net/sk98lin/skaddr.c | 79 drivers/net/sk98lin/skcsum.c |6 drivers/net/sk98lin/skdim.c | 1027 +++--- drivers/net/sk98lin/skethtool.c | 1379 ++--- drivers/net/sk98lin/skge.c| 3779 -- drivers/net/sk98lin/skgehwt.c | 52 drivers/net/sk98lin/skgeinit.c| 1683 drivers/net/sk98lin/skgemib.c | 186 + drivers/net/sk98lin/skgepnmi.c| 2282 +++--- drivers/net/sk98lin/skgesirq.c| 1244 +++- drivers/net/sk98lin/ski2c.c | 1296 - drivers/net/sk98lin/sklm80.c | 10 drivers/net/sk98lin/skproc.c | 587 - drivers/net/sk98lin/skqueue.c | 103 - drivers/net/sk98lin/skrlmt.c | 258 +- drivers/net/sk98lin/sktimer.c | 61 drivers/net/sk98lin/sktwsi.c | 1355 + drivers/net/sk98lin/skvpd.c | 195 + drivers/net/sk98lin/skxmac2.c | 2235 +- drivers/net/sk98lin/sky2.c| 2728 +++ drivers/net/sk98lin/sky2le.c | 510 + 50 files changed, 18204 insertions(+), 8761 deletions(-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Fri, Apr 08, 2005 at 07:34:00PM +0200, Adrian Bunk wrote: > If Debian was at least consistent. > > Why has Debian a much more liberal interpretation of MP3 patent issues > than RedHat? It's impossible to treat patents consistently. The U.S. patent office, at least, has granted patents on natural laws, on stuff that's already patented, on stuff with clear prior art, on trivial math operations and so on. Patents are being granted so quickly there's no way of even knowing what's patented. Or were you hoping that Debian would follow Red Hat's lead? As for this particular patent, I'm not really sure what's being patented. Trial and error? Spectral quantization? The specific data format? Addition, multiplication, and exponentiation? In many respects, mp3 is similar to jpeg. Does that mean that any use of the techniques used by jpeg in the domain of audio is covered by this patent? Does that mean that jpeg is in violation of this patent? If I use the same kind of math with a time dimension, am I violating some other mpeg patents? What about the other hundreds of thousands of patents? How many of them am I violating when I use lossy compression based on spectral quantization? -- Raul - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Fri, 8 Apr 2005, Linus Torvalds wrote: > > Also note that the above algorithm really works for _any_ two commit > points (apart for the two first steps, which are obviously all about > finding the parent tree when you want to diff against a predecessor). Btw, if you want to try this, you should get an updated copy. I've pushed a "raw" git archive of both git and sparse (the latter is much more interesting from an archive standpoint, since it actually has 1400 changesets in it) to kernel.org, but I'm not convinced it gets mirrored out. I think the mirror scripts may mirror only things they understand. I've also added a partial "fsck" for the "git filesystem". It doesn't do the connectivity analysis yet, but that should be pretty straightforward to add - it already parses all the data, it just doesn't save it away (and the connectivity analysis will automatically show how many "root" changesets you have, and what the different HEADs are). I'll make a tar-file (git-0.03), although at this point I've actually been maintaining it in itself, so to some degree it's almost getting easier if I'd just have a place to rsync it.. 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: [PATCH] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
On Sat, 9 Apr 2005, Eberhard Moenkeberg wrote: > Hi, > > On Sat, 9 Apr 2005, Jesper Juhl wrote: > > > Hi Andrew, > > > > I'm sending this to you directly since Eberhard Moenkeberg already > > indicated to me that he approves of the patch. > > Yes OK (I didn't say it yet, did I?), but I guess it is only cosmetic, as you > already said. > Unless I interpreted you wrong I'd say you did (in the "[PATCH] small fixes for example programs in Documentation/cdrom/sbpcd" thread): On Thu, 17 Mar 2005, Eberhard Moenkeberg wrote: ... > Do it. > I'm kind of proud, only "cosmetical" changes after a whole decennium. ;-)) > ... -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] silence spinlock/rwlock uninitialized break_lock member warnings
On Fri, 8 Apr 2005, Andrew Morton wrote: > Jesper Juhl <[EMAIL PROTECTED]> wrote: > > > > Any chance this patch could be added to -mm (and possibly mainline)? > > Spose I can stick it in -mm. > > > It removes a bunch of warnings when building with gcc -W, like these: > > include/linux/wait.h:82: warning: missing initializer > > include/linux/wait.h:82: warning: (near initialization for > > `(anonymous).break_lock') > > include/asm/rwsem.h:88: warning: missing initializer > > include/asm/rwsem.h:88: warning: (near initialization for > > `(anonymous).break_lock') > > so there's less to sift through when looking for real problems with this > > patch applied. > > I've been using it for a while with no ill effects. > > But I'd rather not add a bunch of even-more-ifdefs to support a compiler > flag which we're not going to use. It's easy enough for the `gcc -W' user > to add the patch himself. > True, it's trivial to just add the patch when needed (aka building with -W), but the number of such patches add up and having them in the tree by default is less pain (for the -W user). I'm not on a quest to make the tree -W clean, but I find -W useful to find the odd actual problem and a number of the warnings that -W spits out can be silenced without harm, those are the ones I aim to fix. But I see the point of not adding patches to make -W happy if it adds clutter for the non-W case, so I'll see if I can come up with a cleaner way to fix this case that will be more generally acceptable (perhaps Zwane's suggestion about using named initializers could result in something cleaner - I'll look at that)... -- Jesper - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
Hi, On Sat, 9 Apr 2005, Jesper Juhl wrote: Hi Andrew, I'm sending this to you directly since Eberhard Moenkeberg already indicated to me that he approves of the patch. Yes OK (I didn't say it yet, did I?), but I guess it is only cosmetic, as you already said. Cheers -e -- Eberhard Moenkeberg ([EMAIL PROTECTED], [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: Kernel SCM saga..
On Fri, 8 Apr 2005, Andrea Arcangeli wrote:
>
> We'd need a regenerated coherent copy of BKCVS to pipe into those SCM to
> evaluate how well they scale.
Yes, that makes most sense, I believe. Especially as BKCVS does the
linearization that makes other SCM's _able_ to take the data in the first
place. Few enough SCM's really understand the BK merge model, although the
distributed ones obviously have to do something similar.
> OTOH if your git project already allows storing the data in there,
> that looks nice ;).
I can express the data, and I did a sparse .git archive to prove the
concept. It doesn't even try to save BK-specific details, but as far as I
can tell, my git-conversion did capture all the basic things (ie not just
the actual source tree, but hopefully all the "who did what" parts too).
Of course, my git visualization tools are so horribly crappy that it is
hard to make sure ;)
Also, I suspect that BKCVS actually bothers to get more details out of a
BK tree than I cared about. People have pestered Larry about it, so BKCVS
exports a lot of the nitty-gritty (per-file comments etc) that just
doesn't actually _matter_, but people whine about. Me, I don't care. My
sparse-conversion just took the important parts.
> I don't yet fully understand how the algorithms of the trees are meant
> to work
Well, things like actually merging two git trees is not even something git
tries to do. It leaves that to somebody else - you can see what the
relationship is, and you can see all the data, but as far as I'm
concerned, git is really a "filesystem". It's a way of expression
revisions, but it's not a way of creating them.
> It looks similar to a diff -ur of two hardlinked trees
Yes. You could really think of it that way. It's not really about
hardlinking, but the fact that objects are named by their content does
mean that two objects (regardless of their type) can be seen as
"hardlinked" whenever their contents match.
But the more interesting part is the hierarchical virtual format it has,
ie it is not only hardlinked, but it also has the three different levels
of "views" into those hardlinked objects ("blob", "tree", "revision").
So even though the hash tree looks flat in the _physcal_ filesystem, it
detinitely isn't flat in its own virtual world. It's just flattened to fit
in a normal filesystem ;)
[ There's also a fourth level view in "trust", but that one hasn't been
implemented yet since I think it might as well be done at a higher
level. ]
Btw, the sha1 file format isn't actually designed for "rsync", since rsync
is really a hell of a lot more capable than my format needs. The format is
really designed for something like a offline http grabber, in that you can
just grab files purely by filename (and verify that you got them right by
running sha1sum on the resulting local copy). So think "wget".
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: [PATCH] silence spinlock/rwlock uninitialized break_lock member warnings
Jesper Juhl <[EMAIL PROTECTED]> wrote: > > Any chance this patch could be added to -mm (and possibly mainline)? Spose I can stick it in -mm. > It removes a bunch of warnings when building with gcc -W, like these: > include/linux/wait.h:82: warning: missing initializer > include/linux/wait.h:82: warning: (near initialization for > `(anonymous).break_lock') > include/asm/rwsem.h:88: warning: missing initializer > include/asm/rwsem.h:88: warning: (near initialization for > `(anonymous).break_lock') > so there's less to sift through when looking for real problems with this > patch applied. > I've been using it for a while with no ill effects. But I'd rather not add a bunch of even-more-ifdefs to support a compiler flag which we're not going to use. It's easy enough for the `gcc -W' user to add the patch himself. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] cosmetic fixes for example programs in Documentation/cdrom/sbpcd
Hi Andrew,
I'm sending this to you directly since Eberhard Moenkeberg already
indicated to me that he approves of the patch.
This patch makes a few minor changes to the example programs in
Documentation/cdrom/sbpcd to kill off some warnings and build failures.
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
sbpcd | 16 ++--
1 files changed, 10 insertions(+), 6 deletions(-)
--- linux-2.6.12-rc2-mm2-orig/Documentation/cdrom/sbpcd 2005-03-02
08:38:13.0 +0100
+++ linux-2.6.12-rc2-mm2/Documentation/cdrom/sbpcd 2005-04-09
02:04:11.0 +0200
@@ -419,6 +419,7 @@
*/
#include
#include
+#include
#include
static struct cdrom_tochdr hdr;
@@ -429,7 +430,7 @@
static int i, j, limit, track, err;
static char filename[32];
-main(int argc, char *argv[])
+int main(int argc, char *argv[])
{
/*
* open /dev/cdrom
@@ -516,6 +517,7 @@
}
arg.addr.lba++;
}
+return 0;
}
/*= end program */
@@ -564,15 +566,16 @@
#include
#include
#include
+#include
#include
#ifdef AZT_PRIVATE_IOCTLS
#include
-#endif AZT_PRIVATE_IOCTLS
+#endif /* AZT_PRIVATE_IOCTLS */
#ifdef SBP_PRIVATE_IOCTLS
#include
#include
-#endif SBP_PRIVATE_IOCTLS
+#endif /* SBP_PRIVATE_IOCTLS */
struct cdrom_tochdr hdr;
struct cdrom_tochdr tocHdr;
@@ -590,7 +593,7 @@
struct cdrom_msf msf;
unsigned char buf[CD_FRAMESIZE_RAW];
} azt;
-#endif AZT_PRIVATE_IOCTLS
+#endif /* AZT_PRIVATE_IOCTLS */
int i, i1, i2, i3, j, k;
unsigned char sequence=0;
unsigned char command[80];
@@ -738,7 +741,7 @@
}
}
-main(int argc, char *argv[])
+int main(int argc, char *argv[])
{
printf("\nTesting tool for a CDROM driver's audio functions V0.1\n");
printf("(C) 1995 Eberhard Moenkeberg <[EMAIL PROTECTED]>\n");
@@ -1046,12 +1049,13 @@
rc=ioctl(drive,CDROMAUDIOBUFSIZ,j);
printf("%d frames granted.\n",rc);
break;
-#endif SBP_PRIVATE_IOCTLS
+#endif /* SBP_PRIVATE_IOCTLS */
default:
printf("unknown command: \"%s\".\n",command);
break;
}
}
+ 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] radeonfb: (#2) Implement proper workarounds for PLL accesses
> > This patch adds to the fbdev interface a set_cmap callback that allow > > the driver to "batch" palette changes. This is useful for drivers like > > radeonfb which might require lenghtly workarounds on palette accesses, > > thus allowing to factor out those workarounds efficiently. > > This makes it better. But there is still a delay of half a second, and > there is an annoying flicker when switching from X to the console. Can you redo the counting of the workarounds with the patch ? 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 2/8] correctly name the Shell sort
On Fri, Apr 08, 2005 at 11:52:10AM -0400, Horst von Brand wrote: > [EMAIL PROTECTED] said: > > > As per http://www.nist.gov/dads/HTML/shellsort.html, this should be > > referred to as a Shell sort. Shell-Metzner is a misnomer. > > > Signed-off-by: Daniel Dickman <[EMAIL PROTECTED]> > > Signed-off-by: Domen Puncer <[EMAIL PROTECTED]> > > Why not use the sort routine from lib/sort.c? Because the groups are not in an array. They're in a bunch of page-sized blocks and the indexing function knows how to look at the index block and make everything look like an array from the point of view of the shell sort. I couldn't come up with a clean way to handle it. -- Mathematics is the supreme nostalgia of our time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] silence spinlock/rwlock uninitialized break_lock member warnings
Hi Andrew,
Any chance this patch could be added to -mm (and possibly mainline)?
It removes a bunch of warnings when building with gcc -W, like these:
include/linux/wait.h:82: warning: missing initializer
include/linux/wait.h:82: warning: (near initialization for
`(anonymous).break_lock')
include/asm/rwsem.h:88: warning: missing initializer
include/asm/rwsem.h:88: warning: (near initialization for
`(anonymous).break_lock')
so there's less to sift through when looking for real problems with this
patch applied.
I've been using it for a while with no ill effects.
This patch has surfaced previously, please see the lkml thread
"[RFC] spinlock_t & rwlock_t break_lock member initialization (patch seeking
comments included)"
Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
---
spinlock.h | 16 ++--
1 files changed, 14 insertions(+), 2 deletions(-)
--- linux-2.6.12-rc2-mm2-orig/include/asm-i386/spinlock.h 2005-03-02
08:37:50.0 +0100
+++ linux-2.6.12-rc2-mm2/include/asm-i386/spinlock.h2005-04-09
01:49:48.0 +0200
@@ -32,7 +32,13 @@ typedef struct {
#define SPINLOCK_MAGIC_INIT/* */
#endif
-#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 SPINLOCK_MAGIC_INIT }
+#ifdef CONFIG_PREEMPT
+#define SPINLOCK_BREAK_INIT, 0
+#else
+#define SPINLOCK_BREAK_INIT/* */
+#endif
+
+#define SPIN_LOCK_UNLOCKED (spinlock_t) { 1 SPINLOCK_MAGIC_INIT
SPINLOCK_BREAK_INIT }
#define spin_lock_init(x) do { *(x) = SPIN_LOCK_UNLOCKED; } while(0)
@@ -182,7 +188,13 @@ typedef struct {
#define RWLOCK_MAGIC_INIT /* */
#endif
-#define RW_LOCK_UNLOCKED (rwlock_t) { RW_LOCK_BIAS RWLOCK_MAGIC_INIT }
+#ifdef CONFIG_PREEMPT
+#define RWLOCK_BREAK_INIT , 0
+#else
+#define RWLOCK_BREAK_INIT /* */
+#endif
+
+#define RW_LOCK_UNLOCKED (rwlock_t) { RW_LOCK_BIAS RWLOCK_MAGIC_INIT
RWLOCK_BREAK_INIT }
#define rwlock_init(x) do { *(x) = RW_LOCK_UNLOCKED; } while(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] bootmem.c clean up bad pfn convertions
On Fri, 2005-04-08 at 15:32 +0200, Franck Bui-Huu wrote: > As I described in my previous email, bootmem.c does improper > pfn convertions into phys addr. This simple patch fixes that. ... > - bdata->node_bootmem_map = phys_to_virt(mapstart << PAGE_SHIFT); > - bdata->node_boot_start = (start << PAGE_SHIFT); > + bdata->node_bootmem_map = phys_to_virt(pfn_to_phys(mapstart)); > + bdata->node_boot_start = pfn_to_phys(start); The only arch with phys_to_pfn() defined is UML, so the patch simply won't compile anything but UML on current kernels (unless I'm missing something). Could you try to give us a more complete description of your problem? I know your memory doesn't start at 0x0, but what problems does that cause? Does the mem_map[] allocation blow up, etc... If it's just mem_map[], That calculation could be fixed pretty easily. Something like +#ifdef CONFIG_CRAZY_MIPS_FOO_MEM_MAP_START... +extern unsigned long mem_map_start_pfn +#else +#define mem_map_start_pfn 0UL +#endif -#define pfn_to_page(pfn)(mem_map + (pfn)) +#define pfn_to_page(pfn)(mem_map + (pfn) - mem_map_start_pfn) (those names are horrid, please improve them, if you plan to do this) All of the zone (and allocator) calculations should be just fine, because it already has a zone_start_pfn. -- Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel SCM saga..
Roman Zippel wrote: Preserving the complete merge history does indeed make repeated merges simpler, but it builds up complex meta data, which has to be managed forever. I doubt that this is really an advantage in the long term. I expect that we were better off serializing changesets in the main repository. For example bk does something like this: A1 -> A2 -> A3 -> BM \-> B1 -> B2 --^ and instead of creating the merge changeset, one could merge them like this: A1 -> A2 -> A3 -> B1 -> B2 This results in a simpler repository, which is more scalable and which is easier for users to work with (e.g. binary bug search). The disadvantage would be it will cause more minor conflicts, when changes are pulled back into the original tree, but which should be easily resolvable most of the time. Both darcs and arch (and arch's siblings) have ways of maintaining the complete history but speeding up operations. Arch use's revision libraries: http://www.gnu.org/software/gnu-arch/tutorial/revision-libraries.html though i'm not all that up on arch so I'll just leave it at that. Darcs uses "darcs optimize --checkpoint" http://darcs.net/manual/node7.html#SECTION00764000 which "allows for users to retrieve a working repository with limited history with a savings of disk space and bandwidth." In darcs case, you can pull a partial repository by doing "darcs get --partial", in which case you only grab the state at the point that the repository was optimized and subsequent patches, and all operations only need to work against the set of patches since that optimize. Note, that I'm not promoting darcs for kernel usage because of speed (or the lack thereof) but I am curious why Linus would consider monotone given its speed issues but not consider darcs. -Tupshin - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Friday 08 April 2005 04:38, Andrea Arcangeli wrote: > On Thu, Apr 07, 2005 at 11:41:29PM -0700, Linus Torvalds wrote: > The huge number of changesets is the crucial point, there are good > distributed SCM already but they are apparently not efficient enough at > handling 60k changesets. > > We'd need a regenerated coherent copy of BKCVS to pipe into those SCM to > evaluate how well they scale. > > OTOH if your git project already allows storing the data in there, > that looks nice ;). Hi Andrea, For the immediate future, all we need is something than can _losslessly_ capture the new metadata that's being generated. That buys time to bring one of the promising open source candidates up to full speed. By the way, which one are you working on? :-) Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Add support for semaphore-like structure with support for asynchronous I/O
fr den 08.04.2005 Klokka 18:39 (-0400) skreiv Benjamin LaHaise: > On the aio side of things, I introduced the owner field in the mutex (as > opposed to the flag in Trond's iosem) for the next patch in the series to > enable something like the following api: > > int aio_lock_mutex(struct mutex *lock, struct iocb *iocb); Any chance of a more generic interface too? iocbs are fairly high level objects, and so I do not see them helping to resolve low level filesystem problems such as the NFSv4 state cleanup. Cheers, Trond -- Trond Myklebust <[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: Kernel SCM saga..
On Fri, 8 Apr 2005, Rajesh Venkatasubramanian wrote:
>
> Although directory changes are tracked using change-sets, there
> seems to be no easy way to answer "give me the diff corresponding to
> the commit (change-set) object ". That will be really helpful to
> review the changes.
Actually, it is very easy indeed. Here's what you do:
- look up the commit object ("cat-file commit ")
This object starts out with "tree ", followed by a list of
parent commit objects: "parent "
Remember the tree object (it defines what the tree looks like at
the time of the commit). Pick the parent object you want to diff
against (normally the first one).
Also, print the checking messages at the end of the commit object.
- look up the parent object ("cat-file commit ")
Here you have the same kind of object, but this time you don't care
about going deeper, you just pick up the tree that describes
the tree at the parent.
- look up the two tree objects. Unlike a commit object, a tree object
is a binary data blob, but the format is an _extremely_ simple table
of thse guys:
<20-byte sha1>
and the reason it's binary is really that that way "git" doesn't end
up having any issues with strange pathnames. If you want to have spaces
and newlines in your pathname, go wild.
In particular, the tree object is also _sorted_ by the pathname. This
makes things simple, because you now have to sorted trees, and the
first thing you do is just walk the two trees in lock-step, which is
trivial thanks to the sorted nature of the tree "array".
So now you have three cases:
- you have the same name, and the same sha1
ignore it - the file didn't change, you don't even have to look
at the contents (although if the file mode changed you might
want to note that)
- you have the same name in parent and child tree lists, but the
sha differs. Now you just need to do a "cat-file" on both of the
SHA1 values, and do a "diff -u" between them.
- you have the filename in only parent or only child. Do a
"create" or "delete" diff with the content of the sha1 file.
See? Very efficient. For any files that didn't change, you didn't have to
do anything at all - you didn't even have to look at their data.
Also note that the above algorithm really works for _any_ two commit
points (apart for the two first steps, which are obviously all about
finding the parent tree when you want to diff against a predecessor).
It doesn't have to be parent and child. Pick any commit you have. And pick
them in the other order, and you'll automatically get the reverse diff.
You can even do diffs between unrelated projects this way if you use the
shared sha1 directory model, although that obviously doesn't tend to be
all that sensible ;)
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: 2.6.12-rc2-mm2
On Fri, 8 Apr 2005, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm2/ > Still doesn't build for me with my usual config (available upon request) unless I enable ACPI : ... CC arch/i386/kernel/setup.o arch/i386/kernel/setup.c:96: error: parse error before "acpi_sci_flags" arch/i386/kernel/setup.c:96: warning: type defaults to `int' in declaration of `acpi_sci_flags' arch/i386/kernel/setup.c:96: warning: data definition has no type or storage class arch/i386/kernel/setup.c: In function `parse_cmdline_early': arch/i386/kernel/setup.c:811: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:814: error: request for member `trigger' in something not a structure or union arch/i386/kernel/setup.c:817: error: request for member `polarity' in something not a structure or union arch/i386/kernel/setup.c:820: error: request for member `polarity' in something not a structure or union make[1]: *** [arch/i386/kernel/setup.o] Error 1 make: *** [arch/i386/kernel] Error 2 -- Jesper Juhl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.4.25+ ppc32 "make xconfig" error
Hi,
The make xconfig command spits out the following error (warning):
ERROR - Attempting to write value for unconfigured variable
(CONFIG_ALTIVEC).
This is on a PowerMac 8600 running YellowDog 2.1.
Commenting the VMX thing for the Power4 in arch/ppc/config.in fixes the
problem:
[EMAIL PROTECTED] ppc]$ diff -U 3 config-{old,new}_in
--- config-old_in Thu Apr 7 22:25:11 2005
+++ config-new_in Fri Apr 8 15:56:32 2005
@@ -176,9 +176,9 @@
fi
define_bool CONFIG_PPC_ISATIMER y
fi
-if [ "$CONFIG_POWER4" = "y" ]; then
- bool 'VMX (same as AltiVec) support' CONFIG_ALTIVEC
-fi
+#if [ "$CONFIG_POWER4" = "y" ]; then
+# bool 'VMX (same as AltiVec) support' CONFIG_ALTIVEC
+#fi
if [ "$CONFIG_4xx" = "y" -o "$CONFIG_8xx" = "y" ]; then
bool 'Math emulation' CONFIG_MATH_EMULATION
This problem also prevents you from enabling AltiVec (UI unresponsive).
kevin
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: LIBATA AHCI engine timeout hang with ATAPI devices
Jeff Garzik wrote: You need something like the attached patch. In general, ATAPI is still very much experimental at this point. One known bug that affects libata is that ATAPI DMA is not aligned to a 4-byte boundary. Hello, Thanks. I already have that patch applied. I will poke around the code over the weekend and see if I can figure out the problem. I am alittle rusty as my last disk driver code was modifying Heathkit CPM BIOS to support a SMS SASI board for 8 inch floppies and Shugart SA1000 series hard drives! I would like to help get ATAPI to work as I suspect more SATA ATAPI stuff will appear as motherboards use SATA. It appears that the ahci/libata code is missing some needed steps that the ata_piix/libata code does. Looking at the code and patches I can see that libata had to change to permit the hardware to perform tasks that libata did. Thank you for your web page on IDE drives. I downloaded alot of specs and even read a small bit of them. 73 Eric [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] Priority Lists for the RT mutex
>From: Daniel Walker [mailto:[EMAIL PROTECTED] > >> Current tip of development has some issues with conditional variables >> and broadcasts (requeue stuff) that I need to sink my teeth in. Joe >> Korty is fixing up a lot of corner cases I wasn't catching, but >> other than that is doing fine. > >You try to get out, and they suck you right back in. Don't mention it :] That's why I want to get some more people hooked up to this...so I can move on to do other things :) >> How long ago since you saw it? I also implemented the futex redirection >> stuff we discussed some months ago. > >It's been a while since I've seen the fusyn scheduler changes. I have >the curernt fusyn CVS, I'll take a look at it. All that stuff is in futex.c; bear in mind what I said at the confcall, it is just a hacky proof-of-concept--it doesn't even implement the async interface. It kind of works, but is not all that solid [last time I tried the JVMs locked up]. -- Inaky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/4] cifs: cleanup asn1.c - kfree
On Fri, 8 Apr 2005, Adrian Bunk wrote: > On Mon, Apr 04, 2005 at 11:01:45PM +0200, Jesper Juhl wrote: > > Remove redundant NULL pointer check before calling kfree(). > > > > Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]> > > > > > > --- linux-2.6.12-rc1-mm4/fs/cifs/asn1.c.with_patch1 2005-04-04 > > 22:25:50.0 +0200 > > +++ linux-2.6.12-rc1-mm4/fs/cifs/asn1.c 2005-04-04 22:33:34.0 > > +0200 > > @@ -540,7 +540,6 @@ int decode_negTokenInit(unsigned char *s > >*(oid + 3))); > > rc = compare_oid(oid, oidlen, > > NTLMSSP_OID, > > NTLMSSP_OID_LEN); > > - if(oid) > > kfree(oid); > > if (rc) > > use_ntlmssp = TRUE; > > > Please fix the indentation of the kfree after removing the if. > I do, in the next patch in the series, the "fs_cifs_asn1-spacing-and-long-lines.patch" patch. That one fixes the indentation along with lots of other whitespace issues. -- Jesper Juhl - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Priority Lists for the RT mutex
On Fri, 2005-04-08 at 14:25, Perez-Gonzalez, Inaky wrote: > I concur with Daniel. If we can decide how to deal with that (toss > one out, keep one, merge them, whatever), we could reuse all the user > space glue that is the hardest part to get right. I have a preference to the Real-Time PI , but that's just cause I've worked with it more. Ingo's really the one that should be make those choices though, since he has the biggest influence over what goes into sched.c .. > Current tip of development has some issues with conditional variables > and broadcasts (requeue stuff) that I need to sink my teeth in. Joe > Korty is fixing up a lot of corner cases I wasn't catching, but > other than that is doing fine. You try to get out, and they suck you right back in. > How long ago since you saw it? I also implemented the futex redirection > stuff we discussed some months ago. It's been a while since I've seen the fusyn scheduler changes. I have the curernt fusyn CVS, I'll take a look at it. Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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..
Hi, On Thu, 7 Apr 2005, Linus Torvalds wrote: > I really disliked that in BitKeeper too originally. I argued with Larry > about it, but Larry (correctly, I believe) argued that efficient and > reliable distribution really requires the concept of "history is > immutable". It makes replication much easier when you know that the known > subset _never_ shrinks or changes - you only add on top of it. The problem is you pay a price for this. There must be a reason developers were adding another GB of memory just to run BK. Preserving the complete merge history does indeed make repeated merges simpler, but it builds up complex meta data, which has to be managed forever. I doubt that this is really an advantage in the long term. I expect that we were better off serializing changesets in the main repository. For example bk does something like this: A1 -> A2 -> A3 -> BM \-> B1 -> B2 --^ and instead of creating the merge changeset, one could merge them like this: A1 -> A2 -> A3 -> B1 -> B2 This results in a simpler repository, which is more scalable and which is easier for users to work with (e.g. binary bug search). The disadvantage would be it will cause more minor conflicts, when changes are pulled back into the original tree, but which should be easily resolvable most of the time. I'm not saying with this that the bk model is bad, but I think it's a problem if it's the only model applied to everything. > The thing is, cherry-picking very much implies that the people "up" the > foodchain end up editing the work of the people "below" them. The whole > reason you want cherry-picking is that you want to fix up somebody elses > mistakes, ie something you disagree with. > > That sounds like an obviously good thing, right? Yes it does. > > The problem is, it actually results in the wrong dynamics and psychology > in the system. First off, it makes the implicit assumption that there is > an "up" and "down" in the food-chain, and I think that's wrong. These dynamics do exists and our tools should be able to represent them. For example when people post patches, they get reviewed and often need more changes and bk doesn't really help them to redo the patches. Bk helped you to offload the cherry-picking process to other people, so that you only had to do cherry-collecting very efficiently. Another prime example of cherry-picking is Andrews mm tree, he picks a number of patches which are ready for merging and forwards them to you. Our current basic development model (at least until a few days ago) looks something like this: linux-mm -> linux-bk -> linux-stable Ideally most changes would get into the tree via linux-mm and depending on depending various conditions (e.g. urgency, review state) it would get into the stable tree. In practice linux-mm is more an aggregation of patches which need testing and since most bk users were developing against linux-bk, it got a lot less testing and a lot of problems are only caught at the next stage. Changes from the stable tree would even flow in the opposite direction. Bk supports certain aspects of the kernel development process very well, but due its closed nature it was practically impossible to really integrate it fully into this process (at least for anyone outside BM). In the short term we probably are in for a tough ride and we take whatever works best for you, but in the long term we need to think about how SCM fits into our kernel development model, which includes development, review, testing and releasing of kernel changes. This is more than just pulling and merging kernel trees. I'm aiming at a tool that can also support Andrews work, so that he can also better offload some of this work (and take a break sometimes :) ). Unfortunately every existing tool I know of is lacking in its own way, so we still have some way to go... bye, Roman - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: A way to smoothly overgive graphics control to an other process/program
Dennis Heuer <[EMAIL PROTECTED]> writes: > Hello, > > I feel disturbed by the fact that when display-controlling programs > are started in line (like the bootloader, linux, and finally > xdm/gdm/kdm), there appear several switches of display resolution, > text- and graphics mode, and background images. I asked myself how to > get that more smooth as if there was only one presentation from the > time the bootloader started up to the gnome/kde session. I thought > that one could implement a small api that allows a running process to > freeze display updates until the next process has overtaken the > display, loaded the same presentation (from same location or just by > similar configuration), dumped it to the working buffer of the > graphics card, and released the display (a timeout with fallback-mode > could make this transaction more fault-resistent). This way, the image > loaded by the bootloader could be held on display up to the graphical > login, and even as the > desktop background, without any visible effect. > > Is this technically feasible? It's technically pointless. Take a look at bootsplash, though. -- Måns Rullgård [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: [RFC] Add support for semaphore-like structure with support for asynchronous I/O
On Thu, Apr 07, 2005 at 12:43:02PM +0100, Christoph Hellwig wrote:
> - switch all current semaphore users that don't need counting semaphores
>over to use a mutex_t type. For now it can map to struct semaphore.
> - rip out all existing complicated struct semaphore implementations and
>replace it with a portable C implementation. There's not a lot of users
>anyway. Add a mutex_t implementation that allows sensible assembly hooks
>for architectures instead of reimplementing all of it
> - add more features to mutex_t where nessecary
Oh dear, this is going to take a while. In any case, here is such a
first step in creating such a sequence of patches. Located at
http://www.kvack.org/~bcrl/patches/mutex-A0/ are the following patches:
00_mutex.diff - Introduces the basic mutex abstraction on top
of the existing semaphore implementation.
01_i_sem.diff - Converts all users of i_sem to use the mutex
abstraction.
10_new_mutex.diff - Replaces the semphore mutex with a new mutex
derrived from Trond's iosem patch. Note that
this fixes a serious bug in iosems: see the
change in mutex_lock_wake_function that ignores
the return value of default_wake_function, as
on SMP a process might still be running while
we actually made progress.
sem-test.c - A basic stress tester for the mutex / semaphore.
I'm still not convinced that introducing the mutex type is the best
approach, especially given the history of the up()/down() implementation.
On the aio side of things, I introduced the owner field in the mutex (as
opposed to the flag in Trond's iosem) for the next patch in the series to
enable something like the following api:
int aio_lock_mutex(struct mutex *lock, struct iocb *iocb);
...generic_file_read
{
ret = mutex_lock_aio(>i_sem, iocb);
if (ret)
return ret; /* aio_lock_mutex can return -EIOCBQUEUED */
...
mutex_unlock(>i_sem);
}
mutex_lock_aio will attempt to take the lock if the iocb is not the owner,
otherwise it returns immediately (ie ->owner == iocb). This will allow for
code paths that support aio to follow a fairly similar coding style to the
synchronous io path.
More next week...
-ben
--
"Time is what keeps everything from happening all at once." -- John Wheeler
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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..
Linus wrote: It looks like an operation like "show me the history of mm/memory.c" will be pretty expensive using git. Yes. Per-file history is expensive in git, because if the way it is indexed. Things are indexed by tree and by changeset, and there are no per-file indexes. Although directory changes are tracked using change-sets, there seems to be no easy way to answer "give me the diff corresponding to the commit (change-set) object ". That will be really helpful to review the changes. Rajesh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
PC: 130US$ == Adobe Photoshop v7 ++ Adobe Premiere v7 ++ Adobe Illustrator v10, for download
www.lspz6s59pelkmo3.knalkoxylhe.com - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.12-rc2-mm2
Jan Dittmer <[EMAIL PROTECTED]> wrote: > > Andrew Morton wrote: > > - The bk-acpi patch here causes my ia64 test box to hang during boot > > > bk-ia64.patch > > ia64 defconfig does not even build anymore: > > > CC [M] drivers/char/agp/hp-agp.o > In file included from /usr/src/ctest/mm/kernel/drivers/char/agp/hp-agp.c:18: > include2/asm/acpi-ext.h:15: error: parse error before "hp_acpi_csr_space" > include2/asm/acpi-ext.h:15: error: parse error before "u64" > include2/asm/acpi-ext.h:15: warning: type defaults to `int' in declaration of > `hp_acpi_csr_space' I suppose this is needed. --- 25/include/asm-ia64/acpi-ext.h~acpi-ext-build-fix Fri Apr 8 15:19:43 2005 +++ 25-akpm/include/asm-ia64/acpi-ext.h Fri Apr 8 15:20:12 2005 @@ -11,6 +11,7 @@ #define _ASM_IA64_ACPI_EXT_H #include +#include extern acpi_status hp_acpi_csr_space (acpi_handle, u64 *base, u64 *length); _ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: set keyboard repeat rate: EVIOCGREP and EVIOCSREP
Vernon Mauery wrote: > I was wondering if anyone knows how to change the repeatrate on a USB > keyboard with a 2.4 kernel. The system is a legacy free system (no ps2 > port), so kbdrate does nothing. With evdev loaded, the keyboard and mouse > (both USB devices) get registered with the event system and show up as > /dev/input/event[01]. I know the event subsystem does software key repeating > and was wondering how to change that. > > I poked around and found the EVIOCGREP and EVIOCSREP ioctls, but when I tried > using them, the ioctl returned invalid parameter. Upon further > investigation, I found that the ioctl definitions (located in the > linux/input.h header file) are not used in kernel land. That would explain > why it failed, but that just means I ran into a dead end. Were those > definitions legacy code from 2.2 or is it something that never got > implemented, only defined? I also noticed that the defines are gone in 2.6. > So how _does_ one go about changing the repeat rate on a keyboard input > device in 2.4? > Just in case anyone cares, I spent some more time poking around in the event code and it looks like the way to do this seems to be exposed by the evdev module. If you write to /dev/input/eventX an input_event that contains an event of type EV_REP with either REP_DELAY or REP_PERIOD as the code and a value in milliseconds, I think it is supposed to set up the software auto repeat for you. But with the atkbd driver, you have to turn off hardware auto repeat for this to take effect. --Vernon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
On Fri, 08 Apr 2005 15:08:13 -0700
Jay Lan <[EMAIL PROTECTED]> wrote:
> Hi Evgeniy,
>
> Forget about my previous request of a new patch.
>
> The failures were straight forward enough to figure out.
Ok.
The latest sources are always awailable at
http://tservice.net.ru/~s0mbre/archive/connector
> - jay
>
> Jay Lan wrote:
> > My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
> >
> > Your patch caused 5 out of 8 hunks failure at connector.c
> > and one failure at connector.h.
> >
> > Could you generate a new patch based on my version? A tar
> > file of complete source of drivers/connector would work
> > also. :)
> >
> > Thanks!
> > - jay
> >
> > Evgeniy Polyakov wrote:
> >
> >> Could you give attached patch a try instead of previous one.
> >> It adds gfp mask into cn_netlink_send() call also.
> >> If you need updated CBUS sources, feel free to ask, I will send
> >> updated sources with Andrew's comments resolved too.
> >>
> >> I do not know exactly your connector version, so patch will probably
> >> be applied with fuzz.
> >>
> >> feel free to contact if it does not apply, I will send
> >> the whole sources.
> >>
> >> Thank you.
> >>
> >> * looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
> >> compare with
> >> * comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
> >> M connector.c
> >> M connector.h
> >> M cbus.c
> >>
> >> * modified files
> >>
> >> --- orig/drivers/connector/connector.c
> >> +++ mod/drivers/connector/connector.c
> >> @@ -70,7 +70,7 @@
> >> * then it is new message.
> >> *
> >> */
> >> -void cn_netlink_send(struct cn_msg *msg, u32 __groups)
> >> +void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
> >> {
> >> struct cn_callback_entry *n, *__cbq;
> >> unsigned int size;
> >> @@ -102,7 +102,7 @@
> >>
> >> size = NLMSG_SPACE(sizeof(*msg) + msg->len);
> >>
> >> -skb = alloc_skb(size, GFP_ATOMIC);
> >> +skb = alloc_skb(size, gfp_mask);
> >> if (!skb) {
> >> printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
> >> size);
> >> return;
> >> @@ -119,11 +119,11 @@
> >> #endif
> >>
> >> NETLINK_CB(skb).dst_groups = groups;
> >> -
> >> -uskb = skb_clone(skb, GFP_ATOMIC);
> >> -if (uskb)
> >> +#if 0
> >> +uskb = skb_clone(skb, gfp_mask);
> >> +if (uskb && 0)
> >> netlink_unicast(dev->nls, uskb, 0, 0);
> >> -
> >> +#endif
> >> netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
> >>
> >> return;
> >> @@ -158,7 +158,7 @@
> >> }
> >> spin_unlock_bh(>cbdev->queue_lock);
> >>
> >> -return found;
> >> +return (found)?0:-ENODEV;
> >> }
> >>
> >> /*
> >> @@ -181,7 +181,6 @@
> >> "requested msg->len=%u[%u], nlh->nlmsg_len=%u,
> >> skb->len=%u.\n",
> >> msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
> >> nlh->nlmsg_len, skb->len);
> >> -kfree_skb(skb);
> >> return -EINVAL;
> >> }
> >> #if 0
> >> @@ -215,17 +214,18 @@
> >> skb->len, skb->data_len, skb->truesize, skb->protocol,
> >> skb_cloned(skb), skb_shared(skb));
> >> #endif
> >> -while (skb->len >= NLMSG_SPACE(0)) {
> >> +if (skb->len >= NLMSG_SPACE(0)) {
> >> nlh = (struct nlmsghdr *)skb->data;
> >> +
> >> if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
> >> skb->len < nlh->nlmsg_len ||
> >> nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
> >> -#if 0
> >> +#if 1
> >> printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
> >> nlh->nlmsg_len, sizeof(*nlh));
> >> #endif
> >> kfree_skb(skb);
> >> -break;
> >> +goto out;
> >> }
> >>
> >> len = NLMSG_ALIGN(nlh->nlmsg_len);
> >> @@ -233,22 +233,11 @@
> >> len = skb->len;
> >>
> >> err = __cn_rx_skb(skb, nlh);
> >> -if (err) {
> >> -#if 0
> >> -if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
> >> -netlink_ack(skb, nlh, -err);
> >> -#endif
> >> -break;
> >> -} else {
> >> -#if 0
> >> -if (nlh->nlmsg_flags & NLM_F_ACK)
> >> -netlink_ack(skb, nlh, 0);
> >> -#endif
> >> -break;
> >> -}
> >> -skb_pull(skb, len);
> >> +if (err < 0)
> >> +kfree_skb(skb);
> >> }
> >> -
> >> +
> >> +out:
> >> kfree_skb(__skb);
> >> }
> >>
> >> @@ -310,7 +299,7 @@
> >> m.ack = notify_event;
> >>
> >> memcpy(, id, sizeof(m.id));
> >> -cn_netlink_send(, ctl->group);
> >> +cn_netlink_send(, ctl->group, GFP_ATOMIC);
> >> }
> >> }
> >> spin_unlock_bh(_lock);
> >>
> >>
> >> --- orig/include/linux/connector.h
> >> +++ mod/include/linux/connector.h
> >> @@ -148,7 +148,7 @@
> >>
> >> int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
>
Re: Odd Timer behavior in 2.6 vs 2.4 (1 extra tick)
On Fri, 2005-04-08 at 10:39 -0700, [EMAIL PROTECTED] wrote: > > Hello, > > I've created a pretty straight forward timer using setitimer, and noticed > some odd differences between 2.4 and 2.6, I wonder if I could get a > clarification if this is the way it should work, or if I should continue to > try to "fix" it. Hi, could you send me a simple program that shows the latency, then I'll be able to analysis exactly where the problem (if there is a problem) is. -- Steve - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Reduce dependencies
On Mon, Mar 28, 2005 at 09:16:58AM -0800, Roland Dreier wrote: > The current include file is a little fragile in that > it is not self-contained and hence may cause compile warnings or > errors depending on the files included before it, the kernel config > and the architecture. This patch makes things a little more robust by: > > - including to get definitions of u32, mode_t, and so on. > - forward declaring struct file_operations. > - including when CONFIG_DEBUG_FS is not set > > The last change is particularly useful, as a kernel developer is > likely to build with debugfs always enabled and never see the build > breakage cased if debugfs is disabled. > > Signed-off-by: Roland Dreier <[EMAIL PROTECTED]> Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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-mm3 Fix ver_linux script for no udev utils.
On Tue, Mar 29, 2005 at 09:30:56AM -0700, Steven Cole wrote: > Without the attached patch, the ver_linux script gives > the following if udev utils are not present. > > ./scripts/ver_linux: line 90: udevinfo: command not found > > The patch causes ver_linux to be silent in the case of > no udevinfo command. > > Steven > TSPA (Technical data or Software Publicly Available) Applied, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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
Hi Evgeniy,
Forget about my previous request of a new patch.
The failures were straight forward enough to figure out.
- jay
Jay Lan wrote:
My workarea was based on 2.6.12-rc1-mm4 plus Guilluame's patch.
Your patch caused 5 out of 8 hunks failure at connector.c
and one failure at connector.h.
Could you generate a new patch based on my version? A tar
file of complete source of drivers/connector would work
also. :)
Thanks!
- jay
Evgeniy Polyakov wrote:
Could you give attached patch a try instead of previous one.
It adds gfp mask into cn_netlink_send() call also.
If you need updated CBUS sources, feel free to ask, I will send
updated sources with Andrew's comments resolved too.
I do not know exactly your connector version, so patch will probably
be applied with fuzz.
feel free to contact if it does not apply, I will send
the whole sources.
Thank you.
* looking for [EMAIL PROTECTED]/connector--main--0--patch-38 to
compare with
* comparing to [EMAIL PROTECTED]/connector--main--0--patch-38
M connector.c
M connector.h
M cbus.c
* modified files
--- orig/drivers/connector/connector.c
+++ mod/drivers/connector/connector.c
@@ -70,7 +70,7 @@
* then it is new message.
*
*/
-void cn_netlink_send(struct cn_msg *msg, u32 __groups)
+void cn_netlink_send(struct cn_msg *msg, u32 __groups, int gfp_mask)
{
struct cn_callback_entry *n, *__cbq;
unsigned int size;
@@ -102,7 +102,7 @@
size = NLMSG_SPACE(sizeof(*msg) + msg->len);
-skb = alloc_skb(size, GFP_ATOMIC);
+skb = alloc_skb(size, gfp_mask);
if (!skb) {
printk(KERN_ERR "Failed to allocate new skb with size=%u.\n",
size);
return;
@@ -119,11 +119,11 @@
#endif
NETLINK_CB(skb).dst_groups = groups;
-
-uskb = skb_clone(skb, GFP_ATOMIC);
-if (uskb)
+#if 0
+uskb = skb_clone(skb, gfp_mask);
+if (uskb && 0)
netlink_unicast(dev->nls, uskb, 0, 0);
-
+#endif
netlink_broadcast(dev->nls, skb, 0, groups, GFP_ATOMIC);
return;
@@ -158,7 +158,7 @@
}
spin_unlock_bh(>cbdev->queue_lock);
-return found;
+return (found)?0:-ENODEV;
}
/*
@@ -181,7 +181,6 @@
"requested msg->len=%u[%u], nlh->nlmsg_len=%u,
skb->len=%u.\n",
msg->len, NLMSG_SPACE(msg->len + sizeof(*msg)),
nlh->nlmsg_len, skb->len);
-kfree_skb(skb);
return -EINVAL;
}
#if 0
@@ -215,17 +214,18 @@
skb->len, skb->data_len, skb->truesize, skb->protocol,
skb_cloned(skb), skb_shared(skb));
#endif
-while (skb->len >= NLMSG_SPACE(0)) {
+if (skb->len >= NLMSG_SPACE(0)) {
nlh = (struct nlmsghdr *)skb->data;
+
if (nlh->nlmsg_len < sizeof(struct cn_msg) ||
skb->len < nlh->nlmsg_len ||
nlh->nlmsg_len > CONNECTOR_MAX_MSG_SIZE) {
-#if 0
+#if 1
printk(KERN_INFO "nlmsg_len=%u, sizeof(*nlh)=%u\n",
nlh->nlmsg_len, sizeof(*nlh));
#endif
kfree_skb(skb);
-break;
+goto out;
}
len = NLMSG_ALIGN(nlh->nlmsg_len);
@@ -233,22 +233,11 @@
len = skb->len;
err = __cn_rx_skb(skb, nlh);
-if (err) {
-#if 0
-if (err < 0 && (nlh->nlmsg_flags & NLM_F_ACK))
-netlink_ack(skb, nlh, -err);
-#endif
-break;
-} else {
-#if 0
-if (nlh->nlmsg_flags & NLM_F_ACK)
-netlink_ack(skb, nlh, 0);
-#endif
-break;
-}
-skb_pull(skb, len);
+if (err < 0)
+kfree_skb(skb);
}
-
+
+out:
kfree_skb(__skb);
}
@@ -310,7 +299,7 @@
m.ack = notify_event;
memcpy(, id, sizeof(m.id));
-cn_netlink_send(, ctl->group);
+cn_netlink_send(, ctl->group, GFP_ATOMIC);
}
}
spin_unlock_bh(_lock);
--- orig/include/linux/connector.h
+++ mod/include/linux/connector.h
@@ -148,7 +148,7 @@
int cn_add_callback(struct cb_id *, char *, void (* callback)(void *));
void cn_del_callback(struct cb_id *);
-void cn_netlink_send(struct cn_msg *, u32);
+void cn_netlink_send(struct cn_msg *, u32, int);
int cn_queue_add_callback(struct cn_queue_dev *dev, struct
cn_callback *cb);
void cn_queue_del_callback(struct cn_queue_dev *dev, struct cb_id *id);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] 'is_enabled' flag should be set/cleared when the device is actually enabled/disabled
On Fri, Apr 08, 2005 at 02:53:31PM +0900, Kenji Kaneshige wrote: > Hi, > > I think 'is_enabled' flag in pci_dev structure should be set/cleared > when the device actually enabled/disabled. Especially about > pci_enable_device(), it can be failed. By this change, we will also > get the possibility of refering 'is_enabled' flag from the functions > called through pci_enable_device()/pci_disable_device(). > > Signed-off-by: Kenji Kaneshige <[EMAIL PROTECTED]> Ah, nice catch. I've applied this to my trees now, thanks. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [fix Bug 4395] modprobe bttv freezes the computer
On Tue, Apr 05, 2005 at 04:55:52PM +0200, Johannes Stezenbach wrote: > Here's a patch that fixes > http://bugme.osdl.org/show_bug.cgi?id=4395. > > In case there's a 2.6.11.7 before 2.6.12 is released it would > be nice to include this patch there, too. Thanks, I've added this to the stable queue. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [stable] [patch 1/1] uml: quick fix syscall table [urgent]
On Wed, Apr 06, 2005 at 08:38:00PM +0200, [EMAIL PROTECTED] wrote: > > CC: <[EMAIL PROTECTED]> > > I'm resending this for inclusion in the -stable tree. I've deleted whitespace > cleanups, and hope this can be merged. I've been asked to split the former > patch, I don't know if I must split again this one, even because I don't want > to split this correct patch into multiple non-correct ones by mistake. Thanks, I've added this to the stable queue. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Friday 08 April 2005 13:24, Jon Masters wrote: > On Apr 7, 2005 6:54 PM, Daniel Phillips <[EMAIL PROTECTED]> wrote: > > So I propose that everybody who is interested, pick one of the above > > projects and join it, to help get it to the point of being able to > > losslessly import the version graph. Given the importance, I think that > > _all_ viable alternatives need to be worked on in parallel, so that two > > months from now we have several viable options. > > What about BitKeeper licensing constraints on such involvement? They don't apply to me, for one. Regards, Daniel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
IDE CMD 64x PCI driver
Hello,
I am having difficultly getting the IDE CMD 64x PCI driver to work for the
CMD PCI-648 device. I have decided to dig through kernel and driver code
to find out why and hopefully correct the problem.
I am running linux, version 2.4.21, on a PowerPC in the PCI Mezzanine Card
(PMC) form factor. The CompactPCI Carrier board that this PowerPC card
sits in supports 2 PMC devices. One of which is of course the PowerPC440,
provided by Artesyn, the other is the Compact Flash to IDE device provided
by CMD Technology; CMD PCI-648.
It appears that the kernel is unable to use the IRQ associated with the
CMD PCI-648 device. Ive traced the kernel output messages back to the
do_ide_setup_pci_device() function in drivers/ide/setup-pci.c. In this
portion of the code it seems to...
1. Determine if the device can be brought up in '100% native mode'
(whatever this means)
2. If it cannot bring it up in native mode it then, on a function
pointer, calls init_chipset_cmd64x() defined in the CMD68{3|6|8|9} driver
code (drivers/ide/pci/cmd64x.c). It uses the return value of this
function to assign the IRQ the system uses when communicating to the CMD
device. The init_chipset_cmd64x() function ALWAYS returns 0.
I decided that it would be beneficial to modify the return value of this
function hoping that everything would magically work. Needless to say
this wasn't the case. Before having modified the cmd64x.c driver code I
found, through `lspci` that the CMD device was configured to use IRQ 25.
So I modified the init_chipset_cmd64x() function to return the values 23 -
26 (in separate kernel builds).
I've attached portions of 3 `dmesg` outputs to this email; the first one
is the kernel with no changes, the second uses IRQ 25, and the third uses
IRQ 24. It seems that IRQ 24 yields results that appear slightly better
than IRQ 25. I've also attached the output of `lspci -vv`.
This is the first time I have been exposed to linux device driver / kernel
development. I am hoping someone may have some insight as to what I
should be looking for as I dig through the kernel code, IDE code, and
cmd64x driver code. At this point all recommendations are appreciated.
Thank you.
Regards,
Rob Gubler
DMESG: KERNEL WITH NO CHANGES
# dmesg
Linux version 2.4.21-pmppc440 ([EMAIL PROTECTED]) (gcc version
3.2.2 20030217 (Yellow Dog Linux 3.0 3.2.2-2a_1)5
Artesyn PM/PPC440 Copyright 2003, Artesyn Communication Products, LLC
... snip ...
PCI: Probing PCI hardware
PCI: Cannot allocate resource region 0 of device 00:02.0
PCI: Cannot allocate resource region 1 of device 00:02.0
PCI: Cannot allocate resource region 2 of device 00:02.0
PCI: Cannot allocate resource region 3 of device 00:02.0
PCI: Cannot allocate resource region 4 of device 00:02.0
PCI: Cannot allocate resource region 4 of device 00:03.0
PCI: Cannot allocate resource region 4 of device 00:03.1
PCI: moved device 00:02.0 resource 0 (101) to 1000
PCI: moved device 00:02.0 resource 1 (101) to 1000
PCI: moved device 00:02.0 resource 2 (101) to 1010
PCI: moved device 00:02.0 resource 3 (101) to 1000
PCI: moved device 00:02.0 resource 4 (101) to 1020
PCI: moved device 00:03.0 resource 4 (101) to 1040
PCI: moved device 00:03.1 resource 4 (101) to 1080
... snip ...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx CMD648: IDE controller at PCI slot 00:02.0
CMD648: chipset revision 1
CMD648: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:pio, hdb:pio ide1:
BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: SanDisk SDCFH-1024, CFA DISK drive
hda: IRQ probe failed (0x0)
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx blk: queue c01cbcd8, I/O limit 4095Mb (mask 0x)
Probing IDE interface ide1...
ide0: DISABLED, NO IRQ
... snip ...
DMESG: KERNEL USING IRQ 25
# dmesg
... snip ...
Uniform Multi-Platform E-IDE driver Revision: 7.00beta-2.4
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx CMD648: IDE controller at PCI slot 00:02.0
CMD648: chipset revision 1
CMD648: not 100% native mode: will probe irqs later
ide0: BM-DMA at 0x1020-0x1027, BIOS settings: hda:pio, hdb:pio ide1:
BM-DMA at 0x1028-0x102f, BIOS settings: hdc:pio, hdd:pio
Probing IDE interface ide0...
hda: SanDisk SDCFH-1024, CFA DISK drive
ide: Assuming 33MHz system bus speed for PIO modes; override with
idebus=xx blk: queue c01cbcd8, I/O limit 4095Mb (mask 0x)
Probing IDE interface ide1...
ide0 at 0x1000-0x1007,0x100a on irq 25
hda: lost interrupt
hda: lost interrupt
hda: lost interrupt
hda: task_no_data_intr: status=0x51 { DriveReady SeekComplete Error } hda:
task_no_data_intr: error=0x04 { DriveStatusError }
hda: 2001888 sectors (1025 MB) w/1KiB Cache, CHS=1986/16/63, DMA
Partition check:
/dev/ide/host0/bus0/target0/lun0:<4>hda:
Re: 'BUG: scheduling with irqs disabled' when umounting NFS volume
On Fri, 2005-04-08 at 13:38 -0700, Daniel Walker wrote: > I submitted a fix for this a while ago, I think .. > interruptible_sleep_on()'s are broken .. I saw the fix in -stable, but it does not seem to be in 2.6.12-rc2. Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Updated: Dynamic Tick version 050408-1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Tony Lindgren wrote: > * Frank Sorenson <[EMAIL PROTECTED]> [050408 01:49]: >>This updated patch seems to work just fine on my machine with lapic on >>the cmdline and CONFIG_DYN_TICK_USE_APIC disabled. >> >>Also, you were correct that removing lapic from the cmdline allowed the >>previous version to run at full speed. > > > Cool. > > >>Now, how can I tell if the patch is doing its thing? What should I be >>seeing? :) > > > Download pmstats from http://www.muru.com/linux/dyntick/, you may > need to edit it a bit for correct ACPI battery values. But it should > show you HZ during idle and load. I believe idle still does not go > to ACPI C3 with dyn-tick though... > > Then you might as well run timetest from same location too to make > sure your clock keeps correct time. Seems to be going up when under load, and down when idle, so I suppose it's working :) The clock is only a little jittery, but not more than I'd expect across the network, so it looks like it's keeping time okay. Would it be possible to determine whether the system will wake to the APIC interrupt at system boot, rather than hardcoded in the config? After you explained the problem, I noticed that creating my own interrupts (holding down a key on the keyboard for example) kept the system moving and not slow. For example, something like this (sorry, I don't know the code well enough yet to attempt to code it myself): set the APIC timer to fire in X set another timer/interrupt to fire in 2X wait for the interrupt if (time_elapsed >= 2X) disable the APIC timer else APIC timer should work Or, determine which timer woke us up, etc. Thanks, Frank - -- Frank Sorenson - KD7TZK Systems Manager, Computer Science Department Brigham Young University [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.6 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFCVvriaI0dwg4A47wRAhhyAJ928wgPEY/9X4KmyJcsaJ+WZk0XRQCfTfcj x3yKiwYOhMac/SQ7El9N0q0= =2QVB -END PGP 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: [patch] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
Lee Revell wrote: On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote: Lee Revell wrote: Meh, I'll try again, maybe it's some weird NFS problem. Lee Hmm. Maybe. I should probably mention that I am doing an FC3 install via NFS from my older SMP system right now while also building V0.7.44-03. Tried again and it works. Weird... Lee Very wierd. It worries me when things like that happen. ;-) -- kr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
A way to smoothly overgive graphics control to an other process/program
Hello, I feel disturbed by the fact that when display-controlling programs are started in line (like the bootloader, linux, and finally xdm/gdm/kdm), there appear several switches of display resolution, text- and graphics mode, and background images. I asked myself how to get that more smooth as if there was only one presentation from the time the bootloader started up to the gnome/kde session. I thought that one could implement a small api that allows a running process to freeze display updates until the next process has overtaken the display, loaded the same presentation (from same location or just by similar configuration), dumped it to the working buffer of the graphics card, and released the display (a timeout with fallback-mode could make this transaction more fault-resistent). This way, the image loaded by the bootloader could be held on display up to the graphical login, and even as the desktop background, without any visible effect. Is this technically feasible? Regards Dennis Heuer - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 Fri, 8 Apr 2005 [EMAIL PROTECTED] wrote: > > It looks like an operation like "show me the history of mm/memory.c" will > be pretty expensive using git. Yes. Per-file history is expensive in git, because if the way it is indexed. Things are indexed by tree and by changeset, and there are no per-file indexes. You could create per-file _caches_ (*) on top of git if you wanted to make it behave more like a real SCM, but yes, it's all definitely optimized for the things that _I_ tend to care about, which is the whole-repository operations. Linus (*) Doing caching on that level is probably find, especially since most people really tend to want it for just the relatively few files that they work on anyway. Limiting the caches to a subset of the tree should be quite effective. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Priority Lists for the RT mutex
>From: Daniel Walker [mailto:[EMAIL PROTECTED] > >On Thu, 2005-04-07 at 23:28, Ingo Molnar wrote: > >> this one looks really clean. >> >> it makes me wonder, what is the current status of fusyn's? Such a light >> datastructure would be much more mergeable upstream than the former >> 100-queues approach. > > Inaky was telling me that 100 queues approach is two years old. > >The biggest problem is that fusyn has it's own PI system .. So it's not >clear if that will work with the RT mutex,. I was thinking the PI stuff >could be made generic so, fusyn, maybe futex, can use it also . I concur with Daniel. If we can decide how to deal with that (toss one out, keep one, merge them, whatever), we could reuse all the user space glue that is the hardest part to get right. Current tip of development has some issues with conditional variables and broadcasts (requeue stuff) that I need to sink my teeth in. Joe Korty is fixing up a lot of corner cases I wasn't catching, but other than that is doing fine. How long ago since you saw it? I also implemented the futex redirection stuff we discussed some months ago. -- Inaky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
usbdux registers, but communcation to device times out
Hello, I am working with Fedora Core 2 and the regular (not fast) usbdux controller. We recently upgraded our Dell 2650 machine from RH 9.0 (kernel 2.4) to Fedora Core 2, kernel 2.6.10-1.771_FC2smp. The usb-dux controller worked great on our old kernel, but the new kernel has the following problem. We installed comedi and comedilib according to the instructions on http://www.linux-usb-daq.co.uk/drivers2/2.6/. There were no errors on installation, and the usbdux drivers were auto-detected by hotplug when the usbdux controller was plugged in. We saw the message "kernel: comedi0: usbdux: usb-device 0 is attached to comedi." However, when we run the demo programs or our old programs, we always get errno 110. The accompanying error message is something like "kernel: comedi0: could not transmit dux_command to the usb-device", or "kernel: usb1-1: lt-info timed out on ep4out". dmesg, lsmod, and /proc/comedi output files are attached. I'm very confused, since the device registered just fine with the usb-hotplug, so it must be talking. Can someone please explain this error and offer suggestions to resolve it? Linux linux1 2.6.10-1.771_FC2smp #1 SMP Mon Mar 28 01:10:51 EST 2005 i686 i686 i386 GNU/Linux comedilib-0.7.22 comedi-0.7.69 Thanks in advance, Melanie led. ACPI: PCI Interrupt Link [LNK2] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNK3] (IRQs 3 4 5 6 7 9 10 *11 12 14) ACPI: PCI Interrupt Link [LNK4] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNK5] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNK6] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNK7] (IRQs 3 4 5 6 7 9 *10 11 12 14) ACPI: PCI Interrupt Link [LNK8] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNK9] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 *7 9 10 11 12 14) ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 *10 11 12 14) ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 *7 9 10 11 12 14) ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11 12 14) ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 *10 11 12 14) ACPI: PCI Interrupt Link [LN10] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN11] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN12] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN13] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN14] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN15] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN16] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN17] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN18] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN19] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN1A] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN1B] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN1C] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN1D] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN1E] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LN1F] (IRQs 3 4 5 6 7 9 10 11 12 14) *0, disabled. ACPI: PCI Interrupt Link [LUSB] (IRQs 3 4 *5 6 7 10 11 12 14) Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 11 devices usbcore: registered new driver usbfs usbcore: registered new driver hub PCI: Using ACPI for IRQ routing ** PCI interrupts are no longer routed automatically. If this ** causes a device to stop working, it is probably because the ** driver failed to call pci_enable_device(). As a temporary ** workaround, the "pci=routeirq" argument restores the old ** behavior. If this argument makes the device work again, ** please email the output of "lspci" to [EMAIL PROTECTED] ** so I can fix the driver. pnp: 00:09: ioport range 0x800-0x89f could not be reserved pnp: 00:09: ioport range 0x8a0-0x8af has been reserved pnp: 00:09: ioport range 0xc00-0xcd7 has been reserved pnp: 00:09: ioport range 0xf50-0xf58 has been reserved pnp: 00:09: ioport range 0x8e0-0x8e3 has been reserved apm: BIOS not found. audit: initializing netlink socket (disabled) audit(1112905621.908:0): initialized highmem bounce pool size: 64 pages Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) SELinux: Registering netfilter hooks Initializing Cryptographic API ksign: Installing public key data Loading keyring - Added public key 4E4AD4CE5D64C848 - User ID: Red Hat, Inc. (Kernel Module GPG key) pci_hotplug: PCI Hot Plug PCI Core version: 0.5 isapnp: Scanning for PnP cards... isapnp: No
patch to fix bashism
Hi,
This patch fixes a three bashisms in
scripts/gen_initramfs_list.sh;
I'm not sure of the intention of the second change (local
name=...). So it's very well possible that:
+ local name="${location%/$srcdir}"
is more appropriate.
--- scripts/gen_initramfs_list.sh.orig 2005-03-27 14:53:15.628883408 +0200
+++ scripts/gen_initramfs_list.sh 2005-03-27 15:12:20.093898280 +0200
@@ -1,4 +1,7 @@
-#!/bin/bash
+#!/bin/sh
+
+# script is sourced, the shebang is ignored.
+
# Copyright (C) Martin Schlemmer <[EMAIL PROTECTED]>
# Released under the terms of the GNU GPL
#
@@ -56,9 +59,9 @@
parse() {
local location="$1"
- local name="${location/${srcdir}//}"
+ local name="${location#$srcdir/}"
# change '//' into '/'
- name="${name//\/\///}"
+ name=`echo $name|sed -e 's|//|/|g'`
local mode="$2"
local uid="$3"
local gid="$4"
@@ -68,8 +71,8 @@
[ "$gid" -eq "$root_gid" ] && gid=0
local str="${mode} ${uid} ${gid}"
- [ "${ftype}" == "invalid" ] && return 0
- [ "${location}" == "${srcdir}" ] && return 0
+ [ "${ftype}" = "invalid" ] && return 0
+ [ "${location}" = "${srcdir}" ] && return 0
case "${ftype}" in
"file")
# Han
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 <[EMAIL PROTECTED]> writes: > On Fri, 2005-04-08 at 01:58 +0200, Andreas Schwab wrote: >> Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: >> >> > Yes, that's very extreme, I suspect somebody is banging on set_par or >> > something like that. >> >> fb_setcolreg is it. > > Ok, what about that patch: > > --- > > This patch adds to the fbdev interface a set_cmap callback that allow > the driver to "batch" palette changes. This is useful for drivers like > radeonfb which might require lenghtly workarounds on palette accesses, > thus allowing to factor out those workarounds efficiently. This makes it better. But there is still a delay of half a second, and there is an annoying flicker when switching from X to the console. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Real-Time Preemption, -RT-2.6.12-rc2-V0.7.44-00
On Fri, 2005-04-08 at 15:26 -0500, K.R. Foley wrote: > Lee Revell wrote: > > > > Meh, I'll try again, maybe it's some weird NFS problem. > > > > Lee > > > > Hmm. Maybe. I should probably mention that I am doing an FC3 install via > NFS from my older SMP system right now while also building V0.7.44-03. > Tried again and it works. Weird... Lee - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtime attribute is not being updated on client
On Fri, 2005-04-08 at 09:11, Trond Myklebust wrote: > I'm a bit unclear as to what your end-goal is here. Is it basically to >ensure that fstat() always return the correct value for the mtime? > > The reason I ask is that I think your change is likely to have nasty >consequences for the general performance in a lot of other syscalls that >use nfs_revalidate_inode(). I would expect a particularly nasty hit in >the of the write() syscalls themselves, and they really shouldn't have >to worry about the value of mtime in the close-to-open cache consistency >model. >I therefore think we should look for a more fine-grained solution that >addresses more precisely the issues you see. > >Cheers, > Trond Hi Trond, The goal wasn't to ensure that fstat() always return the correct value for mtime. The goal is to update the mtime within the bounds of the min and max attribute cache timeouts, which was not happening before if the test ran for more than a minute. nfs_refresh_inode() was already being called after every write to the server and fattr->mtime was already set to the server's updated mtime value. However, it didn't check for an updated mtime value if data_unstable was set. Since nfs_refresh_inode() always resets the attribute timer (even when it skipped the mtime check), and the calls to it occurred more frequently than the attribute timer could expire, nfs_update_inode() was never being called again to update the inode's mtime. With the change I proposed, the test shows an mtime change every ~32 secs which corresponds to when the client writes the data to the server. Before this change, the test only showed one mtime change, even when it was run for > 10 mins. I did not see any increase in the calls to either nfs_revalidate_inode() or __nfs_revalidate_inode(). Do you think it would be better for nfs_refresh_inode() to check the mtime, perform the mtime update if needed, and not set the NFS_INO_INVALID_ATTR flag if the data_unstable flag is set? This is how nfs_update_inode() handles its mtime check. Regards, Linda - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux-2.6.11 can't disable CAD
It wasn't the kernel. Many thanks to those who helped me track down this problem. It seems that the 'C' runtime library was trapping the call to reboot() which probably should have been _reboot() in earlier code to prevent this. Anyway, the fix is to call the kernel directly so it doesn't get blamed for something it didn't do. Simple external procedure is attached if anybody else is interested. It ends up being only 0x30 bytes in length. Cheers, Dick Johnson Penguin : Linux version 2.6.11 on an i686 machine (5537.79 BogoMips). Notice : All mail here is now cached for review by Dictator Bush. 98.36% of all statistics are fiction.#-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Copyright(c) 2005 Analogic Corporation # # This program may be distributed under the GNU Public License # version 2, as published by the Free Software Foundation, Inc., # 59 Temple Place, Suite 330 Boston, MA, 02111. # #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= # # Disable Ctl-Alt-Del # Test environment 'C' runtime libraries are screwing with # this so I have to call the kernel directly. This is now # handled in assembly. # #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .extern __set_errno .LREBOOT = 88 .LMAGIC1 = 0xfee1dead .LMAGIC2 = 672274793 .LCADOFF = 0x disable_shutdown: pushl %ebx# Save precious registers pushl %esi movl$.LREBOOT, %eax # Reboot command movl$.LMAGIC1, %ebx # First magic parameter movl$.LMAGIC2, %ecx # Second magic parameter movl$.LCADOFF, %edx # Command xorl%esi, %esi # Zero ignored pointer int $0x80 # Make the call popl%esi# Restore precious registers popl%ebx orl %eax,%eax # Check return value jns 1f # It's okay negl%eax# Make positive pushl %eax call__set_errno # Set new errno addl$0x04, %esp # Level stack movl$-1, %eax 1: ret .size disable_shutdown,.-disable_shutdown .type disable_shutdown,@function .global disable_shutdown #-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= .end
Re: Kernel SCM saga..
It looks like an operation like "show me the history of mm/memory.c" will be pretty expensive using git. I'd need to look at the current tree, and then trace backwards through all 60,000 changesets to see which ones had actual changes to this file. Could you expand the tuple in the tree object to include a back pointer to the previous tree in which the tuple changed? Or does adding history to the tree violate other goals of the tree type? -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: non-free firmware in kernel modules, aggregation and unclear copyright notice.
> I think the "derivative work" angle is a red herring. I do not think > that either of the two parts that are being linked together (i.e. the > driver and the firmware) are derivates of the other. The relevant > point is that distribution of the linked _result_ is nevertheless > subject to the condition in GPL #2, which is in general the only > source we have for a permission to distribute a non-verbatim-source > form of the driver. If the thing distributed is not the covered work and not a derivative work, why does the GPL apply to it at all? 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/
