Re: [PATCH] 2.6.11-rc3 fix compile failure in arch/i386/kernel/i387.c
On Sat, Feb 05, 2005 at 08:40:14AM +0100, Michael Frank at BerliOS wrote: > > My local tree which was built incrementally since 2.6.8 or so has an extra > function: > > $ mdiff -kd xx linux-2.6.10-Vanilla linux-2.6.10-Today > diff -uN -r -X /etc/sys/dont/kexdiff linux-2.6.10-Vanilla/Makefile > linux-2.6.10-Today/Makefile > --- linux-2.6.10-Vanilla/Makefile 2005-01-04 5:54:17.0 +0100 > +++ linux-2.6.10-Today/Makefile 2005-02-05 08:02:11.0 +0100 > @@ -336,7 +336,7 @@ > CFLAGS_MODULE = $(MODFLAGS) > AFLAGS_MODULE = $(MODFLAGS) > LDFLAGS_MODULE = -r > -CFLAGS_KERNEL =-g > +CFLAGS_KERNEL = Just a hint. Use CONFIG_DEBUG_INFO - then you do not have to edit the Makefile. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
On Fri, 2005-02-04 at 11:20 -0600, Olof Johansson wrote:
> * cpu-has-feature(cpu-feature-foo) v cpu-has-feature(foo): I picked the
> latter for readability.
> * Renaming CPU_FTR_ -> CPU_ makes it less obvious that
> it's actually a cpu feature it's describing (i.e. CPU_ALTIVEC vs
> CPU_FTR_ALTIVEC).
> * Renaming would clobber the namespace, CPU_* definitions are used in
> other places in the tree.
> * Can't make it an inline and still use the preprocessor concatenation.
Seriously, if readability is your argument, macro magic is not the
answer. Ok, we can't clobber the CPU_ definitions, so pick another
prefix.
If you want readability, please consider using named enums:
enum cpu_feature {
CF_ALTIVEC = /* ... */
};
static inline int cpu_has_feature(enum cpu_feature cf) { }
Pekka
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: ftp.kernel.org was broken
On Saturday 05 February 2005 02:21, Grant wrote: >Hi there, > >On Sat, 05 Feb 2005 13:13:32 +0900, you wrote: >>Hi. >> >>ftp.kernel.org is broken. >>The contents are empty, and root(uid/gid) is displayed as 0 though >> /pub directory is seen. > >The country code versions appear to be working, I tried 'au' and > 'jp': ftp.au.kernel.org ftp.jp.kernel.org > >Perhaps they're spreading the load? > >Cheers, >Grant. Dunno, its responding to me here in WV, but everything is empty. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) 99.32% setiathome rank, not too shabby for a WV hillbilly Yahoo.com attorneys please note, additions to this message by Gene Heskett are: Copyright 2005 by Maurice Eugene Heskett, all rights reserved. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] 2.6.11-rc3 fix compile failure in arch/i386/kernel/i387.c
On Saturday 05 February 2005 13:36, you wrote:
> On Sat, Feb 05, 2005 at 06:29:06AM +0100, Michael Frank at BerliOS wrote:
> > Using patch-2.6.11-rc3.bz2 from kernel.org on top of
> > 2.6.10, a compile failure in /arch/i386/kernel/i387.c
> > due to tsk->used_math undef.
> >
> > The patch log shows offsets but no rejects
> >
> > patching file arch/i386/kernel/i387.c
> > Hunk #6 succeeded at 538 (offset 15 lines).
> > Hunk #7 succeeded at 553 (offset 15 lines).
>
> No offsets (or compile problems) here. Have you verified
> that your 2.6.10 had no local changes?
OK, checked that after downloading Vanilla 2.6.10 from kernel.org
My local tree which was built incrementally since 2.6.8 or so has an extra
function:
$ mdiff -kd xx linux-2.6.10-Vanilla linux-2.6.10-Today
diff -uN -r -X /etc/sys/dont/kexdiff linux-2.6.10-Vanilla/Makefile
linux-2.6.10-Today/Makefile
--- linux-2.6.10-Vanilla/Makefile 2005-01-04 5:54:17.0 +0100
+++ linux-2.6.10-Today/Makefile 2005-02-05 08:02:11.0 +0100
@@ -336,7 +336,7 @@
CFLAGS_MODULE = $(MODFLAGS)
AFLAGS_MODULE = $(MODFLAGS)
LDFLAGS_MODULE = -r
-CFLAGS_KERNEL =-g
+CFLAGS_KERNEL =
AFLAGS_KERNEL =
NOSTDINC_FLAGS = -nostdinc -iwithprefix include
diff -uN -r -X /etc/sys/dont/kexdiff
linux-2.6.10-Vanilla/arch/i386/kernel/i387.c
linux-2.6.10-Today/arch/i386/kernel/i387.c
--- linux-2.6.10-Vanilla/arch/i386/kernel/i387.c2005-01-04
5:54:17.0 +0100
+++ linux-2.6.10-Today/arch/i386/kernel/i387.c 2005-02-05 08:02:13.0
+0100
@@ -519,21 +519,6 @@
return fpvalid;
}
-int dump_extended_fpu( struct pt_regs *regs, struct user_fxsr_struct *fpu )
-{
- int fpvalid;
- struct task_struct *tsk = current;
-
- fpvalid = tsk->used_math && cpu_has_fxsr;
- if ( fpvalid ) {
- unlazy_fpu( tsk );
- memcpy( fpu, >thread.i387.fxsave,
- sizeof(struct user_fxsr_struct) );
- }
-
- return fpvalid;
-}
-
int dump_task_fpu(struct task_struct *tsk, struct user_i387_struct *fpu)
{
int fpvalid = tsk->used_math;
Above are the only differences between both trees and I have not touched i387.c
Looking at earlier patch logs, the 15 line offset appeared first with 2.6.10-rc3
and there were no rejects.
Would you happen to know when this function was removed?
Thank You
Michael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] x86-64: Fix compilation of 2.6.11rc3
[Linus, please apply before 2.6.11]
> > > CC arch/x86_64/kernel/asm-offsets.s
> > > arch/x86_64/kernel/asm-offsets.c: In function `main':
> > > arch/x86_64/kernel/asm-offsets.c:65: error: invalid
> > application of `sizeof'
> > > to an incomplete type
This patch fixes a compile problem on x86-64 when CONFIG_PM
is turned off.
Signed-off-by: Andi Kleen <[EMAIL PROTECTED]>
diff -u linux-2.6.11rc3/include/linux/suspend.h-o
linux-2.6.11rc3/include/linux/suspend.h
--- linux-2.6.11rc3/include/linux/suspend.h-o 2005-02-04 09:13:32.0
+0100
+++ linux-2.6.11rc3/include/linux/suspend.h 2005-02-05 08:25:13.0
+0100
@@ -10,7 +10,6 @@
#include
#include
-#ifdef CONFIG_PM
/* page backup entry */
typedef struct pbe {
unsigned long address; /* address of the copy */
@@ -33,6 +32,7 @@
extern void drain_local_pages(void);
extern void mark_free_pages(struct zone *zone);
+#ifdef CONFIG_PM
/* kernel/power/swsusp.c */
extern int software_suspend(void);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: ftp.kernel.org was broken
Hi there, On Sat, 05 Feb 2005 13:13:32 +0900, you wrote: >Hi. > >ftp.kernel.org is broken. >The contents are empty, and root(uid/gid) is displayed as 0 though /pub >directory is seen. The country code versions appear to be working, I tried 'au' and 'jp': ftp.au.kernel.org ftp.jp.kernel.org Perhaps they're spreading the load? Cheers, Grant. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.10: kswapd spins like crazy
Nick Piggin <[EMAIL PROTECTED]> skrev: > OK that's good to know. At this stage it is only > working around the intermediate symptoms, and we > might want a different fix for 2.6.11... > > So hopefully you'll be able to test a patch or two > if you get time. Sure. Just drop me a mail. I'm glad if I can help. Regards, Terje - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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.11-rc3] IBM Trackpoint support
On Friday 04 February 2005 09:45, Vojtech Pavlik wrote:
> On Fri, Feb 04, 2005 at 09:17:33AM -0500, Dmitry Torokhov wrote:
>
> > It is still a problem if driver is registered after the port has been
> > detected wich quite often is the case as many people have psmouse as a
> > module.
> >
> > I wonder if we should make driver registration asynchronous too.
>
> Probably yes.
>
> > I
> > don't forsee any issues providing that I bump up module's reference
> > count while driver structure is "in flight", do you?
>
> No, looks OK to me, too.
>
Ok, what about the following patch then?
--
Dmitry
===
[EMAIL PROTECTED], 2005-02-05 01:48:45-05:00, [EMAIL PROTECTED]
Input: make serio drivers register asynchronously. This should
speed up boot process as some drivers take a long time
probing for supported devices.
Also change __inline__ to inline in serio.h
Signed-off-by: Dmitry Torokhov <[EMAIL PROTECTED]>
drivers/input/serio/serio.c | 65
include/linux/serio.h | 25 ++--
2 files changed, 51 insertions(+), 39 deletions(-)
===
diff -Nru a/drivers/input/serio/serio.c b/drivers/input/serio/serio.c
--- a/drivers/input/serio/serio.c 2005-02-05 01:53:56 -05:00
+++ b/drivers/input/serio/serio.c 2005-02-05 01:53:56 -05:00
@@ -44,7 +44,7 @@
EXPORT_SYMBOL(__serio_register_port);
EXPORT_SYMBOL(serio_unregister_port);
EXPORT_SYMBOL(__serio_unregister_port_delayed);
-EXPORT_SYMBOL(serio_register_driver);
+EXPORT_SYMBOL(__serio_register_driver);
EXPORT_SYMBOL(serio_unregister_driver);
EXPORT_SYMBOL(serio_open);
EXPORT_SYMBOL(serio_close);
@@ -120,18 +120,19 @@
* Serio event processing.
*/
-struct serio_event {
- int type;
- struct serio *serio;
- struct module *owner;
- struct list_head node;
-};
-
enum serio_event_type {
SERIO_RESCAN,
SERIO_RECONNECT,
SERIO_REGISTER_PORT,
SERIO_UNREGISTER_PORT,
+ SERIO_REGISTER_DRIVER,
+};
+
+struct serio_event {
+ enum serio_event_type type;
+ void *object;
+ struct module *owner;
+ struct list_head node;
};
static DEFINE_SPINLOCK(serio_event_lock); /* protects serio_event_list */
@@ -140,7 +141,7 @@
static DECLARE_COMPLETION(serio_exited);
static int serio_pid;
-static void serio_queue_event(struct serio *serio, struct module *owner,
+static void serio_queue_event(void *object, struct module *owner,
enum serio_event_type event_type)
{
unsigned long flags;
@@ -156,7 +157,7 @@
* we need to preseve sequence of distinct events.
*/
list_for_each_entry_reverse(event, _event_list, node) {
- if (event->serio == serio) {
+ if (event->object == object) {
if (event->type == event_type)
goto out;
break;
@@ -170,7 +171,7 @@
}
event->type = event_type;
- event->serio = serio;
+ event->object = object;
event->owner = owner;
list_add_tail(>node, _event_list);
@@ -198,7 +199,7 @@
list_for_each_safe(node, next, _event_list) {
e = list_entry(node, struct serio_event, node);
- if (event->serio == e->serio) {
+ if (event->object == e->object) {
/*
* If this event is of different type we should not
* look further - we only suppress duplicate events
@@ -241,6 +242,7 @@
static void serio_handle_events(void)
{
struct serio_event *event;
+ struct serio_driver *serio_drv;
down(_sem);
@@ -248,21 +250,26 @@
switch (event->type) {
case SERIO_REGISTER_PORT:
- serio_add_port(event->serio);
+ serio_add_port(event->object);
break;
case SERIO_UNREGISTER_PORT:
- serio_disconnect_port(event->serio);
- serio_destroy_port(event->serio);
+ serio_disconnect_port(event->object);
+ serio_destroy_port(event->object);
break;
case SERIO_RECONNECT:
- serio_reconnect_port(event->serio);
+ serio_reconnect_port(event->object);
break;
case SERIO_RESCAN:
- serio_disconnect_port(event->serio);
- serio_find_driver(event->serio);
+
Re: [PATCH] relayfs redux, part 3
> The main reason would be that length would be 0 only if the buffers > were full, so the caller can suspend writing if it sees that, until > e.g. a daemon catches up. Would be? Is there actually any caller doing this? Better eliminate it and if someone really does it add a separate function that checks this condition. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] arp_queue: serializing unlink + kfree_skb
On Fri, Feb 04, 2005 at 10:24:28PM -0800, David S. Miller wrote:
>
> Ok, as promised, here is the updated doc. Who should
Looks good David.
--
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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
On Fri, Feb 04, 2005 at 10:13:44PM -0800, David S. Miller wrote:
>
> But Herbert, let's take a step back real quick because I want
> to point something out. IPv6 does try to handle the dangling
> mismatched idev's, in route.c:ip6_dst_ifdown(), this is called
> via net/core/dst.c:dst_ifdown(), and this releases the ipv6
> idev correctly in the split device case.
>
> Did your analysis of this bridging release bug take this into
> account? That's why we added this dst->ops method, specifically
> to handle this problem.
This doesn't work because net/core/dst.c can only search based
on dst->dev. For the split device case, dst->dev is set to
loopback_dev while rt6i_idev is set to the real device.
Therefore net/core/dst.c stands no chance of finding the correct
local address routes that it needs to process.
If we wanted to preserve the split device semantics, then we
can create a local GC list in IPv6 so that it can search based
on rt6i_idev as well as the other keys. Alternatively we can
remove the dst->dev == dev check in dst_dev_event and dst_ifdown
and move that test down to the individual ifdown functions.
However, IMHO the split device semantics is inconsistent with
the philosphy that addresses belong to the host and not the
interface. So it doesn't really make sense in the current
networking stack.
Cheers,
--
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/
bk-usb is now safe (was 2.6.11-rc3-mm1)
On Fri, Feb 04, 2005 at 10:33:50AM -0800, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/ > > > - The bk-usb and bk-pci and bk-driver-core trees have been temporarily > dropped from -mm, for they are not healthy at present. Ok, I've cleaned up the bk-usb tree a bunch. If anyone had a previous copy of it, please just delete it and clone it again. It's at: bk://kernel.bkbits.net/gregkh/linux/usb-2.6 and is safe for consumption. Andrew, can you put it back into the next -mm release? Oh, and below is the diffstat and changelog of the patches in it. I've also placed a full patch of it, against the 2.6.11-rc3-bk1 tree for those who don't like to use bk, or are just curious about putting this on top of the latest -mm release: kernel.org/pub/linux/kernel/people/gregkh/usb/2.6/2.6.11-rc3/bk-usb-2.6.11-rc3-mm1.patch Also, if you have sent me a USB patch that is not already in the mainline tree, and is not included in this big patch-bundle, please resend it, as my USB patch queue is now empty. Oops, no, I have a pending patch from Petko Manolov that didn't make it into here, sorry about that Petko, I'll get to that one next week. Next up, the bk-pci and bk-driver-core mess... thanks, greg k-h --- CREDITS |5 Documentation/usb/sn9c102.txt | 13 MAINTAINERS |6 drivers/block/ub.c | 181 +- drivers/usb/Kconfig |2 drivers/usb/Makefile|2 drivers/usb/class/cdc-acm.c | 84 drivers/usb/class/cdc-acm.h | 49 drivers/usb/core/hcd.c | 166 + drivers/usb/core/hcd.h | 60 drivers/usb/core/hub.c | 56 drivers/usb/core/hub.h |1 drivers/usb/gadget/Kconfig |8 drivers/usb/gadget/ether.c | 237 -- drivers/usb/gadget/net2280.c| 25 drivers/usb/gadget/omap_udc.c | 30 drivers/usb/gadget/rndis.c |2 drivers/usb/gadget/serial.c | 154 - drivers/usb/host/Kconfig| 36 drivers/usb/host/ohci-dbg.c |4 drivers/usb/host/ohci-hcd.c | 34 drivers/usb/host/ohci-omap.c| 98 - drivers/usb/host/ohci-ppc-soc.c | 299 +++ drivers/usb/host/ohci-q.c |9 drivers/usb/host/ohci.h | 48 drivers/usb/host/uhci-debug.c |9 drivers/usb/host/uhci-hcd.c | 1497 - drivers/usb/host/uhci-q.c | 1488 + drivers/usb/image/mdc800.c | 42 drivers/usb/input/ati_remote.c | 19 drivers/usb/input/hid-core.c| 20 drivers/usb/input/wacom.c | 335 +++ drivers/usb/media/sn9c102.h |6 drivers/usb/media/sn9c102_core.c| 52 drivers/usb/misc/Kconfig|2 drivers/usb/misc/Makefile |2 drivers/usb/misc/auerswald.c| 19 drivers/usb/misc/sisusbvga/Kconfig | 14 drivers/usb/misc/sisusbvga/Makefile |6 drivers/usb/misc/sisusbvga/sisusb.c | 3144 drivers/usb/misc/sisusbvga/sisusb.h | 278 +++ drivers/usb/mon/Kconfig | 22 drivers/usb/mon/Makefile|7 drivers/usb/mon/mon_main.c | 377 drivers/usb/mon/mon_stat.c | 74 drivers/usb/mon/mon_text.c | 395 drivers/usb/mon/usb_mon.h | 51 drivers/usb/net/Kconfig |4 drivers/usb/net/kaweth.c| 13 drivers/usb/net/usbnet.c| 571 +- drivers/usb/serial/cypress_m8.c |6 drivers/usb/serial/ftdi_sio.c |3 drivers/usb/serial/ftdi_sio.h |1 drivers/usb/serial/io_edgeport.c| 49 drivers/usb/storage/Kconfig | 22 drivers/usb/storage/Makefile|2 drivers/usb/storage/protocol.c | 39 drivers/usb/storage/scsiglue.c | 10 drivers/usb/storage/shuttle_usbat.c | 1258 +++--- drivers/usb/storage/shuttle_usbat.h | 82 drivers/usb/storage/transport.c | 23 drivers/usb/storage/transport.h |5 drivers/usb/storage/unusual_devs.h | 39 drivers/usb/storage/usb.c | 10 drivers/usb/storage/usb.h |2 include/linux/usb.h |4 include/linux/usb_cdc.h | 162 + 67 files changed, 9056 insertions(+), 2717 deletions(-) - : o USB ftdi_sio: an rs485 adaptor from 4n-galaxy.de Alan Stern: o USB: UHCI: Fix build errors when CONFIG_DEBUG_FS isn't set o USB: Revised fixups for root-hub message handler o USB UHCI: split code from uhci-hcd.c to new file uhci-q.c o USB: Initialize connected ports on newly-activated hubs o USB: Make use_both_schemes=y the default o USB: Retry more aggressively during device initialization Alex Sanks: o USB: don't power down net2280 on suspend Bernard Blackham:
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
On Fri, 4 Feb 2005 15:48:55 -0800
"David S. Miller" <[EMAIL PROTECTED]> wrote:
> Something like that. I'll update the atomic_ops.txt
> doc and post and updated version later tonight.
Ok, as promised, here is the updated doc. Who should
I author this as? Perhaps "Anton's evil twin" :-)
--- atomic_ops.txt ---
This document is intended to serve as a guide to Linux port
maintainers on how to implement atomic counter and bitops operations
properly.
The atomic_t type should be defined as a signed integer.
Also, it should be made opaque such that any kind of cast to
a normal C integer type will fail. Something like the following
should suffice:
typedef struct { volatile int counter; } atomic_t;
The first operations to implement for atomic_t's are
the initializers and plain reads.
#define ATOMIC_INIT(i) { (i) }
#define atomic_set(v, i)((v)->counter = (i))
The first macro is used in definitions, such as:
static atomic_t my_counter = ATOMIC_INIT(1);
The second interface can be used at runtime, as in:
k = kmalloc(sizeof(*k), GFP_KERNEL);
if (!k)
return -ENOMEM;
atomic_set(>counter, 0);
Next, we have:
#define atomic_read(v) ((v)->counter)
which simply reads the current value of the counter.
Now, we move onto the actual atomic operation interfaces.
void atomic_add(int i, atomic_t *v);
void atomic_sub(int i, atomic_t *v);
void atomic_inc(atomic_t *v);
void atomic_dec(atomic_t *v);
These four routines add and subtract integral values to/from the given
atomic_t value. The first two routines pass explicit integers by
which to make the adjustment, whereas the latter two use an implicit
adjustment value of "1".
One very important aspect of these two routines is that
they DO NOT require any explicit memory barriers. They
need only perform the atomic_t counter update in an SMP
safe manner.
Next, we have:
int atomic_inc_return(atomic_t *v);
int atomic_dec_return(atomic_t *v);
These routines add 1 and subtract 1, respectively, from
the given atomic_t and return the new counter value after
the operation is performed.
Unlike the above routines, it is required that explicit memory
barriers are performed before and after the operation. It must
be done such that all memory operations before and after the
atomic operation calls are strongly ordered with respect to the
atomic operation itself.
For example, it should behave as if a smp_mb() call existed both
before and after the atomic operation.
If the atomic instructions used in an implementation provide
explicit memory barrier semantics which satisfy the above requirements,
that is fine as well.
Let's move on:
int atomic_add_return(int i, atomic_t *v);
int atomic_sub_return(int i, atomic_t *v);
These behave just like atomic_{inc,dec}_return() except that an
explicit counter adjustment is given instead of the implicit "1".
This means that like atomic_{inc,dec}_return(), the memory barrier
semantics are required.
Next:
int atomic_inc_and_test(atomic_t *v);
int atomic_dec_and_test(atomic_t *v);
These two routines increment and decrement by 1, respectively,
the given atomic counter. They return a boolean indicating
whether the resulting counter value was zero or not.
It requires explicit memory barrier semantics around the operation
as above.
int atomic_sub_and_test(int i, atomic_t *v);
This is identical to atomic_dec_and_test() except that an explicit
decrement is given instead of the implicit "1". It requires explicit
memory barrier semantics around the operation.
int atomic_add_negative(int i, atomic_t *v);
The given increment is added to the given atomic counter value.
A boolean is return which indicates whether the resulting counter
value is negative. It requires explicit memory barrier semantics
around the operation.
If a caller requires memory barrier semantics around an atomic_t
operation which does not return a value, a set of interfaces
are defined which accomplish this:
void smb_mb__before_atomic_dec(void);
void smb_mb__after_atomic_dec(void);
void smb_mb__before_atomic_inc(void);
void smb_mb__after_atomic_dec(void);
For example, smb_mb__before_atomic_dec() can be used like so:
obj->dead = 1;
smb_mb__before_atomic_dec();
atomic_dec(>ref_count);
It makes sure that all memory operations preceeding the atomic_dec()
call are strongly ordered with respect to the atomic counter
operation. In the above example, it guarentees that the assignment
of "1" to obj->dead will be globally visible to other cpus before
the atomic counter decrement.
Without the explicitl smb_mb__before_atomic_dec() call, the
implementation could legally allow the atomic counter update
visible to other cpus before the "obj->dead = 1;" assignment.
The other three interfaces listed are used to
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
On Sat, 5 Feb 2005 17:11:10 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> You're right of course. I thought they were all harmless but I was
> obviously wrong about this one.
>
> So here is a patch that essentially reverts the split devices
> semantics introduced by these two changesets:
>
> [IPV6] addrconf_dst_alloc() to allocate new route for local address.
> [IPV6] take rt6i_idev into account when looking up routes.
>
> Signed-off-by: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Ok.
But Herbert, let's take a step back real quick because I want
to point something out. IPv6 does try to handle the dangling
mismatched idev's, in route.c:ip6_dst_ifdown(), this is called
via net/core/dst.c:dst_ifdown(), and this releases the ipv6
idev correctly in the split device case.
Did your analysis of this bridging release bug take this into
account? That's why we added this dst->ops method, specifically
to handle this problem.
This was added by Yoshifuji-san in ChangeSet 1.1722.137.17 which
has the checking comment:
[NET]: Add dst->ifdown callback.
Use it to release protocol specific objects that may be
tied to a dst cache object, at ifdown time. Currently
this is used to release ipv4/ipv6 specific device state.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] input/gameport/cs461x.c: make 2 functions static
On Sat, Feb 05, 2005 at 03:41:32AM +0100, Adrian Bunk wrote: > This patch makes two needlessly global functions static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Thanks, applied. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6 patch] input: make some code static
On Fri, Feb 04, 2005 at 04:56:45PM -0500, Dmitry Torokhov wrote: > On Fri, 4 Feb 2005 22:39:55 +0100, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > This patch makes some needlessly global code static. > > > > Hi Adrian, > > I merged your patch into my tree and it is ready for Vojtech to pull from. Dmitry, I already pulled. :) Btw, please use my [EMAIL PROTECTED] (or @suse.de) e-mail addresses during the weekend, as mu @suse.cz doesn't work and likely won't be fixed until Monday. -- Vojtech Pavlik SuSE Labs, SuSE CR - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/7] driver core: export MAJOR/MINOR to the hotplug env
On Wed, Feb 02, 2005 at 01:48:12AM +0100, Kay Sievers wrote: > On Tue, Feb 01, 2005 at 02:56:25PM -0800, Greg KH wrote: > > Hm, that class_simple interface is looking like the way we should move > > toward, as it's "simple" to use, instead of the more complex class code. > > I'll have to look at migrating more code to use it over time, or move > > that interface back into the class code itself... > > Nice idea! What about keeping a list of devices belonging to a > specific class in an own list in 'struct class' and maintaining that list > with class_device_add(), class_device_del()? What would that help out with? > A class driver may use that list to keep track of its own devices if > wanted and class_simple would not be needed anymore as everything > would be available in the core. I must be tired, but I don't see how class_simple could be dropped if that was done. Care to explain it with pseudo-code or something? 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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
On Fri, Feb 04, 2005 at 09:38:13PM -0800, David S. Miller wrote:
>
> It is just the first such thing I found, scanning rt6i_idev uses
> will easily find several others.
You're right of course. I thought they were all harmless but I was
obviously wrong about this one.
So here is a patch that essentially reverts the split devices
semantics introduced by these two changesets:
[IPV6] addrconf_dst_alloc() to allocate new route for local address.
[IPV6] take rt6i_idev into account when looking up routes.
Signed-off-by: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Cheers,
--
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
= include/net/ip6_route.h 1.21 vs edited =
--- 1.21/include/net/ip6_route.h2004-10-26 14:27:49 +10:00
+++ edited/include/net/ip6_route.h 2005-02-05 17:02:36 +11:00
@@ -74,8 +74,7 @@
extern int ndisc_dst_gc(int *more);
extern void fib6_force_start_gc(void);
-extern struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
- const struct in6_addr *addr,
+extern struct rt6_info *addrconf_dst_alloc(const struct in6_addr *addr,
int anycast);
/*
= net/ipv6/addrconf.c 1.129 vs edited =
--- 1.129/net/ipv6/addrconf.c 2005-01-18 08:13:31 +11:00
+++ edited/net/ipv6/addrconf.c 2005-02-05 17:02:00 +11:00
@@ -509,7 +509,7 @@
goto out;
}
- rt = addrconf_dst_alloc(idev, addr, 0);
+ rt = addrconf_dst_alloc(addr, 0);
if (IS_ERR(rt)) {
err = PTR_ERR(rt);
goto out;
= net/ipv6/anycast.c 1.19 vs edited =
--- 1.19/net/ipv6/anycast.c 2005-01-15 08:30:07 +11:00
+++ edited/net/ipv6/anycast.c 2005-02-05 17:01:47 +11:00
@@ -340,7 +340,7 @@
goto out;
}
- rt = addrconf_dst_alloc(idev, addr, 1);
+ rt = addrconf_dst_alloc(addr, 1);
if (IS_ERR(rt)) {
kfree(aca);
err = PTR_ERR(rt);
= net/ipv6/ip6_fib.c 1.34 vs edited =
--- 1.34/net/ipv6/ip6_fib.c 2005-01-14 15:41:06 +11:00
+++ edited/net/ipv6/ip6_fib.c 2005-02-05 17:04:02 +11:00
@@ -450,7 +450,6 @@
*/
if (iter->rt6i_dev == rt->rt6i_dev &&
- iter->rt6i_idev == rt->rt6i_idev &&
ipv6_addr_equal(>rt6i_gateway,
>rt6i_gateway)) {
if (!(iter->rt6i_flags_EXPIRES))
= net/ipv6/route.c 1.105 vs edited =
--- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00
+++ edited/net/ipv6/route.c 2005-02-05 17:01:23 +11:00
@@ -189,17 +189,8 @@
struct net_device *dev = sprt->rt6i_dev;
if (dev->ifindex == oif)
return sprt;
- if (dev->flags & IFF_LOOPBACK) {
- if (sprt->rt6i_idev == NULL ||
- sprt->rt6i_idev->dev->ifindex != oif) {
- if (strict && oif)
- continue;
- if (local && (!oif ||
-
local->rt6i_idev->dev->ifindex == oif))
- continue;
- }
+ if (dev->flags & IFF_LOOPBACK)
local = sprt;
- }
}
if (local)
@@ -1385,8 +1376,7 @@
* Allocate a dst for local (unicast / anycast) address.
*/
-struct rt6_info *addrconf_dst_alloc(struct inet6_dev *idev,
- const struct in6_addr *addr,
+struct rt6_info *addrconf_dst_alloc(const struct in6_addr *addr,
int anycast)
{
struct rt6_info *rt = ip6_dst_alloc();
@@ -1395,13 +1385,12 @@
return ERR_PTR(-ENOMEM);
dev_hold(_dev);
- in6_dev_hold(idev);
rt->u.dst.flags = DST_HOST;
rt->u.dst.input = ip6_input;
rt->u.dst.output = ip6_output;
rt->rt6i_dev = _dev;
- rt->rt6i_idev = idev;
+ rt->rt6i_idev = in6_dev_get(_dev);
rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev);
rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(>u.dst));
rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev);
[XFRM]: Probe selected algorithm only - 2.6.11-rc3 IPSEC problem
Using 2.6.11-rc3 with Openswan, no IPSEC SA can be established. Kernel
logs "kernel: ESP: md5 digestsize 16 != 0" and netlink returns an error.
The changes to XFRM in 2.6.11-rc3 have an error in xfrm_algo.c such that
xfrm_aalg_get_byname() always returns digest_null (which would indeed
have a zero length digest...)
The problem is here:
$ diff -Naur net/xfrm/xfrm_algo.c*
--- net/xfrm/xfrm_algo.c2005-02-04 18:05:53.0 -0500
+++ net/xfrm/xfrm_algo.c~ 2005-02-04 08:08:16.0 -0500
@@ -357,7 +357,7 @@
return NULL;
for (i = 0; i < entries; i++) {
- if (strcmp(name, list[i].name) != 0)
+ if (!strcmp(name, list[i].name))
continue;
if (list[i].available)
where the sense of (!strcmp()) is reversed. It's easier to read by
explicitly comparing to zero, IMHO, as I did in this patch.
--
Andy <[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] Real-Time Preemption, -RT-2.6.11-rc2-V0.7.37-02
On Thu, 2005-02-03 at 21:18 -0500, Steven Rostedt wrote:
> Here's the problem: If I raise the priorities of the processes before
> zeroing the semaphore, the machine hangs. If I zero the semaphore
> before raising the priorities, the program runs fine.
Hi Ingo,
I've looked into this and found where the deadlock occurs. Actually it
is a starving of processes. I finally got around to trying it on
2.6.11-rc3, and it doesn't have a problem.
Anyway, here's the scoop.
The parent process that zeros the semaphore to allow the child process
to run after the parent upped the priority of the child really high,
gets stuck in the following:
In update_queue in ipc/sem.c (I don't have the correct line numbers,
cause I haven't stripped out the debug yet). at the point of:
q->status = IN_WAKEUP;
/*
* Continue scanning. The next operation
* that must be checked depends on the type of the
* completed operation:
* - if the operation modified the array, then
* restart from the head of the queue and
* check for threads that might be waiting
* for semaphore values to become 0.
* - if the operation didn't modify the array,
* then just continue.
*/
if (q->alter)
n = sma->sem_pending;
else
n = q->next;
wake_up_process(q->sleeper);
Here is where it locks up.
/* hands-off: q will disappear immediately after
* writing q->status.
*/
q->status = error;
I also found that the high priority child is running in an infinite
while loop in sys_semtimedop in the same file, at the following:
while(unlikely(error == IN_WAKEUP)) {
cpu_relax();
error = queue.status;
}
So, what looks to be happening is that as soon as the parent wakes up
the child, the child preempts the parent, and hits this while loop. But
since the child is a realtime task, with the highest priority of the
system, it starves the system. Of course this is a UP and I don't think
this will show a problem on an SMP machine.
I can't think of a solution right now, so I'll just pass it on to
you ;-). Once again it's late and I'm going to bed.
Thanks,
-- 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: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
On Sat, 5 Feb 2005 16:24:07 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> This is the key to the problem.
...
> All of these bugs stem from the idev reference held in rtable/rt6_info.
...
> Anyway, this particular problem is due to IPv6 adding local addresses
> with split devices. That is, routes to local addresses are added with
> rt6i_dev set to _dev and rt6i_idev set to the idev of the
> device where the address is added.
...
> It also goes against the Linux philosophy where the addresses are owned
> by the host, not the interface.
>
> Therefore I propose the simple solution of not doing the split device
> accounting in rt6_info.
I agree with your analysis, however... this change is not sufficient.
You have to then walk over all the uses of rt6i_dev and sanitize the
cases that still expect the split semantics. For example, things like
this piece of coe in rt6_device_match():
if (dev->flags & IFF_LOOPBACK) {
if (sprt->rt6i_idev == NULL ||
sprt->rt6i_idev->dev->ifindex != oif) {
if (strict && oif)
continue;
if (local && (!oif ||
local->rt6i_idev->dev->ifindex == oif))
continue;
}
local = sprt;
}
It is just the first such thing I found, scanning rt6i_idev uses
will easily find several others.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.11-rc3 fix compile failure in arch/i386/kernel/i387.c
On Sat, Feb 05, 2005 at 06:29:06AM +0100, Michael Frank at BerliOS wrote: > Using patch-2.6.11-rc3.bz2 from kernel.org on top of 2.6.10, > a compile failure in /arch/i386/kernel/i387.c due to tsk->used_math undef. > > The patch log shows offsets but no rejects > > patching file arch/i386/kernel/i387.c > Hunk #6 succeeded at 538 (offset 15 lines). > Hunk #7 succeeded at 553 (offset 15 lines). No offsets (or compile problems) here. Have you verified that your 2.6.10 had no local changes? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] 2.6.11-rc3 fix compile failure in arch/i386/kernel/i387.c
Using patch-2.6.11-rc3.bz2 from kernel.org on top of 2.6.10,
a compile failure in /arch/i386/kernel/i387.c due to tsk->used_math undef.
The patch log shows offsets but no rejects
patching file arch/i386/kernel/i387.c
Hunk #6 succeeded at 538 (offset 15 lines).
Hunk #7 succeeded at 553 (offset 15 lines).
Patch below fixes it.
Regards
Michael
Signed off by: Michael Frank <[EMAIL PROTECTED]>
diff -uN linux-2.6.11-rc3-Vanilla/arch/i386/kernel/i387.c
linux-2.6.11-rc3-mhf241/arch/i386/kernel/i387.c
--- linux-2.6.11-rc3-Vanilla/arch/i386/kernel/i387.c2005-02-04
10:43:06.0 +0100
+++ linux-2.6.11-rc3-mhf241/arch/i386/kernel/i387.c 2005-02-04
11:12:53.0 +0100
@@ -526,7 +526,7 @@
int fpvalid;
struct task_struct *tsk = current;
- fpvalid = tsk->used_math && cpu_has_fxsr;
+ fpvalid = !!used_math() && cpu_has_fxsr;
if ( fpvalid ) {
unlazy_fpu( tsk );
memcpy( fpu, >thread.i387.fxsave,
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PROBLEM: 2.6.11-rc2 hangs on bridge shutdown (br0)
On Mon, Jan 31, 2005 at 04:22:02PM +, Mirko Parthey wrote:
>
> How to reproduce the problem (I tried this on a Pentium 4 machine):
>
> boot: linux init=/bin/bash
> [...booting...]
> # mount proc -t proc /proc
> # ifconfig lo 127.0.0.1
> # brctl addbr br0
> # modprobe e100 # also reproducible with 3c5x9
> # brctl addif br0 eth0
> # ifconfig br0 192.168.1.1
> # ifconfig eth0 up
> # ifconfig lo down
This is the key to the problem.
It took me a while to find the cause of this. Along the way I
found a few other ref counting bugs in this area as well.
All of these bugs stem from the idev reference held in rtable/rt6_info.
Looking back in my mailbox, it's amazing how many problems this piece
of infrastructure has caused since it was installed last June. AFAIK
to this day there is still no code in the kernel that actually uses
this infrastructure.
Anyway, this particular problem is due to IPv6 adding local addresses
with split devices. That is, routes to local addresses are added with
rt6i_dev set to _dev and rt6i_idev set to the idev of the
device where the address is added.
This is just not going to work unless IPv6 creates its own dst garbage
collection routine since the generic GC in net/core/dst.c has no way
of finding all the rt6_info's referring to a specific net_device through
rt6i_idev.
It is also different from the IPv4 behaviour where we set both dev
and idev to loopback_dev.
Now this stuff is apparently going to be used for IP statistics. As
it is packets sent to/received from local addresses are counted against
the loopback device. Linux has behaved this way for a long time. So
when these statistics actually get implemented it will be very strange
if they were accounted to the device owning the local addresses instead
of loopback.
It also goes against the Linux philosophy where the addresses are owned
by the host, not the interface.
Therefore I propose the simple solution of not doing the split device
accounting in rt6_info.
Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>
I will send the patches for the other bugs separately.
Cheers,
--
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
= net/ipv6/route.c 1.105 vs edited =
--- 1.105/net/ipv6/route.c 2005-01-15 19:44:48 +11:00
+++ edited/net/ipv6/route.c 2005-02-05 16:10:19 +11:00
@@ -1395,13 +1395,12 @@
return ERR_PTR(-ENOMEM);
dev_hold(_dev);
- in6_dev_hold(idev);
rt->u.dst.flags = DST_HOST;
rt->u.dst.input = ip6_input;
rt->u.dst.output = ip6_output;
rt->rt6i_dev = _dev;
- rt->rt6i_idev = idev;
+ rt->rt6i_idev = in6_dev_get(_dev);
rt->u.dst.metrics[RTAX_MTU-1] = ipv6_get_mtu(rt->rt6i_dev);
rt->u.dst.metrics[RTAX_ADVMSS-1] = ipv6_advmss(dst_pmtu(>u.dst));
rt->u.dst.metrics[RTAX_HOPLIMIT-1] = ipv6_get_hoplimit(rt->rt6i_dev);
Re: 2.6: USB disk unusable level of data corruption
On Fri, Feb 04, 2005 at 09:30:45PM -0500, Parag Warudkar wrote: > > > Does 2.6.11-rc3 have this same issue? > > > > thanks, > > > > greg k-h > > I just compiled 2.6.11-rc3 booted and then again did a kernel compile on > the USB disk - no problems. Great! > With FC 2.6.10 kernel I am able to reproduce the problem within no time > - seems something is seriously broken in FC3 latest kernel. Go file a bug in the redhat bugzilla :) Good luck, 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: e1000, sshd, and the infamous "Corrupted MAC on input"
Matt Mackall wrote:
Ok, reproduceable without ssh makes narrowing this down much easier.
Are you seeing errors on the interface? No would indicate problems
post CRC checking on the receive side. Do errors happen in both
directions? If not, it may be CPU speed-related or specific to a given
NIC - swap them if they're not onboard.
The next test is to send patterns. Try sending yourself a gigabyte of:
#include
int main(void)
{
int i;
for (i = 0; i < 0x1000; i++) {
fwrite(, 4, 1, stdout);
}
}
If there's some sort of partial DMA transfer going on, this should
make it evident.
No errors reported on either interface.
Interesting results, in one direction though. It seems highly likely
the problem is only with the 82545EM as I couldn't get a botched
transfer FROM it to the 82547EI after 20 or so attempts, (both of these
are onboard unfortunately so no swapping). Several transfers TO it did
yield bad files, though (using my big 1.6G gzipped tarball).
Now, on to the patterns. I didn't get a _single_ failure in either
directions using what that code snippet generated in over 20 attempts.
Perhaps we're failing on larger amounts of more complex data?
-Ethan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Race condition in ptrace
Nick Piggin wrote:
Andrew Morton wrote:
Nick Piggin <[EMAIL PROTECTED]> wrote:
Andrew, IMO this is another bug to hold 2.6.11 for.
Sure. I wouldn't consider Bodo's patch to be the one to use though..
No. Something similar could be done that works on all architectures
and all wait_task_inactive callers (and is confined to sched.c). That
would still be more or less a hack to work around smtnice's unfortunate
locking though.
Something like the following (untested) extension of Bodo's work
could be the minimal fix for 2.6.11. As I've said though, I'd
consider it a hack and prefer to do something about the locking.
That could be done after 2.6.11 though. Depends how you feel.
Bodo, I wonder if this looks like a suitable fix for your problem?
---
linux-2.6-npiggin/include/linux/init_task.h |1 +
linux-2.6-npiggin/include/linux/sched.h |1 +
linux-2.6-npiggin/kernel/sched.c| 12 ++--
3 files changed, 12 insertions(+), 2 deletions(-)
diff -puN include/linux/sched.h~sched-fixup-locking include/linux/sched.h
--- linux-2.6/include/linux/sched.h~sched-fixup-locking 2005-02-05
15:24:00.0 +1100
+++ linux-2.6-npiggin/include/linux/sched.h 2005-02-05 15:24:39.0
+1100
@@ -533,6 +533,7 @@ struct task_struct {
unsigned long ptrace;
int lock_depth; /* Lock depth */
+ int on_cpu; /* Is the task on the CPU, or in a ctxsw */
int prio, static_prio;
struct list_head run_list;
diff -puN kernel/sched.c~sched-fixup-locking kernel/sched.c
--- linux-2.6/kernel/sched.c~sched-fixup-locking2005-02-05
15:24:02.0 +1100
+++ linux-2.6-npiggin/kernel/sched.c2005-02-05 15:34:37.0 +1100
@@ -294,7 +294,7 @@ static DEFINE_PER_CPU(struct runqueue, r
#ifndef prepare_arch_switch
# define prepare_arch_switch(rq, next) do { } while (0)
# define finish_arch_switch(rq, next) spin_unlock_irq(&(rq)->lock)
-# define task_running(rq, p) ((rq)->curr == (p))
+# define task_running(rq, p) ((p)->on_cpu)
#endif
/*
@@ -867,7 +867,7 @@ void wait_task_inactive(task_t * p)
repeat:
rq = task_rq_lock(p, );
/* Must be off runqueue entirely, not preempted. */
- if (unlikely(p->array)) {
+ if (unlikely(p->array || p->on_cpu)) {
/* If it's preempted, we yield. It could be a while. */
preempted = !task_running(rq, p);
task_rq_unlock(rq, );
@@ -2805,11 +2805,18 @@ switch_tasks:
rq->curr = next;
++*switch_count;
+ next->on_cpu = 1;
prepare_arch_switch(rq, next);
prev = context_switch(rq, prev, next);
barrier();
finish_task_switch(prev);
+ /*
+* Some architectures release the runqueue lock before
+* context switching. Make sure this isn't reordered.
+*/
+ smp_wmb();
+ prev->on_cpu = 0;
} else
spin_unlock_irq(>lock);
@@ -4055,6 +4062,7 @@ void __devinit init_idle(task_t *idle, i
set_task_cpu(idle, cpu);
spin_lock_irqsave(>lock, flags);
+ idle->on_cpu = 1;
rq->curr = rq->idle = idle;
set_tsk_need_resched(idle);
spin_unlock_irqrestore(>lock, flags);
diff -puN include/linux/init_task.h~sched-fixup-locking
include/linux/init_task.h
--- linux-2.6/include/linux/init_task.h~sched-fixup-locking 2005-02-05
15:24:56.0 +1100
+++ linux-2.6-npiggin/include/linux/init_task.h 2005-02-05 15:25:07.0
+1100
@@ -73,6 +73,7 @@ extern struct group_info init_groups;
.usage = ATOMIC_INIT(2), \
.flags = 0,\
.lock_depth = -1, \
+ .on_cpu = 0,\
.prio = MAX_PRIO-20, \
.static_prio= MAX_PRIO-20, \
.policy = SCHED_NORMAL, \
_
ftp.kernel.org was broken
Hi. ftp.kernel.org is broken. The contents are empty, and root(uid/gid) is displayed as 0 though /pub directory is seen. Will you be maintaining it now? If it is it, you might stop the ftp daemon. (Though it might be a breakdown of the disk or something. ) -- <|> YOSHIMURA 'ramsy' Keitaro / Japan Linux Association <|> mailto:[EMAIL PROTECTED] <|> http://jla.linux.or.jp/index.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ns558 bug
[EMAIL PROTECTED] (Adam Belay) wrote: > > As a more general solution for all drivers, I've been thinking about doing > something like this in the long term. > > int ret; > if (!(ret = register_driver(_driver))) > return ret; > add_driver_protocol(_driver, _pnp); > add_driver_protocol(_driver, _isa); > > and then on exit: > > unregister_driver(_driver); /* this tears down any successfully >registered bus protocol automatically */ > > > For now a less invasive solution might be better. Well the thing oopses the kernel at present. Your call, Adam. Something to make it work acceptably for now would suit. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ns558 bug
On Fri, Feb 04, 2005 at 07:21:15PM -0800, Andrew Morton wrote:
> [EMAIL PROTECTED] (Adam Belay) wrote:
> >
> > It looks ok. My only concern is what would happen if the isa probe
> > succeded
> > but the pnp_register_driver failed? "pnp_register_driver" return -ENODEV
> > if
> > "CONFIG_PNP" isn't enabled. Do you think this would conflict with legacy
> > probing?
>
> Fair enough. How about this?
The code no longer is leaking devices. I may be overlooking something, but I
think it still doesn't retain legacy probed devices when PnP isn't available.
If "pnp_register_driver" fails then "ns588_unregister_ports" will unregister
the correctly detected ISA ports. "pnp_register_driver" will always fail if
pnp support isn't compiled into the kernel. We need a way of not
unregistering "ns558_pnp_driver" in "ns558_exit" but retaining the ports
detected by the legacy probe. In a way, this is sort of a driver model
problem.
As a more general solution for all drivers, I've been thinking about doing
something like this in the long term.
int ret;
if (!(ret = register_driver(_driver)))
return ret;
add_driver_protocol(_driver, _pnp);
add_driver_protocol(_driver, _isa);
and then on exit:
unregister_driver(_driver); /* this tears down any successfully
registered bus protocol automatically */
For now a less invasive solution might be better.
Comments?
Thanks,
Adam
>
> static void ns588_unregister_ports(void)
> {
> struct ns558 *port;
>
> list_for_each_entry(port, _list, node) {
> gameport_unregister_port(>gameport);
> switch (port->type) {
>
> #ifdef CONFIG_PNP
> case NS558_PNP:
> /* fall through */
> #endif
> case NS558_ISA:
> release_region(port->gameport.io &
> ~(port->size - 1), port->size);
> kfree(port);
> break;
>
> default:
> break;
> }
> }
> }
>
> static int __init ns558_init(void)
> {
> int i = 0;
> int ret;
>
> /*
> * Probe for ISA ports.
> */
>
> while (ns558_isa_portlist[i])
> ns558_isa_probe(ns558_isa_portlist[i++]);
>
> ret = pnp_register_driver(_pnp_driver);
> if (ret < 0) {
> ns588_unregister_ports();
> return ret;
> }
> return 0;
> }
>
> static void __exit ns558_exit(void)
> {
> ns588_unregister_ports();
> pnp_unregister_driver(_pnp_driver);
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ns558 bug
On Fri, Feb 04, 2005 at 07:06:14PM -0800, Andrew Morton wrote:
It looks ok. My only concern is what would happen if the isa probe succeded
but the pnp_register_driver failed? "pnp_register_driver" return -ENODEV if
"CONFIG_PNP" isn't enabled. Do you think this would conflict with legacy
probing?
Thanks,
Adam
> So would this be the appropriate fix?
>
> --- 25/drivers/input/gameport/ns558.c~ns558-oops-fix 2005-02-04
> 19:03:11.065813120 -0800
> +++ 25-akpm/drivers/input/gameport/ns558.c2005-02-04 19:05:52.607255088
> -0800
> @@ -264,6 +264,7 @@ static struct pnp_driver ns558_pnp_drive
> static int __init ns558_init(void)
> {
> int i = 0;
> + int ret;
>
> /*
> * Probe for ISA ports.
> @@ -272,8 +273,8 @@ static int __init ns558_init(void)
> while (ns558_isa_portlist[i])
> ns558_isa_probe(ns558_isa_portlist[i++]);
>
> - pnp_register_driver(_pnp_driver);
> - return list_empty(_list) ? -ENODEV : 0;
> + ret = pnp_register_driver(_pnp_driver);
> + return (ret < 0) ? ret : 0;
> }
>
> static void __exit ns558_exit(void)
> _
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] ns558 bug
[EMAIL PROTECTED] (Adam Belay) wrote:
>
> It looks ok. My only concern is what would happen if the isa probe succeded
> but the pnp_register_driver failed? "pnp_register_driver" return -ENODEV if
> "CONFIG_PNP" isn't enabled. Do you think this would conflict with legacy
> probing?
Fair enough. How about this?
static void ns588_unregister_ports(void)
{
struct ns558 *port;
list_for_each_entry(port, _list, node) {
gameport_unregister_port(>gameport);
switch (port->type) {
#ifdef CONFIG_PNP
case NS558_PNP:
/* fall through */
#endif
case NS558_ISA:
release_region(port->gameport.io &
~(port->size - 1), port->size);
kfree(port);
break;
default:
break;
}
}
}
static int __init ns558_init(void)
{
int i = 0;
int ret;
/*
* Probe for ISA ports.
*/
while (ns558_isa_portlist[i])
ns558_isa_probe(ns558_isa_portlist[i++]);
ret = pnp_register_driver(_pnp_driver);
if (ret < 0) {
ns588_unregister_ports();
return ret;
}
return 0;
}
static void __exit ns558_exit(void)
{
ns588_unregister_ports();
pnp_unregister_driver(_pnp_driver);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: 3TB disk hassles
Neil Conway <[EMAIL PROTECTED]> wrote: > I thought sure I had read somewhere that typical x86 PC BIOSes just > didn't understand the GPT ptbl, and thus couldn't boot from a GPT'ed > disk. No common x86 BIOS can understand any partition table. Booting is done by loading the first sector of the boot device and executing it. The common MBR code will move it's code to a unused location, load the first sector of the active partition and execute it. If you replace the MBR code with the GPT MBR code, it should understand GPTs. If you replace it with lilo or grub, one of these tools will run. If you replace it with a boot virus, it will (usurally) install it's hooks and chain-load the original boot sector, which in turn does it's work. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ns558 bug
[EMAIL PROTECTED] (Adam Belay) wrote:
>
> On Fri, Feb 04, 2005 at 09:00:54PM +0100, matthieu castet wrote:
> > Hi,
> >
> > this patch is based on http://bugzilla.kernel.org/show_bug.cgi?id=2962
> > patch from adam belay.
> >
> > It solve a oops when pnp_register_driver(_pnp_driver) failed.
> >
> > Please apply this patch.
> >
> > Matthieu
>
> I remember writing a version of this patch a while ago. The current behavior
> is broken because it shouldn't be considered a failure if the driver doesn't
> find any devices.
So would this be the appropriate fix?
--- 25/drivers/input/gameport/ns558.c~ns558-oops-fix2005-02-04
19:03:11.065813120 -0800
+++ 25-akpm/drivers/input/gameport/ns558.c 2005-02-04 19:05:52.607255088
-0800
@@ -264,6 +264,7 @@ static struct pnp_driver ns558_pnp_drive
static int __init ns558_init(void)
{
int i = 0;
+ int ret;
/*
* Probe for ISA ports.
@@ -272,8 +273,8 @@ static int __init ns558_init(void)
while (ns558_isa_portlist[i])
ns558_isa_probe(ns558_isa_portlist[i++]);
- pnp_register_driver(_pnp_driver);
- return list_empty(_list) ? -ENODEV : 0;
+ ret = pnp_register_driver(_pnp_driver);
+ return (ret < 0) ? ret : 0;
}
static void __exit ns558_exit(void)
_
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC: 2.6 patch] IDE: unsexport 3 functions
The patch removes three unneeded EXPORT_SYMBOL's. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/ide/ide-iops.c |4 drivers/ide/ide-taskfile.c |2 -- 2 files changed, 6 deletions(-) --- linux-2.6.11-rc3-mm1-full/drivers/ide/ide-iops.c.old2005-02-05 02:54:15.0 +0100 +++ linux-2.6.11-rc3-mm1-full/drivers/ide/ide-iops.c2005-02-05 02:55:21.0 +0100 @@ -104,8 +104,6 @@ hwif->INSL = ide_insl; } -EXPORT_SYMBOL(default_hwif_iops); - /* * MMIO operations, typically used for SATA controllers */ @@ -329,8 +327,6 @@ hwif->atapi_output_bytes= atapi_output_bytes; } -EXPORT_SYMBOL(default_hwif_transport); - /* * Beginning of Taskfile OPCODE Library and feature sets. */ --- linux-2.6.11-rc3-mm1-full/drivers/ide/ide-taskfile.c.old2005-02-05 02:57:03.0 +0100 +++ linux-2.6.11-rc3-mm1-full/drivers/ide/ide-taskfile.c2005-02-05 02:57:12.0 +0100 @@ -161,8 +161,6 @@ return ide_stopped; } -EXPORT_SYMBOL(do_rw_taskfile); - /* * set_multmode_intr() is invoked on completion of a WIN_SETMULT cmd. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[2.6 patch] sysctl.c: make some code static
This patch makes some needlessly global code static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
include/linux/sysctl.h |7 ---
kernel/sysctl.c| 95 +
2 files changed, 49 insertions(+), 53 deletions(-)
--- linux-2.6.10-rc2-mm4-full/include/linux/sysctl.h.old2004-12-12
03:19:59.0 +0100
+++ linux-2.6.10-rc2-mm4-full/include/linux/sysctl.h2004-12-12
03:21:40.0 +0100
@@ -787,8 +787,6 @@
void __user *, size_t *, loff_t *);
extern int proc_dointvec(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
-extern int proc_dointvec_bset(ctl_table *, int, struct file *,
- void __user *, size_t *, loff_t *);
extern int proc_dointvec_minmax(ctl_table *, int, struct file *,
void __user *, size_t *, loff_t *);
extern int proc_dointvec_jiffies(ctl_table *, int, struct file *,
@@ -806,11 +804,6 @@
void __user *oldval, size_t __user *oldlenp,
void __user *newval, size_t newlen);
-extern int do_sysctl_strategy (ctl_table *table,
- int __user *name, int nlen,
- void __user *oldval, size_t __user *oldlenp,
- void __user *newval, size_t newlen, void **
context);
-
extern ctl_handler sysctl_string;
extern ctl_handler sysctl_intvec;
extern ctl_handler sysctl_jiffies;
--- linux-2.6.10-rc2-mm4-full/kernel/sysctl.c.old 2004-12-12
03:20:14.0 +0100
+++ linux-2.6.10-rc2-mm4-full/kernel/sysctl.c 2004-12-12 03:24:58.0
+0100
@@ -157,8 +157,10 @@
static ssize_t proc_readsys(struct file *, char __user *, size_t, loff_t *);
static ssize_t proc_writesys(struct file *, const char __user *, size_t,
loff_t *);
static int proc_opensys(struct inode *, struct file *);
+static int proc_dointvec_bset(ctl_table *table, int write, struct file *filp,
+ void __user *buffer, size_t *lenp, loff_t *ppos);
-struct file_operations proc_sys_file_operations = {
+static struct file_operations proc_sys_file_operations = {
.open = proc_opensys,
.read = proc_readsys,
.write = proc_writesys,
@@ -1030,50 +1032,12 @@
return test_perm(table->mode, op);
}
-static int parse_table(int __user *name, int nlen,
- void __user *oldval, size_t __user *oldlenp,
- void __user *newval, size_t newlen,
- ctl_table *table, void **context)
-{
- int n;
-repeat:
- if (!nlen)
- return -ENOTDIR;
- if (get_user(n, name))
- return -EFAULT;
- for ( ; table->ctl_name; table++) {
- if (n == table->ctl_name || table->ctl_name == CTL_ANY) {
- int error;
- if (table->child) {
- if (ctl_perm(table, 001))
- return -EPERM;
- if (table->strategy) {
- error = table->strategy(
- table, name, nlen,
- oldval, oldlenp,
- newval, newlen, context);
- if (error)
- return error;
- }
- name++;
- nlen--;
- table = table->child;
- goto repeat;
- }
- error = do_sysctl_strategy(table, name, nlen,
- oldval, oldlenp,
- newval, newlen, context);
- return error;
- }
- }
- return -ENOTDIR;
-}
-
/* Perform the actual read/write of a sysctl table entry. */
-int do_sysctl_strategy (ctl_table *table,
- int __user *name, int nlen,
- void __user *oldval, size_t __user *oldlenp,
- void __user *newval, size_t newlen, void **context)
+static int do_sysctl_strategy (ctl_table *table,
+ int __user *name, int nlen,
+ void __user *oldval, size_t __user *oldlenp,
+ void __user *newval, size_t newlen,
+ void **context)
{
int op = 0, rc;
size_t len;
@@ -1120,6 +1084,45 @@
return 0;
}
+static int parse_table(int __user *name, int nlen,
+ void __user *oldval, size_t __user *oldlenp,
+ void __user *newval, size_t newlen,
+ ctl_table
[2.6 patch] input/gameport/cs461x.c: make 2 functions static
This patch makes two needlessly global functions static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
--- linux-2.6.11-rc3-mm1-full/drivers/input/gameport/cs461x.c.old
2005-02-05 03:23:44.0 +0100
+++ linux-2.6.11-rc3-mm1-full/drivers/input/gameport/cs461x.c 2005-02-05
03:24:21.0 +0100
@@ -318,12 +318,12 @@
.remove = __devexit_p(cs461x_pci_remove),
};
-int __init cs461x_init(void)
+static int __init cs461x_init(void)
{
return pci_module_init(_pci_driver);
}
-void __exit cs461x_exit(void)
+static void __exit cs461x_exit(void)
{
pci_unregister_driver(_pci_driver);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: USB disk unusable level of data corruption
> Does 2.6.11-rc3 have this same issue? > > thanks, > > greg k-h I just compiled 2.6.11-rc3 booted and then again did a kernel compile on the USB disk - no problems. With FC 2.6.10 kernel I am able to reproduce the problem within no time - seems something is seriously broken in FC3 latest kernel. Parag - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Reliable video POSTing on resume
On Sat, 05 Feb 2005 02:17:22 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > On laptops, it's frequently the case that c000:0003 will jump to a > section of code that is no longer mapped into the address space. > Instead, it's entirely possible that some other section of BIOS will be > mapped there. The resulting behaviour is undefined, and can cause the > hardware to hang. I suspect the problem in that case is a compressed VBIOS. Some laptops compress the VBIOS and the system BIOS into a single ROM and then expand them at power on. Sounds like this is not happening on resume. To get around the problem copy the image from C000:0 before suspend to a place in preserved RAM where wakeup.S can find it and then copy it back to C000:0 on resume. To test for this checksum C000:0 before suspend and after and see if it has changed. You can always do a simple test. If a program like vbios.vm86 or vbetool can reset the card, then there is no reason wakeup.S shouldn't be able to do it too if the environment is set up correctly. -- Jon Smirl [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: Post install 2.4.29 causes many apps to seg fault.
On Fri, Feb 04, 2005 at 11:10:19AM -0800, Gary Smith wrote: > Hello, > > I have been running RHEL3 update 3 for some time and need to patch netfilter > for PPTP. After doing so and installing the kernel I found that certain > applications (such as MySQL, nslook, etc) began to segfault. Rolling the > kernel back fixed the problem. > > I have since then gone back and recompiled the vanilla 2.4.29 kernel (without > additing any patches this time - clean from tarball) and installed it and all > of the the applications that failed on the custom kernel (with the PPTP > patches) continue to fail (clean box as well). > > Is there something more that I need to compile besides the kernel for > compatability or is this a sign of some type of bug. I do realize that RHEL3 > itself has some proprietary items added to their kernel but replacing it > shouldn't make other applications fails. RHEL3 glibc (and some application binaries IIRC) assume the existence of futex support in the kernel. Upstream, futex support only exists in 2.6, but Red Hat backported it to their 2.4 kernels for Red Hat 9, RHEL 3, and Fedora Core 1. Red Hat's assumption with RHEL is that you will be running *their* kernel so it's OK for them to make their glibc and application binaries depend on their kernel. If you must run a vanilla kernel, it would be best to use RHEL 2.1 instead, or to run a 2.6 kernel. Note that you'll need to install module-init-tools to get modules working under 2.6. One way to do this is to install a newer "modutils" package (I *think* the one from Fedora Core 2 should work, but I don't remember for certain) -- despite the name, the modutils package from Fedora Core 2 actually has module-init-tools in it as well. You may run into other gotchas when trying to run 2.6 on RHEL3; in that case it may be easiest to wait for RHEL4 (Valentine's Day is rumored), as that will work with 2.6 out-of-the-box and RHEL4's 2.6 kernel will likely be far less heavily patched than RHEL3's 2.4 kernel. If you can't wait for RHEL4, you could try the RHEL4 beta or Fedora Core in the meantime. If you *really* need to run a vanilla 2.4 kernel on RHEL3, you could try installing the glibc packages from Fedora Core 1 or 2 (*maybe* FC3 glibc packages would work too, but I'm less sure about that). Then recompile any applications that still segfault or freeze with a vanilla kernel (note that, for all I know, rpm itself could be one of these!) I hope this helps... -Barry K. Nathan <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Reliable video POSTing on resume
On Fri, 2005-02-04 at 21:09 -0500, Jon Smirl wrote: > How does the hardware die? Are you sure that it is not simply a bug in > the program doing the POST? Look at the scitech source and you will > see many BIOS quirks that have to be emulated in order for the post to > work. If your post program is missing any of these the post won't > work. So far every time I have encountered a non-working post it was > fixed by tweaking some things in the post program. On laptops, it's frequently the case that c000:0003 will jump to a section of code that is no longer mapped into the address space. Instead, it's entirely possible that some other section of BIOS will be mapped there. The resulting behaviour is undefined, and can cause the hardware to hang. -- Matthew Garrett | [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2.6.11-rc2] ide: driver updates (phase 2)
Hello, Bartlomiej. These are reordered/modified/(hopefully)appliable nine patches from the previous series of patches. #01 is the only new one. It kills the unused pkt_task_t in ide.h. #02/#03 are moved upward and #04 is modified as you've requested. #05/#08 now directly use taskfile transport instead of calling ide_taskfile_ioctl(). #08 now also properly handles WIN_SMART case. If these patches go in, I have eight patches left. One of them is ide_explicit_TASKFILE_NO_DATA. As we've discussed, I'm going to add default initialization of task->[pre]handler. That patch wasn't included in this series because I didn't know if do_rw_taskfile() and flagged_taskfile() are going to be merged or not. So, please tell me what you think. :-) I'll talk about other patches in their reply threads. [ Start of patch descriptions ] 01_ide_kill_pkt_task_t.patch : kill unused pkt_task_t Remove unused pkt_task_t definition from ide.h. 02_ide_taskfile_init_drive_cmd.patch : ide_init_drive_cmd() now defaults to REQ_DRIVE_TASKFILE ide_init_drive_cmd() now initializes rq->flags to REQ_DRIVE_TASKFILE. 03_ide_diag_taskfile_use_init_drive_cmd.patch : ide_diag_taskfile() rq initialization fix In ide_diag_taskfile(), when initializing taskfile rq, ref_count wasn't initialized properly. Modified to use ide_init_drive_cmd(). This doesn't really change any behavior as the request isn't managed via the block layer. 04_ide_taskfile_flush.patch : convert REQ_DRIVE_TASK to REQ_DRIVE_TASKFILE All REQ_DRIVE_TASK users except ide_task_ioctl() converted to use REQ_DRIVE_TASKFILE. 1. idedisk_issue_flush() converted to use REQ_DRIVE_TASKFILE. This and the changes in ide_get_error_location() remove a possible race condition between ide_get_error_location() and other requests. 2. ide_queue_flush_cmd() converted to use REQ_DRIVE_TASKFILE. 05_ide_taskfile_task_ioctl.patch : map ide_task_ioctl() to ide_taskfile_ioctl() ide_task_ioctl() modified to map to ide_taskfile_ioctl(). This is the last user of REQ_DRIVE_TASK. 06_ide_remove_task.patch : remove REQ_DRIVE_TASK handling Unused REQ_DRIVE_TASK handling removed. 07_ide_taskfile_cmd.patch : convert REQ_DRIVE_CMD to REQ_DRIVE_TASKFILE All in-kernel REQ_DRIVE_CMD users except for ide_cmd_ioctl() converted to use REQ_DRIVE_TASKFILE. 08_ide_taskfile_cmd_ioctl.patch : map ide_cmd_ioctl() to ide_taskfile_ioctl() ide_cmd_ioctl() converted to use ide_taskfile_ioctl(). This is the last user of REQ_DRIVE_CMD. 09_ide_remove_cmd.patch : remove REQ_DRIVE_CMD handling Removed unused REQ_DRIVE_CMD handling. [ End of patch descriptions ] Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Post install 2.4.29 causes many apps to seg fault.
Quoting Nick Warne <[EMAIL PROTECTED]>: > Yes, I had a similar problems at work when I up2date'd the latest GLIBC for > > RHEL 3 late last year. A colleague in Montreal (I am in UK) sussed what was > > going on. I will _presume_ you are seeing similar problems with a kernel > build. > > Here is the link that explains it... what to do with many processes > segfaulting, I don't know. RHEL support is _very_ good - give them a ring. > > http://people.redhat.com/drepper/assumekernel.html > > Nick Nick, The article seems to make sense about the versioning. I was wondering what your resolution was. Gary - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Reliable video POSTing on resume
On Sat, 05 Feb 2005 02:04:49 +, Matthew Garrett <[EMAIL PROTECTED]> wrote: > On Fri, 2005-02-04 at 12:31 -0500, Jon Smirl wrote: > > > Fixing this at kernel boot (resume) time will let user space apps > > assume that all video cards are reset. That removes a lot of > > complexity from the user space apps (like X). > > This can't be the default on x86. I have hardware that will die if you > attempt to POST it after the BIOS has started the OS. Non-x86 should be > fine, though. How does the hardware die? Are you sure that it is not simply a bug in the program doing the POST? Look at the scitech source and you will see many BIOS quirks that have to be emulated in order for the post to work. If your post program is missing any of these the post won't work. So far every time I have encountered a non-working post it was fixed by tweaking some things in the post program. > -- > Matthew Garrett | [EMAIL PROTECTED] > > -- Jon Smirl [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] Reliable video POSTing on resume
On Fri, 2005-02-04 at 12:31 -0500, Jon Smirl wrote: > Fixing this at kernel boot (resume) time will let user space apps > assume that all video cards are reset. That removes a lot of > complexity from the user space apps (like X). This can't be the default on x86. I have hardware that will die if you attempt to POST it after the BIOS has started the OS. Non-x86 should be fine, though. -- Matthew Garrett | [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: error
On Fri, Feb 04, 2005 at 04:19:30PM -0200, [EMAIL PROTECTED] wrote: > Hi, I encountered the following error trying to select the option: > Ethernet (1000 Mbit) ---> > in my Linux Kernel v2.4.18 Configuration > > Menuconfig has encountered a possible error in one of the kernel's > configuration files and is unable to continue. Here is the error > report: > > Q> scripts/Menuconfig: MCmenu33: command not found > > make: *** [menuconfig] Error 1 > > > > What do I do ? AFAIR this was only in Mandrake kernels due to a bug in a patch Mandrake applied to its' kernels. > Look forward to your answer: > > Andre Perrotta 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: driver model: fix types in usb
On Wed, Feb 02, 2005 at 09:26:10PM +0100, Pavel Machek wrote: > Hi! > > From: Bernard Blackham <[EMAIL PROTECTED]> > > This fixes types in USB w.r.t. driver model. It should not actually > change any code. Please apply, > > Pavel > > Signed-off-by: Pavel Machek <[EMAIL PROTECTED]> Applied to my trees, 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: 3TB disk hassles
Howdy... --- "Pedro Venda (SYSADM)" <[EMAIL PROTECTED]> wrote: > Neil Conway wrote: > > Howdy... > > After much banging of heads on walls, I am throwing in the towel > and > > asking the experts ;-) ... To cut a long story short: > > Is it possible to make a 3TB disk work properly in Linux? > > Our "disk" is 12x300GB in RAID5 (with 1 hot-spare) on a 3ware > 9500-S12, > > so it's actually 2.7TiB ish. It's also /dev/sda - i.e., the one > and > > only disk in the system. > > not meaning to criticise... but isn't it a good idea to have a > separate raid1 volume to boot the system? Well, yes, and we would if we could. Sadly, the chassis we got from our vendor only has space for the 12 hot-swap disks, and we need the capacity too badly to lose 2 slots for a boot volume. If only we could take a sliver of each of the 12 disks to make a tiny RAID5 boot volume... Regards, Neil __ Do you Yahoo!? Yahoo! Mail - Easier than ever with enhanced search. Learn more. http://info.mail.yahoo.com/mail_250 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
Hi, > This is the patch to evaluate CPU_HAS_FEATURE() at compile time whenever > possible. Testing showed that vmlinux shrinks around 4000 bytes with > g5_defconfig. I also checked that pSeries code is completely unaltered > semantically when support for all CPU types is enabled, although a few > instructions are emitted in a different order by gcc. > > I have made cpu_has_feature() an inline function that expects the full > name of a feature bit while the CPU_HAS_FEATURE() macro still behaves > the same way as in Olofs original patch for now. Interesting :) However we already get bug reports with the current CONFIG_POWER4_ONLY option. I worry about adding more options that users could get wrong unless there is a noticeable improvement in performance. Anton - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
> This is the patch to evaluate CPU_HAS_FEATURE() at compile time whenever > possible. Testing showed that vmlinux shrinks around 4000 bytes with > g5_defconfig. I also checked that pSeries code is completely unaltered > semantically when support for all CPU types is enabled, although a few > instructions are emitted in a different order by gcc. > > I have made cpu_has_feature() an inline function that expects the full > name of a feature bit while the CPU_HAS_FEATURE() macro still behaves > the same way as in Olofs original patch for now. Note that this doesn't the asm part of it, where feature "sections" are nop'ed out... it may be interesting to get rid of the nops too here, oh well, that's too complicated for now. 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: 3TB disk hassles
Howdy... Apologies for the somewhat tardy reply; I've been concentrating on getting the hardware to play nice recently and not worrying so much about the software. --- Tomas Carnecky <[EMAIL PROTECTED]> wrote: > It was gentoo, and I even think I installed it right onto the GPT > disk, > so no migration. But I'm not sure. You just have to look that your > kernel supports GPT. I don't know if the kernel from the gentoo > livecd > supports GPT. > > Also have a look here how to create GPT partitions: > http://www.google.ch/search?q=site%3Ausefulthings.org.uk+gpt > I think I did it like it's shown there, mklabel, mkpart and mount > them. > I don't think I migrated from MSDOS to GPT, because I don't even know > how it'is possible if you have only one disk with the system on it. Bizarre... I will give this a try on a spare system as soon as I can. I thought sure I had read somewhere that typical x86 PC BIOSes just didn't understand the GPT ptbl, and thus couldn't boot from a GPT'ed disk. thanks, Neil __ 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/
Re: 2.6: USB disk unusable level of data corruption
On Fri, Feb 04, 2005 at 07:40:13PM -0500, Parag Warudkar wrote: > I don't know if it's related, but - > I have been using Maxtor OneTouch USB Drive,so far without problems, but > today after upgrading to FC3 2.6.10-760 kernel I just recieved this in > dmesg Does 2.6.11-rc3 have this same issue? 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: 2.6.11-rc3 x86-64 compile err on suse 9.1
Same problem here on Fedora Core 3, I have put my .config and make output at http://www.hostmaster.org/~thomasz/linux-2.6.11-rc3/ Tom PS: Tyan Thunder K8W - works great! -- T h o m a s Z e h e t b a u e r ( TZ251 ) PGP encrypted mail preferred - KeyID 96FFCB89 finger [EMAIL PROTECTED] for key Prohibiting cryptography to prevent terrorism is as meaningful as ...prohibiting mumming to prevent bank robbery! signature.asc Description: This is a digitally signed message part
Re: [RFC] Reliable video POSTing on resume
On Sat, 05 Feb 2005 01:52:23 +0100, Carl-Daniel Hailfinger <[EMAIL PROTECTED]> wrote: > My problem (Samsung P35) is that the BIOS wants to call code which > is no longer mapped because the BIOS is too big to fit into the > standard area. Since that additional area has been overwritten, we > are out of luck. Maybe if we did something like backing up all Look at the scitech source code. There are a limited number of system BIOS calls that need to be implemented. It is a fairly small number. wakeup.S could supply implementations for these and patch them into the right interrupt vectors while the VBIOS is being run. There is no requirement that VBIOS run the actual system BIOS, it only has to think that it is running on the system BIOS. This is the same scheme used for running the ROMs in user space. -- Jon Smirl [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] Reliable video POSTing on resume
Xavier Bestel schrieb: > Le vendredi 04 fÃvrier 2005 Ã 00:03 -0500, Jon Smirl a Ãcrit : > >>Doing this in user space lets you have two reset >>programs, vm86 and emu86 for non-x86 machines. > > > Perhaps only emu86 should be used, to have a well-debugged codepath on > all archs (amd64, ppc, ...) > As it's usermode, the code size is less of a problem. Well, if it has to live in initramfs, it better be really small. An initramfs with a size of 8 megabytes isn't going to make you many friends. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Reliable video POSTing on resume
James Simmons schrieb: >>>int video_helper(struct video_actions *what_to_do) >> >>I do not know, synchronously executing userland code from kernel seems >>like wrong thing to do. > > I'm not a fan for this either. The good news is most graphics cards don't > require these tricks. The only ones that do are the ix86 cards. The real > solution would be if the hradware vendors open the parts of the spec to do > what we need. Many of the older cards could be supported in this way if we > talk to the vendors. They shouldn't care if the specs are released anymore. > The problem would be the latest Radeon card and NVIDIA cards which > unfortunely are the most common cards for x86 platforms ;-( Well, either you call userspace synchronously or you crash on resume. I know what I prefer. And this synchronous call isn't so bad because it comes with a timeout. So whatever the userspace program does, after two seconds the kernel will continue unaffected. Once you execute the code asynchronously, you get nondeterministic behaviour. That's sure fun for filling up your random pool, but I wouldn't trust my data to such a system. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Reliable video POSTing on resume
Pavel Machek schrieb: > > I do not understand how initramfs fits into picture... Plus lot of > people (me :-) do not use initramfs... Well, an initrd which is never unmounted should work, too. On SUSE, "mkdir /initrd" and see what you've been missing. I don't know why that directory doesn't exist by default except for the reason that freeing the initrd frees some memory. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm PATCH] driver model: PM type conversions in drivers/net
Daniel Drake wrote:
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/bmac.c linux-dsd/drivers/net/bmac.c
--- linux-2.6.11-rc2-mm2/drivers/net/bmac.c 2005-02-02 21:54:17.353663112 +
+++ linux-dsd/drivers/net/bmac.c 2005-02-02 20:52:48.0 +
@@ -455,7 +455,7 @@ static void bmac_init_chip(struct net_de
}
#ifdef CONFIG_PM
-static int bmac_suspend(struct macio_dev *mdev, u32 state)
+static int bmac_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct net_device* dev = macio_get_drvdata(mdev);
struct bmac_data *bp = netdev_priv(dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/irda/sa1100_ir.c linux-dsd/drivers/net/irda/sa1100_ir.c
--- linux-2.6.11-rc2-mm2/drivers/net/irda/sa1100_ir.c 2004-12-24 21:35:50.0 +
+++ linux-dsd/drivers/net/irda/sa1100_ir.c 2005-02-02 20:59:28.0 +
@@ -291,7 +291,7 @@ static void sa1100_irda_shutdown(struct
/*
* Suspend the IrDA interface.
*/
-static int sa1100_irda_suspend(struct device *_dev, u32 state, u32 level)
+static int sa1100_irda_suspend(struct device *_dev, pm_message_t state, u32 level)
Why does this one have three arguments?
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] Reliable video POSTing on resume
> > int video_helper(struct video_actions *what_to_do) > > I do not know, synchronously executing userland code from kernel seems > like wrong thing to do. I'm not a fan for this either. The good news is most graphics cards don't require these tricks. The only ones that do are the ix86 cards. The real solution would be if the hradware vendors open the parts of the spec to do what we need. Many of the older cards could be supported in this way if we talk to the vendors. They shouldn't care if the specs are released anymore. The problem would be the latest Radeon card and NVIDIA cards which unfortunely are the most common cards for x86 platforms ;-( - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[-mm PATCH] driver model: PM type conversions in drivers/macintosh
This fixes PM driver model type checking for drivers/macintosh.
Acked by Pavel Machek.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/macintosh/macio_asic.c linux-dsd/drivers/macintosh/macio_asic.c
--- linux-2.6.11-rc2-mm2/drivers/macintosh/macio_asic.c 2004-12-24 21:34:31.0 +
+++ linux-dsd/drivers/macintosh/macio_asic.c 2005-02-02 21:30:44.0 +
@@ -106,7 +106,7 @@ static void macio_device_shutdown(struct
drv->shutdown(macio_dev);
}
-static int macio_device_suspend(struct device *dev, u32 state)
+static int macio_device_suspend(struct device *dev, pm_message_t state)
{
struct macio_dev * macio_dev = to_macio_device(dev);
struct macio_driver * drv = to_macio_driver(dev->driver);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/macintosh/mediabay.c linux-dsd/drivers/macintosh/mediabay.c
--- linux-2.6.11-rc2-mm2/drivers/macintosh/mediabay.c 2004-12-24 21:34:26.0 +
+++ linux-dsd/drivers/macintosh/mediabay.c 2005-02-02 21:56:29.0 +
@@ -710,7 +710,7 @@ static int __devinit media_bay_attach(st
}
-static int __pmac media_bay_suspend(struct macio_dev *mdev, u32 state)
+static int __pmac media_bay_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct media_bay_info *bay = macio_get_drvdata(mdev);
@@ -729,8 +729,8 @@ static int __pmac media_bay_resume(struc
{
struct media_bay_info *bay = macio_get_drvdata(mdev);
- if (mdev->ofdev.dev.power.power_state != 0) {
- mdev->ofdev.dev.power.power_state = 0;
+ if (mdev->ofdev.dev.power.power_state != PMSG_ON) {
+ mdev->ofdev.dev.power.power_state = PMSG_ON;
/* We re-enable the bay using it's previous content
only if it did not change. Note those bozo timings,
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/include/asm-ppc/macio.h linux-dsd/include/asm-ppc/macio.h
--- linux-2.6.11-rc2-mm2/include/asm-ppc/macio.h 2004-12-24 21:34:01.0 +
+++ linux-dsd/include/asm-ppc/macio.h 2005-02-02 21:34:30.0 +
@@ -126,7 +126,7 @@ struct macio_driver
int (*probe)(struct macio_dev* dev, const struct of_match *match);
int (*remove)(struct macio_dev* dev);
- int (*suspend)(struct macio_dev* dev, u32 state);
+ int (*suspend)(struct macio_dev* dev, pm_message_t state);
int (*resume)(struct macio_dev* dev);
int (*shutdown)(struct macio_dev* dev);
[-mm PATCH] driver model: PM type conversions in drivers/char
This fixes PM driver model type checking for drivers/char.
Acked by Pavel Machek.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/char/agp/efficeon-agp.c linux-dsd/drivers/char/agp/efficeon-agp.c
--- linux-2.6.11-rc2-mm2/drivers/char/agp/efficeon-agp.c 2005-02-02 21:55:19.0 +
+++ linux-dsd/drivers/char/agp/efficeon-agp.c 2005-02-02 21:45:01.0 +
@@ -408,7 +408,7 @@ static void __devexit agp_efficeon_remov
agp_put_bridge(bridge);
}
-static int agp_efficeon_suspend(struct pci_dev *dev, u32 state)
+static int agp_efficeon_suspend(struct pci_dev *dev, pm_message_t state)
{
return 0;
}
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/char/s3c2410-rtc.c linux-dsd/drivers/char/s3c2410-rtc.c
--- linux-2.6.11-rc2-mm2/drivers/char/s3c2410-rtc.c 2005-02-02 21:54:16.0 +
+++ linux-dsd/drivers/char/s3c2410-rtc.c 2005-02-02 21:44:26.0 +
@@ -514,7 +514,7 @@ static struct timespec s3c2410_rtc_delta
static int ticnt_save;
-static int s3c2410_rtc_suspend(struct device *dev, u32 state, u32 level)
+static int s3c2410_rtc_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct rtc_time tm;
struct timespec time;
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/char/sonypi.c linux-dsd/drivers/char/sonypi.c
--- linux-2.6.11-rc2-mm2/drivers/char/sonypi.c 2005-02-02 21:54:16.0 +
+++ linux-dsd/drivers/char/sonypi.c 2005-02-02 21:44:45.0 +
@@ -693,7 +693,7 @@ static int sonypi_disable(void)
#ifdef CONFIG_PM
static int old_camera_power;
-static int sonypi_suspend(struct device *dev, u32 state, u32 level)
+static int sonypi_suspend(struct device *dev, pm_message_t state, u32 level)
{
if (level == SUSPEND_DISABLE) {
old_camera_power = sonypi_device.camera_power;
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/char/tpm/tpm.c linux-dsd/drivers/char/tpm/tpm.c
--- linux-2.6.11-rc2-mm2/drivers/char/tpm/tpm.c 2005-02-02 21:55:20.0 +
+++ linux-dsd/drivers/char/tpm/tpm.c 2005-02-02 21:45:18.0 +
@@ -564,7 +564,7 @@ static u8 savestate[] = {
* We are about to suspend. Save the TPM state
* so that it can be restored.
*/
-int tpm_pm_suspend(struct pci_dev *pci_dev, u32 pm_state)
+int tpm_pm_suspend(struct pci_dev *pci_dev, pm_message_t pm_state)
{
struct tpm_chip *chip = pci_get_drvdata(pci_dev);
if (chip == NULL)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/char/tpm/tpm.h linux-dsd/drivers/char/tpm/tpm.h
--- linux-2.6.11-rc2-mm2/drivers/char/tpm/tpm.h 2005-02-02 21:55:20.0 +
+++ linux-dsd/drivers/char/tpm/tpm.h 2005-02-02 21:45:52.0 +
@@ -88,5 +88,5 @@ extern ssize_t tpm_write(struct file *,
loff_t *);
extern ssize_t tpm_read(struct file *, char __user *, size_t, loff_t *);
extern void __devexit tpm_remove(struct pci_dev *);
-extern int tpm_pm_suspend(struct pci_dev *, u32);
+extern int tpm_pm_suspend(struct pci_dev *, pm_message_t);
extern int tpm_pm_resume(struct pci_dev *);
Re: 2.6.11-rc3-mm1
On Sat, 05 Feb 2005 11:16:49 +1100, Benjamin Herrenschmidt
<[EMAIL PROTECTED]> wrote:
>
> > I tried it two or three times, same result each time. I'll give it a
> > lash with USB disabled.
>
> Also, can you try editing arch/ppc/syslib/open_pic.c, in function
> openpic_resume(), comment out the call to openpic_reset() and let me
> know if that helps...
Well, maybe I'm to blame this time...
I've introduced bug in ATAPI Power Management handling,
idedisk_pm_idle shouldn't be done for ATAPI devices.
Sorry for that, fix attached.
--- a/drivers/ide/ide-io.c 2005-02-04 03:27:35.0 +0100
+++ b/drivers/ide/ide-io.c 2005-02-05 01:44:33.0 +0100
@@ -230,6 +230,12 @@
memset(args, 0, sizeof(*args));
+ if (drive->media != ide_disk) {
+ /* skip idedisk_pm_idle for ATAPI devices */
+ if (rq->pm->pm_step == idedisk_pm_idle)
+ rq->pm->pm_step = ide_pm_restore_dma;
+ }
+
switch (rq->pm->pm_step) {
case ide_pm_flush_cache: /* Suspend step 1 (flush cache) */
if (drive->media != ide_disk)
Re: [RFC] Reliable video POSTing on resume
Jon Smirl schrieb: > On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[EMAIL PROTECTED]> wrote: > >>We already try to do that, but it hangs on 70% of machines. See >>Documentation/power/video.txt. > > We know that all of these ROMs are run at power on so they have to > work. This implies that there must be something wrong with the > environment the ROM are being run in. Video ROMs make calls into the > INT vectors of the system BIOS. If these haven't been set up yet > running the VBIOS is sure to hang. Has someone with ROM source and > the appropriate debugging tools tried to debug one of these hangs? > Alternatively code could be added to wakeup.S to try and set these up > or dump the ones that are there and see if they are sane. My problem (Samsung P35) is that the BIOS wants to call code which is no longer mapped because the BIOS is too big to fit into the standard area. Since that additional area has been overwritten, we are out of luck. Maybe if we did something like backing up all untouched real mode memory immediately after switching to protected mode, it could work. But I don't know whether that is feasible on boot. Anyways, you don't want to run possibly buggy closed source bios code in an environment where a single random memory write may corrupt the kernel without debuggability. And sometimes there is BIOS code which is can't be run twice. Period. Don't believe that one? I have a machine where calling EDD code in the BIOS twice will hang the second time. See boot parameter edd=off for reference :-( So I agree that we could try to preserve the state better, but I also can guarantee you it won't help everywhere. Regards, Carl-Daniel -- http://www.hailfinger.org/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
On Sünnavend 05 Februar 2005 00:49, Benjamin Herrenschmidt wrote:
> On Fri, 2005-02-04 at 13:36 +0100, Arnd Bergmann wrote:
> > I have a somewhat similar patch that does the same to the
> > systemcfg->platform checks. I'm not sure if we should use the same inline
> > function for both checks, but I do think that they should be used in a
> > similar way, e.g. CPU_HAS_FEATURE(x) and PLATFORM_HAS_FEATURE(x).
>
> Note that I would prefer cpu_has_feature(), it doesn't strictly have to
> be a macro and has function semantics anyway.
> > [ ... ]
> > which will always result in the shortest code for any combination of
> > CONFIG_PPC_ISERIES, CONFIG_PPC_PSERIES and the other platforms.
>
> That's a good idea !
This is the patch to evaluate CPU_HAS_FEATURE() at compile time whenever
possible. Testing showed that vmlinux shrinks around 4000 bytes with
g5_defconfig. I also checked that pSeries code is completely unaltered
semantically when support for all CPU types is enabled, although a few
instructions are emitted in a different order by gcc.
I have made cpu_has_feature() an inline function that expects the full
name of a feature bit while the CPU_HAS_FEATURE() macro still behaves
the same way as in Olofs original patch for now.
I'm not sure if I got the Kconfig dependencies right, maybe you can
check them.
Signed-off-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
Index: linux-2.6-64/include/asm-ppc64/cputable.h
===
--- linux-2.6-64.orig/include/asm-ppc64/cputable.h 2005-02-05
01:24:58.975674192 +0100
+++ linux-2.6-64/include/asm-ppc64/cputable.h 2005-02-05 01:26:17.328762712
+0100
@@ -66,9 +66,6 @@
extern struct cpu_spec cpu_specs[];
extern struct cpu_spec *cur_cpu_spec;
-#define CPU_HAS_FEATURE(x) (cur_cpu_spec->cpu_features & CPU_FTR_##x)
-
-
/* firmware feature bitmask values */
#define FIRMWARE_MAX_FEATURES 63
@@ -154,6 +151,80 @@
#define CPU_FTR_PPCAS_ARCH_V2 (CPU_FTR_PPCAS_ARCH_V2_BASE | CPU_FTR_16M_PAGE)
#endif
+/* We only set the altivec features if the kernel was compiled with altivec
+ * support
+ */
+#ifdef CONFIG_ALTIVEC
+#define CPU_FTR_ALTIVEC_COMP CPU_FTR_ALTIVEC
+#define PPC_FEATURE_HAS_ALTIVEC_COMP PPC_FEATURE_HAS_ALTIVEC
+#else
+#define CPU_FTR_ALTIVEC_COMP 0
+#define PPC_FEATURE_HAS_ALTIVEC_COMP0
+#endif
+
+enum {
+ CPU_FTR_POWER3 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+CPU_FTR_HPTE_TABLE | CPU_FTR_IABR | CPU_FTR_PMC8,
+ CPU_FTR_RS64 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+CPU_FTR_HPTE_TABLE | CPU_FTR_IABR | CPU_FTR_PMC8 |
+CPU_FTR_MMCRA,
+ CPU_FTR_POWER4 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 |
+CPU_FTR_PMC8 | CPU_FTR_MMCRA,
+ CPU_FTR_PPC970 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 |
+CPU_FTR_ALTIVEC_COMP | CPU_FTR_CAN_NAP |
+CPU_FTR_PMC8 | CPU_FTR_MMCRA,
+ CPU_FTR_POWER5 = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2 |
+CPU_FTR_MMCRA | CPU_FTR_SMT | CPU_FTR_COHERENT_ICACHE |
+CPU_FTR_LOCKLESS_TLBIE | CPU_FTR_MMCRA_SIHV,
+ CPU_FTR_COMPATIBLE = CPU_FTR_SPLIT_ID_CACHE | CPU_FTR_USE_TB |
+CPU_FTR_HPTE_TABLE | CPU_FTR_PPCAS_ARCH_V2,
+ CPU_FTR_POSSIBLE =
+#ifdef CONFIG_CPU_POWER3
+CPU_FTR_POWER3 |
+#endif
+#ifdef CONFIG_CPU_RS64
+CPU_FTR_RS64 |
+#endif
+#ifdef CONFIG_CPU_POWER4
+CPU_FTR_POWER4 |
+#endif
+#ifdef CONFIG_CPU_PPC970
+CPU_FTR_PPC970 |
+#endif
+#ifdef CONFIG_CPU_POWER5
+CPU_FTR_POWER5 |
+#endif
+0,
+ CPU_FTR_ALWAYS =
+#ifdef CONFIG_CPU_POWER3
+CPU_FTR_POWER3 &
+#endif
+#ifdef CONFIG_CPU_RS64
+CPU_FTR_RS64 &
+#endif
+#ifdef CONFIG_CPU_POWER4
+CPU_FTR_POWER4 &
+#endif
+#ifdef CONFIG_CPU_PPC970
+CPU_FTR_PPC970 &
+#endif
+#ifdef CONFIG_CPU_POWER5
+CPU_FTR_POWER5 &
+#endif
+CPU_FTR_POSSIBLE,
+};
+
+static inline int cpu_has_feature(unsigned long feature)
+{
+ return (CPU_FTR_ALWAYS & feature) ||
+ (CPU_FTR_POSSIBLE & feature & cur_cpu_spec->cpu_features);
+}
+
+#define CPU_HAS_FEATURE(x) cpu_has_feature(CPU_FTR_##x)
+
#define COMMON_PPC64_FW(0)
#endif
Index: linux-2.6-64/arch/ppc64/Kconfig
===
--- linux-2.6-64.orig/arch/ppc64/Kconfig2005-02-05 01:24:31.098912104
+0100
+++ linux-2.6-64/arch/ppc64/Kconfig 2005-02-05
Re: 2.6: USB disk unusable level of data corruption
I don't know if it's related, but - I have been using Maxtor OneTouch USB Drive,so far without problems, but today after upgrading to FC3 2.6.10-760 kernel I just recieved this in dmesg usb 1-1: USB disconnect, address 2 scsi0 (0:0): rejecting I/O to device being removed scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda2, logical block 6352 lost page write due to I/O error on sda2 Aborting journal on device sda2. journal commit I/O error scsi0 (0:0): rejecting I/O to device being removed Buffer I/O error on device sda2, logical block 15859714 lost page write due to I/O error on sda2 ext3_abort called. EXT3-fs error (device sda2): ext3_journal_start_sb: Detected aborted journal Remounting filesystem read-only scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device usb 1-1: new high speed USB device using ehci_hcd and address 5 usb 1-1: device descriptor read/64, error -71 scsi2 : SCSI emulation for USB Mass Storage devices usb-storage: device found at 5 usb-storage: waiting for device to settle before scanning Vendor: MaxtorModel: OneTouch Rev: 0201 Type: Direct-Access ANSI SCSI revision: 00 SCSI device sdc: 398295040 512-byte hdwr sectors (203927 MB) sdc: assuming drive cache: write through SCSI device sdc: 398295040 512-byte hdwr sectors (203927 MB) sdc: assuming drive cache: write through sdc: sdc1 sdc2 Attached scsi disk sdc at scsi2, channel 0, id 0, lun 0 usb-storage: device scan complete scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead device scsi0 (0:0): rejecting I/O to dead
Re: Legacy IO spaces (was Re: [RFC] Reliable video POSTing on resume)
> > /sys/class/pci_bus I show three buses. You wouldn't want the > > legacy_io/mem attributes on each of these three buses since that > > implies three independent address spaces. > > > > [EMAIL PROTECTED] pci_bus]$ ls /sys/class/pci_bus > > :00 :01 :02 > > In that case they'll all point to the same memory and I/O space. On the > machines I coded it on, each bus has its own space. If they all point to the same space, I can't tell whether I have three legacy spaces or one. I need to know how many legacy spaces there are in order to know how many VGA cards can simultaneously be enabled. > We might have to add more arch code in that case, but I thought it might be > easiest for apps if they could just open the space for the bus they're > interested in and it would be routed correctly. I think that'll be ok so > long as two apps aren't trying to do stuff on the bus at the same time. > > > In order to know how many VGA many simultaneous VGA devices you can > > have there needs to be some way to count the number of legacy address > > spaces. Maybe there should be a /sys/class/legacy to describe the > > legacy spaces. Is it possible to have the same legacy space aliased at > > two different addresses depending on which root bus is used to get to > > it? What I meant by the questions is how can my video reset program ask these questions, it needs to know the answers in order to properly reset the VGA hardware. There needs to be some way to figure out the answers from sysfs info. 1) how many legacy spaces are there no way to tell 2) how many VGA devices are in each space no way to tell, you need to know which legacy space each card is in 3) how do I do VGA bus routing to access the VGA device I've posted code that starts doing this 4) how do I address each of the devices. The routing code I posted needs to be update to handle multiple spaces. For example I might have a machine with 3 spaces, 2 vga in #1, 1 in #2 and zero in #3. In that case I can have two active VGA's. My home machine has one space and 2 vga's so I can have one active. There needs to be enough info available to figure this out. Or maybe the answer is simpler, if the legacy_io/mem attributes exist, then you can assume each bus has it's own legacy space. If they don't exist then there is a single legacy space. Is this a safe assumption? -- Jon Smirl [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] ns558 bug
On Fri, Feb 04, 2005 at 09:00:54PM +0100, matthieu castet wrote:
> Hi,
>
> this patch is based on http://bugzilla.kernel.org/show_bug.cgi?id=2962
> patch from adam belay.
>
> It solve a oops when pnp_register_driver(_pnp_driver) failed.
>
> Please apply this patch.
>
> Matthieu
I remember writing a version of this patch a while ago. The current behavior
is broken because it shouldn't be considered a failure if the driver doesn't
find any devices.
Thanks,
Adam
> Index: drivers/input/gameport/ns558.c
> ===
> RCS file:
> /home/mat/dev/linux-cvs-rep/linux-cvs/drivers/input/gameport/ns558.c,v
> retrieving revision 1.15
> diff -u -u -r1.15 ns558.c
> --- drivers/input/gameport/ns558.c16 Sep 2004 14:04:04 - 1.15
> +++ drivers/input/gameport/ns558.c4 Feb 2005 19:53:20 -
> @@ -261,6 +261,8 @@
>
> #endif
>
> +static int registered = 0;
> +
> int __init ns558_init(void)
> {
> int i = 0;
> @@ -272,8 +274,10 @@
> while (ns558_isa_portlist[i])
> ns558_isa_probe(ns558_isa_portlist[i++]);
>
> - pnp_register_driver(_pnp_driver);
> - return list_empty(_list) ? -ENODEV : 0;
> + if (pnp_register_driver(_pnp_driver) >= 0)
> + registered = 1;
> +
> + return (list_empty(_list) && !registered) ? -ENODEV : 0;
> }
>
> void __exit ns558_exit(void)
> @@ -297,7 +301,8 @@
> break;
> }
> }
> - pnp_unregister_driver(_pnp_driver);
> + if (registered)
> + pnp_unregister_driver(_pnp_driver);
> }
>
> module_init(ns558_init);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Reliable video POSTing on resume
> Jon does your emulator sit on top of the new legacy I/O and memory APIs? I > added them for this very reason, though atm only ia64 supports them. There's > documentation in Documentation/filesystems/sysfs-pci.txt if you want to take > a look. On kernels that support it, sysfs can be a one stop shop for all > your gfx programming needs, since it provides access to the rom, PCI > resources (i.e. MMIO ranges, fb memory, etc.) and legacy I/O ports and > memory. Thanks for the info. Actually the is what /sys/bus/graphics is for. I'm working on some patchs to migrate the fbdev subsystem to using 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/
[-mm PATCH] driver model: PM type conversions in drivers/serial
This fixes PM driver model type checking for drivers/serial.
Acked by Pavel Machek.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/amba-pl010.c linux-dsd/drivers/serial/amba-pl010.c
--- linux-2.6.11-rc2-mm2/drivers/serial/amba-pl010.c 2004-12-24 21:34:00.0 +
+++ linux-dsd/drivers/serial/amba-pl010.c 2005-02-02 20:16:42.0 +
@@ -772,7 +772,7 @@ static int pl010_remove(struct amba_devi
return 0;
}
-static int pl010_suspend(struct amba_device *dev, u32 state)
+static int pl010_suspend(struct amba_device *dev, pm_message_t state)
{
struct uart_amba_port *uap = amba_get_drvdata(dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/imx.c linux-dsd/drivers/serial/imx.c
--- linux-2.6.11-rc2-mm2/drivers/serial/imx.c 2004-12-24 21:35:39.0 +
+++ linux-dsd/drivers/serial/imx.c 2005-02-02 20:17:08.0 +
@@ -818,7 +818,7 @@ static struct uart_driver imx_reg = {
.cons = IMX_CONSOLE,
};
-static int serial_imx_suspend(struct device *_dev, u32 state, u32 level)
+static int serial_imx_suspend(struct device *_dev, pm_message_t state, u32 level)
{
struct imx_port *sport = dev_get_drvdata(_dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/mpc52xx_uart.c linux-dsd/drivers/serial/mpc52xx_uart.c
--- linux-2.6.11-rc2-mm2/drivers/serial/mpc52xx_uart.c 2005-02-02 21:54:20.0 +
+++ linux-dsd/drivers/serial/mpc52xx_uart.c 2005-02-02 20:17:39.0 +
@@ -794,7 +794,7 @@ mpc52xx_uart_remove(struct ocp_device *o
#ifdef CONFIG_PM
static int
-mpc52xx_uart_suspend(struct ocp_device *ocp, u32 state)
+mpc52xx_uart_suspend(struct ocp_device *ocp, pm_message_t state)
{
struct uart_port *port = (struct uart_port *) ocp_get_drvdata(ocp);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/pmac_zilog.c linux-dsd/drivers/serial/pmac_zilog.c
--- linux-2.6.11-rc2-mm2/drivers/serial/pmac_zilog.c 2005-02-02 21:55:28.0 +
+++ linux-dsd/drivers/serial/pmac_zilog.c 2005-02-02 21:57:44.114230728 +
@@ -1590,7 +1590,7 @@ static int pmz_detach(struct macio_dev *
}
-static int pmz_suspend(struct macio_dev *mdev, u32 pm_state)
+static int pmz_suspend(struct macio_dev *mdev, pm_message_t pm_state)
{
struct uart_pmac_port *uap = dev_get_drvdata(>ofdev.dev);
struct uart_state *state;
@@ -1661,7 +1661,7 @@ static int pmz_resume(struct macio_dev *
if (uap == NULL)
return 0;
- if (mdev->ofdev.dev.power.power_state == 0)
+ if (mdev->ofdev.dev.power.power_state == PMSG_ON)
return 0;
pmz_debug("resume, switching to state 0\n");
@@ -1714,7 +1714,7 @@ static int pmz_resume(struct macio_dev *
pmz_debug("resume, switching complete\n");
- mdev->ofdev.dev.power.power_state = 0;
+ mdev->ofdev.dev.power.power_state = PMSG_ON;
return 0;
}
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/pxa.c linux-dsd/drivers/serial/pxa.c
--- linux-2.6.11-rc2-mm2/drivers/serial/pxa.c 2004-12-24 21:35:28.0 +
+++ linux-dsd/drivers/serial/pxa.c 2005-02-02 20:18:54.0 +
@@ -797,7 +797,7 @@ static struct uart_driver serial_pxa_reg
.cons = PXA_CONSOLE,
};
-static int serial_pxa_suspend(struct device *_dev, u32 state, u32 level)
+static int serial_pxa_suspend(struct device *_dev, pm_message_t state, u32 level)
{
struct uart_pxa_port *sport = dev_get_drvdata(_dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/s3c2410.c linux-dsd/drivers/serial/s3c2410.c
--- linux-2.6.11-rc2-mm2/drivers/serial/s3c2410.c 2005-02-02 21:55:28.0 +
+++ linux-dsd/drivers/serial/s3c2410.c 2005-02-02 20:19:20.0 +
@@ -1135,7 +1135,7 @@ int s3c24xx_serial_remove(struct device
#ifdef CONFIG_PM
-int s3c24xx_serial_suspend(struct device *dev, u32 state, u32 level)
+int s3c24xx_serial_suspend(struct device *dev, pm_message_t state, u32 level)
{
struct uart_port *port = s3c24xx_dev_to_port(dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/sa1100.c linux-dsd/drivers/serial/sa1100.c
--- linux-2.6.11-rc2-mm2/drivers/serial/sa1100.c 2004-12-24 21:34:00.0 +
+++ linux-dsd/drivers/serial/sa1100.c 2005-02-02 20:20:04.0 +
@@ -854,7 +854,7 @@ static struct uart_driver sa1100_reg = {
.cons = SA1100_CONSOLE,
};
-static int sa1100_serial_suspend(struct device *_dev, u32 state, u32 level)
+static int sa1100_serial_suspend(struct device *_dev, pm_message_t state, u32 level)
{
struct sa1100_port *sport = dev_get_drvdata(_dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/serial/serial_txx9.c linux-dsd/drivers/serial/serial_txx9.c
--- linux-2.6.11-rc2-mm2/drivers/serial/serial_txx9.c 2005-02-02 21:55:28.0 +
+++ linux-dsd/drivers/serial/serial_txx9.c 2005-02-02 20:21:09.0 +
@@ -1095,7 +1095,7 @@ static void __devexit pciserial_txx9_rem
}
}
-static int pciserial_txx9_suspend_one(struct pci_dev *dev, u32 state)
+static int
Re: [linux-usb-devel] 2.6: USB disk unusable level of data corruption
>> Is USB/SCSI just terminally broken under 2.6? David> I don't think so, but there are problems that appear in some David> hardware configs and not others. Many folk report no problems; David> a (very) few report nothing but. This is just a chime in to let people know others are seeing problems with USB/SCSI external enclosures. I haven't tried lately, but my USB/FireWire enclosure never worked with Linux (or WinNT under firewire, sigh...) so I haven't touched it in months. Money down the drain. David> If you've verified this on 2.6.10, then you certainly have have David> the ehci-hcd (re)queueing race fix that has made a big David> difference for some folk. I don't know of any other issues in David> that driver that could explain usb-storage problems. I should try it again and see how it works under USB/Firewire, my last attempts were under 2.6.[78] or so time frame. John - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Race condition in ptrace
Bodo Stroesser wrote: Nick Piggin wrote: Bodo Stroesser wrote: I don't see how this could help because AFAIKS, child->saving is only set and cleared while the runqueue is locked. And the same runqueue lock is taken by wait_task_inactive. Sorry, that not right. There are some routines called by sched(), that release and reacquire the runqueue lock. Oh yeah, it is the wake_sleeping_dependent / dependent_sleeper crap. Sorry, you are right. And that's definitely a bug in sched.c, because it breaks wait_task_inactive, as you've rightly observed. Andrew, IMO this is another bug to hold 2.6.11 for. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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 scrub daemon (prezeroing)
Christoph Lameter writes: > scrubd clears pages of orders 7-4 by default. That means 2^4 to 2^7 > pages are cleared at once. So are you saying that clearing an order 4 page will take measurably less time than clearing 16 order 0 pages? I find that hard to believe. Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1
On Fri, 2005-02-04 at 22:17 +, Sean Neakums wrote: > I gave this a crack on the PowerBook5.4 -- somewhat more successful > than 2.6.11-rc2-mm2. It boots, radeonfb works and X starts. However, > suspend seems a tad faster than usual, and resume stops after setting > the hard disk's DMA mode, although the log below made it to disk. Looks like USB is dying on wakeup... Anyway, that's still better than 2.6.11 since your model will not sleep/wakeup at all without these patches. I'll have to look into the USB thing. From the error messages, it looks like at least some of my patches removing some old pmac IRQ cruft from the ohci driver didn't make it (I though david picked it up a while ago though). Or it could be a problem with the interrupt controller, I've had reports of cases where the PIC just stops working on resume, I'm still investigating. Is this totally reproduceable or does it wake up sometimes ? Have you tried with USB disabled ? 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: 2.6.11-rc3-mm1
> I tried it two or three times, same result each time. I'll give it a > lash with USB disabled. Also, can you try editing arch/ppc/syslib/open_pic.c, in function openpic_resume(), comment out the call to openpic_reset() and let me know if that helps... 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/
[-mm PATCH] driver model: PM type conversions in drivers/net
This fixes PM driver model type checking for drivers/net.
Acked by Pavel Machek.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/8139cp.c linux-dsd/drivers/net/8139cp.c
--- linux-2.6.11-rc2-mm2/drivers/net/8139cp.c 2005-02-02 21:55:22.417771864 +
+++ linux-dsd/drivers/net/8139cp.c 2005-02-02 20:52:06.0 +
@@ -1862,7 +1862,7 @@ static void cp_remove_one (struct pci_de
}
#ifdef CONFIG_PM
-static int cp_suspend (struct pci_dev *pdev, u32 state)
+static int cp_suspend (struct pci_dev *pdev, pm_message_t state)
{
struct net_device *dev;
struct cp_private *cp;
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/bmac.c linux-dsd/drivers/net/bmac.c
--- linux-2.6.11-rc2-mm2/drivers/net/bmac.c 2005-02-02 21:54:17.353663112 +
+++ linux-dsd/drivers/net/bmac.c 2005-02-02 20:52:48.0 +
@@ -455,7 +455,7 @@ static void bmac_init_chip(struct net_de
}
#ifdef CONFIG_PM
-static int bmac_suspend(struct macio_dev *mdev, u32 state)
+static int bmac_suspend(struct macio_dev *mdev, pm_message_t state)
{
struct net_device* dev = macio_get_drvdata(mdev);
struct bmac_data *bp = netdev_priv(dev);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/irda/sa1100_ir.c linux-dsd/drivers/net/irda/sa1100_ir.c
--- linux-2.6.11-rc2-mm2/drivers/net/irda/sa1100_ir.c 2004-12-24 21:35:50.0 +
+++ linux-dsd/drivers/net/irda/sa1100_ir.c 2005-02-02 20:59:28.0 +
@@ -291,7 +291,7 @@ static void sa1100_irda_shutdown(struct
/*
* Suspend the IrDA interface.
*/
-static int sa1100_irda_suspend(struct device *_dev, u32 state, u32 level)
+static int sa1100_irda_suspend(struct device *_dev, pm_message_t state, u32 level)
{
struct net_device *dev = dev_get_drvdata(_dev);
struct sa1100_irda *si;
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/irda/stir4200.c linux-dsd/drivers/net/irda/stir4200.c
--- linux-2.6.11-rc2-mm2/drivers/net/irda/stir4200.c 2005-02-02 21:54:17.0 +
+++ linux-dsd/drivers/net/irda/stir4200.c 2005-02-02 20:58:41.0 +
@@ -1128,7 +1128,7 @@ static void stir_disconnect(struct usb_i
#ifdef CONFIG_PM
/* Power management suspend, so power off the transmitter/receiver */
-static int stir_suspend(struct usb_interface *intf, u32 state)
+static int stir_suspend(struct usb_interface *intf, pm_message_t state)
{
struct stir_cb *stir = usb_get_intfdata(intf);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/irda/vlsi_ir.c linux-dsd/drivers/net/irda/vlsi_ir.c
--- linux-2.6.11-rc2-mm2/drivers/net/irda/vlsi_ir.c 2005-02-02 21:54:17.0 +
+++ linux-dsd/drivers/net/irda/vlsi_ir.c 2005-02-02 21:19:25.0 +
@@ -1737,7 +1737,7 @@ static void __devexit vlsi_irda_remove(s
*/
-static int vlsi_irda_suspend(struct pci_dev *pdev, u32 state)
+static int vlsi_irda_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *ndev = pci_get_drvdata(pdev);
vlsi_irda_dev_t *idev;
@@ -1755,7 +1755,7 @@ static int vlsi_irda_suspend(struct pci_
down(>sem);
if (pdev->current_state != 0) { /* already suspended */
if (state > pdev->current_state) { /* simply go deeper */
- pci_set_power_state(pdev,state);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
pdev->current_state = state;
}
else
@@ -1774,7 +1774,7 @@ static int vlsi_irda_suspend(struct pci_
idev->new_baud = idev->baud;
}
- pci_set_power_state(pdev,state);
+ pci_set_power_state(pdev, pci_choose_state(pdev, state));
pdev->current_state = state;
idev->resume_ok = 1;
up(>sem);
@@ -1798,7 +1798,7 @@ static int vlsi_irda_resume(struct pci_d
return 0;
}
- pci_set_power_state(pdev, 0);
+ pci_set_power_state(pdev, PCI_D0);
pdev->current_state = 0;
if (!idev->resume_ok) {
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/ixgb/ixgb_main.c linux-dsd/drivers/net/ixgb/ixgb_main.c
--- linux-2.6.11-rc2-mm2/drivers/net/ixgb/ixgb_main.c 2005-02-02 21:54:18.0 +
+++ linux-dsd/drivers/net/ixgb/ixgb_main.c 2005-02-02 21:20:34.0 +
@@ -2101,7 +2101,7 @@ ixgb_notify_reboot(struct notifier_block
* @param state power state to enter
**/
static int
-ixgb_suspend(struct pci_dev *pdev, uint32_t state)
+ixgb_suspend(struct pci_dev *pdev, pm_message_t state)
{
struct net_device *netdev = pci_get_drvdata(pdev);
struct ixgb_adapter *adapter = netdev->priv;
@@ -2113,7 +2113,7 @@ ixgb_suspend(struct pci_dev *pdev, uint3
pci_save_state(pdev);
- state = (state > 0) ? 3 : 0;
+ state = (state > 0) ? PCI_D3hot : PCI_D0;
pci_set_power_state(pdev, state);
msec_delay(200);
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/net/ne2k-pci.c linux-dsd/drivers/net/ne2k-pci.c
--- linux-2.6.11-rc2-mm2/drivers/net/ne2k-pci.c 2005-02-02 21:55:22.999683400 +
+++ linux-dsd/drivers/net/ne2k-pci.c 2005-02-02 21:20:52.0 +
@@ -669,7 +669,7 @@ static int ne2k_pci_resume (struct pci_d
{
struct net_device *dev = pci_get_drvdata
[-mm PATCH] driver model: PM type conversions in drivers/pcmcia
This fixes PM driver model type checking for drivers/pcmcia.
Acked by Pavel Machek.
Signed-off-by: Daniel Drake <[EMAIL PROTECTED]>
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/au1000_generic.c linux-dsd/drivers/pcmcia/au1000_generic.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/au1000_generic.c 2005-02-02 21:55:26.0 +
+++ linux-dsd/drivers/pcmcia/au1000_generic.c 2005-02-02 20:43:45.0 +
@@ -521,7 +521,7 @@ static int au1x00_drv_pcmcia_probe(struc
}
-static int au1x00_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int au1x00_drv_pcmcia_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/hd64465_ss.c linux-dsd/drivers/pcmcia/hd64465_ss.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/hd64465_ss.c 2005-02-02 21:55:26.0 +
+++ linux-dsd/drivers/pcmcia/hd64465_ss.c 2005-02-02 20:44:51.0 +
@@ -860,7 +860,7 @@ static void hs_exit_socket(hs_socket_t *
local_irq_restore(flags);
}
-static int hd64465_suspend(struct device *dev, u32 state, u32 level)
+static int hd64465_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/m32r_cfc.c linux-dsd/drivers/pcmcia/m32r_cfc.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/m32r_cfc.c 2005-02-02 21:55:26.789107320 +
+++ linux-dsd/drivers/pcmcia/m32r_cfc.c 2005-02-02 20:46:32.0 +
@@ -749,7 +749,7 @@ static struct pccard_operations pcc_oper
/**/
-static int m32r_pcc_suspend(struct device *dev, u32 state, u32 level)
+static int m32r_pcc_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/m32r_pcc.c linux-dsd/drivers/pcmcia/m32r_pcc.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/m32r_pcc.c 2005-02-02 21:55:26.790107168 +
+++ linux-dsd/drivers/pcmcia/m32r_pcc.c 2005-02-02 20:47:01.0 +
@@ -701,7 +701,7 @@ static struct pccard_operations pcc_oper
/**/
-static int m32r_pcc_suspend(struct device *dev, u32 state, u32 level)
+static int m32r_pcc_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/pxa2xx_base.c linux-dsd/drivers/pcmcia/pxa2xx_base.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/pxa2xx_base.c 2004-12-24 21:36:02.0 +
+++ linux-dsd/drivers/pcmcia/pxa2xx_base.c 2005-02-02 20:47:27.0 +
@@ -205,7 +205,7 @@ int pxa2xx_drv_pcmcia_probe(struct devic
}
EXPORT_SYMBOL(pxa2xx_drv_pcmcia_probe);
-static int pxa2xx_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int pxa2xx_drv_pcmcia_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/sa1100_generic.c linux-dsd/drivers/pcmcia/sa1100_generic.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/sa1100_generic.c 2004-12-24 21:35:00.0 +
+++ linux-dsd/drivers/pcmcia/sa1100_generic.c 2005-02-02 20:47:56.0 +
@@ -75,7 +75,7 @@ static int sa11x0_drv_pcmcia_probe(struc
return ret;
}
-static int sa11x0_drv_pcmcia_suspend(struct device *dev, u32 state, u32 level)
+static int sa11x0_drv_pcmcia_suspend(struct device *dev, pm_message_t state, u32 level)
{
int ret = 0;
if (level == SUSPEND_SAVE_STATE)
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/sa_generic.c linux-dsd/drivers/pcmcia/sa_generic.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/sa_generic.c 2004-12-24 21:34:29.0 +
+++ linux-dsd/drivers/pcmcia/sa_generic.c 2005-02-02 20:48:21.0 +
@@ -158,7 +158,7 @@ static int __devexit pcmcia_remove(struc
return 0;
}
-static int pcmcia_suspend(struct sa_dev *dev, u32 state)
+static int pcmcia_suspend(struct sa_dev *dev, pm_message_t state)
{
return pcmcia_socket_dev_suspend(>dev, state);
}
diff -urNpX dontdiff linux-2.6.11-rc2-mm2/drivers/pcmcia/yenta_socket.c linux-dsd/drivers/pcmcia/yenta_socket.c
--- linux-2.6.11-rc2-mm2/drivers/pcmcia/yenta_socket.c 2005-02-02 21:55:26.797106104 +
+++ linux-dsd/drivers/pcmcia/yenta_socket.c 2005-02-02 20:49:58.0 +
@@ -873,7 +873,7 @@ static void yenta_config_init(struct yen
u16 bridge;
struct pci_dev *dev = socket->dev;
- pci_set_power_state(socket->dev, 0);
+ pci_set_power_state(socket->dev, PCI_D0);
config_writel(socket, CB_LEGACY_MODE_BASE, 0);
config_writel(socket, PCI_BASE_ADDRESS_0, dev->resource[0].start);
@@ -1052,7 +1052,7 @@ static int yenta_dev_resume (struct pci_
struct yenta_socket *socket = pci_get_drvdata(dev);
if (socket) {
-
Re: [PATCH][I2C] ST M41T00 I2C RTC chip driver
Greg KH wrote:
Can you resend it with a proper Changelog description in the top of the
email and the signed-off-by line? thanks,
greg k-h
Certainly.
--
This patch adds support for the ST M41T00 I2C RTC chip.
This rtc chip has no mechanism to freeze it's registers while being
read; however, it will delay updating the external values of the
registers for 250ms after a register is read. To ensure that a sane
time value is read, the driver verifies that the same registers values
were read twice before returning.
Also, when setting the rtc from an interrupt handler, a tasklet is used
to provide the context required by the i2c core code.
Please apply.
Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]>
--
diff -Nru a/drivers/i2c/chips/Kconfig b/drivers/i2c/chips/Kconfig
--- a/drivers/i2c/chips/Kconfig 2005-02-04 17:00:45 -07:00
+++ b/drivers/i2c/chips/Kconfig 2005-02-04 17:00:45 -07:00
@@ -371,4 +371,13 @@
This driver can also be built as a module. If so, the module
will be called isp1301_omap.
+config SENSORS_M41T00
+ tristate "ST M41T00 RTC chip"
+ depends on I2C && PPC32
+ help
+ If you say yes here you get support for the ST M41T00 RTC chip.
+
+ This driver can also be built as a module. If so, the module
+ will be called m41t00.
+
endmenu
diff -Nru a/drivers/i2c/chips/Makefile b/drivers/i2c/chips/Makefile
--- a/drivers/i2c/chips/Makefile2005-02-04 17:00:45 -07:00
+++ b/drivers/i2c/chips/Makefile2005-02-04 17:00:45 -07:00
@@ -26,6 +26,7 @@
obj-$(CONFIG_SENSORS_LM87) += lm87.o
obj-$(CONFIG_SENSORS_LM90) += lm90.o
obj-$(CONFIG_SENSORS_MAX1619) += max1619.o
+obj-$(CONFIG_SENSORS_M41T00) += m41t00.o
obj-$(CONFIG_SENSORS_PC87360) += pc87360.o
obj-$(CONFIG_SENSORS_PCF8574) += pcf8574.o
obj-$(CONFIG_SENSORS_PCF8591) += pcf8591.o
diff -Nru a/drivers/i2c/chips/m41t00.c b/drivers/i2c/chips/m41t00.c
--- /dev/null Wed Dec 31 16:00:00 196900
+++ b/drivers/i2c/chips/m41t00.c2005-02-04 17:00:45 -07:00
@@ -0,0 +1,247 @@
+/*
+ * drivers/i2c/chips/m41t00.c
+ *
+ * I2C client/driver for the ST M41T00 Real-Time Clock chip.
+ *
+ * Author: Mark A. Greer <[EMAIL PROTECTED]>
+ *
+ * 2005 (c) MontaVista Software, Inc. This file is licensed under
+ * the terms of the GNU General Public License version 2. This program
+ * is licensed "as is" without any warranty of any kind, whether express
+ * or implied.
+ */
+/*
+ * This i2c client/driver wedges between the drivers/char/genrtc.c RTC
+ * interface and the SMBus interface of the i2c subsystem.
+ * It would be more efficient to use i2c msgs/i2c_transfer directly but, as
+ * recommened in .../Documentation/i2c/writing-clients section
+ * "Sending and receiving", using SMBus level communication is preferred.
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+
+#defineM41T00_DRV_NAME "m41t00"
+
+static DECLARE_MUTEX(m41t00_mutex);
+
+static struct i2c_driver m41t00_driver;
+static struct i2c_client *save_client;
+
+static unsigned short ignore[] = { I2C_CLIENT_END };
+static unsigned short normal_addr[] = { 0x68, I2C_CLIENT_END };
+
+static struct i2c_client_address_data addr_data = {
+ .normal_i2c = normal_addr,
+ .normal_i2c_range = ignore,
+ .probe = ignore,
+ .probe_range= ignore,
+ .ignore = ignore,
+ .ignore_range = ignore,
+ .force = ignore,
+};
+
+ulong
+m41t00_get_rtc_time(void)
+{
+ s32 sec, min, hour, day, mon, year;
+ s32 sec1, min1, hour1, day1, mon1, year1;
+ ulong limit = 10;
+
+ sec = min = hour = day = mon = year = 0;
+ sec1 = min1 = hour1 = day1 = mon1 = year1 = 0;
+
+ down(_mutex);
+ do {
+ if (((sec = i2c_smbus_read_byte_data(save_client, 0)) >= 0)
+ && ((min = i2c_smbus_read_byte_data(save_client, 1))
+ >= 0)
+ && ((hour = i2c_smbus_read_byte_data(save_client, 2))
+ >= 0)
+ && ((day = i2c_smbus_read_byte_data(save_client, 4))
+ >= 0)
+ && ((mon = i2c_smbus_read_byte_data(save_client, 5))
+ >= 0)
+ && ((year = i2c_smbus_read_byte_data(save_client, 6))
+ >= 0)
+ && ((sec == sec1) && (min == min1) && (hour == hour1)
+ && (day == day1) && (mon == mon1)
+ && (year == year1)))
+
+ break;
+
+ sec1 = sec;
+ min1 = min;
+ hour1 = hour;
+ day1 = day;
+ mon1 = mon;
+ year1 = year;
+ } while (--limit > 0);
+ up(_mutex);
+
+ if (limit ==
Re: Patch to add usbmon
Hi Pete, > > While I am really thinking about starting usbdump, I may ask why you > > have choosen to use debugfs as interface. This will not be available in > > normal distribution kernels and I think a general USB monitoring ability > > would be great. For example like we have it for Ethernet, Bluetooth and > > IrDA. So my idea is to create some /dev/usbmonX (for each bus one) where > > usbdump can read its information from. What do you think? > > The debugfs will be available in distributions. And it's no different from > having SOCK_PACKET enabled before tcpdump can work. There's no practical > disadvantage, unless we consider a backport of usbmon into a legacy > distribution > such as RHEL 4 or SuSE 9.1. I am not interested in a backport. > Since usbmon rides raw file_operations, it can use a chardev interface with > a minimal change. The advantage of debugfs is only not needing to allocate > a major and dealing with minor partitioning. I also thought it would help > to shut up the namespace pollution whiners (the debate of /dbg versus > /sys/kernel/debug was rather mild by comparison). Getting a major number should be no problem and the minor partitioning is also easy, because the root hubs are already numbered by USB. > It should make little difference for the tool anyway, the base path ought to > be configurable. The biggest difference would be to scripts which launch the > tool: in one case they need to mount debugfs if not mounted (if initscripts > haven't), in other case they mknod if necessary (if hal hasn't done it). The mknod reason is no reason for, because we have udev (not hal btw) and this working perfect. > It is too early to care about this anyway. Since I am really thinking of writing usbdump, it is not to early. What stuff is missing in your usbmon patch? Regards Marcel - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3: intel8x0 alsa outputs no sound
Hi John, On Friday 04 February 2005 01:33 pm, you wrote: > i'm using a thinkpad r40 w/ intel8x0 sound card. it worked with 2.6.10. > % ogg123 -d alsa09 file.ogg > i can get no sound through either alsa or oss emulation. I'm running 2.6.11-rc3 on a T30 also with an intel8x0 card and not experiencing any troubles with sound. (Using Alsa, btw) Did you check the usual culprits- that your modules are being loaded, permissions of /dev/sound/*, that the channels are unmuted, etc? Checkout the thinkpad list too, they're always very helpful. Good luck, Shaw - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH REPOST 2.6.11-rc2 14/14] ide_pci: Merges serverworks.h into serverworks.c
Sorry, the original #14 added back SVWKS_DEBUG_DRIVE_INFO which #13
removed. This is the regenerated patch.
14_ide_pci_serverworks_merge.patch
Merges ide/pci/serverworks.h into serverworks.c.
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
Index: linux-idepci-export/drivers/ide/pci/serverworks.c
===
--- linux-idepci-export.orig/drivers/ide/pci/serverworks.c 2005-02-05
08:56:34.184740697 +0900
+++ linux-idepci-export/drivers/ide/pci/serverworks.c 2005-02-05
08:57:24.673562622 +0900
@@ -39,7 +39,18 @@
#include
-#include "serverworks.h"
+#define SVWKS_CSB5_REVISION_NEW0x92 /* min PCI_REVISION_ID for UDMA5
(A2.0) */
+#define SVWKS_CSB6_REVISION0xa0 /* min PCI_REVISION_ID for UDMA4 (A1.0) */
+
+/* Seagate Barracuda ATA IV Family drives in UDMA mode 5
+ * can overrun their FIFOs when used with the CSB5 */
+static const char *svwks_bad_ata100[] = {
+ "ST320011A",
+ "ST340016A",
+ "ST360021A",
+ "ST380021A",
+ NULL
+};
static u8 svwks_revision = 0;
static struct pci_dev *isa_dev;
@@ -582,6 +593,48 @@ static int __init init_setup_csb6 (struc
return ide_setup_pci_device(dev, d);
}
+/*
+ * Table of the various serverworks capability blocks
+ */
+
+static ide_pci_device_t serverworks_chipsets[] __devinitdata = {
+ { /* 0 */
+ .name = "SvrWks OSB4",
+ .init_setup = init_setup_svwks,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 1 */
+ .name = "SvrWks CSB5",
+ .init_setup = init_setup_svwks,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .init_dma = init_dma_svwks,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 2 */
+ .name = "SvrWks CSB6",
+ .init_setup = init_setup_csb6,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .init_dma = init_dma_svwks,
+ .channels = 2,
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ },{ /* 3 */
+ .name = "SvrWks CSB6",
+ .init_setup = init_setup_csb6,
+ .init_chipset = init_chipset_svwks,
+ .init_hwif = init_hwif_svwks,
+ .init_dma = init_dma_svwks,
+ .channels = 1,/* 2 */
+ .autodma= AUTODMA,
+ .bootable = ON_BOARD,
+ }
+};
/**
* svwks_init_one - called when a OSB/CSB is found
Index: linux-idepci-export/drivers/ide/pci/serverworks.h
===
--- linux-idepci-export.orig/drivers/ide/pci/serverworks.h 2005-02-05
08:57:24.477594365 +0900
+++ /dev/null 1970-01-01 00:00:00.0 +
@@ -1,67 +0,0 @@
-
-#ifndef SERVERWORKS_H
-#define SERVERWORKS_H
-
-#include
-#include
-#include
-
-#define SVWKS_CSB5_REVISION_NEW0x92 /* min PCI_REVISION_ID for UDMA5
(A2.0) */
-#define SVWKS_CSB6_REVISION0xa0 /* min PCI_REVISION_ID for UDMA4 (A1.0) */
-
-/* Seagate Barracuda ATA IV Family drives in UDMA mode 5
- * can overrun their FIFOs when used with the CSB5 */
-static const char *svwks_bad_ata100[] = {
- "ST320011A",
- "ST340016A",
- "ST360021A",
- "ST380021A",
- NULL
-};
-
-static int init_setup_svwks(struct pci_dev *, ide_pci_device_t *);
-static int init_setup_csb6(struct pci_dev *, ide_pci_device_t *);
-static unsigned int init_chipset_svwks(struct pci_dev *, const char *);
-static void init_hwif_svwks(ide_hwif_t *);
-static void init_dma_svwks(ide_hwif_t *, unsigned long);
-
-static ide_pci_device_t serverworks_chipsets[] __devinitdata = {
- { /* 0 */
- .name = "SvrWks OSB4",
- .init_setup = init_setup_svwks,
- .init_chipset = init_chipset_svwks,
- .init_hwif = init_hwif_svwks,
- .channels = 2,
- .autodma= AUTODMA,
- .bootable = ON_BOARD,
- },{ /* 1 */
- .name = "SvrWks CSB5",
- .init_setup = init_setup_svwks,
- .init_chipset = init_chipset_svwks,
- .init_hwif = init_hwif_svwks,
- .init_dma = init_dma_svwks,
- .channels = 2,
- .autodma= AUTODMA,
- .bootable = ON_BOARD,
- },{ /*
Re: 2.6.11-rc3-mm1
Benjamin Herrenschmidt <[EMAIL PROTECTED]> writes: > On Fri, 2005-02-04 at 22:17 +, Sean Neakums wrote: >> I gave this a crack on the PowerBook5.4 -- somewhat more successful >> than 2.6.11-rc2-mm2. It boots, radeonfb works and X starts. However, >> suspend seems a tad faster than usual, and resume stops after setting >> the hard disk's DMA mode, although the log below made it to disk. > > Looks like USB is dying on wakeup... Anyway, that's still better than > 2.6.11 since your model will not sleep/wakeup at all without these > patches. > > I'll have to look into the USB thing. From the error messages, it looks > like at least some of my patches removing some old pmac IRQ cruft from > the ohci driver didn't make it (I though david picked it up a while ago > though). Or it could be a problem with the interrupt controller, I've > had reports of cases where the PIC just stops working on resume, I'm > still investigating. > > Is this totally reproduceable or does it wake up sometimes ? Have you > tried with USB disabled ? I tried it two or three times, same result each time. I'll give it a lash with USB disabled. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1: device_resume() hangs on Athlon64
On Friday, 4 of February 2005 19:33, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.11-rc3/2.6.11-rc3-mm1/
>
On my box (Athlon64-based) swsusp hangs forever in device_resume() called
from swsusp_write(), although interrupts are apparently handled
normally then (eg magic SysRq works). The last thing it says is:
ACPI: PCI interrupt :00:06.0[A] -> GSI 5 (level, low) -> IRQ 5
PCI: Setting latency timer of device :00:06.0 to 64
ACPI: PCI interrupt :02:00.0[A] -> GSI 11 (level, low) -> IRQ 11
ACPI: PCI interrupt :02:01.2[C] -> GSI 11 (level, low) -> IRQ 11
When I press Alt+SysRq+p it says:
SysRq : Show Regs
Modules linked in: snd_seq snd_seq_device usbserial parport_pc lp parport
thermal processor fan button battery ac snd_pcm_oss snd_mixer_oss snd
Pid: 0, comm: swapper Not tainted 2.6.11-rc3-mm1
RIP: 0010:[] {__delay+12}
RSP: 0018:804dae20 EFLAGS: 0216
RAX: 000adaaa RBX: 804dad78 RCX: d3afd2ab
RDX: 0076 RSI: 88b8 RDI: 000c0a08
RBP: 8010f199 R08: 00140040 R09: 81001db48ce0
R10: R11: R12: 0046
R13: 801117e2 R14: 8054d900 R15: 81001fde4ab8
FS: 2b28b800() GS:80565800() knlGS:
CS: 0010 DS: 0018 ES: 0018 CR0: 8005003b
CR2: 2abab000 CR3: 0d557000 CR4: 06e0
Call Trace: {ide_wait_not_busy+31}
{ide_do_request+1153}
{ide_end_drive_cmd+1074}
{end_8259A_irq+96}
{ide_intr+1316} {handle_IRQ_event+44}
{__do_IRQ+470} {__do_softirq+83}
{do_IRQ+66} {ret_from_intr+0}
{console_callback+0}
{thread_return+41}
{default_idle+0} {default_idle+32}
{cpu_idle+54} {start_kernel+463}
{_sinittext+576}
This happens 100% of the time. It also happened on 2.6.11-rc2-mm2, but not on
2.6.11-rc2-mm1, AFAIR. It does not occur on the -rc[1-3] kernels.
Greets,
Rafael
--
- Would you tell me, please, which way I ought to go from here?
- That depends a good deal on where you want to get to.
-- Lewis Carroll "Alice's Adventures in Wonderland"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] arp_queue: serializing unlink + kfree_skb
On Fri, 4 Feb 2005 22:33:05 +1100
Herbert Xu <[EMAIL PROTECTED]> wrote:
> I think you should probably note that some sort of locking or RCU
> scheme is required to make this safe. As it is the atomic_inc
> and the list_add can be reordered such that the atomic_inc occurs
> after the atomic_dec_and_test.
>
> Either that or you can modify the example to add an
> smp_mb__after_atomic_inc(). That'd be a good way to
> demonstrate its use.
Yeah, this example is totally bogus. I'll make it match the
neighbour cache case which started this discussion. Which is
something like:
static void obj_list_add(struct obj *obj)
{
obj->active = 1;
list_add(>list);
}
static void obj_list_del(struct obj *obj)
{
list_del(>list);
obj->active = 0;
}
static void obj_destroy(struct obj *obj)
{
BUG_ON(obj->active);
kfree(obj);
}
struct obj *obj_list_peek(struct list_head *head)
{
if (!list_empty(head)) {
struct obj *obj;
obj = list_entry(head->next, struct obj, list);
atomic_inc(>refcnt);
return obj;
}
return NULL;
}
void obj_poke(void)
{
struct obj *obj;
spin_lock(_list_lock);
obj = obj_list_peek(_list);
spin_unlock(_list_lock);
if (obj) {
obj->ops->poke(obj);
if (atomic_dec_and_test(>refcnt))
obj_destroy(obj);
}
}
void obj_timeout(struct obj *obj)
{
spin_lock(_list_lock);
obj_list_del(obj);
spin_unlock(_list_lock);
if (atomic_dec_and_test(>refcnt))
obj_destroy(obj);
}
Something like that. I'll update the atomic_ops.txt
doc and post and updated version later tonight.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 to add usbmon
On Tue, Feb 01, 2005 at 10:25:13PM -0800, Pete Zaitcev wrote: > This patch adds so-called "usbmon", or USB monitoring framework, similar > to what tcpdump provides for Ethernet. This is an initial version, but > it should be safe and useful. It adds an overhead of an if () statement > into submission and giveback paths even when not monitoring, but this > was deemed a lesser evil than stealth manipulation of function pointers. > > The patch makes two changes to hcd.c which make usbmon more useful: > - Change the way we determine that DMA should not be mapped for root >hubs, so that usbmon knows easily when it's safe to capture data. > - Return exports of usb_bus_list and usb_bus_list_lock for those who >wish to build usbmon as a module. > > This version of the patch changes #define to inlines for hooks and > drops extra mod_ops. > > Signed-off-by: Pete Zaitcev 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] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
On Fri, 2005-02-04 at 12:35 -0600, Olof Johansson wrote: > On Fri, Feb 04, 2005 at 01:36:55PM +0100, Arnd Bergmann wrote: > > I have a somewhat similar patch that does the same to the > > systemcfg->platform checks. I'm not sure if we should use the same inline > > function for both checks, but I do think that they should be used in a > > similar way, e.g. CPU_HAS_FEATURE(x) and PLATFORM_HAS_FEATURE(x). > > Yep. Firmware features are also on the list. I figured I'd do CPU features > first though since they are the ones that started bugging me. > > > The same stuff is obviously possible for cur_cpu_spec->cpu_features as well. > > Do you think that it will help there? > > Nice. It won't be quite as easy to do compile-time for cpu features. > pSeries will need all cpus enabled since we have them all on various > machines, etc. I guess Powermac/Maple could benefit from it. In the > end it depends on how hairy the implementation would get vs performance > improvement. One other thing we did on ppc32 was to have separate ELF sections for pmac, chrp and prep specific code & get rid of them after boot... It may be worth bringing this back in... 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] PPC/PPC64: Introduce CPU_HAS_FEATURE() macro
On Fri, 2005-02-04 at 13:36 +0100, Arnd Bergmann wrote:
> On Freedag 04 Februar 2005 08:22, Olof Johansson wrote:
> > It's getting pretty old to have see and type cur_cpu_spec->cpu_features
> > & CPU_FTR_, when a shorter and less TLA-ridden macro is more
> > readable.
> >
> > This also takes care of the differences between PPC and PPC64 cpu
> > features for the common code; most places in PPC could be replaced with
> > the macro as well.
>
> I have a somewhat similar patch that does the same to the
> systemcfg->platform checks. I'm not sure if we should use the same inline
> function for both checks, but I do think that they should be used in a
> similar way, e.g. CPU_HAS_FEATURE(x) and PLATFORM_HAS_FEATURE(x).
Note that I would prefer cpu_has_feature(), it doesn't strictly have to
be a macro and has function semantics anyway.
> My implementation of the platform checks tries to be extra clever by turning
> runtime checks into compile time checks if possible. This reduces code size
> and in some cases execution speed. It can also be used to replace compile
> time checks, i.e. it allows us to write
>
> static inline unsigned int readl(const volatile void __iomem *addr)
> {
> if (platform_is(PLATFORM_PPC_ISERIES))
> return iSeries_readl(addr);
> if (platform_possible(PLATFORM_PPC_PSERIES))
> return eeh_readl(addr);
> return in_le32();
> }
>
> which will always result in the shortest code for any combination of
> CONFIG_PPC_ISERIES, CONFIG_PPC_PSERIES and the other platforms.
That's a good idea !
> The required code for this is roughly
>
> enum {
> PPC64_PLATFORM_POSSIBLE =
> #ifdef CONFIG_PPC_ISERIES
> PLATFORM_ISERIES |
> #endif
> #ifdef CONFIG_PPC_PSERIES
> PLATFORM_PSERIES |
> #endif
> #ifdef CONFIG_PPC_PSERIES
> PLATFORM_PSERIES_LPAR |
> #endif
> #ifdef CONFIG_PPC_POWERMAC
> PLATFORM_POWERMAC |
> #endif
> #ifdef CONFIG_PPC_MAPLE
> PLATFORM_MAPLE |
> #endif
> 0,
> PPC64_PLATFORM_ONLY =
> #ifdef CONFIG_PPC_ISERIES
> PLATFORM_ISERIES &
> #endif
> #ifdef CONFIG_PPC_PSERIES
> PLATFORM_PSERIES &
> #endif
> #ifdef CONFIG_PPC_POWERMAC
> PLATFORM_POWERMAC &
> #endif
> #ifdef CONFIG_PPC_MAPLE
> PLATFORM_MAPLE &
> #endif
> -1ul,
> };
>
> static inline platform_is(unsigned long platform)
> {
> return ((PPC64_PLATFORM_ONLY & platform)
>|| (PPC64_PLATFORM_POSSIBLE & platform & systemcfg->platform));
> }
>
> static inline platform_possible(unsigned long platform)
> {
> reutrn !!(PPC64_PLATFORM_POSSIBLE & platform);
> }
>
> The same stuff is obviously possible for cur_cpu_spec->cpu_features as well.
> Do you think that it will help there?
>
> Arnd <><
> ___
> Linuxppc64-dev mailing list
> [EMAIL PROTECTED]
> https://ozlabs.org/cgi-bin/mailman/listinfo/linuxppc64-dev
--
Benjamin Herrenschmidt <[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: Drive performance bottleneck
Lincoln Dale <[EMAIL PROTECTED]> wrote: > > sg_dd uses a window into a kernel DMA window. as such, two of the four > memory acccesses are cut out (1. DMA from HBA to RAM, 2. userspace > accessing data). > 1.6Gbps / 2 = 800MB/s -- or roughly what Ian was seeing with sg_dd. Right. That's a fancy way of saying "cheating" ;) But from the oprofile output it appears to me that there is plenty of CPU capacity left over. Maybe I'm misreading it due to oprofile adding in the SMP factor (25% CPU on a 4-way means we've exhausted CPU capacity). > DIRECT_IO should achieve similar numbers to sg_dd, but perhaps not quite as > efficient. Probably so. There are various tools in http://www.zip.com.au/~akpm/linux/patches/stuff/ext3-tools.tar.gz which are more useful than dd, btw. `odread' and `odwrite' are usful for this sort of thing. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] relayfs redux, part 3
Andi Kleen writes: > > > + > > + local_irq_save(flags); > > + if (unlikely(buf->offset + length > chan->subbuf_size)) > > + length = relay_switch_subbuf(buf, length); > > + memcpy(buf->data + buf->offset, data, length); > > + buf->offset += length; > > + local_irq_restore(flags); > > + > > + return length; > > Is there any useful user case for returning length here? > (e.g. are users likely to handle errors? I doubt it somehow) > > If not I would eliminate it. > The main reason would be that length would be 0 only if the buffers were full, so the caller can suspend writing if it sees that, until e.g. a daemon catches up. Thanks for your other comments - I'll make those changes in the next version. Tom - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][i386] HPET setup, duplicate HPET_T0_CMP needed for some platforms
This patch fixes the issue with HPET on some platforms. According to Vojtech Pavlik: The first write after writing TN_SETVAL to the config register sets the counter value, the second write sets the threshold. When you only do the first write you never set the threshold and interrupts won't be generated properly. Thanks to John Stultz and Andrew Walrond for reporting, root causing the issue and verifying this fix. Signed-off-by: Venkatesh Pallipadi <[EMAIL PROTECTED]> --- linux-2.6.10/arch/i386/kernel/time_hpet.c.org 2005-02-04 12:04:09.0 -0800 +++ linux-2.6.10/arch/i386/kernel/time_hpet.c 2005-02-04 18:01:25.0 -0800 @@ -81,6 +81,11 @@ static int hpet_timer_stop_set_go(unsign cfg |= HPET_TN_ENABLE | HPET_TN_PERIODIC | HPET_TN_SETVAL | HPET_TN_32BIT; hpet_writel(cfg, HPET_T0_CFG); + /* +* Some systems seems to need two writes to HPET_T0_CMP, +* to get interrupts working +*/ + hpet_writel(tick, HPET_T0_CMP); hpet_writel(tick, HPET_T0_CMP); /* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: [Ext2-devel] [PATCH] JBD: journal_release_buffer()
Hi, On Sun, 2005-01-30 at 10:55, Alex Tomas wrote: > yup, you're right. so, here is an implementation of this. > tested on UP/SMP by dbench/fsx. Stephen, Andrew, could you > review the patch and give it a run? Just to say I haven't forgotten, just been battling this week against all sorts of apparent hardware problems on some test boxes... I'll try to get you some proper results next week. Cheers, Stephen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-bk1: ide1: failed to initialize IDE interface
On Fri, 4 Feb 2005 23:44:22 +0100, Jean Delvare <[EMAIL PROTECTED]> wrote: > Hi all, > > I just gave a quick try to 2.6.11-rc3-bk1, and noticed the following > new message in dmesg: > ide1: failed to initialize IDE interface > > This seems to be new in 2.6.11-rc3-bk1. I could find the relevant > changeset in bk: > http://linux.bkbits.net:8080/linux-2.5/[EMAIL PROTECTED] > > My (admittedly quick) analysis of the code (drivers/ide/ide-probe.c) is > that init_hwif() can return 0 in two cases: either because the IDE > interface is somehow not really there (!hwif->present) or because > something wrong happened while initializing the IDE interface. My > system's ide1 happens to be enabled (BIOS settings) but no IDE device is > connected to it. I traced the code and it unsurprisingly happens that I > am in the first "error" case - init_hwif() exits immediately because > !hwif->present. > > I would tend to think that this is *not* an error, so we shouldn't > display an error message in this case. Maybe init_hwif() should return 1 Yep this is the simplest fix - interface without a drives should return success value. Care to make a patch? > instead of 0 in this case. Or maybe it should return -1, 0 and 1 for > error, no interface and success, respectively. I'm not certain I > understand the semantics behind the returned value, does it mean > error/success or interface absent/present (or a bit of each)? Or maybe Return value currently means only error/success and till the latest patch this value was ignored completely. > we could move the error message into init_hwif() itself, but that would > require some error path changes. > > I do not propose a patch because I'm not exactly sure what has to be > done, but I still believe something has to be done. Insight anyone? > > Thanks, > -- > Jean Delvare > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Legacy IO spaces (was Re: [RFC] Reliable video POSTing on resume)
On Friday, February 4, 2005 2:59 pm, Jon Smirl wrote: > Can you build a no-op version of these that will run on the x86? That > would allow a single user space API for x86, ia64. Maybe the ppc > people will join too. Shouldn't be too hard I think. > Why does this appear in /sys/class/pci_bus/:17/? For example on my > x86 system I have a single legacy space but if I do a dir of > /sys/class/pci_bus I show three buses. You wouldn't want the > legacy_io/mem attributes on each of these three buses since that > implies three independent address spaces. > > [EMAIL PROTECTED] pci_bus]$ ls /sys/class/pci_bus > :00 :01 :02 In that case they'll all point to the same memory and I/O space. On the machines I coded it on, each bus has its own space. > How would things be sorted out so that legacy_io/mem attributes only > appear on my root bridge chip :00 and not on the child buses. I > guess this also means the user space app has to search through the bus > entries. We might have to add more arch code in that case, but I thought it might be easiest for apps if they could just open the space for the bus they're interested in and it would be routed correctly. I think that'll be ok so long as two apps aren't trying to do stuff on the bus at the same time. > In order to know how many VGA many simultaneous VGA devices you can > have there needs to be some way to count the number of legacy address > spaces. Maybe there should be a /sys/class/legacy to describe the > legacy spaces. Is it possible to have the same legacy space aliased at > two different addresses depending on which root bus is used to get to > it? > > I need to know how to answer these questions: > 1) how many legacy spaces are there Depends on your platform. > 2) how many VGA devices are in each space Ditto since the number of spaces depends on the platform. > 3) how do I do VGA bus routing to access the VGA device This interface just deals with the whole legacy ISA space, not just VGA ports. I guess some chipsets will do VGA only or split them up? > 4) how do I address each of the devices. Jesse - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] Linux Kernel Subversion Howto
Stelian Pop <[EMAIL PROTECTED]> : [...] > Now, suppose one of my patches introduced a problem. How can someone > not using BK isolate the patch which introduced the problem ? All he > can do is to back out the entire set of patches, and the whole point > of having split the patch initialy into logical changes is lost. Nope: he digs the bk-commit mailing list archives. For example, from Roland's mail 2005/01/31 01:37:39-05:00 len.brown 2005/01/31 01:35:48-05:00 len.brown 2005/01/31 00:15:20-05:00 len.brown 2005/01/31 00:12:40-05:00 len.brown [etc.] $ grep +/^ChangeSet.*2005/01/31.*len.brown ~/Mail/linux/bk-commit/200505 ChangeSet 1.1983.5.2, 2005/01/31 00:15:20-05:00, [EMAIL PROTECTED] ChangeSet 1.1938.498.11, 2005/01/31 00:12:40-05:00, [EMAIL PROTECTED] ChangeSet 1.1983.5.3, 2005/01/31 01:37:39-05:00, [EMAIL PROTECTED] ChangeSet 1.1938.498.12, 2005/01/31 01:35:48-05:00, [EMAIL PROTECTED] Same thing as in Roland's mail but the changes are isolated. -- Ueimor - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] invalidate range of pages after direct IO write
Zach Brown <[EMAIL PROTECTED]> wrote:
>
> Andrew Morton wrote:
>
> > I'd be inclined to hold off on the macro until we actually get the
> > open-coded stuff right.. Sometimes the page lookup loops take an end+1
> > argument and sometimes they take an inclusive `end'. I think. That might
> > make it a bit messy.
> >
> > How's this look?
>
> Looks good. It certainly stops the worst behaviour we were worried
> about. I wonder about 2 things:
>
> 1) Now that we're calculating a specifc length for pagevec_lookup(), is
> testing that page->index > end still needed for pages that get remapped
> somewhere weird before we locked? If it is, I imagine we should test
> for < start as well.
Nope. We're guaranteed that the pages which pagevec_lookup() returned are
a) at or beyond `start' and
b) in ascending pgoff_t order, although not necessarily contiguous.
There will be gaps for not-present pages. It's just an in-order gather.
So we need the `page->index > end' test to cope with the situation where a
request for three pages returned the three pages at indices 10, 11 and
3,000,000.
> 2) If we get a pagevec full of pages that fail the != mapping test we
> will probably just try again, not having changed next. This is fine, we
> won't find them in our mapping again.
Yes, good point. That page should go away once we drop our ref, and
it's not in the radix tree any more.
> But this won't happen if next
> started as 0 and we didn't update it. I don't know if retrying is the
> intended behaviour or if we care that the start == 0 case doesn't do it.
Good point. Let's make it explicit?
--- 25/mm/truncate.c~invalidate-range-of-pages-after-direct-io-write-fix-fix
Fri Feb 4 15:33:52 2005
+++ 25-akpm/mm/truncate.c Fri Feb 4 15:34:47 2005
@@ -260,11 +260,12 @@ int invalidate_inode_pages2_range(struct
int i;
int ret = 0;
int did_range_unmap = 0;
+ int wrapped = 0;
pagevec_init(, 0);
next = start;
- while (next <= end &&
- !ret && pagevec_lookup(, mapping, next,
+ while (next <= end && !ret && !wrapped &&
+ pagevec_lookup(, mapping, next,
min(end - next, (pgoff_t)PAGEVEC_SIZE - 1) + 1)) {
for (i = 0; !ret && i < pagevec_count(); i++) {
struct page *page = pvec.pages[i];
@@ -277,6 +278,8 @@ int invalidate_inode_pages2_range(struct
}
wait_on_page_writeback(page);
next = page->index + 1;
+ if (next == 0)
+ wrapped = 1;
while (page_mapped(page)) {
if (!did_range_unmap) {
/*
@@ -307,8 +310,6 @@ int invalidate_inode_pages2_range(struct
}
pagevec_release();
cond_resched();
- if (next == 0)
- break; /* The pgoff_t wrapped */
}
return ret;
}
_
> I'm being less excited by the iterating macro the more I think about it.
>Tearing down the pagevec in some complicated for(;;) doesn't sound
> reliable and I fear that some function that takes a per-page callback
> function pointer from the caller will turn people's stomachs.
heh, OK.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.11-rc3-mm1 (compile stats)
On Fri, 2005-02-04 at 13:51 -0800, John Cherry wrote: > On Fri, 2005-02-04 at 13:13 -0800, Andrew Morton wrote: > > John Cherry <[EMAIL PROTECTED]> wrote: > > > > > > Errors in the build relate to an undefined reference to > > > "randomize_va_space"... > > > > > >LD init/built-in.o > > >LD .tmp_vmlinux1 > > > arch/i386/kernel/built-in.o(.text+0xf92): In function `arch_align_stack': > > > : undefined reference to `randomize_va_space' > > > make: [.tmp_vmlinux1] Error 1 (ignored) > > > > hm. You must have CONFIG_SYSCTL=n? > > > > I'll fix that up. > > CONFIG_SYSCTL=n in the allnoconfig build, which I would expect. > > http://developer.osdl.org/cherry/compile/2.6/linux-2.6.11-rc3-mm1.results/2.6.11-rc3-mm1.allnoconfig.bzImage.txt > > However, CONFIG_SYSCTL=y in the defconfig with similar errors... > > http://developer.osdl.org/cherry/compile/2.6/linux-2.6.11-rc3-mm1.results/2.6.11-rc3-mm1.defconfig.bzImage.txt The errors in the defconfig build (with CONFIG_SYSCTL=y) are unrelated to the undefined reference found in the allnoconfig build. The errors in this build are.. kernel/power/swsusp.c: In function `alloc_pagedir': kernel/power/swsusp.c:608: sorry, unimplemented: inlining failed in call to 'free_pagedir': function body not available kernel/power/swsusp.c:646: sorry, unimplemented: called from here make[2]: [kernel/power/swsusp.o] Error 1 (ignored) Adrian Bunk has submitted a patch for this. > > I suspect the problem may be fixed with Frank Sorenson's patch. I'll > kick off a rebuild with his patch and see what happens. Frank's patch did not fix the undefined reference to randomize_va_space. I suspect it is a CONFIG_SYSCTL=n problem as well since it only appears in the allnoconfig build. John > > John > > --- > > The stack randomization patches that went into 2.6.11-rc3-mm1 broke > compilation of ARCH=um. This patch fixes compiling by adding > arch_align_stack back in. > > Signed-off-by: Frank Sorenson <[EMAIL PROTECTED]> > Acked-By: Jeff Dike <[EMAIL PROTECTED]> > > Frank > > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: SysKonnect sk98lin Gigabit lan missing in action from 2.6.10 on
Jeff Garzik [EMAIL PROTECTED] wrote: > maxer wrote: > >What is the status of sk98lin? Do we have to wait until Syskonnect gets > >their act together > >and write a new driver for 2.6.10? > > > >Their latest is Oct 2004 and not at all compatible with 2.6.10 and beyond. > > I've been telling SysKonnect for _years_ that they need to split up > their patches, but they still keep sending ever-larger jumbo driver > update patches. > > Stephen Hemminger split up their patch into a bunch of patches, and I > applied several of those. > > Apparently, Stephen also got sick of trying to patch and clean sk98lin, > so he went and wrote his own "skge" driver. It's available in my > netdev-2.6 queue, and should be in the latest -mm. > > Jeff > > > > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to [EMAIL PROTECTED] > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ I have a SysKonnect card, and tried the skge driver (it's in the mm tree), with nominal testing I'd have to say it works well, if not better then the sk98lin driver. -- *--* Mail: [EMAIL PROTECTED] *--* Voice: 425.739.4247 *--* Fax: 425.827.9577 *--* HTTP://the-penguin.otak.com/~lawrence -- - - - - - - O t a k i n c . - - - - - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][I2C] ST M41T00 I2C RTC chip driver
On Fri, Feb 04, 2005 at 04:14:51PM -0700, Mark A. Greer wrote: > From http://archives.andrew.net.au/lm-sensors/msg29319.html: > > Mark A. Greer wrote: > > > > > > >Here is a replacement patch that should address Jean Delvare and Dick > >Johnson's issues. Please let me know if there are any more issues. > > > >Thanks, > > > >Mark > > > >Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> > >-- > > > I haven't heard of any more problems so can I get this patch applied? Can you resend it with a proper Changelog description in the top of the email and the signed-off-by line? 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: 2.6.10: kswapd spins like crazy
Terje Fåberg wrote: Terje Fåberg <[EMAIL PROTECTED]> skrev: I'll continue to do the same things I did yesterday before kswapd started to spin. Looks very good so far. I am unable to reproduce the bad kswapd behaviour with your patch, Nick. To double-check I booted into the old kernel an hour ago and I _could_ reproduce the bad behaviour within a few minutes. Looks like your patch fixes it for my workload. OK that's good to know. At this stage it is only working around the intermediate symptoms, and we might want a different fix for 2.6.11... So hopefully you'll be able to test a patch or two if you get time. Thanks, Nick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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][I2C] ST M41T00 I2C RTC chip driver
From http://archives.andrew.net.au/lm-sensors/msg29319.html: Mark A. Greer wrote: Here is a replacement patch that should address Jean Delvare and Dick Johnson's issues. Please let me know if there are any more issues. Thanks, Mark Signed-off-by: Mark A. Greer <[EMAIL PROTECTED]> -- I haven't heard of any more problems so can I get this patch applied? Thanks, Mark - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: Race condition in ptrace
Andrew Morton wrote: Nick Piggin <[EMAIL PROTECTED]> wrote: Bodo Stroesser wrote: Nick Piggin wrote: Bodo Stroesser wrote: I don't see how this could help because AFAIKS, child->saving is only set and cleared while the runqueue is locked. And the same runqueue lock is taken by wait_task_inactive. Sorry, that not right. There are some routines called by sched(), that release and reacquire the runqueue lock. Oh yeah, it is the wake_sleeping_dependent / dependent_sleeper crap. Sorry, you are right. And that's definitely a bug in sched.c, because it breaks wait_task_inactive, as you've rightly observed. Andrew, IMO this is another bug to hold 2.6.11 for. Sure. I wouldn't consider Bodo's patch to be the one to use though.. No. Something similar could be done that works on all architectures and all wait_task_inactive callers (and is confined to sched.c). That would still be more or less a hack to work around smtnice's unfortunate locking though. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
