[PATCH] relay: use plain timer instead of delayed work
Hi,
This patch makes relay use timers instead of workqueues for reader
waking.
Tom
---
relay doesn't need to use schedule_delayed_work() for waking readers
when a simple timer will do.
Signed-off-by: Tom Zanussi <[EMAIL PROTECTED]>
---
include/linux/relay.h |2 +-
kernel/relay.c| 37 -
2 files changed, 21 insertions(+), 18 deletions(-)
diff --git a/include/linux/relay.h b/include/linux/relay.h
index 759a0f9..cac0732 100644
--- a/include/linux/relay.h
+++ b/include/linux/relay.h
@@ -38,7 +38,7 @@ struct rchan_buf
size_t subbufs_consumed;/* count of sub-buffers consumed */
struct rchan *chan; /* associated channel */
wait_queue_head_t read_wait;/* reader wait queue */
- struct delayed_work wake_readers; /* reader wake-up work struct */
+ struct timer_list timer;/* reader wake-up timer */
struct dentry *dentry; /* channel file dentry */
struct kref kref; /* channel buffer refcount */
struct page **page_array; /* array of current buffer pages */
diff --git a/kernel/relay.c b/kernel/relay.c
index 577f251..6b252be 100644
--- a/kernel/relay.c
+++ b/kernel/relay.c
@@ -310,16 +310,13 @@ static struct rchan_callbacks default_channel_callbacks =
{
/**
* wakeup_readers - wake up readers waiting on a channel
- * @work: work struct that contains the the channel buffer
+ * @data: contains the the channel buffer
*
- * This is the work function used to defer reader waking. The
- * reason waking is deferred is that calling directly from write
- * causes problems if you're writing from say the scheduler.
+ * This is the timer function used to defer reader waking.
*/
-static void wakeup_readers(struct work_struct *work)
+static void wakeup_readers(unsigned long data)
{
- struct rchan_buf *buf =
- container_of(work, struct rchan_buf, wake_readers.work);
+ struct rchan_buf *buf = (struct rchan_buf *)data;
wake_up_interruptible(>read_wait);
}
@@ -337,11 +334,11 @@ static void __relay_reset(struct rchan_buf *buf, unsigned
int init)
if (init) {
init_waitqueue_head(>read_wait);
kref_init(>kref);
- INIT_DELAYED_WORK(>wake_readers, NULL);
- } else {
- cancel_delayed_work(>wake_readers);
- flush_scheduled_work();
- }
+ init_timer(>timer);
+ buf->timer.data = (unsigned long)buf;
+ buf->timer.function = wakeup_readers;
+ } else
+ del_timer_sync(>timer);
buf->subbufs_produced = 0;
buf->subbufs_consumed = 0;
@@ -447,8 +444,7 @@ end:
static void relay_close_buf(struct rchan_buf *buf)
{
buf->finalized = 1;
- cancel_delayed_work(>wake_readers);
- flush_scheduled_work();
+ del_timer_sync(>timer);
kref_put(>kref, relay_remove_buf);
}
@@ -609,9 +605,16 @@ size_t relay_switch_subbuf(struct rchan_buf *buf, size_t
length)
buf->padding[old_subbuf];
smp_mb();
if (waitqueue_active(>read_wait)) {
- PREPARE_DELAYED_WORK(>wake_readers,
-wakeup_readers);
- schedule_delayed_work(>wake_readers, 1);
+ /*
+* Calling wake_up_interruptible() from here
+* will deadlock if we happen to be logging
+* from the scheduler (trying to re-grab
+* rq->lock), so defer it.
+*/
+ if (!timer_pending(>timer)) {
+ buf->timer.expires = jiffies + 1;
+ add_timer(>timer);
+ }
}
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. >> Would be good to check if PLL really can go downto x4,0. Can You >> limit minimal CPU multiplier to 5,0 and check if is stable? If it >> is check 4,5. > > I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which > worked better than `cpufreq -u xxx -d xxx`. > > Lockup after 9 minutes. (Perhaps the longest time so far.) Can You send me Your entire boot log with performance governor set? > Jan Rafał -- Po meczu.kurde...:) >>> http://link.interia.pl/f1a72 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
2007/5/6, Bodo Eggert <[EMAIL PROTECTED]>: Theodore Tso <[EMAIL PROTECTED]> wrote: > But as has already been discussed on this thread, in situations where > the fileserver is under high memory pressure, any filesystem (XFS or > ext4) would still end up allocating blocks out of order, resulting in > fragmentation. Explicit preallocation, as opposed to delayed > allocation, is really the best long-term solution; and in order to do > that, Samba needs to detect this scenario --- which as has been noted, > there appears to be no good reason for the Windows CIFS client (or any > other application)to be doing this, other than perhaps to deliberate > trigger a worst case allocation pattern in ext3 --- and translate it > into a explicit preallocation request. There is an interface to tell the kernel about the way the file will be accessed. IMO this interface should be used to do the preallocation, too. The other question is: How to tell the poor-bill's preallocation from a very clever application that communicates with another application and which is supposed to zero out that exact byte from the data the other application sent. I was tempted to say "just let samba cache these calls", but it would be wrong. You'll need magic in the kernel to DTRT. There are three correct ways of handling these one-zerobyte-writes after EOF: 1) Extend the file like truncate 2) Extend the file like write() (current behaviour) 3) Preallocate these blocks (to be implemented) 4) Write all zeroes (current behaviour for FAT) (2) will cause bad allocations, it's obviously worse than (1). (3) would be better than (1) and (2), but only xfs(?) and ext4 will support this in the near future. (4) should double the write time, but give the best possible read speed. According to [1], the expected read speed is about as high as (1) gives, "playback performance improves to expected levels". If preallocation does not seem to make a big difference, I don't think we should do (4) as a replacement untill the filesystem does support real preallocations. I suggest: 1) Make samba use fadvise(MIGHT_PREALLOCATE) 2) Make the kernel turn these 1-byte-writes-after-EOF into truncates on MIGHT_PREALLOCATE, and possibly turn off MIGHT_PREALLOCATE on other read/writes 3) Make the kernel fadvise(PREALLOCATE, $filesize) on MIGHT_PREALLOCATE + lseek(0), turning off the MIGHT_PREALLOCATE Possibly it might also turn on FADV_SEQUENTIAL. 4) Make the filesystems optionally preallocate the desired area, or ignore fadvise(PREALLOCATE, $filesize) instead. [1] http://softwarecommunity.intel.com/articles/eng/1259.htm -- It is still called paranoia when they really are out to get you. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] So it would be possible, that "Explicit Preallocation" + "Delayed Allocation" + (some other technology) would minimize file-system fragmentation. And further more, massive fragments of large downloads may could be solved by "Explicit Preallocation" too. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "modularized" 2.4.34.4 -> ide-core "unresolved symbols"
On Sat, May 05, 2007 at 09:49:22PM +0200, Zbigniew Baniewski wrote: > Hallo, > > I was trying to make "modularized kernel" (s.c. "Debian way") recently, yes, > I made even kernel.deb package - but at the installation, I'm still getting > an error: "ide-core: unresolved symbols". > > Making a quick search with Google I could see, it did occur to many other > people even long ago. There was even a patch introduced - which, I believe, > is in the 2.4.34.4 "drivers/ide" sub-dir - unfortunately it seems, that the > patch is working no more. > > Perhaps there is another patch available for 2.4.34.4 ? Could you please be a bit more precise : - config - what are the unresolved symbols ? - link to the patch you are talking about ? Thanks, Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ I have the following message after kernel compilation: --- ... WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0x11e) and 'try_name' ... ... WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x20) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x24) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x28) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x2c) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x30) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x34) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x38) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x3c) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x40) WARNING: drivers/dma/async_tx.o - Section mismatch: reference to .init.data: from .data after 'channel_table' (at offset 0x44) -- Dan Kruchinin. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Broken process startup times after suspend (regression)
john stultz writes: Indeed. The monotonic clock's behavior around suspend and resume is poorly defined. When we increased it, folks didn't like the fact that uptime would increase while a system was suspended. The uptime really does need to increase during suspend. Otherwise, things get really weird with devices like the OLPC XO which will be sleeping between keystrokes. You could run the device for hours, yet get an uptime of only a few minutes. Suspended time should get counted as stolen time, same as when a hypervisor takes away time. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: "modularized" 2.4.34.4 -> ide-core "unresolved symbols"
Zbigniew Baniewski wrote: Hallo, I was trying to make "modularized kernel" (s.c. "Debian way") recently, yes, I made even kernel.deb package - but at the installation, I'm still getting an error: "ide-core: unresolved symbols". Making a quick search with Google I could see, it did occur to many other people even long ago. There was even a patch introduced - which, I believe, is in the 2.4.34.4 "drivers/ide" sub-dir - unfortunately it seems, that the patch is working no more. Perhaps there is another patch available for 2.4.34.4 ? I don't think drivers/ide ever really played well when built modular, at least not in 2.4, quite possibly in 2.6 as well. Things like DMA not getting turned on automatically when the low-level driver was a module, etc. Likely why Red Hat/Fedora never built it modular when they did everything else.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [POWERPC] 8xx: mpc885ads pcmcia support
On Sun, May 06, 2007 at 03:04:14AM +0200, Segher Boessenkool wrote:
> > + [EMAIL PROTECTED] {
>
> > + #interrupt-cells = <1>;
>
> > + interrupt-parent = ;
> > + interrupts = ;
> > + };
>
> Since this node's children's interrupt representation
> is different from the node's parent's, you need an
> interrupt-map in here. You also forgot "#address-cells"
> and I think you need "ranges" too?
And we should use a reference, instead of an implicit phandle for the
interrupt-parent.
--
David Gibson| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] [POWERPC] 8xx: mpc885ads pcmcia support
+ [EMAIL PROTECTED] {
+ #interrupt-cells = <1>;
+ interrupt-parent = ;
+ interrupts = ;
+ };
Since this node's children's interrupt representation
is different from the node's parent's, you need an
interrupt-map in here. You also forgot "#address-cells"
and I think you need "ranges" too?
Segher
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
Andrew Morton writes: "Cabot, Mason B" <[EMAIL PROTECTED]> wrote: I've been testing the NAS performance of ext3/Openfiler 2.2 against NTFS/WinXP and have found that NTFS significantly outperforms ext3 for video workloads. The Windows CIFS client will attempt a poor-man's pre-allocation of the file on the server by sending 1-byte writes at 128K-byte strides, breaking block allocation on ext3 and leading to fragmentation and poor performance. This will happen for many applications (including iTunes) as the CIFS client issues these pre-allocates under the application layer. Oh my gawd, what a stupid hack. Now we know what the MS interoperability lab has been working on. Stupid or not, this is their protocol. The cifs filesystem driver needs a patch to do this. Probably that'll help get better performance when Linux is writing to a Windows server. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-ck1
Hello Con, Con Kolivas wrote: This patchset is designed to improve system responsiveness and interactivity. It is configurable to any workload but the default -ck patch is aimed at the desktop and -cks is available with more emphasis on serverspace. I have used SD for the first time with this patchset, and I have to say, my experience has been very positive over the past four days. My desktop has been extraordinarily smooth during interactive tasks with no audio drop-outs. Best of all, the desktop has been completely responsive despite CPU hogging tasks. I do not need to nice X either. This looks like a perfect scheduler. Swap prefetch continues to work its miracles as I've been doing a lot of work lately with a 33"x44" poster that contains many high-resolutions images, while using gimp at the same time! Thanks so much for all your incredible work! 乾杯 best, Ryan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/2] [POWERPC] 8xx: fix whitespace and indentation
Rolling forward PCMCIA driver, it was discovered that the indentation
in existing one is very odd. This patch is just result of Lindent run ontop
of culprit files.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
---
drivers/pcmcia/m8xx_pcmcia.c | 548 +-
1 files changed, 278 insertions(+), 270 deletions(-)
diff --git a/drivers/pcmcia/m8xx_pcmcia.c b/drivers/pcmcia/m8xx_pcmcia.c
index 40f6e20..79e14ab 100644
--- a/drivers/pcmcia/m8xx_pcmcia.c
+++ b/drivers/pcmcia/m8xx_pcmcia.c
@@ -113,7 +113,7 @@ MODULE_LICENSE("Dual MPL/GPL");
#define CONFIG_PCMCIA_SLOT_B
#endif
-#endif /* !defined(CONFIG_PCMCIA_SLOT_A) && !defined(CONFIG_PCMCIA_SLOT_B) */
+#endif /* !defined(CONFIG_PCMCIA_SLOT_A) &&
!defined(CONFIG_PCMCIA_SLOT_B) */
#if defined(CONFIG_PCMCIA_SLOT_A) && defined(CONFIG_PCMCIA_SLOT_B)
@@ -146,9 +146,9 @@ MODULE_LICENSE("Dual MPL/GPL");
/* - */
-#define PCMCIA_MEM_WIN_BASE 0xe000 /* base address for memory window 0 */
-#define PCMCIA_MEM_WIN_SIZE 0x0400 /* each memory window is 64 MByte */
-#define PCMCIA_IO_WIN_BASE _IO_BASE /* base address for io window 0 */
+#define PCMCIA_MEM_WIN_BASE 0xe000 /* base address for memory window 0 */
+#define PCMCIA_MEM_WIN_SIZE 0x0400 /* each memory window is 64 MByte */
+#define PCMCIA_IO_WIN_BASE _IO_BASE /* base address for io window 0 */
/* - */
static int pcmcia_schlvl;
@@ -169,8 +169,8 @@ static u32 *m8xx_pgcrx[2];
*/
struct pcmcia_win {
- u32 br;
- u32 or;
+ u32 br;
+ u32 or;
};
/*
@@ -214,7 +214,7 @@ struct pcmcia_win {
/* we keep one lookup table per socket to check flags */
-#define PCMCIA_EVENTS_MAX 5 /* 4 max at a time + termination */
+#define PCMCIA_EVENTS_MAX 5/* 4 max at a time + termination */
struct event_table {
u32 regbit;
@@ -224,8 +224,8 @@ struct event_table {
static const char driver_name[] = "m8xx-pcmcia";
struct socket_info {
- void(*handler)(void *info, u32 events);
- void*info;
+ void (*handler) (void *info, u32 events);
+ void *info;
u32 slot;
pcmconf8xx_t *pcmcia;
@@ -234,7 +234,7 @@ struct socket_info {
socket_state_t state;
struct pccard_mem_map mem_win[PCMCIA_MEM_WIN_NO];
- struct pccard_io_map io_win[PCMCIA_IO_WIN_NO];
+ struct pccard_io_map io_win[PCMCIA_IO_WIN_NO];
struct event_table events[PCMCIA_EVENTS_MAX];
struct pcmcia_socket socket;
};
@@ -248,8 +248,7 @@ static struct socket_info socket[PCMCIA_SOCKETS_NO];
#define M8XX_SIZES_NO 32
-static const u32 m8xx_size_to_gray[M8XX_SIZES_NO] =
-{
+static const u32 m8xx_size_to_gray[M8XX_SIZES_NO] = {
0x0001, 0x0002, 0x0008, 0x0004,
0x0080, 0x0040, 0x0010, 0x0020,
0x8000, 0x4000, 0x1000, 0x2000,
@@ -265,7 +264,7 @@ static const u32 m8xx_size_to_gray[M8XX_SIZES_NO] =
static irqreturn_t m8xx_interrupt(int irq, void *dev);
-#define PCMCIA_BMT_LIMIT (15*4) /* Bus Monitor Timeout value */
+#define PCMCIA_BMT_LIMIT (15*4)/* Bus Monitor Timeout value */
/* - */
/* board specific stuff: */
@@ -289,8 +288,9 @@ static int voltage_set(int slot, int vcc, int vpp)
{
u32 reg = 0;
- switch(vcc) {
- case 0: break;
+ switch (vcc) {
+ case 0:
+ break;
case 33:
reg |= BCSR1_PCVCTL4;
break;
@@ -301,11 +301,12 @@ static int voltage_set(int slot, int vcc, int vpp)
return 1;
}
- switch(vpp) {
- case 0: break;
+ switch (vpp) {
+ case 0:
+ break;
case 33:
case 50:
- if(vcc == vpp)
+ if (vcc == vpp)
reg |= BCSR1_PCVCTL6;
else
return 1;
@@ -316,25 +317,29 @@ static int voltage_set(int slot, int vcc, int vpp)
return 1;
}
- if(!((vcc == 50) || (vcc == 0)))
+ if (!((vcc == 50) || (vcc == 0)))
return 1;
/* first, turn off all power */
- out_be32(((u32 *)RPX_CSR_ADDR), in_be32(((u32 *)RPX_CSR_ADDR)) &
~(BCSR1_PCVCTL4 | BCSR1_PCVCTL5 | BCSR1_PCVCTL6 | BCSR1_PCVCTL7));
+ out_be32(((u32 *) RPX_CSR_ADDR),
+in_be32(((u32 *) RPX_CSR_ADDR)) & ~(BCSR1_PCVCTL4 |
+BCSR1_PCVCTL5 |
+BCSR1_PCVCTL6 |
+BCSR1_PCVCTL7));
/* enable new powersettings */
- out_be32(((u32
[PATCH 0/2] of_device 8xx PCMCIA support && cleanup
Current series features the reworked 8xx of_device PCMCIA patch based on feedback from Andrew + indentation & whitespace fixes in drivers/pcmcia/m8xx_pcmcia.c Andrew, Please disregard previous patch since it contains a typo. Indentation patch is not strictly necessary but is useful too, imho. -- -Vitaly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/2] [POWERPC] 8xx: mpc885ads pcmcia support
Adds support for PowerQuicc on-chip PCMCIA. The driver is implemented as
of_device, so only arch/powerpc stuff is capable to use it, which now
implies only mpc885ads reference board.
To cope with the code that should be hooked inside driver, but is really
board specific (like set_voltage), global structure mpc8xx_pcmcia_ops
holds necessary function pointers that are filled in the BSP code.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc885ads.dts | 12 +
arch/powerpc/platforms/8xx/m8xx_setup.c |5
arch/powerpc/platforms/8xx/mpc885ads.h |8 +
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 76 ++
arch/powerpc/sysdev/fsl_soc.c| 13 +
arch/powerpc/sysdev/mpc8xx_pic.h |2
drivers/pcmcia/Kconfig |1
drivers/pcmcia/m8xx_pcmcia.c | 351 --
include/asm-powerpc/mpc8xx.h |4
include/linux/fsl_devices.h |5
10 files changed, 292 insertions(+), 185 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 110bf61..0f3e8cf 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -112,6 +112,18 @@
compatible = "CPM";
};
+ [EMAIL PROTECTED] {
+ linux,phandle = <0080>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ compatible = "fsl,pq-pcmcia";
+ device_type = "pcmcia";
+ reg = <80 80>;
+ clock-frequency = <2faf080>;
+ interrupt-parent = ;
+ interrupts = ;
+ };
+
[EMAIL PROTECTED] {
linux,phandle = ;
#address-cells = <1>;
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
b/arch/powerpc/platforms/8xx/m8xx_setup.c
index 0901dba..f169355 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,10 @@
#include "sysdev/mpc8xx_pic.h"
+#ifdef CONFIG_PCMCIA_M8XX
+struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
+#endif
+
void m8xx_calibrate_decr(void);
extern void m8xx_wdt_handler_install(bd_t *bp);
extern int cpm_pic_init(void);
diff --git a/arch/powerpc/platforms/8xx/mpc885ads.h
b/arch/powerpc/platforms/8xx/mpc885ads.h
index 7c31aec..932b59a 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads.h
+++ b/arch/powerpc/platforms/8xx/mpc885ads.h
@@ -91,5 +91,13 @@
#define SICR_ENET_MASK ((uint)0x00ff)
#define SICR_ENET_CLKRT((uint)0x002c)
+/*
+ * Some internal interrupt registers use an 8-bit mask for the interrupt
+ * level instead of a number.
+ */
+static inline uint mk_int_int_mask(uint mask) {
+ return (1 << (7 - (mask/2)));
+}
+
#endif /* __ASM_MPC885ADS_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index a57b577..4e76e1c 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
@@ -51,6 +52,11 @@ static void init_smc1_uart_ioports(struct
fs_uart_platform_info* fpi);
static void init_smc2_uart_ioports(struct fs_uart_platform_info* fpi);
static void init_scc3_ioports(struct fs_platform_info* ptr);
+#ifdef CONFIG_PCMCIA_M8XX
+static void pcmcia_hw_setup(int slot, int enable);
+static int pcmcia_set_voltage(int slot, int vcc, int vpp);
+#endif
+
void __init mpc885ads_board_setup(void)
{
cpm8xx_t *cp;
@@ -115,6 +121,12 @@ void __init mpc885ads_board_setup(void)
immr_unmap(io_port);
#endif
+
+#ifdef CONFIG_PCMCIA_M8XX
+ /*Set up board specific hook-ups*/
+ m8xx_pcmcia_ops.hw_ctrl = pcmcia_hw_setup;
+ m8xx_pcmcia_ops.voltage_set = pcmcia_set_voltage;
+#endif
}
@@ -322,6 +334,70 @@ void init_smc_ioports(struct fs_uart_platform_info *data)
}
}
+#ifdef CONFIG_PCMCIA_M8XX
+static void pcmcia_hw_setup(int slot, int enable)
+{
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+ if (enable)
+ clrbits32(bcsr_io, BCSR1_PCCEN);
+ else
+ setbits32(bcsr_io, BCSR1_PCCEN);
+
+ iounmap(bcsr_io);
+}
+
+static int pcmcia_set_voltage(int slot, int vcc, int vpp)
+{
+ u32 reg = 0;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ switch(vcc) {
+ case 0:
+ break;
+ case 33:
+ reg |= BCSR1_PCCVCC0;
+ break;
+ case 50:
+ reg |=
Re: [PROBLEM] 2.6.21-git oops
--- Michal Piotrowski <[EMAIL PROTECTED]> wrote: > Hi Srihari, Hello Michal, [...] > > It turns out the system is no go with 4 GB of RAM (4 * 1 GB modules): > system > > instability & SATA controller doesn't detect the drives (as I reported to > > linux-ide: > > http://www.mail-archive.com/[EMAIL PROTECTED]/msg06174.html). > > > > With only 2 GB of RAM (with either pairs), system is very stable > (surviving > > many parallel kernel compiles for over 3 times longer than that of 4 GB), > and > > it detects & works fine with the SATA drives also. > > > > Any advice on getting all of 4 GB to work reliably with SATA also? [...] > This looks like a bad RAM problem too me. Check the RAM memory > http://www.memtest.org/ I disagree it to be a bad RAM problem (please read on). But agree undeniably to run the memtest a little later on (FWIW, Linux & kernel compile tests are indeed my test case to prove the stability of the machine). (I can assure no component is overclocked; I prefer stability over performance with instability :-). Power & ventilation seem quite adequate, but nonetheless I haven't eliminated yet - for stability, not for SATA detection.) Assuming it's indeed a bad RAM (which I don't sincerely/logically believe), may I ask then how would you explain: 1. SATA drives aren't even detected with 4 GB of RAM 2. Or the system working reliably with _both_ pairs of memory modules individually, ie when limited to 2 GB only, when kernel compile torture test succeeds for many hours with no problems (repeated the test case for a few times also to prove the memory modules are themselves in very good condition), while crashing in a few minutes reliably/repeatably under 4 GB Logically speaking, if I were to hypothesize what the problem might be: 1. mother board is no go with 4 GB of RAM (for both system stability & SATA drives detection) - Escalated it to Asus to confirm. 2. (my dearest) Linux kernel doesn't configure/program things in this board to work reliably. 3. Sadly I don't know yet if there is a boot parameter for Linux or a configuration setting in BIOS to make things work both reliably & completely. (I vaguely remember in a thread a few weeks/months ago in LKML on AMD64/Nvidia chipset combo, using SW IOMMU lead to improved stability on machines with large amount of RAM?? Or was that limiting the RAM to under 4 GB that helped?? I could be completely wrong here.) > (Removed from the list of known regressions > http://kernelnewbies.org/known_regressions) (Initially I believed it to be a regression wrongly, but it was not. Since then I've eliminated a few variables in my tests. Sorry for my misunderstanding.) Thank you for your help so far. Hari Send instant messages to your online friends http://au.messenger.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: [PATCH 4/10] ARM: OMAP: gpio init section cleanups
* Russell King <[EMAIL PROTECTED]> [070505 03:29]:
> On Sat, May 05, 2007 at 11:04:26AM +0100, Russell King wrote:
> > On Mon, Apr 09, 2007 at 05:01:06PM -0400, Tony Lindgren wrote:
> > > From: David Brownell <[EMAIL PROTECTED]>
> > >
> > > Minor GPIO cleanups: remove needless #include, and omap_gpio_init()
> > > should be __init, as well as all the board init code calling it.
> > >
> > > Signed-off-by: David Brownell <[EMAIL PROTECTED]>
> > > Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
> >
> > I've applied 8 patches from this series by cherry picking it from your
> > git tree, minus this patch which git wouldn't apply due to fuzz in
> > arch/arm/plat-omap/gpio.c.
I wonder what causes the fuzz? Do you have your git tree somewhere
so I can update this patch against it?
> Incidentally, when doing a build after these patches, I'm seeing:
>
> arch/arm/plat-omap/dma.c: In function `omap_get_dma_src_pos':
> arch/arm/plat-omap/dma.c:750: warning: 'offset' might be used uninitialized
> in this function
> arch/arm/plat-omap/dma.c: In function `omap_get_dma_dst_pos':
> arch/arm/plat-omap/dma.c:772: warning: 'offset' might be used uninitialized
> in this function
>
> These look like they're valid warnings to me.
Thanks for letting me know, here's a patch to fix the wardning.
Regards,
Tony
Subject: ARM: OMAP: Fix warning in dma.c
Fix warning: 'offset' might be uninitialized
Signed-off-by: Tony Lindgren <[EMAIL PROTECTED]>
--- a/arch/arm/plat-omap/dma.c
+++ b/arch/arm/plat-omap/dma.c
@@ -747,7 +747,7 @@ int omap_set_dma_callback(int lch,
*/
dma_addr_t omap_get_dma_src_pos(int lch)
{
- dma_addr_t offset;
+ dma_addr_t offset = 0;
if (cpu_class_is_omap1())
offset = (dma_addr_t) (OMAP1_DMA_CSSA_L_REG(lch) |
[PATCH 1/1] sunrpc: Use path_component_lookup
use path_component_lookup instead of open-coding the necessary
functionality.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
net/sunrpc/rpc_pipe.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 9b9ea50..c93a454 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -451,21 +451,19 @@ void rpc_put_mount(void)
static int
rpc_lookup_parent(char *path, struct nameidata *nd)
{
+ struct vfsmount *mnt;
+
if (path[0] == '\0')
return -ENOENT;
- nd->mnt = rpc_get_mount();
- if (IS_ERR(nd->mnt)) {
+
+ mnt = rpc_get_mount();
+ if (IS_ERR(mnt)) {
printk(KERN_WARNING "%s: %s failed to mount "
"pseudofilesystem \n", __FILE__, __FUNCTION__);
- return PTR_ERR(nd->mnt);
+ return PTR_ERR(mnt);
}
- mntget(nd->mnt);
- nd->dentry = dget(rpc_mount->mnt_root);
- nd->last_type = LAST_ROOT;
- nd->flags = LOOKUP_PARENT;
- nd->depth = 0;
- if (path_walk(path, nd)) {
+ if (path_component_lookup(mnt->mnt_root, mnt, path, LOOKUP_PARENT, nd))
{
printk(KERN_WARNING "%s: %s failed to find path %s\n",
__FILE__, __FUNCTION__, path);
rpc_put_mount();
--
1.5.2.rc1.20.g86b9
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [POWERPC] 8xx: mpc885ads pcmcia support
Adds support for PowerQuicc on-chip PCMCIA. The driver is implemented as
of_device, so only arch/powerpc stuff is capable to use it, which now
implies only mpc885ads reference board.
To cope with the code that should be hooked inside driver, but is really
board specific (like set_voltage), global structure mpc8xx_pcmcia_ops
holds necessary function pointers that are filled in the BSP code.
Signed-off-by: Vitaly Bordug <[EMAIL PROTECTED]>
Acked-by: Arnd Bergmann <[EMAIL PROTECTED]>
---
arch/powerpc/boot/dts/mpc885ads.dts | 12 +
arch/powerpc/platforms/8xx/m8xx_setup.c |5
arch/powerpc/platforms/8xx/mpc885ads.h |8 +
arch/powerpc/platforms/8xx/mpc885ads_setup.c | 76 ++
arch/powerpc/sysdev/fsl_soc.c| 13 +
arch/powerpc/sysdev/mpc8xx_pic.h |2
drivers/pcmcia/Kconfig |1
drivers/pcmcia/m8xx_pcmcia.c | 352 --
include/asm-powerpc/mpc8xx.h |4
include/linux/fsl_devices.h |5
10 files changed, 292 insertions(+), 186 deletions(-)
diff --git a/arch/powerpc/boot/dts/mpc885ads.dts
b/arch/powerpc/boot/dts/mpc885ads.dts
index 110bf61..0f3e8cf 100644
--- a/arch/powerpc/boot/dts/mpc885ads.dts
+++ b/arch/powerpc/boot/dts/mpc885ads.dts
@@ -112,6 +112,18 @@
compatible = "CPM";
};
+ [EMAIL PROTECTED] {
+ linux,phandle = <0080>;
+ #interrupt-cells = <1>;
+ #size-cells = <2>;
+ compatible = "fsl,pq-pcmcia";
+ device_type = "pcmcia";
+ reg = <80 80>;
+ clock-frequency = <2faf080>;
+ interrupt-parent = ;
+ interrupts = ;
+ };
+
[EMAIL PROTECTED] {
linux,phandle = ;
#address-cells = <1>;
diff --git a/arch/powerpc/platforms/8xx/m8xx_setup.c
b/arch/powerpc/platforms/8xx/m8xx_setup.c
index 0901dba..f169355 100644
--- a/arch/powerpc/platforms/8xx/m8xx_setup.c
+++ b/arch/powerpc/platforms/8xx/m8xx_setup.c
@@ -32,6 +32,7 @@
#include
#include
#include
+#include
#include
#include
@@ -49,6 +50,10 @@
#include "sysdev/mpc8xx_pic.h"
+#ifdef CONFIG_PCMCIA_M8XX
+struct mpc8xx_pcmcia_ops m8xx_pcmcia_ops;
+#endif
+
void m8xx_calibrate_decr(void);
extern void m8xx_wdt_handler_install(bd_t *bp);
extern int cpm_pic_init(void);
diff --git a/arch/powerpc/platforms/8xx/mpc885ads.h
b/arch/powerpc/platforms/8xx/mpc885ads.h
index 7c31aec..932b59a 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads.h
+++ b/arch/powerpc/platforms/8xx/mpc885ads.h
@@ -91,5 +91,13 @@
#define SICR_ENET_MASK ((uint)0x00ff)
#define SICR_ENET_CLKRT((uint)0x002c)
+/*
+ * Some internal interrupt registers use an 8-bit mask for the interrupt
+ * level instead of a number.
+ */
+static inline uint mk_int_int_mask(uint mask) {
+ return (1 << (7 - (mask/2)));
+}
+
#endif /* __ASM_MPC885ADS_H__ */
#endif /* __KERNEL__ */
diff --git a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
index a57b577..4e76e1c 100644
--- a/arch/powerpc/platforms/8xx/mpc885ads_setup.c
+++ b/arch/powerpc/platforms/8xx/mpc885ads_setup.c
@@ -22,6 +22,7 @@
#include
#include
+#include
#include
#include
@@ -51,6 +52,11 @@ static void init_smc1_uart_ioports(struct
fs_uart_platform_info* fpi);
static void init_smc2_uart_ioports(struct fs_uart_platform_info* fpi);
static void init_scc3_ioports(struct fs_platform_info* ptr);
+#ifdef CONFIG_PCMCIA_M8XX
+static void pcmcia_hw_setup(int slot, int enable);
+static int pcmcia_set_voltage(int slot, int vcc, int vpp);
+#endif
+
void __init mpc885ads_board_setup(void)
{
cpm8xx_t *cp;
@@ -115,6 +121,12 @@ void __init mpc885ads_board_setup(void)
immr_unmap(io_port);
#endif
+
+#ifdef CONFIG_PCMCIA_M8XX
+ /*Set up board specific hook-ups*/
+ m8xx_pcmcia_ops.hw_ctrl = pcmcia_hw_setup;
+ m8xx_pcmcia_ops.voltage_set = pcmcia_set_voltage;
+#endif
}
@@ -322,6 +334,70 @@ void init_smc_ioports(struct fs_uart_platform_info *data)
}
}
+#ifdef CONFIG_PCMCIA_M8XX
+static void pcmcia_hw_setup(int slot, int enable)
+{
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+ if (enable)
+ clrbits32(bcsr_io, BCSR1_PCCEN);
+ else
+ setbits32(bcsr_io, BCSR1_PCCEN);
+
+ iounmap(bcsr_io);
+}
+
+static int pcmcia_set_voltage(int slot, int vcc, int vpp)
+{
+ u32 reg = 0;
+ unsigned *bcsr_io;
+
+ bcsr_io = ioremap(BCSR1, sizeof(unsigned long));
+
+ switch(vcc) {
+ case 0:
+ break;
+ case 33:
+ reg |= BCSR1_PCCVCC0;
+ break;
+ case 50:
+ reg |=
Re: [PATCH] synclink_gt add compat_ioctl
On Saturday 05 May 2007, Paul Fulghum wrote:
> That declaration will need to be duplicated in each driver that
> uses it (4 drivers in my case). In that sense (a structure declaration
> used by multiple code modules) it does seem like an interface definition.
>
> If that is what is needed, I will do it.
Now that you mention the duplication, this sounds wrong as well. The easiest
solution is probably to just put the definition of your data structure
inside of #ifdef CONFIG_COMPAT in the header file.
Or you could go really fancy and write a new file that does the synclink
compat_ioctl handling in a generic way end in the end just calls the
fops->{unlocked_,}ioctl() function.
Which reminds me that I have been meaning to do a patch that creates
a new generic_compat_ioctl() [1] function for some time, and convert
drivers to this if their handlers are all compatible.
Arnd <><
[1]
/*
* Can be used as the ->compat_ioctl method in the file_operations
* for any driver that does not need any conversion in its ioctl
* handler
*/
long generic_file_compat_ioctl(struct file *file, unsigned int cmd,
unsigned long arg)
{
int ret;
arg = (unsigned long)compat_ptr(arg);
if (file->f_ops->unlocked_ioctl)
ret = file->f_ops->unlocked_ioctl(file, cmd, arg);
else {
lock_kernel();
ret = file->f_ops->ioctl(file, cmd, arg);
unlock_kernel();
} else
ret = -ENOIOCTLCMD;
return ret;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/4] sunrpc: Use path_component_lookup
On Sat, 2007-05-05 at 19:09 -0400, Josef 'Jeff' Sipek wrote:
> use path_component_lookup instead of open-coding the necessary
> functionality.
>
> Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
> ---
> net/sunrpc/rpc_pipe.c | 16 +++-
> 1 files changed, 7 insertions(+), 9 deletions(-)
>
> diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
> index 9b9ea50..b67cb54 100644
> --- a/net/sunrpc/rpc_pipe.c
> +++ b/net/sunrpc/rpc_pipe.c
> @@ -451,21 +451,19 @@ void rpc_put_mount(void)
> static int
> rpc_lookup_parent(char *path, struct nameidata *nd)
> {
> + struct vfsmount *mnt;
> +
> if (path[0] == '\0')
> return -ENOENT;
> - nd->mnt = rpc_get_mount();
> - if (IS_ERR(nd->mnt)) {
> +
> + mnt = rpc_get_mount();
> + if (IS_ERR(mnt)) {
> printk(KERN_WARNING "%s: %s failed to mount "
> "pseudofilesystem \n", __FILE__, __FUNCTION__);
> - return PTR_ERR(nd->mnt);
> + return PTR_ERR(mnt);
> }
> - mntget(nd->mnt);
> - nd->dentry = dget(rpc_mount->mnt_root);
> - nd->last_type = LAST_ROOT;
> - nd->flags = LOOKUP_PARENT;
> - nd->depth = 0;
>
> - if (path_walk(path, nd)) {
> + if (path_component_lookup(rpc_mount->mnt_root, mnt, path,
> LOOKUP_PARENT, nd)) {
> printk(KERN_WARNING "%s: %s failed to find path %s\n",
> __FILE__, __FUNCTION__, path);
> rpc_put_mount();
Just one minor nit: could you make that
if (path_component_lookup(mnt->mnt_root, mnt, path, LOOKUP_PARENT, nd))
{
instead. It really is a bug even for the existing code to be referencing
rpc_mount directly.
Cheers
Trond
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-mm1: many processes end up in D state
On Sat, 05 May 2007 17:30:51 +0200, Tejun Heo wrote: > Mikael Pettersson wrote: > >> I.e. no freezing of ports... > > > > Your patch to delete the 'return 1;' on error is correct, > > and makes the code match exactly the behaviour of previous > > versions of sata_promise, except for the additional error > > decoding. > > > > ahci and sata_sil24 do the return in this situation. I don't > > yet understand why they can get away with it while sata_promise > > cannot, but for now the return should be removed. > > That's because sata_sil24 and ahci call either ata_port_abort() or > ata_port_freeze() prior to finishing error_intr routine. Both functions > abort all in-flight command and schedule EH. Ah. Thanks, that clarifies things. Jiri: please test the patch below instead. That is, revert to the original code _with_ the 'return 1;', and then add this patch to it. It should have pretty much the same effect as removing the 'return 1;', however calling ata_port_abort() is more in line with libata's new-style error handling. /Mikael --- linux-2.6.21-mm1/drivers/ata/sata_promise.c.~1~ 2007-05-05 22:24:41.0 +0200 +++ linux-2.6.21-mm1/drivers/ata/sata_promise.c 2007-05-05 22:25:21.0 +0200 @@ -653,6 +653,8 @@ static void pdc_error_intr(struct ata_po qc->err_mask |= ac_err_mask; pdc_reset_port(ap); + + ata_port_abort(ap); } static inline unsigned int pdc_host_intr( struct ata_port *ap, - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix nfsroot build
On Sat, 2007-05-05 at 22:05 +0100, Ralf Baechle wrote:
> CC fs/nfs/nfsroot.o
> fs/nfs/nfsroot.c:131: error: tokens causes a section type conflict
> make[2]: *** [fs/nfs/nfsroot.o] Error 1
>
> This is due to mixing const and non-const content in the same section
> which halfway recent gccs absolutely hate. Fixed by dropping the const.
>
> Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Acked-by: Trond Myklebust <[EMAIL PROTECTED]>
>
> diff --git a/include/linux/parser.h b/include/linux/parser.h
> index 86676f6..26b2bdf 100644
> --- a/include/linux/parser.h
> +++ b/include/linux/parser.h
> @@ -14,7 +14,7 @@ struct match_token {
> const char *pattern;
> };
>
> -typedef const struct match_token match_table_t[];
> +typedef struct match_token match_table_t[];
>
> /* Maximum number of arguments that match_token will find in a pattern */
> enum {MAX_OPT_ARGS = 3};
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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.21-git oops
Hi Srihari, On 06/05/07, Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote: [Sorry to reply to my own email, but I had some good development on this problem] --- Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote: > Here's the first one (there a couple following this; > the complete dmesg is at the bottom of this email): It turns out the system is no go with 4 GB of RAM (4 * 1 GB modules): system instability & SATA controller doesn't detect the drives (as I reported to linux-ide: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06174.html). With only 2 GB of RAM (with either pairs), system is very stable (surviving many parallel kernel compiles for over 3 times longer than that of 4 GB), and it detects & works fine with the SATA drives also. Any advice on getting all of 4 GB to work reliably with SATA also? Thanks PS: Here's a dmesg of the all stably working 2 GB system, & the oopsy one with 4 GB. This looks like a bad RAM problem too me. Check the RAM memory http://www.memtest.org/ (Removed from the list of known regressions http://kernelnewbies.org/known_regressions) Regards, Michal -- Michal K. K. Piotrowski Kernel Monkeys (http://kernel.wikidot.com/start) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] [POWERPC] 8xx: mpc885ads pcmcia support
On Fri, 4 May 2007 12:35:43 -0700 Andrew Morton wrote: > On Fri, 04 May 2007 03:57:51 +0400 > Vitaly Bordug <[EMAIL PROTECTED]> wrote: > > > > > Adds support for PowerQuicc on-chip PCMCIA. The driver is > > implemented as of_device, so only arch/powerpc stuff is capable to > > use it, which now implies only mpc885ads reference board. > > > > To cope with the code that should be hooked inside driver, but is > > really board specific (like set_voltage), global structure > > mpc8xx_pcmcia_ops holds necessary function pointers that are filled > > in the BSP code. > > > > argh. > > akpm:/home/akpm> grep '^.*' x | wc -l > 72 > > please, Linux uses hard-tabs, not > spacespacespacespacespacespacespacespace everywhere. > Whoops. That must've survived being copypasted from the original m8xx_pcmcia.c. That reminds me to do Lindent on the affected sources but that is subject for another patch. Sorry for the hassle. Apparently all the issues were correct, and I'll follow-up with the reworked patch. Thanks for looking at it. -- Sincerely, Vitaly - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-git oops
[Sorry to reply to my own email, but I had some good development on this problem] --- Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote: > Here's the first one (there a couple following this; > the complete dmesg is at the bottom of this email): It turns out the system is no go with 4 GB of RAM (4 * 1 GB modules): system instability & SATA controller doesn't detect the drives (as I reported to linux-ide: http://www.mail-archive.com/[EMAIL PROTECTED]/msg06174.html). With only 2 GB of RAM (with either pairs), system is very stable (surviving many parallel kernel compiles for over 3 times longer than that of 4 GB), and it detects & works fine with the SATA drives also. Any advice on getting all of 4 GB to work reliably with SATA also? Thanks PS: Here's a dmesg of the all stably working 2 GB system, & the oopsy one with 4 GB. Send instant messages to your online friends http://au.messenger.yahoo.com dmesg-2.6.21.1-2gigs Description: 569209996-dmesg-2.6.21.1-2gigs oops2-mm-2.6.21.1-libata-4gigs Description: 2887524220-oops2-mm-2.6.21.1-libata-4gigs
Re: 2.6.21-mm1
On 05/05/07 09:49, Andrew Morton wrote: ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ WARNING: init/built-in.o - Section mismatch: reference to .init.text: from .text between 'rest_init' (at offset 0x9) and 'run_init_process' WARNING: arch/i386/kernel/built-in.o - Section mismatch: reference to .init.text: from .data between 'thermal_throttle_cpu_notifier' (at offset 0x21cc) and 'mce_work' WARNING: kernel/built-in.o - Section mismatch: reference to .init.text: from .text between 'kthreadd' (at offset 0x181d8) and 'init_waitqueue_head' -- Simon Arlott config.bz2 Description: application/bzip
[PATCH 1/4] fs: Introduce path_component_lookup
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/namei.c| 26 ++
include/linux/namei.h |2 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 3449e0a..b547af0 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1175,6 +1175,31 @@ int fastcall path_lookup(const char *name, unsigned int
flags,
return do_path_lookup(AT_FDCWD, name, flags, nd);
}
+int path_component_lookup(struct dentry *dentry, struct vfsmount *mnt,
+ const char *name, unsigned int flags,
+ struct nameidata *nd)
+{
+ int retval;
+
+ /* same as do_path_lookup */
+ nd->last_type = LAST_ROOT;
+ nd->flags = flags;
+ nd->depth = 0;
+
+ nd->mnt = mntget(mnt);
+ nd->dentry = dget(dentry);
+
+ retval = path_walk(name, nd);
+ if (likely(retval == 0)) {
+ if (unlikely(!audit_dummy_context() && nd && nd->dentry &&
+ nd->dentry->d_inode))
+ audit_inode(name, nd->dentry->d_inode);
+ }
+
+ return retval;
+
+}
+
static int __path_lookup_intent_open(int dfd, const char *name,
unsigned int lookup_flags, struct nameidata *nd,
int open_flags, int create_mode)
@@ -2799,6 +2824,7 @@ EXPORT_SYMBOL(__page_symlink);
EXPORT_SYMBOL(page_symlink);
EXPORT_SYMBOL(page_symlink_inode_operations);
EXPORT_SYMBOL(path_lookup);
+EXPORT_SYMBOL(path_component_lookup);
EXPORT_SYMBOL(path_release);
EXPORT_SYMBOL(path_walk);
EXPORT_SYMBOL(permission);
diff --git a/include/linux/namei.h b/include/linux/namei.h
index 0ab27ba..2247397 100644
--- a/include/linux/namei.h
+++ b/include/linux/namei.h
@@ -70,6 +70,8 @@ extern int FASTCALL(__user_walk_fd(int dfd, const char __user
*, unsigned, struc
#define user_path_walk_link(name,nd) \
__user_walk_fd(AT_FDCWD, name, 0, nd)
extern int FASTCALL(path_lookup(const char *, unsigned, struct nameidata *));
+extern int path_component_lookup(struct dentry *, struct vfsmount *,
+const char *, unsigned int, struct nameidata
*);
extern int FASTCALL(path_walk(const char *, struct nameidata *));
extern int FASTCALL(link_path_walk(const char *, struct nameidata *));
extern void path_release(struct nameidata *);
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 3/4] nfsctl: Use path_component_lookup
use path_component_lookup instead of open-coding the necessary
functionality.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/nfsctl.c | 15 +--
1 files changed, 5 insertions(+), 10 deletions(-)
diff --git a/fs/nfsctl.c b/fs/nfsctl.c
index c043136..2035dc7 100644
--- a/fs/nfsctl.c
+++ b/fs/nfsctl.c
@@ -23,19 +23,14 @@
static struct file *do_open(char *name, int flags)
{
struct nameidata nd;
+ struct vfsmount *mnt;
int error;
- nd.mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
+ mnt = do_kern_mount("nfsd", 0, "nfsd", NULL);
+ if (IS_ERR(mnt))
+ return (struct file *)mnt;
- if (IS_ERR(nd.mnt))
- return (struct file *)nd.mnt;
-
- nd.dentry = dget(nd.mnt->mnt_root);
- nd.last_type = LAST_ROOT;
- nd.flags = 0;
- nd.depth = 0;
-
- error = path_walk(name, );
+ error = path_component_lookup(mnt->mnt_root, mnt, name, 0, );
if (error)
return ERR_PTR(error);
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/4] fs: Remove path_walk export
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> --- fs/namei.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index b547af0..0262594 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2826,7 +2826,6 @@ EXPORT_SYMBOL(page_symlink_inode_operations); EXPORT_SYMBOL(path_lookup); EXPORT_SYMBOL(path_component_lookup); EXPORT_SYMBOL(path_release); -EXPORT_SYMBOL(path_walk); EXPORT_SYMBOL(permission); EXPORT_SYMBOL(vfs_permission); EXPORT_SYMBOL(file_permission); -- 1.5.0.3.1043.g4342 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/4] sunrpc: Use path_component_lookup
use path_component_lookup instead of open-coding the necessary
functionality.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
net/sunrpc/rpc_pipe.c | 16 +++-
1 files changed, 7 insertions(+), 9 deletions(-)
diff --git a/net/sunrpc/rpc_pipe.c b/net/sunrpc/rpc_pipe.c
index 9b9ea50..b67cb54 100644
--- a/net/sunrpc/rpc_pipe.c
+++ b/net/sunrpc/rpc_pipe.c
@@ -451,21 +451,19 @@ void rpc_put_mount(void)
static int
rpc_lookup_parent(char *path, struct nameidata *nd)
{
+ struct vfsmount *mnt;
+
if (path[0] == '\0')
return -ENOENT;
- nd->mnt = rpc_get_mount();
- if (IS_ERR(nd->mnt)) {
+
+ mnt = rpc_get_mount();
+ if (IS_ERR(mnt)) {
printk(KERN_WARNING "%s: %s failed to mount "
"pseudofilesystem \n", __FILE__, __FUNCTION__);
- return PTR_ERR(nd->mnt);
+ return PTR_ERR(mnt);
}
- mntget(nd->mnt);
- nd->dentry = dget(rpc_mount->mnt_root);
- nd->last_type = LAST_ROOT;
- nd->flags = LOOKUP_PARENT;
- nd->depth = 0;
- if (path_walk(path, nd)) {
+ if (path_component_lookup(rpc_mount->mnt_root, mnt, path,
LOOKUP_PARENT, nd)) {
printk(KERN_WARNING "%s: %s failed to find path %s\n",
__FILE__, __FUNCTION__, path);
rpc_put_mount();
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/4] [RFC] New path lookup function
Stackable file systems, among others, frequently need to lookup paths or
path components starting from an arbitrary point in the namespace
(identified by a dentry and a vfsmount). Currently, such file systems use
lookup_one_len, which is frowned upon [1] as it does not pass the lookup
intent along; not passing a lookup intent, for example, can trigger BUG_ON's
when stacking on top of NFSv4.
The first patch introduces a new lookup function to allow lookup starting
from an arbitrary point in the namespace. This approach has been suggested
by Christoph Hellwig [2].
The second patch changes sunrpc to use path_component_lookup.
The third patch changes nfsctl.c to use path_component_lookup.
The fourth, and last patch, unexports path_walk because it is no longer
unnecessary to call it directly, and using the new path_component_lookup is
cleaner.
For example, the following snippet of code, looks up "some/path/component"
in a directory pointed to by parent_{dentry,vfsmnt}:
err = path_component_lookup(parent_dentry, parent_vfsmnt,
"some/path/component", 0, );
if (!err) {
/* exits */
...
/* once done, release the references */
path_release();
} else if (err == -ENOENT) {
/* doesn't exist */
} else {
/* other error */
}
VFS functions such as lookup_create can be used on the nameidata structure
to pass the create intent to the file system.
Currently, there is no easy way to pass the LOOKUP_OPEN intent. The proper
way would be to call open_namei.
We'd like to get comments about what's necessary to make stackable file
systems do lookups right: this includes potential changes to open_namei.
Josef 'Jeff' Sipek.
[1] http://lkml.org/lkml/2007/3/9/95
[2] http://lkml.org/lkml/2007/5/4/51
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mkfs.ext2 triggerd RAM corruption
On Sat, May 05, 2007 at 02:57:35PM -0400, Theodore Tso wrote: > On Sat, May 05, 2007 at 03:36:37AM +0200, Bernd Schubert wrote: > > distribution: modified debian sarge, in which aspect is the distribution > > important for this problem? mkfs2.ext2 is supposed to write to /dev/sdaX > > and not /dev/rd/0. Stracing it and grepping for open calls shows that > > only /dev/sdaX is opened in read-write mode. > > /dev/rd/0? What's this? Is this the partition where your root > partition is found? What is it? Is it a ramdisk? Or is it some kind > of persistent storage device? > > If it is a persistant storage device, do the corrupted files stay > corrupted when you reboot? (If it's a ramdisk which you load, then > obviously it's getting reloaded on reboot.) You didn't give enough > information to be sure exactly what's going on. Sorry, should have expressed myself more clearly, /dev/rd/0 is the devfs-style name of the first ram disk device (don't like those devfs names myself, but since I'm rather new in this group I couldn't convice my boss to switch to short names yet ;) ). However, its only the devfs-style of udev and not devfs itself. > > The next thing to ask is how the files are corrupted. Can you see > save a copy of the corrupted files to stable storage, so you can see > *how* they were corrupted. Were large swaths of zeros getting written > into it? Yes, many zeros. Binary files, hexdump and diff are here: http://www.q-leap.com/~bschubert/data-corruption > > Next question; if you don't use these mke2fs parameters, can you > reproduce the corruption? > > mkfs.ext2 -j -b 4096 -F -i 4096 -J size=400 -I 512 /dev/sda4 > > What if you change the it to: > > mkfs.ext2 -j -b 4096 /dev/sda4 > > Do you still see corruption problems? No, no observable corruption. > > > I already tested several partition types, e.g. something like this for a > > test on sda3 > > > > beo-05:~# sfdisk -d /dev/sda > > # partition table of /dev/sda > > unit: sectors > > > > /dev/sda1 : start= 63, size= 4208967, Id=83 > > /dev/sda2 : start= 4209030, size= 4209030, Id=83 > > /dev/sda3 : start= 8418060, size=313251435, Id=83 > > /dev/sda4 : start=0, size=0, Id= 0 > > What if the partition size is smaller; does that make the problem go > away? If so, can you do a binary search on the partition size where > the problem appears? Need to test this thouroughly, but will do it tomorrow, its too late here for this kind of tests. > > And what can you say about the SATA driver you were using; were all of > the machines that you tested this on using the same SATA controller > and same driver? As you can see from my previous reply ;) tested with at least two different controllers - intel and nvidia (will reboot on the 4th system on Monday to figure out its hardware, once the corruption happened, the system tend to stop working). > > Obviously if this were a generic kernel problem, we'd been hearing > about this from a lot more people. So there has to be something > unique to your setup, and we need to figure out what that might happen > to be. I also still have problems to believe its a generic problem... Thanks for your help, Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] fs: Use path_walk in do_path_lookup
Since, path_walk sets the total_link_count to 0, and calls link_path_walk,
we can just call path_walk directly.
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/namei.c |4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 600a4e7..86f0def 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1153,8 +1153,8 @@ static int fastcall do_path_lookup(int dfd, const char
*name,
fput_light(file, fput_needed);
}
- current->total_link_count = 0;
- retval = link_path_walk(name, nd);
+
+ retval = path_walk(name, nd);
out:
if (likely(retval == 0)) {
if (unlikely(!audit_dummy_context() && nd && nd->dentry &&
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 0/2] [TRIVIAL] Small cleanups for do_path_lookup
The following 2 patches are trivial cleanups to do_path_lookup in namei.c. Since these changes are trivial, they can go into 2.6.22-rc1 without any problems. Josef 'Jeff' Sipek (2): fs: Fix indentation in do_path_lookup fs: Use path_walk in do_path_lookup diffstat for good measure: fs/namei.c |6 +++--- 1 files changed, 3 insertions(+), 3 deletions(-) Josef 'Jeff' Sipek. [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 1/2] fs: Fix indentation in do_path_lookup
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/namei.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/fs/namei.c b/fs/namei.c
index 0262594..600a4e7 100644
--- a/fs/namei.c
+++ b/fs/namei.c
@@ -1159,7 +1159,7 @@ out:
if (likely(retval == 0)) {
if (unlikely(!audit_dummy_context() && nd && nd->dentry &&
nd->dentry->d_inode))
- audit_inode(name, nd->dentry->d_inode);
+ audit_inode(name, nd->dentry->d_inode);
}
out_fail:
return retval;
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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] Blacklist Dell Optiplex 320 from using the HPET
The lspci output: 00:00.0 Host bridge: ATI Technologies Inc Radeon Xpress 200 Host Bridge (rev 01) 00:01.0 PCI bridge: ATI Technologies Inc RS480 PCI Bridge 00:12.0 SATA controller: ATI Technologies Inc SB600 Non-Raid-5 SATA 00:13.0 USB Controller: ATI Technologies Inc SB600 USB (OHCI0) 00:13.1 USB Controller: ATI Technologies Inc SB600 USB (OHCI1) 00:13.2 USB Controller: ATI Technologies Inc SB600 USB (OHCI2) 00:13.3 USB Controller: ATI Technologies Inc SB600 USB (OHCI3) 00:13.4 USB Controller: ATI Technologies Inc SB600 USB (OHCI4) 00:13.5 USB Controller: ATI Technologies Inc SB600 USB Controller (EHCI) 00:14.0 SMBus: ATI Technologies Inc SB600 SMBus (rev 13) 00:14.1 IDE interface: ATI Technologies Inc SB600 IDE 00:14.2 Audio device: ATI Technologies Inc SB600 Azalia 00:14.3 ISA bridge: ATI Technologies Inc SB600 PCI to LPC Bridge 00:14.4 PCI bridge: ATI Technologies Inc SB600 PCI to PCI Bridge 01:05.0 VGA compatible controller: ATI Technologies Inc RC410 [Radeon Xpress 200] 02:09.0 Ethernet controller: Broadcom Corporation BCM4401-B0 100Base-TX (rev 02) And what about the patch? there's a final version to try? Thanks. john stultz wrote: On Sat, 2007-05-05 at 01:18 +0200, Andi Kleen wrote: On Friday 04 May 2007 23:29:04 john stultz wrote: One of the 2.6.21 regressions was Guilherme's problem seeing his box lock up when the system detected an unstable TSC and dropped back to using the HPET. In digging deeper, we found the HPET is not actually incrementing on this system. And in fact, the reason why this issue just cropped up was because of Thomas's clocksource watchdog code was comparing the TSC to the HPET (which wasn't moving) and thought the TSC was broken. Anyway, Guliherme checked for a BIOS update and did not find one, so I've added a DMI blacklist against his system so the HPET is not used. Many thanks to Guilherme for the slow and laborious testing that finally narrowed down this issue. Before going to hard to maintain DMI black lists we should first check if it's a more general problem and can't it be solved better? Most likely that system isn't the one with this issue and I don't want to apply DMI patches forever. We can give it a whirl, I just didn't want to add yet another "compare with some other counter that may or may not work" check. In this case, probably reading three times in a row and getting the same result would be a clearly broken box. In particular: what lspci chipset does it have? If it's Intel it might be worth checking the datasheet if there is some "HPET stop" bit -- perhaps it could be fixed up. Guilherme: Could you provide lspci output? We seem to have a couple of Intel systems recently with HPET trouble. Ok, I wasn't aware it was a common issue. thanks -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: 2.6.21-mm1
On Sat, May 05, 2007 at 11:48:49PM +0200, Michael Buesch wrote: > On Saturday 05 May 2007 20:48:11 Andrew Morton wrote: > > On Sat, 05 May 2007 17:48:28 +0200 Maciej Rutecki <[EMAIL PROTECTED]> wrote: > > > > > Andrew Morton pisze: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > > > > > > > > > > > > CC [M] lib/zlib_deflate/deflate_syms.o > > > LD [M] lib/zlib_deflate/zlib_deflate.o > > > Building modules, stage 2. > > > MODPOST 791 modules > > > ERROR: "ssb_pcihost_register" [drivers/net/b44.ko] undefined! > > > ERROR: "ssb_pcihost_unregister" [drivers/net/b44.ko] undefined! > > > make[2]: *** [__modpost] Error 1 > > > make[1]: *** [modules] Error 2 > > > make[1]: Leaving directory `/usr/src/linux-mm' > > > make: *** [debian/stamp-build-kernel] Error 2 > > config B44_PCI > bool "Broadcom 4400 PCI device support" > depends on B44 && NET_PCI > > We simply need a SELECT SSB_PCIHOST here. Not sure why it's not there. > I thought it used to be there. That may have only been applied to the mm-master branch, which now no longer exists. I'll patch it now. John -- John W. Linville [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/
[ext3] journal commit interval
Hello all, this is something I have long wondered about but have been afraid to ask. When my system is chewing away on builds, the disk I/O write access pattern of my ext3 root filesystem (using CFQ, Intel SATA controller, hard disk) when visualized by GNOME System Monitor clearly shows a repetitive landscape of large peaks, 5 seconds apart, which not much activity inbetween. I understand that's due to the ex3 journal commit interval (defaults to 5 seconds). But why isn't the filesystem continuously committing only that part of the journal that is older than 5 seconds? I would then expect the write requests to be smoothened over time, which can only be good in terms of performance and low latency. Regards, -- Leon - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Ext3 vs NTFS performance
Theodore Tso <[EMAIL PROTECTED]> wrote: > But as has already been discussed on this thread, in situations where > the fileserver is under high memory pressure, any filesystem (XFS or > ext4) would still end up allocating blocks out of order, resulting in > fragmentation. Explicit preallocation, as opposed to delayed > allocation, is really the best long-term solution; and in order to do > that, Samba needs to detect this scenario --- which as has been noted, > there appears to be no good reason for the Windows CIFS client (or any > other application)to be doing this, other than perhaps to deliberate > trigger a worst case allocation pattern in ext3 --- and translate it > into a explicit preallocation request. There is an interface to tell the kernel about the way the file will be accessed. IMO this interface should be used to do the preallocation, too. The other question is: How to tell the poor-bill's preallocation from a very clever application that communicates with another application and which is supposed to zero out that exact byte from the data the other application sent. I was tempted to say "just let samba cache these calls", but it would be wrong. You'll need magic in the kernel to DTRT. There are three correct ways of handling these one-zerobyte-writes after EOF: 1) Extend the file like truncate 2) Extend the file like write() (current behaviour) 3) Preallocate these blocks (to be implemented) 4) Write all zeroes (current behaviour for FAT) (2) will cause bad allocations, it's obviously worse than (1). (3) would be better than (1) and (2), but only xfs(?) and ext4 will support this in the near future. (4) should double the write time, but give the best possible read speed. According to [1], the expected read speed is about as high as (1) gives, "playback performance improves to expected levels". If preallocation does not seem to make a big difference, I don't think we should do (4) as a replacement untill the filesystem does support real preallocations. I suggest: 1) Make samba use fadvise(MIGHT_PREALLOCATE) 2) Make the kernel turn these 1-byte-writes-after-EOF into truncates on MIGHT_PREALLOCATE, and possibly turn off MIGHT_PREALLOCATE on other read/writes 3) Make the kernel fadvise(PREALLOCATE, $filesize) on MIGHT_PREALLOCATE + lseek(0), turning off the MIGHT_PREALLOCATE Possibly it might also turn on FADV_SEQUENTIAL. 4) Make the filesystems optionally preallocate the desired area, or ignore fadvise(PREALLOCATE, $filesize) instead. [1] http://softwarecommunity.intel.com/articles/eng/1259.htm -- It is still called paranoia when they really are out to get you. Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] led-class.c permission change
On 05 May 2007 at 22h05, Alan Cox wrote: Hi, > > This patch changes the led brightness file's permissions to 0666, > > so that a user's MUA can light up the mail LED without needing root > > permissions. > > NAK. > > The management of user specific temporary permissions belongs in user > space with a safe "no" default value to stop background daemons doing > silly things. Mmh, ok... My usage pattern for this is for an MUA plugin[1] that does write 1 to /sys/class/leds/asus:mail/brightness, for example, when new mail comes. The MUA typically runs as user and until now most of the handled LEDs had no such permission problems (/proc/acpi/asus/mled, /proc/acpi/acer/mailled etc). So, I've got to find a way to write into that file as user so that things automatically work. > Take a look at the various pam console management modules (and also > beat people up to get revoke() support into the kernel). So, you suggest me to link my plugin to libpam and find something that allows the plugin to write into /brightness? Thanks, [1] http://www.claws-mail.org/plugin.php?plugin=acpinotifier -- Colin signature.asc Description: PGP signature
[PATCH -mm] libata-core: convert to use cancel_rearming_delayed_work()
Compile tested, depends on
make-cancel_rearming_delayed_work-reliable.patch
We should not use cancel_work_sync(delayed_work->work). This works, but not
good. We can use cancel_rearming_delayed_work(), this also simplifies the
code.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
drivers/ata/libata-core.c | 44
include/linux/libata.h|1 -
2 files changed, 4 insertions(+), 41 deletions(-)
--- OLD/include/linux/libata.h~ATA 2007-04-05 12:20:35.0 +0400
+++ OLD/include/linux/libata.h 2007-05-06 01:41:10.0 +0400
@@ -192,7 +192,6 @@ enum {
ATA_PFLAG_UNLOADING = (1 << 5), /* module is unloading */
ATA_PFLAG_SCSI_HOTPLUG = (1 << 6), /* SCSI hotplug scheduled */
- ATA_PFLAG_FLUSH_PORT_TASK = (1 << 16), /* flush port task */
ATA_PFLAG_SUSPENDED = (1 << 17), /* port is suspended (power) */
ATA_PFLAG_PM_PENDING= (1 << 18), /* PM operation pending */
--- OLD/drivers/ata/libata-core.c~ATA 2007-04-05 12:20:34.0 +0400
+++ OLD/drivers/ata/libata-core.c 2007-05-06 01:53:43.0 +0400
@@ -1079,18 +1079,11 @@ static unsigned int ata_id_xfermask(cons
void ata_port_queue_task(struct ata_port *ap, work_func_t fn, void *data,
unsigned long delay)
{
- int rc;
-
- if (ap->pflags & ATA_PFLAG_FLUSH_PORT_TASK)
- return;
-
PREPARE_DELAYED_WORK(>port_task, fn);
ap->port_task_data = data;
- rc = queue_delayed_work(ata_wq, >port_task, delay);
-
- /* rc == 0 means that another user is using port task */
- WARN_ON(rc == 0);
+ /* may fail if ata_port_flush_task() in progress */
+ queue_delayed_work(ata_wq, >port_task, delay);
}
/**
@@ -1105,32 +1098,9 @@ void ata_port_queue_task(struct ata_port
*/
void ata_port_flush_task(struct ata_port *ap)
{
- unsigned long flags;
-
DPRINTK("ENTER\n");
- spin_lock_irqsave(ap->lock, flags);
- ap->pflags |= ATA_PFLAG_FLUSH_PORT_TASK;
- spin_unlock_irqrestore(ap->lock, flags);
-
- DPRINTK("flush #1\n");
- cancel_work_sync(>port_task.work); /* akpm: seems unneeded */
-
- /*
-* At this point, if a task is running, it's guaranteed to see
-* the FLUSH flag; thus, it will never queue pio tasks again.
-* Cancel and flush.
-*/
- if (!cancel_delayed_work(>port_task)) {
- if (ata_msg_ctl(ap))
- ata_port_printk(ap, KERN_DEBUG, "%s: flush #2\n",
- __FUNCTION__);
- cancel_work_sync(>port_task.work);
- }
-
- spin_lock_irqsave(ap->lock, flags);
- ap->pflags &= ~ATA_PFLAG_FLUSH_PORT_TASK;
- spin_unlock_irqrestore(ap->lock, flags);
+ cancel_rearming_delayed_work(>port_task);
if (ata_msg_ctl(ap))
ata_port_printk(ap, KERN_DEBUG, "%s: EXIT\n", __FUNCTION__);
@@ -6094,13 +6064,7 @@ void ata_port_detach(struct ata_port *ap
spin_unlock_irqrestore(ap->lock, flags);
ata_port_wait_eh(ap);
-
- /* Flush hotplug task. The sequence is similar to
-* ata_port_flush_task().
-*/
- cancel_work_sync(>hotplug_task.work); /* akpm: why? */
- cancel_delayed_work(>hotplug_task);
- cancel_work_sync(>hotplug_task.work);
+ cancel_rearming_delayed_work(>hotplug_task);
skip_eh:
/* remove the associated SCSI host */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: mkfs.ext2 triggerd RAM corruption
On Sat, May 05, 2007 at 09:12:02PM +0200, Jan Engelhardt wrote: > > On May 5 2007 14:57, Theodore Tso wrote: > >On Sat, May 05, 2007 at 03:36:37AM +0200, Bernd Schubert wrote: > >> distribution: modified debian sarge, in which aspect is the distribution > >> important for this problem? mkfs2.ext2 is supposed to write to /dev/sdaX > >> and not /dev/rd/0. Stracing it and grepping for open calls shows that > >> only /dev/sdaX is opened in read-write mode. > > > >/dev/rd/0? What's this? > > devfs (hint hint) naming for /dev/ram0. Yep, but udev knows devfs style ... (I already told I tested vanilla kernels, so no patches). Bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Blacklist Dell Optiplex 320 from using the HPET
On Saturday 05 May 2007 21:15:01 Thomas Gleixner wrote: > On Sat, 2007-05-05 at 19:24 +0200, Andi Kleen wrote: > > > if (!is_hpet_capable()) > > > @@ -278,6 +279,14 @@ int __init hpet_enable(void) > > > /* Start the counter */ > > > hpet_start_counter(); > > > > > > + /* Verify whether hpet counter works */ > > > + t1 = hpet_read(); > > > + udelay(50); > > > > Are you sure udelay is calibrated at this point? I didn't think so. > > In fact it needs the external clocks and it's a chicken and egg problem. > > Oops. You are right. OTOH it does not matter whether it is accurate or > not. It might be very short if you're very unlucky and the CPU is fast and then trigger the check incorrectly. -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: Interrupt-Handling in User Space
> afaics there is no mechanism in the official kernel tree to handle > interrupts in user space yet. I'd need that for an embedded project I'm Its basically not possible to do with most hardware because you get deadlocks when there are shared interrupts. However see drivers/uio in the current GIT tree (or recent -mm kernels), that assumes you write a truely minimal IRQ handler/board driver in the kernel and it then exposes the memory spaces and IRQ stream to user space. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: lxr problem - newbie needs help
On 05/05/07, Shahbaz Khan <[EMAIL PROTECTED]> wrote: I am using Fedora core 6. I have configured lxr 0.3 with the latest I'm no expert on 'lxr', but as far as I can see version 0.3 is quite old - according to http://sourceforge.net/projects/lxr - the latest version is 0.9.4 - try upgrading to the latest version. glimpse but I get the following in the browser: -> Parent Directory - fileidx - xref when i click the files it gives me some wierd source code with lots of funny faces like ones in the ascii command line screens (if that makes sense at all!). lxr installprefix is /var/www/lxr/ My document root for apache is /var/www/ attached is my lxr configuration. I think you'll have better luck with your query if you ask on one of the lxr mailing lists, see http://sourceforge.net/mail/?group_id=27350 for details. The linux-kernel mailing list is for discussing technical details of the Linux kernel itself, not for asking questions about various other tools. -- Jesper Juhl <[EMAIL PROTECTED]> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.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: [-mm patch] do_revoke error handling (was Re: 2.6.21-mm1)
On Sun, May 06, 2007 at 12:23:15AM +0300, Pekka J Enberg wrote: > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > > > fs/revoke.c: In function 'do_revoke': > > fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this > > function > > fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized > > in this function > > On Sat, 5 May 2007, Frederik Deweerdt wrote: > > It seems that we should goto 'out_free_table' if an error happens in > > the mainloop. Otherwise 'details' is passed to restore_files() without > > being initialized. > > Good catch. The patch is wrong, though. Wwe must restore the file > descriptors in case revoke fails; otherwise we'll leave non-revoked files > hanging. The proper fix is to move initialization before the > do_each_thread() bit. Care to make a new patch, Frederik? > OK, thanks for the explanation. Here it is. Frederik Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]> diff --git a/fs/revoke.c b/fs/revoke.c index 1f2e3ef..86a2842 100644 --- a/fs/revoke.c +++ b/fs/revoke.c @@ -597,6 +597,9 @@ static int do_revoke(struct inode *inode, struct file *to_exclude) goto retry; } + details.fset = fset; + details.restore_start = 0; + /* * First revoke the descriptors. After we are done, no one can start * new operations on them. @@ -625,9 +628,6 @@ static int do_revoke(struct inode *inode, struct file *to_exclude) if (err) goto out_restore; - details.fset = fset; - details.restore_start = 0; - /* * Now, revoke the files for good. */ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
On Saturday 05 May 2007 20:48:11 Andrew Morton wrote: > On Sat, 05 May 2007 17:48:28 +0200 Maciej Rutecki <[EMAIL PROTECTED]> wrote: > > > Andrew Morton pisze: > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > > > > > > > > CC [M] lib/zlib_deflate/deflate_syms.o > > LD [M] lib/zlib_deflate/zlib_deflate.o > > Building modules, stage 2. > > MODPOST 791 modules > > ERROR: "ssb_pcihost_register" [drivers/net/b44.ko] undefined! > > ERROR: "ssb_pcihost_unregister" [drivers/net/b44.ko] undefined! > > make[2]: *** [__modpost] Error 1 > > make[1]: *** [modules] Error 2 > > make[1]: Leaving directory `/usr/src/linux-mm' > > make: *** [debian/stamp-build-kernel] Error 2 config B44_PCI bool "Broadcom 4400 PCI device support" depends on B44 && NET_PCI We simply need a SELECT SSB_PCIHOST here. Not sure why it's not there. I thought it used to be there. -- Greetings 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/
Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]
On Sat, 5 May 2007 20:07:15 +0200 Oliver Neukum <[EMAIL PROTECTED]> wrote: > Am Samstag, 5. Mai 2007 18:36 schrieb Alan Cox: > > > In the serial driver this usually just results in dropping > > > RTS to signal the remote end to stop sending. The serial > > > driver always immediately gives receive data to the tty buffering > > > without regard to the throttled state. > > > > > > I would argue that cdc-acm should do the same as the serial driver. > > > > This is a bug in cdc-acm really. It should not double buffer, but to be > > fair to the authors prior to the new tty buffering it *had* to do this. > > Hi, > > should I understand this so that, if tty_buffer_request_room() returns > less than requested, the rest of the data should be dropped on the > floor? If it returns NULL then either there is > 64K buffered (we can adjust that if anyone shows need - its just for sanity) or the system is out of RAM. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SOLVED] Serial buffer corruption [was Re: FTDI usb-serial possible bug]
> > This is a bug in cdc-acm really. It should not double buffer, but to be > > fair to the authors prior to the new tty buffering it *had* to do this. > > I assume this applies to all serial drivers in the wider sense? When possible at least. Obviously there will always be some buffering in the hardware or interface glue but you should never need to work around the tty buffers now. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] led-class.c permission change
On Sat, 5 May 2007 12:49:54 +0200 Colin Leroy <[EMAIL PROTECTED]> wrote: > Hi, > > This patch changes the led brightness file's permissions to 0666, so that a > user's MUA can light up the mail LED without needing root permissions. NAK. The management of user specific temporary permissions belongs in user space with a safe "no" default value to stop background daemons doing silly things. Take a look at the various pam console management modules (and also beat people up to get revoke() support into the kernel). Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rfc: threaded epoll_wait thundering herd
Davide Libenzi wrote: > On Fri, 4 May 2007, Davi Arnaut wrote: > >> Hi, >> >> If multiple threads are parked on epoll_wait (on a single epoll fd) and >> events become available, epoll performs a wake up of all threads of the >> poll wait list, causing a thundering herd of processes trying to grab >> the eventpoll lock. >> >> This patch addresses this by using exclusive waiters (wake one). Once >> the exclusive thread finishes transferring it's events, a new thread >> is woken if there are more events available. >> >> Makes sense? > > Theorically, make sense. I said theorically because all the use > epoll_wait MT use cases I've heard of, use a single thread that does the > epoll_wait, and then dispatch to worker threads. So thundering herd is not > in the picture. OTOH, it does not hurt either. A google search turns up a few users. It also addresses some complaints from Drepper. > But, that code is completely changed with the new single-pass epoll delivery > code that is in -mm. So, I'd either wait for that code to go in, or I > (or you, if you like) can make a patch against -mm. Fell free to update the patch for -mm and to include my signed-of-by. Thanks. -- Davi Arnaut - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] sata_nv: fix ADMA freeze/thaw/irq_clear issues
This patch fixes some problems with ADMA-capable controllers with regard to
freeze,
thaw and irq_clear libata callbacks. Freeze and thaw didn't switch the
ADMA-specific
interrupts on or off, and more critically the irq_clear function didn't respect
the restriction that the notifier clear registers for both ports have to be
written
at the same time even when only one port is being cleared. This could result in
timeouts on one port when error handling (i.e. as a result of hotplug)
occurred on the other port.
As well, this fixes some issues in the interrupt handler: we shouldn't check any
ADMA status if the port has ADMA switched off because of an ATAPI device, and
it also checks to see if any ADMA interrupt has been raised even when we are in
port-register mode.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.21.1/drivers/ata/sata_nv.c2007-04-27 15:49:26.0
-0600
+++ linux-2.6.21.1edit/drivers/ata/sata_nv.c2007-05-05 15:25:04.0
-0600
@@ -257,6 +257,8 @@ static void nv_adma_port_stop(struct ata
static int nv_adma_port_suspend(struct ata_port *ap, pm_message_t mesg);
static int nv_adma_port_resume(struct ata_port *ap);
#endif
+static void nv_adma_freeze(struct ata_port *ap);
+static void nv_adma_thaw(struct ata_port *ap);
static void nv_adma_error_handler(struct ata_port *ap);
static void nv_adma_host_stop(struct ata_host *host);
static void nv_adma_post_internal_cmd(struct ata_queued_cmd *qc);
@@ -446,8 +448,8 @@ static const struct ata_port_operations
.bmdma_status = ata_bmdma_status,
.qc_prep= nv_adma_qc_prep,
.qc_issue = nv_adma_qc_issue,
- .freeze = nv_ck804_freeze,
- .thaw = nv_ck804_thaw,
+ .freeze = nv_adma_freeze,
+ .thaw = nv_adma_thaw,
.error_handler = nv_adma_error_handler,
.post_internal_cmd = nv_adma_post_internal_cmd,
.data_xfer = ata_data_xfer,
@@ -810,8 +812,16 @@ static irqreturn_t nv_adma_interrupt(int
u16 status;
u32 gen_ctl;
u32 notifier, notifier_error;
+
+ /* if ADMA is disabled, use standard ata interrupt
handler */
+ if (pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE) {
+ u8 irq_stat = readb(host->iomap[NV_MMIO_BAR] +
NV_INT_STATUS_CK804)
+ >> (NV_INT_PORT_SHIFT * i);
+ handled += nv_host_intr(ap, irq_stat);
+ continue;
+ }
- /* if in ATA register mode, use standard ata interrupt
handler */
+ /* if in ATA register mode, check for standard
interrupts */
if (pp->flags & NV_ADMA_PORT_REGISTER_MODE) {
u8 irq_stat = readb(host->iomap[NV_MMIO_BAR] +
NV_INT_STATUS_CK804)
>> (NV_INT_PORT_SHIFT * i);
@@ -821,7 +831,6 @@ static irqreturn_t nv_adma_interrupt(int
command is active, to prevent
losing interrupts. */
irq_stat |= NV_INT_DEV;
handled += nv_host_intr(ap, irq_stat);
- continue;
}
notifier = readl(mmio + NV_ADMA_NOTIFIER);
@@ -907,22 +916,77 @@ static irqreturn_t nv_adma_interrupt(int
return IRQ_RETVAL(handled);
}
+static void nv_adma_freeze(struct ata_port *ap)
+{
+ struct nv_adma_port_priv *pp = ap->private_data;
+ void __iomem *mmio = pp->ctl_block;
+ u16 tmp;
+
+ nv_ck804_freeze(ap);
+
+ if (pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE)
+ return;
+
+ /* clear any outstanding CK804 notifications */
+ writeb( NV_INT_ALL << (ap->port_no * NV_INT_PORT_SHIFT),
+ ap->host->iomap[NV_MMIO_BAR] + NV_INT_STATUS_CK804);
+
+ /* Disable interrupt */
+ tmp = readw(mmio + NV_ADMA_CTL);
+ writew( tmp & ~(NV_ADMA_CTL_AIEN | NV_ADMA_CTL_HOTPLUG_IEN),
+ mmio + NV_ADMA_CTL);
+ readw( mmio + NV_ADMA_CTL );/* flush posted write */
+}
+
+static void nv_adma_thaw(struct ata_port *ap)
+{
+ struct nv_adma_port_priv *pp = ap->private_data;
+ void __iomem *mmio = pp->ctl_block;
+ u16 tmp;
+
+ nv_ck804_thaw(ap);
+
+ if (pp->flags & NV_ADMA_ATAPI_SETUP_COMPLETE)
+ return;
+
+ /* Enable interrupt */
+ tmp = readw(mmio + NV_ADMA_CTL);
+ writew( tmp | (NV_ADMA_CTL_AIEN | NV_ADMA_CTL_HOTPLUG_IEN),
+ mmio + NV_ADMA_CTL);
+ readw( mmio + NV_ADMA_CTL );/* flush posted write */
+}
+
static void nv_adma_irq_clear(struct ata_port *ap)
{
struct nv_adma_port_priv
[PATCH] make-cancel_rearming_delayed_work-reliable-fix
on top of
make-cancel_rearming_delayed_work-reliable-spelling.patch
Add cpu-relax() into spinloops, and a comments update.
Small note. The new implementation has another downside. Suppose that rearming
work->func() gets a preemtion after setting WORK_STRUCT_PENDING but before
add_timer/__queue_work. In that case cancel_rearming_delayed_work() will burn
CPU in a busy-wait loop. Fortunately this can happen only with CONFIG_PREEMPT
and we spin with preemption enabled.
We can avoid this,
void cancel_rearming_delayed_work(struct delayed_work *dwork)
{
int retry;
do {
retry = !del_timer(>timer) &&
!try_to_grab_pending(>work);
wait_on_work(>work);
} while (retry);
work_clear_pending(>work);
}
but I don't think this is worth fixing.
Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]>
--- OLD/kernel/workqueue.c~2_RELAX 2007-05-05 23:17:48.0 +0400
+++ OLD/kernel/workqueue.c 2007-05-05 23:59:59.0 +0400
@@ -475,13 +475,16 @@ static void wait_on_work(struct work_str
* case it only guarantees that work->func() has completed on the last queued
* workqueue.
*
+ * cancel_work_sync(_work->work) should be used only if ->timer is not
+ * pending, otherwise it goes into a busy-wait loop until the timer expires.
+ *
* The caller must ensure that workqueue_struct on which this work was last
* queued can't be destroyed before this function returns.
*/
void cancel_work_sync(struct work_struct *work)
{
while (!try_to_grab_pending(work))
- ;
+ cpu_relax();
wait_on_work(work);
work_clear_pending(work);
}
@@ -498,7 +501,7 @@ void cancel_rearming_delayed_work(struct
{
while (!del_timer(>timer) &&
!try_to_grab_pending(>work))
- ;
+ cpu_relax();
wait_on_work(>work);
work_clear_pending(>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: cpufreq longhaul locks up
Is patch attached below making things better?
You should see in log that You are using VT8235 support now.
---
arch/i386/kernel/cpu/cpufreq/longhaul.c |6 --
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/arch/i386/kernel/cpu/cpufreq/longhaul.c
b/arch/i386/kernel/cpu/cpufreq/longhaul.c
index 5548e5b..c3c9096 100644
--- a/arch/i386/kernel/cpu/cpufreq/longhaul.c
+++ b/arch/i386/kernel/cpu/cpufreq/longhaul.c
@@ -635,6 +635,8 @@ static int longhaul_setup_vt8235(void)
/* Find VT8235 southbridge */
dev = pci_find_device(PCI_VENDOR_ID_VIA, PCI_DEVICE_ID_VIA_8235, NULL);
+ if (dev == NULL)
+ dev = pci_find_device(PCI_VENDOR_ID_VIA,
PCI_DEVICE_ID_VIA_8237, NULL);
if (dev != NULL) {
/* Set transition time to max */
pci_read_config_byte(dev, 0xec, _cmd);
@@ -771,11 +773,11 @@ static int __init longhaul_cpu_init(struct cpufreq_policy
*policy)
}
}
/* Check if northbridge is friendly */
- if (enable_arbiter_disable()) {
+/* if (enable_arbiter_disable()) {
longhaul_flags |= USE_NORTHBRIDGE;
goto print_support_type;
}
- /* Use VT8235 southbridge if present */
+*/ /* Use VT8235 southbridge if present */
if (longhaul_version == TYPE_POWERSAVER && vt8235_present) {
longhaul_flags |= USE_VT8235;
goto print_support_type;
--
--
Wicie, rozumicie
Zobacz >>> http://link.interia.pl/f1a74
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
BUG: sleeping function called from invalid context at net/core/sock.c:1523
Upon resume (from suspend to RAM) of my laptop, I'm getting the following. (Not a regression, it's been there a while.) This is under 2.6.21. Everything *seems* fine afterward, but... -- it's not like I use bluetooth all that often. My laptop has the bluetooth adapter hooked via USB insternally, so it's the hci_usb driver. Authors cc:d. [1.329537] BUG: sleeping function called from invalid context at net/core/sock.c:1523 [1.329574] in_atomic():1, irqs_disabled():0 [1.329576] INFO: lockdep is turned off. [1.329578] [1.329578] Call Trace: [1.329585] [] debug_show_held_locks+0x1c/0x30 [1.329598] [] __might_sleep+0xe5/0xf0 [1.329603] [] lock_sock_nested+0x2c/0x120 [1.329617] [] :bluetooth:hci_sock_dev_event+0x4a/0xf0 [1.329627] [] :bluetooth:hci_sock_dev_event+0xc7/0xf0 [1.329634] [] notifier_call_chain+0x2f/0x50 [1.329639] [] atomic_notifier_call_chain+0x39/0x70 [1.329649] [] :bluetooth:hci_notify+0x16/0x20 [1.329657] [] :bluetooth:hci_unregister_dev+0x5b/0x80 [1.329664] [] :hci_usb:hci_usb_disconnect+0x56/0x90 [1.329683] [] :usbcore:usb_unbind_interface+0x4e/0xa0 [1.329690] [] __device_release_driver+0x93/0xc0 [1.329694] [] device_release_driver+0x46/0x70 [1.329699] [] bus_remove_device+0x78/0x90 [1.329703] [] device_del+0x187/0x200 [1.329717] [] :usbcore:usb_disable_device+0x82/0x110 [1.329731] [] :usbcore:usb_disconnect+0xba/0x140 [1.329746] [] :usbcore:hub_thread+0x400/0xcc0 [1.329757] [] autoremove_wake_function+0x0/0x40 [1.329772] [] :usbcore:hub_thread+0x0/0xcc0 [1.329775] [] keventd_create_kthread+0x0/0x90 [1.329781] [] kthread+0xd3/0x110 [1.329784] [] schedule_tail+0x0/0xe0 [1.329791] [] child_rip+0xa/0x12 [1.329796] [] restore_args+0x0/0x30 [1.329802] [] kthread+0x0/0x110 [1.329806] [] child_rip+0x0/0x12 [1.329809] dmesg and lspci -vvv at http://madrabbit.org/~ray/2.6.21-dmesg http://madrabbit.org/~ray/nx6125.lspci Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] do_revoke error handling (was Re: 2.6.21-mm1)
On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > > > fs/revoke.c: In function 'do_revoke': > fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this > function > fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized > in this function On Sat, 5 May 2007, Frederik Deweerdt wrote: > It seems that we should goto 'out_free_table' if an error happens in > the mainloop. Otherwise 'details' is passed to restore_files() without > being initialized. Good catch. The patch is wrong, though. Wwe must restore the file descriptors in case revoke fails; otherwise we'll leave non-revoked files hanging. The proper fix is to move initialization before the do_each_thread() bit. Care to make a new patch, Frederik? 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: [git pull] New firewire stack
On Thu, May 03, Olaf Hering wrote:
> On Thu, May 03, Stefan Richter wrote:
>
> > ieee1394-old
>
> Noone will seriously ship two firewire stacks, so that cant be the
> issue (for distributors).
>
> Once there is a way to easily switch between kernel releases, I'm ok
> with whatever module names you pick.
This patch loads fw-sbp2 if sbp2 is still in the config file. So one can
go back and forth between releases without worry about the root
filesystem drivers.
Index: linux-2.6.21/drivers/firewire/fw-ohci.c
===
--- linux-2.6.21.orig/drivers/firewire/fw-ohci.c
+++ linux-2.6.21/drivers/firewire/fw-ohci.c
@@ -1881,6 +1881,9 @@ static struct pci_driver fw_ohci_pci_dri
MODULE_AUTHOR("Kristian Hoegsberg <[EMAIL PROTECTED]>");
MODULE_DESCRIPTION("Driver for PCI OHCI IEEE1394 controllers");
MODULE_LICENSE("GPL");
+#ifndef CONFIG_IEEE1394_OHCI1394_MODULE
+MODULE_ALIAS("ohci1394");
+#endif
static int __init fw_ohci_init(void)
{
Index: linux-2.6.21/drivers/firewire/fw-sbp2.c
===
--- linux-2.6.21.orig/drivers/firewire/fw-sbp2.c
+++ linux-2.6.21/drivers/firewire/fw-sbp2.c
@@ -1150,6 +1150,9 @@ MODULE_AUTHOR("Kristian Hoegsberg <[EMAIL PROTECTED]
MODULE_DESCRIPTION("SCSI over IEEE1394");
MODULE_LICENSE("GPL");
MODULE_DEVICE_TABLE(ieee1394, sbp2_id_table);
+#ifndef CONFIG_IEEE1394_SBP2_MODULE
+MODULE_ALIAS("sbp2");
+#endif
static int __init sbp2_init(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] suspend/resume debugging: device filter
Hi! > > Here's a (compile tested only) patch that does this on a per-device > > basis, which is smaller, and should work just as well as your patch. > > > > It creates a new file in the power/ directory for every device called > > "can_suspend". Write a '0' to it to prevent that device from being > > suspended. > > > > Does this work for you? > > yeah, i was able to use this too to debug suspend/resume problems. But > i've added the check to the resume path too - for example sw-suspend > does a resume of devices during its suspend cycle, cutting off much of > the netconsole output. > > which makes the can_suspend flag mis-named - perhaps rename it to > exclude_pm ? debug_exclude_pm? I do not want people playing with it, then complaining that they broke the suspend. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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/
[-mm patch] do_revoke error handling (was Re: 2.6.21-mm1)
On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/ > fs/revoke.c: In function 'do_revoke': fs/revoke.c:563: warning: 'details.fset' may be used uninitialized in this function fs/revoke.c:563: warning: 'details.restore_start' may be used uninitialized in this function It seems that we should goto 'out_free_table' if an error happens in the mainloop. Otherwise 'details' is passed to restore_files() without being initialized. Regards, Frederik Signed-off-by: Frederik Deweerdt <[EMAIL PROTECTED]> diff --git a/fs/revoke.c b/fs/revoke.c index 1f2e3ef..6ab5223 100644 --- a/fs/revoke.c +++ b/fs/revoke.c @@ -611,7 +611,7 @@ static int do_revoke(struct inode *inode, struct file *to_exclude) read_unlock(_lock); if (err) - goto out_restore; + goto out_free_table; /* * Take down shared memory mappings. @@ -623,7 +623,7 @@ static int do_revoke(struct inode *inode, struct file *to_exclude) */ err = revoke_break_cow(fset, inode, to_exclude); if (err) - goto out_restore; + goto out_free_table; details.fset = fset; details.restore_start = 0; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x
On Saturday 05 May 2007, Sergei Shtylyov wrote: > Hello. > > Bartlomiej Zolnierkiewicz wrote: > > >>HPT36x chip don't seem to have the channel enable bits, so prevent the IDE > >>core > >>from checking them... > > >>Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> > > > applied > > I'm getting "403 Forbidden" trying to browse this patch (and > ide-cs-recognize-2gb-compactflash-from-transcend.patch as well). Should be fixed now - sorry for that. While at it I replaced mine version of "the hpt366: simplify UltraDMA filtering (take 2)" with the official one ;) and fixed my damn scripts to always do "chmod 644 pata-2.6/patches/*.patch" before pushing updates to kernel.org. Bart - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix nfsroot build
CC fs/nfs/nfsroot.o
fs/nfs/nfsroot.c:131: error: tokens causes a section type conflict
make[2]: *** [fs/nfs/nfsroot.o] Error 1
This is due to mixing const and non-const content in the same section
which halfway recent gccs absolutely hate. Fixed by dropping the const.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
diff --git a/include/linux/parser.h b/include/linux/parser.h
index 86676f6..26b2bdf 100644
--- a/include/linux/parser.h
+++ b/include/linux/parser.h
@@ -14,7 +14,7 @@ struct match_token {
const char *pattern;
};
-typedef const struct match_token match_table_t[];
+typedef struct match_token match_table_t[];
/* Maximum number of arguments that match_token will find in a pattern */
enum {MAX_OPT_ARGS = 3};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -mm] PM: Separate hibernation code from suspend code
Hi! > > > Power off the system instead of halting it if the 'platform' mode of > > > hibernation > > > has been requested, but hibernation_ops is not set. > > > > Ehm, unless you made a mistake in the patch then that shouldn't be > > possible. > > Hmm, right, but the patch is correct nevertheless. :-) > > I see where the problem is. hibernation_mode is 0 by default > (HIBERNATION_INVALID) and it's not changed to anything else later if > defaults are used. > Something like this is necessary, I think: > > --- > From: Rafael J. Wysocki <[EMAIL PROTECTED]> > > Make sure that hibernation_mode is set to a reasonable value by default. > > Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]> ACK. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.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: cpufreq longhaul locks up
On May 5 2007 21:58, Rafał Bilski wrote: >:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. >Would be good to check if PLL really can go downto x4,0. Can You >limit minimal CPU multiplier to 5,0 and check if is stable? If it >is check 4,5. I directly wrote to /sys/devices/system/cpu/cpu0/cpufreq, which worked better than `cpufreq -u xxx -d xxx`. Lockup after 9 minutes. (Perhaps the longest time so far.) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFT][PATCH] swsusp: Change code ordering related to ACPI
On 5/5/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: On Saturday, 5 May 2007 01:11, Ray Lee wrote: > On 5/4/07, Rafael J. Wysocki <[EMAIL PROTECTED]> wrote: > > The change of the hibernation/suspend code ordering made before 2.6.21 has > > caused some systems to have problems related to ACPI. In particular, the > > 'platform' hibernation mode doesn't work any more on some systems. > > It seems that somewhere between 2.6.21-rc4 and 2.6.21 final my laptop > stopped being able to come out of suspend to RAM. Before I start > bisecting (again, sigh), is this ringing any bells for anyone? In > particular your, patch (snipped) that deals with hibernation, would it > also affect suspend to RAM? Not this particular one, but you may try to move pm_finish() after resume_console() in kernel/power/main.c:suspend_prepare() and see if that helps. If it doesn't help, then try to compile the kernel with NO_HZ and HIGH_RES_TIMERS unset. If that doesn't help, you may try with HPET_TIMER unset additionally. Okay, my system is doing it with a known good kernel as well (2.6.21-rc4), so this is something else. Please ignore my report for now. In the meantime, I'll be downgrading my hal and drm to what they were a week ago to see if that fixes the problem. (I knew better than to change more than one thing at a time, really I did. Sigh.) Thanks for your help regardless, Ray - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-cifs-client] Re: [PATCH] CIFS: make sec=none force an anonymous mount
Shirish S Pargaonkar wrote: When a session setup request is sent as an anonymous user (NUL user), should/could there be password associated with that? Right now, sec=none option, will prompt you for a password. And when we add code to retry session setup as anonymous user if the first session setup request fails, should that retry request be sent with the password or without password? When smbfs sends requests as an anonymous user, it does not send a password along with it. Regards, Shirish We should allow a password to be specified (presumably it is not common for a server to have a password associated with a null user), but probably not prompt (similar to "guest" - except for the case of guest, we start with the username of uid of current process, and only if it fails with access denied do we try "user=" (or equivalently sec=none)) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
lxr problem - newbie needs help
I am using Fedora core 6. I have configured lxr 0.3 with the latest glimpse but I get the following in the browser: -> Parent Directory - fileidx - xref when i click the files it gives me some wierd source code with lots of funny faces like ones in the ascii command line screens (if that makes sense at all!). lxr installprefix is /var/www/lxr/ My document root for apache is /var/www/ attached is my lxr configuration. lxr.conf Description: Binary data
cpufreq_set_policy [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined!
On Sat, May 05, Andrew Morton wrote: > git-cpufreq.patch ERROR: ".cpufreq_set_policy" [arch/powerpc/platforms/cell/cbe_cpufreq.ko] undefined! This is also broken in mainline. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On Sat, May 05, 2007 at 07:00:12PM +0200, Adrian Bunk wrote: > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote: > >... > > Changes since 2.6.21-rc7-mm2: > >... > > git-unionfs.patch > >... > > git trees > >... > > <-- snip --> > > ... > CC fs/unionfs/super.o > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In function > ‘init_once’: > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: > ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function) > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: > (Each undeclared identifier is reported only once > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: > for each function it appears in.) > make[3]: *** [fs/unionfs/super.o] Error 1 > > <-- snip --> > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> Applied. Thanks. Josef "Jeff" Sipek. -- *NOTE: This message is ROT-13 encrypted twice for extra protection* - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: git-tree compilation error "pci_module_init" [drivers/scsi/tmscsim.ko] undefined!
On Sat, 5 May 2007, [EMAIL PROTECTED] wrote: > > WARNING: "pci_module_init" [drivers/scsi/tmscsim.ko] undefined! Ok, that driver needs to be converted to use "pci_register_driver()" instead of "pci_module_init()". It's probably the following one-liner, do you actually have that hardware to test? Linus --- drivers/scsi/tmscsim.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c index a583e89..3158949 100644 --- a/drivers/scsi/tmscsim.c +++ b/drivers/scsi/tmscsim.c @@ -2680,7 +2680,7 @@ static int __init dc390_module_init(void) printk (KERN_INFO "DC390: Using safe settings.\n"); } - return pci_module_init(_driver); + return pci_register_driver(_driver); } static void __exit dc390_module_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: cpufreq longhaul locks up
On May 5 2007 21:58, Rafał Bilski wrote: > >>> I found one line which wasn't were it should be. Probably this will not >>> fix Your problem with powersave governor, but it is a bit related. >>> Looks like Longhaul isn't skipping frequency transtition when it is asked >>> to set f which is already set. Now after first transition it will not >>> try to set same frequency again. Second part contains some magic >>> because I don't have CN400 datasheet. It is NDA protected :-( Should >>> print You one byte in hex and will try to set one register. I don't >>> know if anything will change but it is worth testing. >> >> Did not help unfortunately. The output the printk line generated was >> longhaul: 0x0 >> >> (Strangely enough, %#02x with glibc outputs "00", not "0x0". >> And I would have expected "0x00". Subtleties of the kernel >> printk/glibc?) > >:-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. >Would be good to check if PLL really can go downto x4,0. Can You >limit minimal CPU multiplier to 5,0 and check if is stable? If it >is check 4,5. How do I do that? I tried `cpufreq-set -d 665 -u 665` (x5.0), but that changed the frequency to 532 (x4.0). I can set the CPU frequency in the BIOS, from x3.0 to x16.0, in x0.5 steps (base frequency is 133, DIMM freq is 266). [ Actually, the values are a bit off, cn:~ # cpufreq-info cpufrequtils 002: cpufreq-info (C) Dominik Brodowski 2004-2006 Report errors and bugs to http://bugs.opensuse.org, please. analyzing CPU 0: driver: longhaul CPUs which need to switch frequency at the same time: 0 hardware limits: 532 MHz - 731 MHz available frequency steps: 532 MHz, 598 MHz, 731 MHz, 665 MHz available cpufreq governors: performance current policy: frequency should be within 532 MHz and 731 MHz. The governor "performance" may decide which speed to use within this range. current CPU frequency is 731 MHz (asserted by call to hardware). ] The BIOS default is x5.5, producing 733 MHz. With longhaul/cpufreq, I can then choose from between 533 MHz (x4.0) and the value that was set in the BIOS. >Please send me below part of Your dmesg too: >CPU: After generic identify, caps: 0381b83f > >CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) >CPU: L2 Cache: 64K (32 bytes/line) >CPU: After all inits, caps: 0381b93f >00dd CPU: After generic identify, caps: 0381b03f CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After all inits, caps: 0381b13f 00dd Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
acpi_handle is intel only.
On Sat, May 05, Andrew Morton wrote: > +gregkh-pci-pci-reduce-aer-init-error-information.patch include/linux/pci-acpi.h:57: error: expected ')' before 'handle' make[4]: *** [drivers/pci/pcie/portdrv_pci.o] Error 1 acpi_handle is intel only. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: DC390: replace pci_module_init in dc390_module_init
On Sat, 5 May 2007, Niklas Steinkamp wrote: > while compiling the DC930 SCSI driver, i got this message: > > drivers/built-in.o: In function `dc390_module_init': > tmscsim.c:(.init.text+0x124c4): undefined reference to `pci_module_init' > make: *** [.tmp_vmlinux1] Fehler 1 > > so i replaced "pci_module_init" with "pci_register_device" > and it works just fine. > -- > > diff --git a/drivers/scsi/tmscsim.c b/drivers/scsi/tmscsim.c > index a583e89..3158949 100644 > --- a/drivers/scsi/tmscsim.c > +++ b/drivers/scsi/tmscsim.c > @@ -2680,7 +2680,7 @@ static int __init dc390_module_init(void) > printk (KERN_INFO "DC390: Using safe settings.\n"); > } > > - return pci_module_init(_driver); > + return pci_register_driver(_driver); > } > > static void __exit dc390_module_exit(void) Thanks for the patch, but this is already fixed in -mm tree: http://marc.info/?l=linux-scsi=117757368229767=2 Thanks Guennadi --- Guennadi Liakhovetski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt-Handling in User Space
On Sat, May 05, 2007 at 09:55:33PM +0200, Thomas Gleixner wrote: > On Sat, 2007-05-05 at 21:17 +0200, Clifford Wolf wrote: > > afaics there is no mechanism in the official kernel tree to handle > > interrupts in user space yet. I'd need that for an embedded project I'm > > woking on atm and are so far not sure if I'm going to implement such a > > generic interface or just write a simple driver that does the job for my > > application. So I'd like to find out what the chances are that such a > > feature will get accepted in the official kernel.. > > Please take a look at drivers/uio, which is currently in -mm and on the > way to mainline. UIO is featured in latest LWN kernel edition (subscribers only until Thursday). That may help to get an overview. http://lwn.net 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/
[PATCH 3/3] [PATCH] fix unionfs compilation
From: Adrian Bunk <[EMAIL PROTECTED]>
On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
>...
> Changes since 2.6.21-rc7-mm2:
>...
> git-unionfs.patch
>...
> git trees
>...
<-- snip -->
...
CC fs/unionfs/super.o
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In function
‘init_once’:
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
‘SLAB_CTOR_VERIFY’ undeclared (first use in this function)
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
(Each undeclared identifier is reported only once
/home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error: for
each function it appears in.)
make[3]: *** [fs/unionfs/super.o] Error 1
<-- snip -->
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/super.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index 02c0cc8..af5a1c5 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -821,8 +821,7 @@ static void init_once(void *v, struct kmem_cache * cachep,
unsigned long flags)
{
struct unionfs_inode_info *i = v;
- if ((flags & (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
- SLAB_CTOR_CONSTRUCTOR)
+ if (flags & SLAB_CTOR_CONSTRUCTOR)
inode_init_once(>vfs_inode);
}
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/3] Unionfs: Accept MS_SILENT during remount
From: Adrian Brunyate <[EMAIL PROTECTED]>
[jsipek: whitespace cleanup]
Signed-off-by: Adrian Brunyate <[EMAIL PROTECTED]>
Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]>
---
fs/unionfs/super.c | 12 +++-
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c
index e6a6cc1..ee12d03 100644
--- a/fs/unionfs/super.c
+++ b/fs/unionfs/super.c
@@ -425,11 +425,12 @@ static int unionfs_remount_fs(struct super_block *sb, int
*flags,
unionfs_write_lock(sb);
/*
-* The VFS will take care of "ro" and "rw" flags, so anything else
-* is an error. So we need to check if any other flags may have
-* been passed (none are allowed/supported as of now).
+* The VFS will take care of "ro" and "rw" flags, and we can safely
+* ignore MS_SILENT, but anything else left over is an error. So we
+* need to check if any other flags may have been passed (none are
+* allowed/supported as of now).
*/
- if ((*flags & ~MS_RDONLY) != 0) {
+ if ((*flags & ~(MS_RDONLY | MS_SILENT)) != 0) {
printk(KERN_WARNING
"unionfs: remount flags 0x%x unsupported\n", *flags);
err = -EINVAL;
@@ -731,7 +732,8 @@ out_no_change:
i = atomic_inc_return(_SB(sb)->generation);
atomic_set(_D(sb->s_root)->generation, i);
atomic_set(_I(sb->s_root->d_inode)->generation, i);
- printk("unionfs: new generation number %d\n", i);
+ if (!(*flags & MS_SILENT))
+ printk("unionfs: new generation number %d\n", i);
err = 0;/* reset to success */
/*
--
1.5.0.3.1043.g4342
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[GIT PULL -mm] Unionfs updates
The following patches (also available though the git tree) fix few small bugs in Unionfs. You can pull from 'master' branch of git://git.kernel.org/pub/scm/linux/kernel/git/jsipek/unionfs.git to receive the following: Adrian Brunyate (2): Unionfs: Accept MS_SILENT during remount Unionfs: Check remount options for being NULL Adrian Bunk (1): fix unionfs compilation fs/unionfs/super.c | 17 + 1 files changed, 9 insertions(+), 8 deletions(-) Josef 'Jeff' Sipek. [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/3] Unionfs: Check remount options for being NULL
From: Adrian Brunyate <[EMAIL PROTECTED]> Signed-off-by: Adrian Brunyate <[EMAIL PROTECTED]> Signed-off-by: Josef 'Jeff' Sipek <[EMAIL PROTECTED]> --- fs/unionfs/super.c |2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/unionfs/super.c b/fs/unionfs/super.c index ee12d03..02c0cc8 100644 --- a/fs/unionfs/super.c +++ b/fs/unionfs/super.c @@ -442,7 +442,7 @@ static int unionfs_remount_fs(struct super_block *sb, int *flags, * the union to a "ro" or "rw" and the VFS took care of it. So * nothing to do and we're done. */ - if (options[0] == '\0') + if (!options || options[0] == '\0') goto out_error; /* -- 1.5.0.3.1043.g4342 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x
Hello. Bartlomiej Zolnierkiewicz wrote: HPT36x chip don't seem to have the channel enable bits, so prevent the IDE core from checking them... Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> applied I'm getting "403 Forbidden" trying to browse this patch (and ide-cs-recognize-2gb-compactflash-from-transcend.patch as well). MBR, Sergei - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 pata-2.6 fix queue] hpt366: don't check enablebits for HPT36x
On Friday 04 May 2007, Sergei Shtylyov wrote: > HPT36x chip don't seem to have the channel enable bits, so prevent the IDE > core > from checking them... > > Signed-off-by: Sergei Shtylyov <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[git patches] IDE updates
Updates/fixes for host drivers.
Please pull from:
master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/
to receive the following updates:
drivers/ide/cris/ide-cris.c|9 +-
drivers/ide/legacy/ide-cs.c|1 +
drivers/ide/pci/aec62xx.c | 22 +--
drivers/ide/pci/alim15x3.c |7 +-
drivers/ide/pci/cmd64x.c | 537 +---
drivers/ide/pci/hpt366.c |7 +-
drivers/ide/pci/it821x.c | 126 +-
drivers/ide/pci/pdc202xx_new.c |3 -
drivers/ide/pci/siimage.c | 12 +-
drivers/ide/pci/sl82c105.c | 247 ---
include/linux/ide.h|1 -
11 files changed, 459 insertions(+), 513 deletions(-)
Bartlomiej Zolnierkiewicz (5):
alim15x3: PIO fallback fix
pdc202xx_new: enable DMA for all ATAPI devices
it821x: PIO mode setup fixes
siimage: fix wrong ->swdma_mask
ide-cris: fix ->speedproc and wrong ->swdma_mask
Fabrice Aeschbacher (1):
ide-cs: recognize 2GB CompactFlash from Transcend
Sergei Shtylyov (9):
sl82c105: rework PIO support (take 2)
sl82c105: DMA support code cleanup (take 4)
cmd64x: fix multiword and remove single-word DMA support
cmd64x: interrupt status fixes (take 2)
cmd64x: add/fix enablebits (take 2)
cmd64x: procfs code fixes/cleanups (take 2)
cmd64x: use interrupt status from MRDMODE register (take 2)
aec62xx: fix PIO/DMA setup issues
hpt366: don't check enablebits for HPT36x
diff --git a/drivers/ide/cris/ide-cris.c b/drivers/ide/cris/ide-cris.c
index 556455f..5e8efc8 100644
--- a/drivers/ide/cris/ide-cris.c
+++ b/drivers/ide/cris/ide-cris.c
@@ -730,7 +730,7 @@ static int speed_cris_ide(ide_drive_t *drive, u8 speed)
if (speed >= XFER_PIO_0 && speed <= XFER_PIO_4) {
tune_cris_ide(drive, speed - XFER_PIO_0);
- return 0;
+ return ide_config_drive_speed(drive, speed);
}
switch(speed)
@@ -760,7 +760,8 @@ static int speed_cris_ide(ide_drive_t *drive, u8 speed)
hold = ATA_DMA2_HOLD;
break;
default:
- return 0;
+ BUG();
+ break;
}
if (speed >= XFER_UDMA_0)
@@ -768,7 +769,7 @@ static int speed_cris_ide(ide_drive_t *drive, u8 speed)
else
cris_ide_set_speed(TYPE_DMA, 0, strobe, hold);
- return 0;
+ return ide_config_drive_speed(drive, speed);
}
void __init
@@ -821,7 +822,6 @@ init_e100_ide (void)
hwif->udma_four = 0;
hwif->ultra_mask = cris_ultra_mask;
hwif->mwdma_mask = 0x07; /* Multiword DMA 0-2 */
- hwif->swdma_mask = 0x07; /* Singleword DMA 0-2 */
hwif->autodma = 1;
hwif->drives[0].autodma = 1;
hwif->drives[1].autodma = 1;
@@ -1010,7 +1010,6 @@ static int cris_config_drive_for_dma (ide_drive_t *drive)
return 0;
speed_cris_ide(drive, speed);
- ide_config_drive_speed(drive, speed);
return ide_dma_enable(drive);
}
diff --git a/drivers/ide/legacy/ide-cs.c b/drivers/ide/legacy/ide-cs.c
index b08c37c..c6522a6 100644
--- a/drivers/ide/legacy/ide-cs.c
+++ b/drivers/ide/legacy/ide-cs.c
@@ -401,6 +401,7 @@ static struct pcmcia_device_id ide_ids[] = {
PCMCIA_DEVICE_PROD_ID12("TOSHIBA", "MK2001MPL", 0xb4585a1a, 0x3489e003),
PCMCIA_DEVICE_PROD_ID1("TRANSCEND512M ", 0xd0909443),
PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS1GCF80", 0x709b1bf1,
0x2a54d4b1),
+ PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS2GCF120", 0x709b1bf1,
0x969aa4f2),
PCMCIA_DEVICE_PROD_ID12("TRANSCEND", "TS4GCF120", 0x709b1bf1,
0xf54a91c8),
PCMCIA_DEVICE_PROD_ID12("WIT", "IDE16", 0x244e5994, 0x3e232852),
PCMCIA_DEVICE_PROD_ID12("WEIDA", "TWTTI", 0xcc7cf69c, 0x212bb918),
diff --git a/drivers/ide/pci/aec62xx.c b/drivers/ide/pci/aec62xx.c
index 990eafe..73bdf64 100644
--- a/drivers/ide/pci/aec62xx.c
+++ b/drivers/ide/pci/aec62xx.c
@@ -1,7 +1,8 @@
/*
- * linux/drivers/ide/pci/aec62xx.c Version 0.11March 27, 2002
+ * linux/drivers/ide/pci/aec62xx.c Version 0.21Apr 21, 2007
*
* Copyright (C) 1999-2002 Andre Hedrick <[EMAIL PROTECTED]>
+ * Copyright (C) 2007 MontaVista Software, Inc. <[EMAIL PROTECTED]>
*
*/
@@ -193,18 +194,8 @@ static int config_chipset_for_dma (ide_drive_t *drive)
static void aec62xx_tune_drive (ide_drive_t *drive, u8 pio)
{
- u8 speed = 0;
- u8 new_pio = XFER_PIO_0 + ide_get_best_pio_mode(drive, 255, 5, NULL);
-
- switch(pio) {
- case 5: speed = new_pio; break;
- case 4: speed = XFER_PIO_4; break;
- case 3: speed = XFER_PIO_3; break;
- case 2: speed = XFER_PIO_2; break;
- case
Re: [PATCH] use mutex instead of semaphore in IDE driver
On Thursday 26 April 2007, Matthias Kaehlcke wrote: > the IDE driver uses a semaphore as mutex. use the mutex API instead of > the (binary) semaphore > > Signed-off-by: Matthias Kaehlcke <[EMAIL PROTECTED]> applied - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
>> I found one line which wasn't were it should be. Probably this will not >> fix Your problem with powersave governor, but it is a bit related. >> Looks like Longhaul isn't skipping frequency transtition when it is asked >> to set f which is already set. Now after first transition it will not >> try to set same frequency again. Second part contains some magic >> because I don't have CN400 datasheet. It is NDA protected :-( Should >> print You one byte in hex and will try to set one register. I don't >> know if anything will change but it is worth testing. > > Did not help unfortunately. The output the printk line generated was > longhaul: 0x0 > > (Strangely enough, %#02x with glibc outputs "00", not "0x0". > And I would have expected "0x00". Subtleties of the kernel > printk/glibc?) :-/ Weird. Nothing new in datasheet. Longhaul MSR seems to be OK too. Would be good to check if PLL really can go downto x4,0. Can You limit minimal CPU multiplier to 5,0 and check if is stable? If it is check 4,5. Please send me below part of Your dmesg too: CPU: After generic identify, caps: 0381b83f CPU: L1 I Cache: 64K (32 bytes/line), D cache 64K (32 bytes/line) CPU: L2 Cache: 64K (32 bytes/line) CPU: After all inits, caps: 0381b93f 00dd "dd" is very important here. > Jan Rafał -- Kasia Cichopek eksponuje biust >>> http://link.interia.pl/f1a6f - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
"modularized" 2.4.34.4 -> ide-core "unresolved symbols"
Hallo, I was trying to make "modularized kernel" (s.c. "Debian way") recently, yes, I made even kernel.deb package - but at the installation, I'm still getting an error: "ide-core: unresolved symbols". Making a quick search with Google I could see, it did occur to many other people even long ago. There was even a patch introduced - which, I believe, is in the 2.4.34.4 "drivers/ide" sub-dir - unfortunately it seems, that the patch is working no more. Perhaps there is another patch available for 2.4.34.4 ? -- pozdrawiam / regards Zbigniew Baniewski - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Interrupt-Handling in User Space
On Sat, 2007-05-05 at 21:17 +0200, Clifford Wolf wrote: > afaics there is no mechanism in the official kernel tree to handle > interrupts in user space yet. I'd need that for an embedded project I'm > woking on atm and are so far not sure if I'm going to implement such a > generic interface or just write a simple driver that does the job for my > application. So I'd like to find out what the chances are that such a > feature will get accepted in the official kernel.. Please take a look at drivers/uio, which is currently in -mm and on the way to mainline. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Interrupt-Handling in User Space
Hi, afaics there is no mechanism in the official kernel tree to handle interrupts in user space yet. I'd need that for an embedded project I'm woking on atm and are so far not sure if I'm going to implement such a generic interface or just write a simple driver that does the job for my application. So I'd like to find out what the chances are that such a feature will get accepted in the official kernel.. Rationale: I'm not a fried of 'device drivers in userland'. But sometimes one wants to talk to the hardware directly without anything like a 'device driver' at all (e.g. for hardwaretesting, prototyping and debugging). In my application I have my hardware block memory mmapped in the application using /dev/mem to avoid additional copying steps between kernel and userland. All I need now is an easy way to handle interrupts in my application. My plan is to extend drivers/char/mem.c to implement an additional /dev/irq device file with the following ICOTLs: IOCTL_IRQ_REGISTER Integer argument: Interrupt Number Must be the first ioctl issued after opening the device file. It registeres an interrupt handler which is associated with the fd and gets unregisteredwhen the fd is closed. IOCTL_IRQ_AUTHORITIVE Argument is ignored Usually the interrupt handler returns IRQ_NONE. After this ioctl has been called it returns IRQ_HANDLED instead. IOCTL_IRQ_FLUSH Argument is ignored. Returns the number of interrupts since the last IOCTL_IRQ_FLUSH, IOCTL_IRQ_WAIT or read() call. IOCTL_IRQ_WAIT Argument is ignored. Returns without blocking if there have been any interrupts since the last IOCTL_IRQ_FLUSH or IOCTL_IRQ_WAIT call or blocks until the next interrupt otherwise. Returns the number of interrupts since the last IOCTL_IRQ_FLUSH, IOCTL_IRQ_WAIT or read() call. Reading from the device file has the same effect as calling IOCTL_IRQ_WAIT when reading in blocking or IOCTL_IRQ_FLUSH when reading in non-blocking mode. When the read buffer len is 4 or more and there have been any interrupts the first 4 bytes are filled with the number of interrupts since the last IOCTL_IRQ_FLUSH, IOCTL_IRQ_WAIT or read() call and 4 is returned. Using select() or epoll() will also be possible. Reading returns zero (EOF) when there haven't been any interrupts and the read is non-blocking. What do you think? Any arguments against approach? Does anyone else also feel the need for something like that in the kernel? yours, - clifford -- Once you have something that grows faster than education grows, you're always going to get a pop culture. -- Alan Kay - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On Sat, May 05, 2007 at 10:19:42PM +0300, Pekka Enberg wrote: > On 5/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > >Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is > >inexplicably > >dependent upon CONFIG_SLAB. > > > >How come? > > I think Adrian added it before we introduced krealloc() to fix uniofs > from poking slab internals. I believe the (commented out) patch in -mm series file fixes things: unionfs-fix-slab-abuses-with-krealloc.patch It probably got commented out when unionfs got temporarily dropped from -mm. Josef "Jeff" Sipek. -- Keyboard not found! Press F1 to enter Setup - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On Sat, 5 May 2007 15:13:13 -0400 Josef Sipek <[EMAIL PROTECTED]> wrote: > As it was discussed a while back on the mailing lists, Unionfs is trying to > be smart and tries to do reallocation on its own. The way it does it makes > it depend on some internals of the SLAB allocator. There have been some > patches out there for a realloc function (by Pekka Enberg, IIRC), but as far > as I can tell, they haven't been merged in. krealloc should be in mainline within a couple of days. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On 5/5/07, Andrew Morton <[EMAIL PROTECTED]> wrote: Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is inexplicably dependent upon CONFIG_SLAB. How come? I think Adrian added it before we introduced krealloc() to fix uniofs from poking slab internals. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On Sat, May 05, 2007 at 11:57:18AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 19:00:12 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.21-rc7-mm2:
> > >...
> > > git-unionfs.patch
> > >...
> > > git trees
> > >...
> >
> > <-- snip -->
> >
> > ...
> > CC fs/unionfs/super.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In
> > function ‘init_once’:
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function)
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > (Each undeclared identifier is reported only once
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > for each function it appears in.)
> > make[3]: *** [fs/unionfs/super.o] Error 1
> >
> > <-- snip -->
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> > --- linux-2.6.21-mm1/fs/unionfs/super.c.old 2007-05-05 18:45:25.0
> > +0200
> > +++ linux-2.6.21-mm1/fs/unionfs/super.c 2007-05-05 18:46:03.0
> > +0200
> > @@ -819,8 +819,7 @@
> > {
> > struct unionfs_inode_info *i = v;
> >
> > - if ((flags & (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
> > - SLAB_CTOR_CONSTRUCTOR)
> > + if (flags & SLAB_CTOR_CONSTRUCTOR)
> > inode_init_once(>vfs_inode);
> > }
>
> Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is
> inexplicably
> dependent upon CONFIG_SLAB.
>
> How come?
As it was discussed a while back on the mailing lists, Unionfs is trying to
be smart and tries to do reallocation on its own. The way it does it makes
it depend on some internals of the SLAB allocator. There have been some
patches out there for a realloc function (by Pekka Enberg, IIRC), but as far
as I can tell, they haven't been merged in.
Josef "Jeff" Sipek.
--
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like
that.
- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Blacklist Dell Optiplex 320 from using the HPET
On Sat, 2007-05-05 at 19:24 +0200, Andi Kleen wrote: > > if (!is_hpet_capable()) > > @@ -278,6 +279,14 @@ int __init hpet_enable(void) > > /* Start the counter */ > > hpet_start_counter(); > > > > + /* Verify whether hpet counter works */ > > + t1 = hpet_read(); > > + udelay(50); > > Are you sure udelay is calibrated at this point? I didn't think so. > In fact it needs the external clocks and it's a chicken and egg problem. Oops. You are right. OTOH it does not matter whether it is accurate or not. > It might be safer to use a long loop with io port accesses or similar. Should work as well. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mkfs.ext2 triggerd RAM corruption
On May 5 2007 14:57, Theodore Tso wrote: >On Sat, May 05, 2007 at 03:36:37AM +0200, Bernd Schubert wrote: >> distribution: modified debian sarge, in which aspect is the distribution >> important for this problem? mkfs2.ext2 is supposed to write to /dev/sdaX >> and not /dev/rd/0. Stracing it and grepping for open calls shows that >> only /dev/sdaX is opened in read-write mode. > >/dev/rd/0? What's this? devfs (hint hint) naming for /dev/ram0. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On Sat, May 05, 2007 at 11:57:18AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 19:00:12 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> > On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> > >...
> > > Changes since 2.6.21-rc7-mm2:
> > >...
> > > git-unionfs.patch
> > >...
> > > git trees
> > >...
> >
> > <-- snip -->
> >
> > ...
> > CC fs/unionfs/super.o
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In
> > function ‘init_once’:
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function)
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > (Each undeclared identifier is reported only once
> > /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> > for each function it appears in.)
> > make[3]: *** [fs/unionfs/super.o] Error 1
> >
> > <-- snip -->
> >
> > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
> >
> > ---
> > --- linux-2.6.21-mm1/fs/unionfs/super.c.old 2007-05-05 18:45:25.0
> > +0200
> > +++ linux-2.6.21-mm1/fs/unionfs/super.c 2007-05-05 18:46:03.0
> > +0200
> > @@ -819,8 +819,7 @@
> > {
> > struct unionfs_inode_info *i = v;
> >
> > - if ((flags & (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
> > - SLAB_CTOR_CONSTRUCTOR)
> > + if (flags & SLAB_CTOR_CONSTRUCTOR)
> > inode_init_once(>vfs_inode);
> > }
>
> Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is
> inexplicably
> dependent upon CONFIG_SLAB.
>
> How come?
http://lkml.org/lkml/2007/2/19/326
cu
Adrian
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] rfc: threaded epoll_wait thundering herd
On Fri, 4 May 2007, Davi Arnaut wrote: > Hi, > > If multiple threads are parked on epoll_wait (on a single epoll fd) and > events become available, epoll performs a wake up of all threads of the > poll wait list, causing a thundering herd of processes trying to grab > the eventpoll lock. > > This patch addresses this by using exclusive waiters (wake one). Once > the exclusive thread finishes transferring it's events, a new thread > is woken if there are more events available. > > Makes sense? Theorically, make sense. I said theorically because all the use epoll_wait MT use cases I've heard of, use a single thread that does the epoll_wait, and then dispatch to worker threads. So thundering herd is not in the picture. OTOH, it does not hurt either. But, that code is completely changed with the new single-pass epoll delivery code that is in -mm. So, I'd either wait for that code to go in, or I (or you, if you like) can make a patch against -mm. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: mkfs.ext2 triggerd RAM corruption
On Sat, May 05, 2007 at 03:36:37AM +0200, Bernd Schubert wrote: > distribution: modified debian sarge, in which aspect is the distribution > important for this problem? mkfs2.ext2 is supposed to write to /dev/sdaX > and not /dev/rd/0. Stracing it and grepping for open calls shows that > only /dev/sdaX is opened in read-write mode. /dev/rd/0? What's this? Is this the partition where your root partition is found? What is it? Is it a ramdisk? Or is it some kind of persistent storage device? If it is a persistant storage device, do the corrupted files stay corrupted when you reboot? (If it's a ramdisk which you load, then obviously it's getting reloaded on reboot.) You didn't give enough information to be sure exactly what's going on. The next thing to ask is how the files are corrupted. Can you see save a copy of the corrupted files to stable storage, so you can see *how* they were corrupted. Were large swaths of zeros getting written into it? Next question; if you don't use these mke2fs parameters, can you reproduce the corruption? mkfs.ext2 -j -b 4096 -F -i 4096 -J size=400 -I 512 /dev/sda4 What if you change the it to: mkfs.ext2 -j -b 4096 /dev/sda4 Do you still see corruption problems? > I already tested several partition types, e.g. something like this for a > test on sda3 > > beo-05:~# sfdisk -d /dev/sda > # partition table of /dev/sda > unit: sectors > > /dev/sda1 : start= 63, size= 4208967, Id=83 > /dev/sda2 : start= 4209030, size= 4209030, Id=83 > /dev/sda3 : start= 8418060, size=313251435, Id=83 > /dev/sda4 : start=0, size=0, Id= 0 What if the partition size is smaller; does that make the problem go away? If so, can you do a binary search on the partition size where the problem appears? And what can you say about the SATA driver you were using; were all of the machines that you tested this on using the same SATA controller and same driver? Obviously if this were a generic kernel problem, we'd been hearing about this from a lot more people. So there has to be something unique to your setup, and we need to figure out what that might happen to be. - Ted - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] fix unionfs compilation
On Sat, 5 May 2007 19:00:12 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> On Sat, May 05, 2007 at 01:49:55AM -0700, Andrew Morton wrote:
> >...
> > Changes since 2.6.21-rc7-mm2:
> >...
> > git-unionfs.patch
> >...
> > git trees
> >...
>
> <-- snip -->
>
> ...
> CC fs/unionfs/super.o
> /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c: In function
> ‘init_once’:
> /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> ‘SLAB_CTOR_VERIFY’ undeclared (first use in this function)
> /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> (Each undeclared identifier is reported only once
> /home/bunk/linux/kernel-2.6/linux-2.6.21-mm1/fs/unionfs/super.c:822: error:
> for each function it appears in.)
> make[3]: *** [fs/unionfs/super.o] Error 1
>
> <-- snip -->
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
> --- linux-2.6.21-mm1/fs/unionfs/super.c.old 2007-05-05 18:45:25.0
> +0200
> +++ linux-2.6.21-mm1/fs/unionfs/super.c 2007-05-05 18:46:03.0
> +0200
> @@ -819,8 +819,7 @@
> {
> struct unionfs_inode_info *i = v;
>
> - if ((flags & (SLAB_CTOR_VERIFY | SLAB_CTOR_CONSTRUCTOR)) ==
> - SLAB_CTOR_CONSTRUCTOR)
> + if (flags & SLAB_CTOR_CONSTRUCTOR)
> inode_init_once(>vfs_inode);
> }
Bah, that was hidden from my allmodconfig because CONFIG_UNIONFS is inexplicably
dependent upon CONFIG_SLAB.
How come?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [Kernel-discuss] Re: [PATCH 3/8] Universal power supply class (was: battery class)
On May 5 2007 15:39, pHilipp Zabel wrote:
>> > > > +enum power_supply_type {
>> > > > + POWER_SUPPLY_TYPE_BATTERY = 0,
>> > > > + POWER_SUPPLY_TYPE_UPS,
>> > > > + POWER_SUPPLY_TYPE_AC,
>> > > > + POWER_SUPPLY_TYPE_USB,
>> > > > +};
>> > >
>> > > How about dumb (non-USB) DC power? Any reason to distinguish it
>> > > from AC?
>> >
>> > Hmm, if it should not be distinguished, it is better to rename
>> > AC to something that means continuous power. But I'd rather
>> > have it AC and DC, as something might have both supplies
>> > separate, and you might want to differentiate them for some
>> > (human interface) reason. After all, USB and DC are not really
>> > different anyway...
>> >
>> > Anyway, what IS the difference between UPS and battery, or UPS
>> > and AC/DC for that matter? When should UPS be used? If you
>> > have UPS there, should not MGG (motor-generator group) also be
>> > provided?
Sorry for jumping in late... there is basically no way to know whether
you are on AC or DC, unless you have a *really smart* power supply.
Embedded or near-embedded devices usually have a "12V DC" connector on
the mainboard. "Home" use usually requires a small PSU as are common for
laptops to transform from 230V to whatever is needed. So the mainboard
technically is always on 12VDC (what could be called "DC"), even if you
power it up with using the 230VAC->12VDC PSU (what people call "AC").
Jan
--
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 14/22] pollfs: pollable futex
On Fri, 4 May 2007, Ulrich Drepper wrote: > On 5/4/07, Davide Libenzi <[EMAIL PROTECTED]> wrote: > > This is a pretty specific case, that is not very typical to find in the > > usual common event loop dispatch application design. > > This is where you are very wrong. Yes, it's rare in the Unix world > because non-trivial programs cannot implement this in most cases with > the available infrastructure. But it is very common in other places > and what is more, it makes a lot of sense. It gives you scalability > with the size of the machines at no cost associated to reorganizing > the program. But we have our own *sane* version of WaitForMultipleObjects, and it's called poll(2). > > And if you *really* want your truly generic WaitForMultipleObjects > > implementation, your only way is to base it on files. Files are our almost > > perfect match to HANDLEs in our world. We have the basic infrastructure > > already there. > > "basic", but not complete. And I never said that the implementation > thye have is perfect, far from it. The concept is good and if we now > can implement it, with all the event sources available, using an > efficient event delivery mechanism we are far ahead of their design. > > The proposal now on the table doesn't bring us there all the way and > it has the potential to make future work in the area of event delivery > harder just because there is more legacy code to be kept happy. This > is why I propose to not consider these changes and instead go for the > gold, i.e., the full solution. So, on one side we have a proposal made by a set of new modular objects that fits our own infrastructure (internal - kernel, and external - POSIX) and that are not bound to a specific interface. On the other side we have a completely new, monolitic interface, whose objects are strictly bound to it and are not usable if not only inside the interface itself. Now, considering that POSIX is the backbone of Linux (and *nix in general), and considering that we certainly cannot drop existing POSIX semantics, where the lagacy code will come from? I really do not understand your point. You're too smart to not appreciate the beauty and the simmetry of objects that responds to a common interface (our files, win32 handles), and that fits our existing kernel infrastructure. - Davide - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.21-mm1
On Sat, 05 May 2007 17:48:28 +0200 Maciej Rutecki <[EMAIL PROTECTED]> wrote:
> Andrew Morton pisze:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21/2.6.21-mm1/
> >
> >
>
> CC [M] lib/zlib_deflate/deflate_syms.o
> LD [M] lib/zlib_deflate/zlib_deflate.o
> Building modules, stage 2.
> MODPOST 791 modules
> ERROR: "ssb_pcihost_register" [drivers/net/b44.ko] undefined!
> ERROR: "ssb_pcihost_unregister" [drivers/net/b44.ko] undefined!
> make[2]: *** [__modpost] Error 1
> make[1]: *** [modules] Error 2
> make[1]: Leaving directory `/usr/src/linux-mm'
> make: *** [debian/stamp-build-kernel] Error 2
>
> Config:
> http://www.unixy.pl/maciek/download/kernel/2.6.21-mm1/config-2.6.21-mm1.gz
>
OK, thanks. I assume that's a Kconfig mistake in the wireless tree.
But it looks like a real minefield:
+static inline void b44_pci_exit(void)
+{
+#ifdef CONFIG_B44_PCI
+ ssb_pcihost_unregister(_pci_driver);
+#endif
+}
and
+#ifdef CONFIG_BCM43XX_MAC80211_PCI
+ ssb_pcihost_unregister(_pci_driver);
+#endif
and
+#ifdef CONFIG_SSB_PCIHOST
+/* PCI-host wrapper driver */
+extern int ssb_pcihost_register(struct pci_driver *driver);
+static inline void ssb_pcihost_unregister(struct pci_driver *driver)
+{
+ pci_unregister_driver(driver);
+}
+#endif /* CONFIG_SSB_PCIHOST */
That looks waay more complicated than it needs to be.
I'm thinking that the first two ifdefs should be removed and that third one
needs a #else clause which implements stubs and that b44 Kconfig needs to
be taught about CONFIG_SSB_PCIHOST in some fashion.
Or something like that.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [linux-dvb] DST/BT878 module customization (.. was: Critical points about ...)
Hello Mauro, Mauro Carvalho Chehab wrote: > Hi Manu, > > Em Qui, 2007-05-03 às 23:03 +0400, Manu Abraham escreveu: >> Mauro Carvalho Chehab wrote: >>> Enough. Let's stop arguing non technical issues. >>> >>> If either one of you have any technical argue against the Trent's >>> patches, please point where the fix is wrong. Otherwise, if you wish, >>> you may send an acked-by agreeing with the fix. >>> >> Why don't you stop this childish behaviour ? > > I just want to solve the current issue, and decide the proper way for Trent's > fixes. > > I consider you a very skilled programmer. Unfortunately, it seems that > you're not interested anymore on submitting kernel patches, since your > last contribution, as an author, were back on Aug, 8, 2006: hmm .. multiple Caps "I 's" .. anyway. >From my side, quite some time has been put forward to write that mail. Inspite of that if you feel that you do have to go your own way, then it is completely upto you. I would say: do as you feel in such a case. In such a case are you willing to fix all the issues/requests that surface ? Really do you want me to explain those issues in this thread ? I would say, think over it yourself, why that huge gap occurred. Take some time off all this, think on a cool mind. > > commit bbdd11fa957913d6648cabbca59be1da479180ed > Author: Manu Abraham <[EMAIL PROTECTED]> > Date: Tue Aug 8 15:48:08 2006 -0300 > > V4L/DVB (4432): Fix Circular dependencies > > Signed-off-by: Manu Abraham <[EMAIL PROTECTED]> > Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> > > It would be a pleasure to have you contributing again. However, we need to > fix the pointed issues. I do have a written another mail with regards to the issues that do prevail on the "discussions thread" > > Also, considering that: > > 1) the Trent patches addressing the issues exists since august, 2006; > > 2) nobody pointed any troubles at the current approach; > Surely there was a long mail from my side. I don't know whether you missed that mail, but surely you should read it again. > 3) the patch does provide a proper fix for module removal, working well on > both hardwares with and without DST; > Other than what i wrote earlier: DST is not for just one device alone (It is really a combo driver), AFAICS there are ~15 -20 main devices, for which there are additional 5 - 6 clone manufacturers. So eventually there are around 80 different cards at least. So, in fact there are a large number of cards that do exist rather than the one card that i have sent you, some time back. The non dst cards supported by dvb-bt8xx are just 3 or 4 cards, IIRC. > 4) I'm responsible for reviewing and forwarding patches for /drivers/media > stuff; > > I think there's no reason for me to not forward the proper fixes to > mainstream. > >From what i know, you do need an ACK from the relevant maintainer too. Did the concept of dvb-maintainers change without any of the DVB developers knowing ? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: cpufreq longhaul locks up
On May 5 2007 19:48, Rafał Bilski wrote: > >I found one line which wasn't were it should be. Probably this will not >fix Your problem with powersave governor, but it is a bit related. >Looks like Longhaul isn't skipping frequency transtition when it is asked >to set f which is already set. Now after first transition it will not >try to set same frequency again. Second part contains some magic >because I don't have CN400 datasheet. It is NDA protected :-( Should >print You one byte in hex and will try to set one register. I don't >know if anything will change but it is worth testing. Did not help unfortunately. The output the printk line generated was longhaul: 0x0 (Strangely enough, %#02x with glibc outputs "00", not "0x0". And I would have expected "0x00". Subtleties of the kernel printk/glibc?) Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
