Re: [PATCH] Fix posix-cpu-timer breakage caused by stale p->last_ran value
On Thu, 2007-02-22 at 08:46 +0100, Ingo Molnar wrote:
> * Thomas Gleixner <[EMAIL PROTECTED]> wrote:
>
> > The problem is that the p->last_ran value is not updated after a
> > context switch. So a subsequent call to current_sched_time()
> > calculates with a stale p->last_ran value, i.e. accounts the full
> > time, which the task was scheduled away.
> >
> > Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
>
> > sched_info_switch(prev, next);
> > if (likely(prev != next)) {
> > - next->timestamp = now;
> > + next->timestamp = next->last_ran = now;
>
> ouch! nice catch. Also for v2.6.20.2 i think. 2.6.19 should be
> unaffected.
Yes, was introduced in 2.6.20 and definitely should hit the stable tree.
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: dirty balancing deadlock
> On Thu, 22 Feb 2007 08:42:26 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > > > > Index: linux/mm/page-writeback.c > > > === > > > --- linux.orig/mm/page-writeback.c2007-02-19 17:32:41.0 > > > +0100 > > > +++ linux/mm/page-writeback.c 2007-02-19 18:05:28.0 +0100 > > > @@ -198,6 +198,25 @@ static void balance_dirty_pages(struct a > > > dirty_thresh) > > > break; > > > > > > + /* > > > + * Acquit this producer if there's little or nothing > > > + * to write back to this particular queue > > > + * > > > + * Without this check a deadlock is possible in the > > > + * following case: > > > + * > > > + * - filesystem A writes data through filesystem B > > > + * - filesystem A has dirty pages over dirty_thresh > > > + * - writeback is started, this triggers a write in B > > > + * - balance_dirty_pages() is called synchronously > > > + * - the write to B blocks > > > + * - the writeback completes, but dirty is still over threshold > > > + * - the blocking write prevents futher writes from happening > > > + */ > > > + if (atomic_long_read(&bdi->nr_dirty) + > > > + atomic_long_read(&bdi->nr_writeback) < 16) > > > + break; > > > + > > > > The problem seems to that little "- the write to B blocks". > > > > How come it blocks? I mean, if we cannot retire writes to that filesystem > > then we're screwed anyway. > > Sorry about the sloppy description. I mean, it's not the lowlevel > write that will block, but rather the VFS one > (generic_file_aio_write). It will block (or rather loop forever with > 0.1 second sleeps) in balance_dirty_pages(). That means, that for > this inode, i_mutex is held and no other writer can continue the work. "this inode" I assume is the inode against filesystem A? Why does holding that inode's i_mutex prevent further writeback of pages in A? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 posix-cpu-timer breakage caused by stale p->last_ran value
* Thomas Gleixner <[EMAIL PROTECTED]> wrote:
> The problem is that the p->last_ran value is not updated after a
> context switch. So a subsequent call to current_sched_time()
> calculates with a stale p->last_ran value, i.e. accounts the full
> time, which the task was scheduled away.
>
> Signed-off-by: Thomas Gleixner <[EMAIL PROTECTED]>
> sched_info_switch(prev, next);
> if (likely(prev != next)) {
> - next->timestamp = now;
> + next->timestamp = next->last_ran = now;
ouch! nice catch. Also for v2.6.20.2 i think. 2.6.19 should be
unaffected.
Acked-by: Ingo Molnar <[EMAIL PROTECTED]>
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] update ctime and mtime for mmaped write
> On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > > > This patch makes writing to shared memory mappings update st_ctime and > > st_mtime as defined by SUSv3: > > > >The st_ctime and st_mtime fields of a file that is mapped with > >MAP_SHARED and PROT_WRITE shall be marked for update at some point > >in the interval between a write reference to the mapped region and > >the next call to msync() with MS_ASYNC or MS_SYNC for that portion > >of the file by any process. If there is no such call and if the > >underlying file is modified as a result of a write reference, then > >these fields shall be marked for update at some time after the > >write reference. > > > > A new address_space flag is introduced: AS_CMTIME. This is set each > > time a page is dirtied through a userspace memory mapping. This > > includes write accesses via get_user_pages(). > > > > Note, the flag is set unconditionally, even if the page is already > > dirty. This is important, because the page might have been dirtied > > earlier by a non-mmap write. > > > > This flag is checked in msync() and __fput(), and if set, the file > > times are updated and the flag is cleared > > > > The flag is also cleared, if the time update is triggered by a normal > > write. This is not mandated by the standard, but seems to be a sane > > thing to do. > > Why is the flag checked in __fput()? It's because of this bit in the standard: If there is no such call and if the underlying file is modified as a result of a write reference, then these fields shall be marked for update at some time after the write reference. It could be done in munmap/mremap, but it seemed more difficult to track down all the places where the vma is removed. But yes, that may be a nicer solution. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 00/13] Syslets, "Threadlets", generic AIO support, v3
* Ulrich Drepper <[EMAIL PROTECTED]> wrote: > Ingo Molnar wrote: > > in terms of AIO, the best queueing model is i think what the kernel uses > > internally: freely ordered, with barrier support. > > Speaking of AIO, how do you imagine lio_listio is implemented? If > there is no asynchronous syscall it would mean creating a threadlet > for each request but this means either waiting or creating > several/many threads. my current thinking is that special-purpose (non-programmable, static) APIs like aio_*() and lio_*(), where every last cycle of performance matters, should be implemented using syslets - even if it is quite tricky to write syslets (which they no doubt are - just compare the size of syslet-test.c to threadlet-test.c). So i'd move syslets into the same category as raw syscalls: pieces of the raw infrastructure between the kernel and glibc, not an exposed API to apps. [and even if we keep them in that category they still need quite a bit of API work, to clean up the 32/64-bit issues, etc.] The size of the async thread pool can be kept in check either from user-space (by starting to queue up requests after a certain point of saturation without submitting them) or from kernel-space which involves waiting (the latter was present in v2 but i temporarily removed it from v3). "You have to wait" is the eventual final answer in every well-behaved queueing system anyway. How things work out with a large number of outstanding threads in real apps is still an open question (until someone tries it) but i'm cautiously optimistic: in my own (FIO based) measurements syslets beat the native KAIO interfaces both in the cached and in the non-cached [== many threads] case. I did not expect the latter at all: the non-cached syslet codepath is not optimized at all yet, so i expected it to have (much) higher CPU overhead than KAIO. This means that KAIO is in worse shape than i thought - there's just way too much context KAIO has to build up to submit parallel IO contexts. Many years of optimizations went into KAIO already, so it's probably at its outer edge of performance capabilities. Furthermore, what KAIO has to compete against in the syslet case are the synchronous syscalls turned async, and more than a decade of optimizations went into all the synchronous syscalls. Plus the 'threading overhead of syslets' really boils down to 'scheduling overhead' in the end - and we can do over a million context-switches a second, per CPU. What killed user-space thread-based AIO performance many moons ago wasnt really the threading concept itself or scheduling overhead, it was the (then) fragile threading implementation of Linux, combined with the resulting signal-based AIO code. Catching and handling a single signal is more expensive than a context-switch - and signals have legacies attached to them that make them hard to scale within the kernel. Plus with syslets the 'threading overhead' is optional, it only happens when it has to. Plus there's the fundamental killer that KAIO is a /lot/ harder to implement (and to maintain) on the kernel side: it has to be implemented for every IO discipline, and even for the IO disciplines it supports at the moment, it is not truly asynchronous for things like metadata blocking or VFS blocking. To handle things like metadata blocking it has to resort to non-statemachine techniques like retries - which are bad for performance. Syslets/threadlets on the other hand, once the core is implemented, have near zero ongoing maintainance cost (compared to KAIO pushed into every IO subsystem) and cover all IO disciplines and API variants immediately, and they are as perfectly asynchronous as it gets. So all in one, i used to think that AIO state-machines have a long-term place within the kernel, but with syslets i think i've proven myself embarrasingly wrong =B-) Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: dirty balancing deadlock
> > How about this? > > I still don't understand this bug. > > > Solves the FUSE deadlock, but not the throttle_vm_writeout() one. > > I'll try to tackle that one as well. > > > > If the per-bdi dirty counter goes below 16, balance_dirty_pages() > > returns. > > > > Does the constant need to tunable? If it's too large, then the global > > threshold is more easily exceeded. If it's too small, then in a tight > > situation progress will be slower. > > > > Thanks, > > Miklos > > > > Index: linux/mm/page-writeback.c > > === > > --- linux.orig/mm/page-writeback.c 2007-02-19 17:32:41.0 +0100 > > +++ linux/mm/page-writeback.c 2007-02-19 18:05:28.0 +0100 > > @@ -198,6 +198,25 @@ static void balance_dirty_pages(struct a > > dirty_thresh) > > break; > > > > + /* > > +* Acquit this producer if there's little or nothing > > +* to write back to this particular queue > > +* > > +* Without this check a deadlock is possible in the > > +* following case: > > +* > > +* - filesystem A writes data through filesystem B > > +* - filesystem A has dirty pages over dirty_thresh > > +* - writeback is started, this triggers a write in B > > +* - balance_dirty_pages() is called synchronously > > +* - the write to B blocks > > +* - the writeback completes, but dirty is still over threshold > > +* - the blocking write prevents futher writes from happening > > +*/ > > + if (atomic_long_read(&bdi->nr_dirty) + > > + atomic_long_read(&bdi->nr_writeback) < 16) > > + break; > > + > > The problem seems to that little "- the write to B blocks". > > How come it blocks? I mean, if we cannot retire writes to that filesystem > then we're screwed anyway. Sorry about the sloppy description. I mean, it's not the lowlevel write that will block, but rather the VFS one (generic_file_aio_write). It will block (or rather loop forever with 0.1 second sleeps) in balance_dirty_pages(). That means, that for this inode, i_mutex is held and no other writer can continue the work. Miklos - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-usb-devel] 2.6.20 kernel hang with USB drive and vfat doing ftruncate
On Feb 21, 2007, at 3:31 PM, Andrew Morton wrote: On Wed, 21 Feb 2007 16:22:17 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: On Wed, 21 Feb 2007, Andrew Morton wrote: It seems like usb-storage and aio are completely off in the weeds. Ideas? It seems usb-storage should remove some kmalloc and use mempool () for urb... Is someone working on this? And idea? I think Pete said that we're supposed to be using GFP_NOIO in there. We _are_ using it. How admirably prompt. Not that it'll help much: the VM calls throttle_vm_writeout() for GFP_NOIO and GFP_NOFS allocations, which is a bug. Because if the caller holds locks which prevent filesystem or IO progress, we deadlock. I'll fix the VM if someone else fixes USB ;) What else needs to be fixed? Would be nice if someone can confirm that this fixes it: Doesn't seem to help my problem in a quick test, will get more data in the morning. - k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial related oops
On Wed, Feb 21, 2007 at 09:57:50PM -0800, H. Peter Anvin wrote: > Russell King wrote: > > >Plainly, %ebx changed across the call to serial_in() at c01c0f7b. > >First thing to notice is this violates the C code - "up" can not > >change. > >Now let's look at serial_in: > >c01bfa70: 55 push %ebp > >c01bfa71: 89 e5 mov%esp,%ebp > >c01bfa73: 53 push %ebx > >... > >c01bfab7: 5b pop%ebx > >c01bfab8: 5d pop%ebp > >c01bfab9: c3 ret > >This code tells the CPU to preserves %ebx and %ebp. But we know %ebx > >_wasn't_ preserved. Ergo, your CPU is plainly not doing what the code > >told it to do. > > ... assuming nothing else clobbered the stack slot (which would be a compiler > error, or a wild pointer.) > > Got a disassembly of the whole function? > Jose posted it higher in the thread: http://lkml.org/lkml/2007/2/21/139 Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] ecryptfs remove unnecessary flush_dcache_page
Dmitriy Monakhov <[EMAIL PROTECTED]> writes: > 1)Function ecryptfs_do_readpage() calls flush_dcache_page(lower_page), > but lower_page was't changed here. So remove this line. > > 2)prepare_write ret val was ignored in ecryptfs_write_inode_size_to_header(). > If error happends we can't call commit_write, just do cleanup and fial. > It is issue easy to reproduce with full lower_fs, in this case prepare_write() Second issue was fixed by "ecryptfs-resolve-lower-page-unlocking-problem.patch", but first issue was't. [LOG] Function ecryptfs_do_readpage() calls flush_dcache_page(lower_page), but lower_page was't changed here. Even if it was changed by lower_a_ops->readpage() dcache was flushed by readpage() itself. So remove this unnecessary line. Signed-off-by: Dmitriy Monakhov <[EMAIL PROTECTED]> diff --git a/fs/ecryptfs/mmap.c b/fs/ecryptfs/mmap.c index 1e5d2ba..2e45513 100644 --- a/fs/ecryptfs/mmap.c +++ b/fs/ecryptfs/mmap.c @@ -238,7 +238,6 @@ int ecryptfs_do_readpage(struct file *file, struct page *page, lower_page_data = kmap_atomic(lower_page, KM_USER1); memcpy(page_data, lower_page_data, PAGE_CACHE_SIZE); kunmap_atomic(lower_page_data, KM_USER1); - flush_dcache_page(lower_page); kunmap_atomic(page_data, KM_USER0); flush_dcache_page(page); rc = 0;
[PATCH] Speedup divides by cpu_power in scheduler
I noticed expensive divides done in try_to_wakeup() and find_busiest_group()
on a bi dual core Opteron machine (total of 4 cores), moderatly loaded (15.000
context switch per second)
oprofile numbers :
CPU: AMD64 processors, speed 2600.05 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Cycles outside of halt state) with a unit
mask of 0x00 (No unit mask) count 5
samples %symbol name
...
6139141.0498 try_to_wake_up
834 0.0013 :80227ae1: div%rcx
77513 0.1191 :80227ae4: mov%rax,%r11
6088931.0413 find_busiest_group
1841 0.0031 :802260bf: div%rdi
140109 0.2394 :802260c2: test %sil,%sil
Some of these divides can use the reciprocal divides we introduced some time
ago (currently used in slab AFAIK)
We can assume a load will fit in a 32bits number, because with a
SCHED_LOAD_SCALE=128 value, its still a theorical limit of 33554432
When/if we reach this limit one day, probably cpus will have a fast hardware
divide and we can zap the reciprocal divide trick.
I did not convert the divide in cpu_avg_load_per_task(), because tracking
nr_running changes may be not worth it ? We could use a static table of 32
reciprocal values but it would add a conditional branch and table lookup.
Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>
--- linux-2.6.21-rc1/include/linux/sched.h 2007-02-21 21:08:32.0
+0100
+++ linux-2.6.21-rc1-ed/include/linux/sched.h 2007-02-22 08:53:26.0
+0100
@@ -669,7 +669,12 @@ struct sched_group {
* CPU power of this group, SCHED_LOAD_SCALE being max power for a
* single CPU. This is read only (except for setup, hotplug CPU).
*/
- unsigned long cpu_power;
+ unsigned int cpu_power;
+ /*
+* reciprocal value of cpu_power to avoid expensive divides
+* (see include/linux/reciprocal_div.h)
+*/
+ u32 reciprocal_cpu_power;
};
struct sched_domain {
--- linux-2.6.21-rc1/kernel/sched.c.orig2007-02-21 21:10:54.0
+0100
+++ linux-2.6.21-rc1-ed/kernel/sched.c 2007-02-22 08:46:56.0 +0100
@@ -52,6 +52,7 @@
#include
#include
#include
+#include
#include
#include
@@ -182,6 +183,26 @@ static unsigned int static_prio_timeslic
}
/*
+ * Divide a load by a sched group cpu_power : (load / sg->cpu_power)
+ * Since cpu_power is a 'constant', we can use a reciprocal divide.
+ */
+static inline u32 sg_div_cpu_power(const struct sched_group *sg, u32 load)
+{
+ return reciprocal_divide(load, sg->reciprocal_cpu_power);
+}
+/*
+ * Each time a sched group cpu_power is changed,
+ * we must compute its reciprocal value
+ */
+static inline void sg_inc_cpu_power(struct sched_group *sg, u32 val)
+{
+ sg->cpu_power += val;
+ BUG_ON(sg->cpu_power == 0);
+ sg->reciprocal_cpu_power = reciprocal_value(sg->cpu_power);
+}
+
+
+/*
* task_timeslice() scales user-nice values [ -20 ... 0 ... 19 ]
* to time slice values: [800ms ... 100ms ... 5ms]
*
@@ -1241,7 +1262,8 @@ find_idlest_group(struct sched_domain *s
}
/* Adjust by relative CPU power of the group */
- avg_load = (avg_load * SCHED_LOAD_SCALE) / group->cpu_power;
+ avg_load = sg_div_cpu_power(group,
+ avg_load * SCHED_LOAD_SCALE);
if (local_group) {
this_load = avg_load;
@@ -2355,7 +2377,8 @@ find_busiest_group(struct sched_domain *
total_pwr += group->cpu_power;
/* Adjust by relative CPU power of the group */
- avg_load = (avg_load * SCHED_LOAD_SCALE) / group->cpu_power;
+ avg_load = sg_div_cpu_power(group,
+ avg_load * SCHED_LOAD_SCALE);
group_capacity = group->cpu_power / SCHED_LOAD_SCALE;
@@ -2510,8 +2533,8 @@ small_imbalance:
pwr_now /= SCHED_LOAD_SCALE;
/* Amount of load we'd subtract */
- tmp = busiest_load_per_task * SCHED_LOAD_SCALE /
- busiest->cpu_power;
+ tmp = sg_div_cpu_power(busiest,
+ busiest_load_per_task * SCHED_LOAD_SCALE);
if (max_load > tmp)
pwr_move += busiest->cpu_power *
min(busiest_load_per_task, max_load - tmp);
@@ -2519,10 +2542,11 @@ small_imbalance:
/* Amount of load we'd add */
if (max_load * busiest->cpu_power <
busiest_load_per_task * SCHED_LOAD_SCALE)
- tmp = max_load * busiest->cpu_power / this->cpu_power;
+ tmp = sg_div_cpu_power(this,
+ max_load * busiest->cpu_power);
else
- tmp = busiest_load_per_task * SCHED_LOAD_SCALE /
- this->cpu_power;
+
Re: [PATCH] EXPORT_SYMBOL() time functions
Christoph Hellwig wrote: > On Wed, Feb 21, 2007 at 02:13:38PM +0100, Rolf Eike Beer wrote: > > These functions were inlines before > > 8b9365d753d9870bb6451504c13570b81923228f. Now EXPORT_SYMBOL() them to > > allow them to be used in modules again. > > Just because they happened to be inlined that doesn't mean modules should > be using them. In fact no intree module uses them exactly because they're > not intended to be used by this kind of code. Please show the code you > want to use this for so we can see what you're really trying to do. Trying to convert a given user value (in milliseconds) to a timeout. No problem doing this with struct timespec. Eike pgpzZU2hCFZ61.pgp Description: PGP signature
Re: Weird hard disk noise on shutdown (bug #7674)
Robert Hancock wrote: > Robert Hancock wrote: >> Alan wrote: >>> Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or >>> turn on all the ATA debug and shutdown, the code should issue a cache >>> flush followed by a standbynow1 command for each disk. >>> >>> Alan >> >> I believe it runs on suspend, but we don't run that code on normal >> shutdown, do we? >> >> Tejun Heo had a patch for sd that could (optionally) trigger a START >> STOP UNIT command to spin the disk down after synchronizing the cache >> before shutdown, but I haven't heard anything of it lately.. I just came back from LSF and lunar new year's holidays and need a bit more time to get to it. I'll get to it in one or two weeks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sata_nv: complain on spurious completion notifiers
Robert Hancock wrote: > Recently Tejun wrote a patch to ahci.c to make it raise a HSM violation > if the drive attempted to complete a tag that wasn't outstanding. We could > run into the same problem with sata_nv ADMA. This adds code to raise a HSM > violation error if the controller gives us a notifier tag that isn't > outstanding, since the drive may be issuing spurious completions. > > Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> Acked-by: Tejun Heo <[EMAIL PROTECTED]> -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
* Michael K. Edwards <[EMAIL PROTECTED]> wrote: > [...] Unless you essentially lock one application thread to each CPU > core, with a complete understanding of its cache sharing and latency > relationships to all the other cores, and do your own userspace I/O > scheduling and dispatching state machine -- which is what all > industrial-strength databases and other sorts of transaction engines > currently do -- you get the same old best-effort context-thrashing > scheduler we've had since Solaris 2.0. the syslet/threadlet framework has been derived from Tux, which one can accuse of may things, but which i definitely can not accuse of being slow. It has no relationship whatsoever to Solaris 2.0 or later. Your other mail showed that you have very basic misunderstandings about how threadlets work, on which you based a string of firm but incorrect conclusions. In this discussion i'm mostly interested in specific feedback about syslets/threadlets - thankfully we are past the years of "unless Linux does generic technique X it will stay a hobby OS forever" type of time-wasting discussions. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
SLUB: The unqueued Slab allocator
This is a new slab allocator which was motivated by the complexity of the existing code in mm/slab.c. It attempts to address a variety of concerns with the existing implementation. A. Management of object queues A particular concern was the complex management of the numerous object queues in SLAB. SLUB has no such queues. Instead we dedicate a slab for each cpus allocating and use a slab directly instead of objects from queues. B. Storage overhead of object queues SLAB Object queues exist per node, per cpu. The alien cache queue even has a queue array that contain a queue for each processor on each node. For very large systems the number of queues and the number of objects that may be caught in those queues grows exponentially. On our systems with 1k nodes / processors we have several gigabytes just tied up for storing references to objects for those queues This does not include the objects that could be on those queues. One fears that the whole memory of the machine could one day be consumed by those queues. C. SLAB metadata overhead SLAB has overhead at the beginning of each slab. This means that data cannot be naturally aligned at the beginning of a slab block. SLUB keeps all metadata in the corresponding page_struct. Objects can be naturally aligned in the slab. F.e. a 128 byte object will be aligned at 128 byte boundaries and can fit tightly into a 4k page with no bytes left over. SLAB cannot do this. D. SLAB has a complex cache reaper SLUB does not need a cache reaper for UP systems. On SMP systems the per cpu slab may be pushed back into partial list but that operation is simple and does not require an iteration over a list of objects. SLAB expires per cpu, shared and alien object queues during cache reaping which may cause strange holdoffs. E. SLAB's has a complex NUMA policy layer support. SLUB pushes NUMA policy handling into the page allocator. This means that allocation is coarser (SLUB does interleave on a page level) but that situation was also present before 2.6.13. SLABs application of policies to individual slab objects allocated in SLAB is certainly a performance concern due to the frequent references to memory policies which may lead a sequence of objects to come from one node after another. SLUB will get a slab full of objects from one node and then will switch to the next. F. Reduction of the size of partial slab lists SLAB has per node partial lists. This means that over time a large number of partial slabs may accumulate on those lists. These can only be reused if allocator occur on specific nodes. SLUB has a global pool of partial slabs and will consume slabs from that pool to decrease fragmentation. G. Tunables SLAB has sophisticated tuning abilities for each slab cache. One can manipulate the queue sizes in detail. However, filling the queues still requires the uses of the spinlock to check out slabs. SLUB has a global parameter (min_slab_order) for tuning. Increasing the minimum slab order can decrease the locking overhead. The bigger the slab order the less motions of pages between per cpu and partial lists occur and the better SLUB will be scaling. G. Slab merging We often have slab caches with similar parameters. SLUB detects those on bootup and merges them into the corresponding general caches. This leads to more effective memory use. The patch here is only the core portion. There are various add-ons that may become ready later when this one has matured a bit. SLUB should be fine for UP and SMP. No NUMA optimizations have been done so far so it works but it does not scale to the high processor and node numbers yet. To use SLUB: Apply this patch and then select SLUB as the default slab allocator. The output of /proc/slabinfo will then change. Here is a sample (this is an UP/SMP format. The NUMA display will show on which nodes the slabs were allocated): slubinfo - version: 1.0 # name // radix_tree_node 5574 0 560 797/0/1CP bdev_cache 5 0 7682/1/1 CSrPa sysfs_dir_cache 5946 0 80 117/0/1 inode_cache 2690 0 536 386/3/1 CSrP dentry_cache7735 0 192 369/1/1 SrP idr_layer_cache 79 0 536 12/0/1 C buffer_head 5427 0 112 151/0/1 CSrP mm_struct 37 1 8326/5/1Pa vm_area_struct 1734 0 168 73/3/1 P files_cache 37 0 6408/6/1Pa signal_cache 63 0 640 12/4/1Pa sighand_cache 63 22112 11/4/1 CRPa task_struct 75 21728 11/6/1 P anon_vma 590 0 244/3/1 CRP kmalloc-192 424 0 192 21/0/1 kmalloc-96 1150 0 96 28/3/1 kmalloc-262144
Re: [PATCH] ACPI driver support for pata
Robert Hancock wrote: Alan wrote: - Add a driver for motherboard ACPI method devices - Link it after normal drivers so ACPI is not preferred - Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is active - While we are at it fix up the simplex clear the AMD driver. Depends upon the set_mode -> do_set_mode wrapper patch Signed-off-by: Alan Cox <[EMAIL PROTECTED]> I tried out 2.6.21-rc1 with the pata_acpi patch. First off, when you enable pata_acpi, it appears that the Fedora mkinitrd stuff decides that that should be loaded as the first driver. On boot it promptly attempts to attach to all of the ATA controllers, including the nForce SATA controllers, which somehow it fails to actually drive causing a failure to mount the root filesystem. I got around that by blacklisting pata_acpi in /etc/modprobe.conf before installing the kernel and un-blacklisting it afterwards, so it wouldn't make the initrd try and load it, but there must be a better solution. It does seem to drive the PATA controllers, but the cable detection doesn't seem to be working: scsi5 : pata_acpi ata5.00: ATAPI, max UDMA/66 ata5.00: limited to UDMA/33 due to 40-wire cable ata5.00: configured for UDMA/33 Honestly I don't think pata_acpi is the best way to go. Unless we know /nothing/ about the controller (not true, in sata_nv case), I think it would be better to initiate ACPI actions from specific drivers, rather than forcing the user to switch from pata_amd to pata_acpi. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: add NCQ blacklist entries from Silicon Image Windows driver
Robert Hancock wrote:
This patch adds in some NCQ blacklist entries taken from the Silicon
Image Windows drivers' .inf files for the 3124 and 3132 controllers.
These entries were marked as ""DisableSataQueueing". Assume these are
in their blacklist for a reason and disable NCQ on these drives.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.21-rc1edit/drivers/ata/libata-core.c.prev2007-02-21
22:23:05.0 -0600
+++ linux-2.6.21-rc1edit/drivers/ata/libata-core.c2007-02-21
22:25:44.0 -0600
@@ -3269,6 +3269,13 @@ static const struct ata_blacklist_entry
/* Devices with NCQ limits */
+/* The following blacklist entries are taken from the Windows
+ driver .inf files for the Silicon Image 3124 and 3132. */
+{ "Maxtor 7B250S0","BANC1B70",ATA_HORKAGE_NONCQ, },
+{ "HTS541060G9SA00","MB3OC60D",ATA_HORKAGE_NONCQ, },
+{ "HTS541080G9SA00","MB4OC60D",ATA_HORKAGE_NONCQ, },
+{ "HTS541010G9SA00","MBZOC60D",ATA_HORKAGE_NONCQ, },
Do we have information that these drives fail on non-SiI controllers?
Sometimes the problem can be related to a single family of controllers.
Jeff
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
* Michael K. Edwards <[EMAIL PROTECTED]> wrote: > [...] As for threadlets, making them kernel threads is not such a good > design feature, O(1) scheduler or not. You take the full hit of > kernel task creation, on the spot, for every threadlet that blocks. > [...] this is very much not how they work. Threadlets share the same basic infrastructure with syslets and they do /not/ take a 'full hit of kernel thread creation' when they block. Please read the announcements, past discussions on lkml and the code about how it works. about your other point: > > threadlets, when they block, are regular kernel threads, so the > > regular O(1) scheduler takes care of them. If MMU trashing is of any > > concern then syslets should be used to implement the most > > performance-critical events: under Linux a kernel thread that does > > not exit out to user-space does not do any TLB switching at all. > > (even if there are multiple processes active and their syslets > > intermix) > > As far as I am concerned syslets by themselves are a dead letter, > because you can't do any of the things that potential application > coders need to do with them. [...] syslets are not meant to be directly exposed to application coders. Syslets (like many of my previous mails stated) are meant as building blocks to higher-level AIO interfaces such as in glibc or libaio. Then user-space can build its state-machine based on syslet-implemented glibc/libaio. In that specific role they are a very fast and scalable mechanism. Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Thu, 22 Feb 2007, Pekka Enberg wrote: > I think we can merge krealloc without unionfs. I'll whoop up a new patch as > per Christoph's suggestions. I think at least XFS already has its own realloc > and there might be some other open-coded users. It's not _changing_ the slab > as much as adding new functionality that makes sense fron a general point of > view. I really like the krealloc idea. Could we useful elsewhere to extend objects and it is similar to the realloc() available in glibc. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird hard disk noise on shutdown (bug #7674)
Robert Hancock wrote: Alan wrote: Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or turn on all the ATA debug and shutdown, the code should issue a cache flush followed by a standbynow1 command for each disk. Alan I believe it runs on suspend, but we don't run that code on normal shutdown, do we? Tejun Heo had a patch for sd that could (optionally) trigger a START STOP UNIT command to spin the disk down after synchronizing the cache before shutdown, but I haven't heard anything of it lately.. And yes, this is something we need to deal with. I don't think that disks that use contact start-stop heads care so much, but disks that use load-unload heads (like most laptop drives, it seems) generally quote a much lower cycle lifetime for "emergency unloads" caused by power loss than by normal unloads done while power is still applied. It's important enough that in some cases, like the Compaq X1000-series laptop I have, the BIOS appears to have a power button handler that spins down the drive before power-down when the power button is pressed and an ACPI OS isn't running. (Holding the button down when an ACPI OS is running just forces the power off, then you get the clunk from the drive..) Windows XP (and even as far back as Windows 98) get this right, surely we can do as well :-) -- 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: [-mm patch] UNION_FS must depend on SLAB
On Thu, Feb 22, 2007 at 08:18:39AM +0200, Pekka Enberg wrote: > Pekka Enberg wrote: > >The ksize exports we can add later if unionfs is to be merged. > > Actually, we probably don't need it after the krealloc optimizations. I > think we need a new unionfs patch too... :) I'm for it! Josef "Jeff" Sipek. -- Don't drink and derive. Alcohol and algebra don't mix. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] UNION_FS must depend on SLAB
Pekka Enberg wrote: The ksize exports we can add later if unionfs is to be merged. Actually, we probably don't need it after the krealloc optimizations. I think we need a new unionfs patch too... :) 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: [-mm patch] UNION_FS must depend on SLAB
Hi Andrew, Andrew Morton wrote: Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. I think we can merge krealloc without unionfs. I'll whoop up a new patch as per Christoph's suggestions. I think at least XFS already has its own realloc and there might be some other open-coded users. It's not _changing_ the slab as much as adding new functionality that makes sense fron a general point of view. The ksize exports we can add later if unionfs is to be merged. 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: GPL vs non-GPL device drivers
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote: Actually, on re-reading the GPL, I see exactly why they made that pair of exceptions. Where it's quite evident that a small to mid scale parsers that could have been written *without* the use of Bison is clearly a non-derivative work - Bison was not required, but was used as a mean of expediency. When you reach a large scale parser, such as one that meets all requirements to act as the parser for an ANSI C99 compiler, Bison stops being expedient - it'd likely take just as much time to hand craft the parser as it would to debug the Bison input. However, it makes maintaining the parser easier. I repeat, that is not what "derivative work" means. Do not try to reason about the phrase "derivative work" without reference to its definition in statute and its legal history in appellate decisions. You will get it wrong every time. You have not "recast, transformed, or adapted" the _creative_expression_ in Bison or Flex in the course of using it; so whether or not you have infringed the FSF's copyright, you have NOT created a "derivative work". If Bison and Flex were offered under the "bare" GPL, and you used them to build a parser, and the FSF sued you for offering that parser to other people on terms other than the GPL's, you don't defend by claiming license under the GPL with regard to your parser. You attack the claim of "copying" itself by saying that the _creative_expression_ copied from Bison/Flex into your parser is "de minimis" under the Altai Abstraction-Filtration-Comparison test. You also point out that, even if it weren't "de minimis", it's "fair use"; that's a complex four-factor test, but the main thing is that you're not interfering with the FSF's ability to monetize its copyright in Bison/Flex. If you have any sense, you will strenuously argue that the various "special exceptions" for things like Bison/Flex and GNU Classpath are _not_ part of the offer of contract contained in the GPL, any more than the Preamble is. They're declarations of intent on the part of the copyright holder, and can be used to _estop_ the FSF from making the copyright infringement claim against you in court in the first place. They promised you they wouldn't, not as part of the contract terms, but as part of the inducement to form a contract with them by acceptance through conduct. But the fact is that it's the small to medium scale parsers that have a lower ratio of original to GPL'd code that are at risk of being declared derivative works. All of this because the GPL contains the following text in section 0: "The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." I'm sorry, but that "ratio test" has nothing to do with whether something is a derivative work or not. It comes up mostly in evaluating a "fair use" defense, and it's the ratio of the amount of creative expression _copied_ to the amount of creative expression in the _original_work_ that matters. Just because you're writing a 49-volume encyclopedia does not give you the right to copy two thirds of my one-page essay. Those weasel-words about "depending on what the Program does" are nonsense. It depends on what _creative_expression_ from the Program winds up in the output. That clause, to me, seems specifically tailored to cover programs such as Bison and Flex. (and is the reason that I try to use Byacc and when I need to, write tokenizers by hand) This frankly stinks of attempts to cover all possible code. (I actually started studying Copyright law in my free time because I was wondering how legal the GPL was and was also puzzled by some major online entities actually complaining about it) I've written tokenizers in at least six different languages to date, including Fortran. It's a pain in the butt. The last thing I want to be worrying about when I write a tokenizer is whether somebody else's peanut butter is winding up in my chocolate. So I will only use a tool which, like bison and flex, is accompanied by a promise not to claim that its output infringes the tool author's copyright or is otherwise encumbered in any way. M$ VC++ is actually more trustworthy in that respect than G++. If you don't believe (as I do) that it is arrant nonsense to claim that the use of interface headers or linking of any kind creates a derivative work, then you must believe that any programs compiled with G++ can only be distributed under the terms of the GPL. libstdc++ is GPL, not LGPL. Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. That's kind of silly. I use the GPL for my own from-scratch programs all the time. It's quite a sensible set of terms for source code created as a side effect of a consu
Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)
On Thu, Feb 22, 2007 at 12:34:17PM +0900, YOSHIFUJI Hideaki / ?$B5HF#1QL@ wrote: > In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 11:04:40 +0900 (JST)), > YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> says: > > > In article <[EMAIL PROTECTED]> (at Thu, 22 Feb 2007 04:12:04 +0900), OGAWA > > Hirofumi <[EMAIL PROTECTED]> says: > > > > > YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> writes: > > > > > > > In article <[EMAIL PROTECTED]> (at Tue, 20 Feb 2007 20:53:45 -0800 > > > > (PST)), Linus Torvalds <[EMAIL PROTECTED]> says: > > > > > > > >> But there's a ton of architecture updates (arm, mips, powerpc, x86, > > > >> you > > > >> name it), ACPI updates, and lots of driver work. And just a lot of > > > >> cleanups. > > > > > > > > I cannot boot 2.6.21-rc1; it falls into OOM-Killer. > > > > > > > > Interesting error message I can see is: > > > >request_module: runaway loop modprobe net-pf-1 > > > > > > > > After bisecting, the commit > > > > Driver core: let request_module() send a /sys/modules/kmod/-uevent > > > > (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame. > > > > > > > > Reverting it fixes the issue to me. > > > > > > /sbin/hotplug needs some module, but request_module() call /sbin/hotplug > > > loop? > > > Hm.. does the patch fix the problem? > > > > Yes, it absolutely fixes the issue. > > Several options: > > - To revert the changeset to blame No. > - To apply Ogawa-san's (or other appropriate) patch His patch just avoids the issue, but isn't correct. > - To select UNIX in init/Kconfig:KMOD I like this one, but some people might still want it as a module (I really don't know why, does anyone else???) > I think it would be a good idea to rate-limit frequency of requesing a > single module, anyway. Yes, if we can detect the loop, that would be best. Or, maybe the easiest thing is to just not do the netlink call if it's asking for the network module? :) Any other suggestions or thoughts? thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Serial related oops
Russell King wrote: Plainly, %ebx changed across the call to serial_in() at c01c0f7b. First thing to notice is this violates the C code - "up" can not change. Now let's look at serial_in: c01bfa70: 55 push %ebp c01bfa71: 89 e5 mov%esp,%ebp c01bfa73: 53 push %ebx ... c01bfab7: 5b pop%ebx c01bfab8: 5d pop%ebp c01bfab9: c3 ret This code tells the CPU to preserves %ebx and %ebp. But we know %ebx _wasn't_ preserved. Ergo, your CPU is plainly not doing what the code told it to do. ... assuming nothing else clobbered the stack slot (which would be a compiler error, or a wild pointer.) Got a disassembly of the whole function? -hpa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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] libata: add NCQ blacklist entries from Silicon Image Windows driver
This patch adds in some NCQ blacklist entries taken from the Silicon
Image Windows drivers' .inf files for the 3124 and 3132 controllers.
These entries were marked as ""DisableSataQueueing". Assume these are
in their blacklist for a reason and disable NCQ on these drives.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.21-rc1edit/drivers/ata/libata-core.c.prev 2007-02-21
22:23:05.0 -0600
+++ linux-2.6.21-rc1edit/drivers/ata/libata-core.c 2007-02-21
22:25:44.0 -0600
@@ -3269,6 +3269,13 @@ static const struct ata_blacklist_entry
/* Devices with NCQ limits */
+ /* The following blacklist entries are taken from the Windows
+ driver .inf files for the Silicon Image 3124 and 3132. */
+ { "Maxtor 7B250S0", "BANC1B70", ATA_HORKAGE_NONCQ, },
+ { "HTS541060G9SA00", "MB3OC60D", ATA_HORKAGE_NONCQ, },
+ { "HTS541080G9SA00", "MB4OC60D", ATA_HORKAGE_NONCQ, },
+ { "HTS541010G9SA00", "MBZOC60D", ATA_HORKAGE_NONCQ, },
+
/* End Marker */
{ }
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: complain on spurious completion notifiers
Recently Tejun wrote a patch to ahci.c to make it raise a HSM violation
if the drive attempted to complete a tag that wasn't outstanding. We could
run into the same problem with sata_nv ADMA. This adds code to raise a HSM
violation error if the controller gives us a notifier tag that isn't
outstanding, since the drive may be issuing spurious completions.
Signed-off-by: Robert Hancock <[EMAIL PROTECTED]>
--- linux-2.6.21-rc1edit/drivers/ata/sata_nv.c.prev 2007-02-21
22:17:31.0 -0600
+++ linux-2.6.21-rc1edit/drivers/ata/sata_nv.c 2007-02-21 22:22:14.0
-0600
@@ -740,6 +740,17 @@ static int nv_adma_check_cpb(struct ata_
DPRINTK("Completing qc from tag %d with err_mask
%u\n",cpb_num,
qc->err_mask);
ata_qc_complete(qc);
+ } else {
+ struct ata_eh_info *ehi = &ap->eh_info;
+ /* Notifier bits set without a command may indicate the
drive
+ is misbehaving. Raise host state machine violation
on this
+ condition. */
+ ata_port_printk(ap, KERN_ERR, "notifier for tag %d with no
command?\n",
+ cpb_num);
+ ehi->err_mask |= AC_ERR_HSM;
+ ehi->action |= ATA_EH_SOFTRESET;
+ ata_port_freeze(ap);
+ return 1;
}
}
return 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 18/24] Xen-paravirt_ops: Some generic early printk & boot console fixups
Andrew Morton wrote: > hm, this patch series seems to have gone out of its way to cause problems. > > This particular (pathetically changelogged) patch is already in my tree, > only in a later, much more comprehensive form. Similarly the HVC changes > were already in Rusty's stuff and were supposed to be merged by Paulus, but > haven't been yet. > > Can we just drop this one? Does the Xen work actually depend on it? Well, some form of the hvc patches is needed to get a console. I'll rationalize them with respect to Gerd and Rusty's latest patches, but I did want to make the series stand on its own rather than have external dependencies on unmerged patches. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] [patch 00/18] 2.6.18-stable review
Hi Greg,
On Wed, Feb 21, 2007 at 09:34:45AM -0800, Greg KH wrote:
> On Wed, Feb 21, 2007 at 01:55:04PM +0200, S.??a??lar Onur wrote:
> > 21 ??ub 2007 ??ar tarihinde, Greg KH ??unlar?? yazmt??:
> > > Responses should be made by Friday February 23 00:00 UTC. Anything
> > > received after that time might be too late.
> >
> > We have still some CVEish patches in our package which maybe you want to
> > consider adding into -stable.
> >
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-4814
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5749
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5753
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-5823
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6053
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6054
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2006-6333
> > * http://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2007-0006
>
> Do you have a pointer to the patches for these fixes anywhere?
>
> And are you sure they are all for 2.6.18? The first one above is for
> the 2.4 kernel tree :)
No, in fact the CVE description is not precise enough. Maybe we should
propose an update to Steven, I don't know how CVE descriptions are
supposed to evolve.
The patch merged in 2.4 was a backport by Hugh Dickins of Linus' 2.6 patch,
which itself was composed of three successive fixes :
2f77d107050abc14bc393b34bdb7b91cf670c250
4fb23e439ce09157d64b89a21061b9fc08f2b495
825020c3866e7312947e17a0caa9dd1a5622bafc
I attach all of them to this mail for your convenience. I noticed that
Linus recently applied other changes to mincore, though I'm not sure
they are security-related.
Hoping this helps,
Willy
>From 2f77d107050abc14bc393b34bdb7b91cf670c250 Mon Sep 17 00:00:00 2001
From: Linus Torvalds <[EMAIL PROTECTED]>
Date: Sat, 16 Dec 2006 09:44:32 -0800
Subject: Fix incorrect user space access locking in mincore()
Doug Chapman noticed that mincore() will doa "copy_to_user()" of the
result while holding the mmap semaphore for reading, which is a big
no-no. While a recursive read-lock on a semaphore in the case of a page
fault happens to work, we don't actually allow them due to deadlock
schenarios with writers due to fairness issues.
Doug and Marcel sent in a patch to fix it, but I decided to just rewrite
the mess instead - not just fixing the locking problem, but making the
code smaller and (imho) much easier to understand.
Cc: Doug Chapman <[EMAIL PROTECTED]>
Cc: Marcel Holtmann <[EMAIL PROTECTED]>
Cc: Hugh Dickins <[EMAIL PROTECTED]>
Cc: Andrew Morton <[EMAIL PROTECTED]>
Signed-off-by: Linus Torvalds <[EMAIL PROTECTED]>
---
mm/mincore.c | 190 ++
1 files changed, 86 insertions(+), 104 deletions(-)
diff --git a/mm/mincore.c b/mm/mincore.c
index 7289078..b44d7f8 100644
--- a/mm/mincore.c
+++ b/mm/mincore.c
@@ -1,7 +1,7 @@
/*
* linux/mm/mincore.c
*
- * Copyright (C) 1994-1999 Linus Torvalds
+ * Copyright (C) 1994-2006 Linus Torvalds
*/
/*
@@ -38,46 +38,60 @@ static unsigned char mincore_page(struct
return present;
}
-static long mincore_vma(struct vm_area_struct * vma,
- unsigned long start, unsigned long end, unsigned char __user * vec)
+/*
+ * Do a chunk of "sys_mincore()". We've already checked
+ * all the arguments, we hold the mmap semaphore: we should
+ * just return the amount of info we're asked for.
+ */
+static long do_mincore(unsigned long addr, unsigned char *vec, unsigned long
pages)
{
- long error, i, remaining;
- unsigned char * tmp;
+ unsigned long i, nr, pgoff;
+ struct vm_area_struct *vma = find_vma(current->mm, addr);
- error = -ENOMEM;
- if (!vma->vm_file)
- return error;
-
- start = ((start - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
- if (end > vma->vm_end)
- end = vma->vm_end;
- end = ((end - vma->vm_start) >> PAGE_SHIFT) + vma->vm_pgoff;
+ /*
+* find_vma() didn't find anything: the address
+* is above everything we have mapped.
+*/
+ if (!vma) {
+ memset(vec, 0, pages);
+ return pages;
+ }
- error = -EAGAIN;
- tmp = (unsigned char *) __get_free_page(GFP_KERNEL);
- if (!tmp)
- return error;
+ /*
+* find_vma() found something, but we might be
+* below it: check for that.
+*/
+ if (addr < vma->vm_start) {
+ unsigned long gap = (vma->vm_start - addr) >> PAGE_SHIFT;
+ if (gap > pages)
+ gap = pages;
+ memset(vec, 0, gap);
+ return gap;
+ }
- /* (end - start) is # of pages, and also # of bytes in "vec */
- remaining = (end - start),
+ /*
+* Ok, got it. But check whether it's a segment we support
+* mincore() on. Right now, we don'
Re: [PATCH] ACPI driver support for pata
Alan wrote: - Add a driver for motherboard ACPI method devices - Link it after normal drivers so ACPI is not preferred - Hook the AMD driver to prefer ACPI for the Nvidia devices if ACPI is active - While we are at it fix up the simplex clear the AMD driver. Depends upon the set_mode -> do_set_mode wrapper patch Signed-off-by: Alan Cox <[EMAIL PROTECTED]> I tried out 2.6.21-rc1 with the pata_acpi patch. First off, when you enable pata_acpi, it appears that the Fedora mkinitrd stuff decides that that should be loaded as the first driver. On boot it promptly attempts to attach to all of the ATA controllers, including the nForce SATA controllers, which somehow it fails to actually drive causing a failure to mount the root filesystem. I got around that by blacklisting pata_acpi in /etc/modprobe.conf before installing the kernel and un-blacklisting it afterwards, so it wouldn't make the initrd try and load it, but there must be a better solution. It does seem to drive the PATA controllers, but the cable detection doesn't seem to be working: scsi5 : pata_acpi ata5.00: ATAPI, max UDMA/66 ata5.00: limited to UDMA/33 due to 40-wire cable ata5.00: configured for UDMA/33 I can assure you that is an 80-wire cable on that device :-) I suppose next step is adding debug to see where it is having issues? -- 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: Block layer still stack abuser?
Neil Brown wrote: > On Friday February 16, [EMAIL PROTECTED] wrote: > >> I was wondering if the block layer has been changed into a more serialized >> manner yet? I've been trying to google this, but so far no luck. I know there >> was some talk about removing the stack based approach, but I can't find any >> information about where this went. >> >> If it is currently fixed, a pointer to from which version would be nice. >> > > Might this: >http://lkml.org/lkml/2007/2/10/22 > > relate to your question? > If you are talking about stacking block device (via dm or md), then a > patch to fix this in in -mm but there are or were some potential > issues in dm that seem to be holding it up. > > Yes, I am. I know there has been general work to reduce stack usage here and there, but the final suggested solution was to serialize all the block subsystems so that only one was present on the stack at any given time. I was constantly hitting this problem a few years ago when I was running md+xfs+nfs. The fix was in -mm back then as well. ;) Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/4] coredump: ELF-FDPIC: enable to omit anonymous shared memory
Hi David and Robin,
Thank you for your reply.
Robin Holt wrote:
> On Wed, Feb 21, 2007 at 11:33:31AM +, David Howells wrote:
>
>>Kawai, Hidehiro <[EMAIL PROTECTED]> wrote:
>>
>>>Is coredump_setting_sem a global semaphore? If so, it prevents concurrent
>>>core dumping.
>>
>>No, it doesn't. Look again:
>>
>> int do_coredump(long signr, int exit_code, struct pt_regs * regs)
>> {
>>
>>
>> down_read(&coredump_settings_sem);
Oh, I'm sorry. I have overlooked it. There is no problem.
>>>Additionally, while some process is dumped, writing to
>>>coredump_omit_anon_shared of unrelated process will be blocked.
>>
>>Yes, but that's probably reasonable. How likely (a) is a process to coredump,
>>and (b) is a coredump to occur simultaneously with someone altering their
>>settings?
>
> And (c) altering the setting during a core dump going to produce an
> unusable core dump. I don't think the locking is that difficult to add
> and it just makes sense. I would venture a guess that it will take less
> time to actually do the locking than to continue arguing it is not needed
> when it clearly appears it is needed for even a small number of cases.
Okay, the probability that the process is blocked in the proc handler seems
to be small. But I'm not sure if problems never occur in enterprise use.
So I'd like to use down_write_trylock() as Robin said before. And if it
fails to acquire the lock, it returns EBUSY immediately.
Do you have any comments?
Thanks,
--
Hidehiro Kawai
Hitachi, Ltd., Systems Development Laboratory
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] ibmebus: dynamic add/remove, uevent, root device and whitespace
This is the aforementioned whitespace fix which applies on top of
part 1/2.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebus.c | 126 +-
include/asm-powerpc/ibmebus.h | 42 +++---
diff -urp b/arch/powerpc/kernel/ibmebus.c c/arch/powerpc/kernel/ibmebus.c
--- b/arch/powerpc/kernel/ibmebus.c 2007-02-22 05:43:32.133934656 +0100
+++ c/arch/powerpc/kernel/ibmebus.c 2007-02-20 23:31:39.0 +0100
@@ -4,35 +4,35 @@
* Copyright (c) 2005 IBM Corporation
* Joachim Fenkes <[EMAIL PROTECTED]>
* Heiko J Schick <[EMAIL PROTECTED]>
- *
+ *
* All rights reserved.
*
- * This source code is distributed under a dual license of GPL v2.0 and OpenIB
- * BSD.
+ * This source code is distributed under a dual license of GPL v2.0 and OpenIB
+ * BSD.
*
* OpenIB BSD License
*
- * Redistribution and use in source and binary forms, with or without
- * modification, are permitted provided that the following conditions are met:
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
*
- * Redistributions of source code must retain the above copyright notice, this
- * list of conditions and the following disclaimer.
+ * Redistributions of source code must retain the above copyright notice, this
+ * list of conditions and the following disclaimer.
*
- * Redistributions in binary form must reproduce the above copyright notice,
- * this list of conditions and the following disclaimer in the documentation
+ * Redistributions in binary form must reproduce the above copyright notice,
+ * this list of conditions and the following disclaimer in the documentation
* and/or other materials
- * provided with the distribution.
+ * provided with the distribution.
*
- * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
- * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
- * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
- * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
- * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
- * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
+ * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+ * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+ * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
+ * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
+ * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
+ * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
* SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER
- * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
- * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
+ * IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
+ * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
* POSSIBILITY OF SUCH DAMAGE.
*/
@@ -54,7 +54,7 @@ static void *ibmebus_alloc_coherent(stru
gfp_t flag)
{
void *mem;
-
+
mem = kmalloc(size, flag);
*dma_handle = (dma_addr_t)mem;
@@ -62,7 +62,7 @@ static void *ibmebus_alloc_coherent(stru
}
static void ibmebus_free_coherent(struct device *dev,
- size_t size, void *vaddr,
+ size_t size, void *vaddr,
dma_addr_t dma_handle)
{
kfree(vaddr);
@@ -78,7 +78,7 @@ static dma_addr_t ibmebus_map_single(str
static void ibmebus_unmap_single(struct device *dev,
dma_addr_t dma_addr,
-size_t size,
+size_t size,
enum dma_data_direction direction)
{
return;
@@ -89,13 +89,13 @@ static int ibmebus_map_sg(struct device
int nents, enum dma_data_direction direction)
{
int i;
-
+
for (i = 0; i < nents; i++) {
- sg[i].dma_address = (dma_addr_t)page_address(sg[i].page)
+ sg[i].dma_address = (dma_addr_t)page_address(sg[i].page)
+ sg[i].offset;
sg[i].dma_length = sg[i].length;
}
-
+
return nents;
}
@@ -127,15 +127,15 @@ static int ibmebus_bus_probe(struct devi
struct ibmebus_driver *ibmebusdrv = to_ibmebus_driver(dev->driver);
const struct of_device_id *id;
int error = -ENODEV;
-
+
if (!ibmebusdrv->probe)
return error;
-
+
id = of_match_
[PATCH 1/2] ibmebus: dynamic add/remove, uevent, root device and whitespace
The first part of this patch summarizes the patches of the
previous days, namely:
- Add dynamic addition/removal of adapters
(with spiffy error reporting)
- Implement the uevent interface using Sylvain's generic function
- Base fake root device on device instead of of_device
The first part will apply against the vanilla 2.6.20 source.
The second part is just a whitespace fix and applies on top of the first.
If nobody objects, I deem these patches ready for inclusion.
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
arch/powerpc/kernel/ibmebus.c | 129 ++
include/asm-powerpc/ibmebus.h |2
diff -wurp a/arch/powerpc/kernel/ibmebus.c b/arch/powerpc/kernel/ibmebus.c
--- a/arch/powerpc/kernel/ibmebus.c 2007-02-22 05:26:24.971939672 +0100
+++ b/arch/powerpc/kernel/ibmebus.c 2007-02-20 23:31:39.0 +0100
@@ -2,6 +2,7 @@
* IBM PowerPC IBM eBus Infrastructure Support.
*
* Copyright (c) 2005 IBM Corporation
+ * Joachim Fenkes <[EMAIL PROTECTED]>
* Heiko J Schick <[EMAIL PROTECTED]>
*
* All rights reserved.
@@ -43,10 +44,8 @@
#include
#include
-static struct ibmebus_dev ibmebus_bus_device = { /* fake "parent" device */
- .name = ibmebus_bus_device.ofdev.dev.bus_id,
- .ofdev.dev.bus_id = "ibmebus",
- .ofdev.dev.bus= &ibmebus_bus_type,
+static struct device ibmebus_bus_device = { /* fake "parent" device */
+ .bus_id = "ibmebus",
};
static void *ibmebus_alloc_coherent(struct device *dev,
@@ -161,18 +160,19 @@ static void __devinit ibmebus_dev_releas
static ssize_t ibmebusdev_show_name(struct device *dev,
struct device_attribute *attr, char *buf)
{
- return sprintf(buf, "%s\n", to_ibmebus_dev(dev)->name);
+ struct ibmebus_dev *ebus_dev = to_ibmebus_dev(dev);
+ char *name = (char*)get_property(ebus_dev->ofdev.node, "name", NULL);
+ return sprintf(buf, "%s\n", name);
}
static DEVICE_ATTR(name, S_IRUSR | S_IRGRP | S_IROTH, ibmebusdev_show_name,
NULL);
-static struct ibmebus_dev* __devinit ibmebus_register_device_common(
+static int __devinit ibmebus_register_device_common(
struct ibmebus_dev *dev, const char *name)
{
int err = 0;
- dev->name = name;
- dev->ofdev.dev.parent = &ibmebus_bus_device.ofdev.dev;
+ dev->ofdev.dev.parent = &ibmebus_bus_device;
dev->ofdev.dev.bus = &ibmebus_bus_type;
dev->ofdev.dev.release = ibmebus_dev_release;
@@ -186,12 +186,12 @@ static struct ibmebus_dev* __devinit ibm
if ((err = of_device_register(&dev->ofdev)) != 0) {
printk(KERN_ERR "%s: failed to register device (%d).\n",
__FUNCTION__, err);
- return NULL;
+ return -ENODEV;
}
device_create_file(&dev->ofdev.dev, &dev_attr_name);
- return dev;
+ return 0;
}
static struct ibmebus_dev* __devinit ibmebus_register_device_node(
@@ -205,18 +205,18 @@ static struct ibmebus_dev* __devinit ibm
if (!loc_code) {
printk(KERN_WARNING "%s: node %s missing 'ibm,loc-code'\n",
__FUNCTION__, dn->name ? dn->name : "");
- return NULL;
+ return ERR_PTR(-EINVAL);
}
if (strlen(loc_code) == 0) {
printk(KERN_WARNING "%s: 'ibm,loc-code' is invalid\n",
__FUNCTION__);
- return NULL;
+ return ERR_PTR(-EINVAL);
}
dev = kzalloc(sizeof(struct ibmebus_dev), GFP_KERNEL);
if (!dev) {
- return NULL;
+ return ERR_PTR(-ENOMEM);
}
dev->ofdev.node = of_node_get(dn);
@@ -227,9 +227,9 @@ static struct ibmebus_dev* __devinit ibm
min(length, BUS_ID_SIZE - 1));
/* Register with generic device framework. */
- if (ibmebus_register_device_common(dev, dn->name) == NULL) {
+ if (ibmebus_register_device_common(dev, dn->name) != 0) {
kfree(dev);
- return NULL;
+ return ERR_PTR(-ENODEV);
}
return dev;
@@ -240,9 +240,8 @@ static void ibmebus_probe_of_nodes(char*
struct device_node *dn = NULL;
while ((dn = of_find_node_by_name(dn, name))) {
- if (ibmebus_register_device_node(dn) == NULL) {
+ if (IS_ERR(ibmebus_register_device_node(dn))) {
of_node_put(dn);
-
return;
}
}
@@ -262,9 +261,15 @@ static void ibmebus_add_devices_by_id(st
return;
}
-static int ibmebus_match_helper(struct device *dev, void *data)
+static int ibmebus_match_helper_name(struct device *dev, void *data)
{
- if (strcmp((char*)data, to_ibmebus_dev(dev)->name) == 0)
+ const struct ibmebus_dev *ebus_dev = to_ibmebus_dev(dev);
+
Re: no backlight on radeon after recent kernel "upgrade"s
Richard Purdie <[EMAIL PROTECTED]> writes: > If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1 > with that option disabled? i've disabled FB_RADEON_BACKLIGHT (FB_BACKLIGHT also got deselected) and i managed to boot into 2.6.21-rc1 and have a working backlight. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ANNOUNCE] DualFS: File System with Meta-data and Data Separation
Hi Jörn, I have been thinking about the problem that you describe, and, definitively, DualFS does not have that problem. I could be wrong, but, I actually believe that the GC implemented by DualFS is deadlock-free. The key is the design of the log-structured file system used by DualFS for the meta-data device, which is different to the design that you propose. On Wed, 21 Feb 2007, [utf-8] Jörn Engel wrote: On Wed, 21 February 2007 19:31:40 +0100, Juan Piernas Canovas wrote: I do not understand. Do you mean that if I have 10 segments, 5 busy and 5 free, after cleaning I could need 6 segments? How? Where the extra blocks come from? This is a fairly complicated subject and I have trouble explaining it to people - even though I hope that maybe one or two dozen understand it by now. So let me try to give you an example: In LogFS, inodes are stored in an inode file. There are no B-Trees yet, so the regular unix indirect blocks are used. My example will be writing to a directory, so that should only involve metadata by your definition and be a valid example for DualFS as well. If it is not, please tell me where the difference lies. The directory is large, so appending to it involves writing a datablock (D0), and indirect block (D1) and a doubly indirect block (D2). Before: Segment 1: [some data] [ D1 ] [more data] Segment 2: [some data] [ D0 ] [more data] Segment 3: [some data] [ D2 ] [more data] Segment 4: [ empty ] ... DualFS writes meta-blocks in variable-sized chunks that we call partial segments. The meta-data device, however, is divided into segments, which have the same size. A partial segment can be as large a a segment, but a segment usually has more that one partial segment. Besides, a partial segment can not cross a segment boundary. A partial segment is a transaction unit, and contains "all" the blocks modified by a file system operation, including indirect blocks and i-nodes (actually, it contains the blocks modified by several file system operations, but let us assume that every partial segment only contains the blocks modified by a single file system operation). So, the above figure is as follows in DualFS: Before: Segment 1: [some data] [ D0 D1 D2 I ] [more data] Segment 2: [ some data ] Segment 3: [ empty] If the datablock D0 is modified, what you get is: Segment 1: [some data] [ garbage ] [more data] Segment 2: [ some data ] Segment 3: [ D0 D1 D2 I ] [ empty ] This is very similar to what the cleaner does. Therefore, moving a direct datablock (D0) to a new segment does not require more space than in the original segment. That is, cleaning a segment in DualFS requires just one free segment, and not more. The result is that you can use all the free segments in DualFS, and its cleaner is simple and deadlock-free. Probably the design is not the most space-efficient in the world, but it removes some other serious problems. And, remember, we are talking about meta-data (which is a small part of the file system), and disk space (which is quite inexpensive). Regards, Juan. After: Segment 1: [some data] [garbage] [more data] Segment 2: [some data] [garbage] [more data] Segment 3: [some data] [garbage] [more data] Segment 4: [D0][D1][D2][ empty] ... Ok. After this, the position of D2 on the medium has changed. So we need to update the inode and write that as well. If the inode number for this directory is high, we will need to write the inode (I0), an indirect block (I1) and a doubly indirect block (I2). The picture becomes a bit more complicates. Before: Segment 1: [some data] [ D1 ] [more data] Segment 2: [some data] [ D0 ] [more data] Segment 3: [some data] [ D2 ] [more data] Segment 4: [ empty ] Segment 5: [some data] [ I1 ] [more data] Segment 6: [some data] [ I0 ] [more data] Segment 7: [some data] [ I2 ] [more data] ... After: Segment 1: [some data] [garbage] [more data] Segment 2: [some data] [garbage] [more data] Segment 3: [some data] [garbage] [more data] Segment 4: [D0][D1][D2][I0][I1][I2][ empty ] Segment 5: [some data] [garbage] [more data] Segment 6: [some data] [garbage] [more data] Segment 7: [some data] [garbage] [more data] ... So what has just happened? The user did a single "touch foo" in a large directory and has caused six objects to move. Unless some of those objects were in the same segment before, we now have six segments containing a tiny amount of garbage. And there is almost no way how you can squeeze that garbage back out. The cleaner will fundamentally do the same thing as a regular write - it will move objects. So if you want to clean a segment containing the block of a different directory, you may again have to move five additional objects, the indirect blocks, inode and ifile indirect blocks. At this point, y
Re: [PATCH] update ctime and mtime for mmaped write
On Wed, 21 Feb 2007 18:51:52 +0100 Miklos Szeredi <[EMAIL PROTECTED]> wrote: > This patch makes writing to shared memory mappings update st_ctime and > st_mtime as defined by SUSv3: > >The st_ctime and st_mtime fields of a file that is mapped with >MAP_SHARED and PROT_WRITE shall be marked for update at some point >in the interval between a write reference to the mapped region and >the next call to msync() with MS_ASYNC or MS_SYNC for that portion >of the file by any process. If there is no such call and if the >underlying file is modified as a result of a write reference, then >these fields shall be marked for update at some time after the >write reference. > > A new address_space flag is introduced: AS_CMTIME. This is set each > time a page is dirtied through a userspace memory mapping. This > includes write accesses via get_user_pages(). > > Note, the flag is set unconditionally, even if the page is already > dirty. This is important, because the page might have been dirtied > earlier by a non-mmap write. > > This flag is checked in msync() and __fput(), and if set, the file > times are updated and the flag is cleared > > The flag is also cleared, if the time update is triggered by a normal > write. This is not mandated by the standard, but seems to be a sane > thing to do. Why is the flag checked in __fput()? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/22/07, D. Hazelton <[EMAIL PROTECTED]> wrote: " We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. Put *down* the crack pipe. Trent - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wednesday 21 February 2007 21:05, Michael K. Edwards wrote: > On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote: > > Related to that... Though a parser generated by Bison and a tokenizer > > generated by Flex both contain large chunks of GPL'd code, their > > inclusion in the source file that is to be compiled is mechanical - the > > true unique work is in writing the file that is processed by the tool to > > produce the output. Since the aggregation of the GPL'd code into the > > output source is done mechanically - via mechanical translation (which is > > what compilation is as well) - the result is *not* and under US copyright > > law *cannot* be a derivative work. What this means is that the GNU/FSF > > "special" terms applied to parsers generated by Bison and tokenizers > > generated by Flex is unnecessary - they are granting you a right you > > already have. > > Half true. It's not a derivative work exactly, but it could > conceivably be held to infringe against the copyright in Flex/Bison, > if you could prove that the amount of _creative_expression_ copied > into the output exceeds a "de minimis" standard and doesn't constitute > a "fair use". Those nifty photomosaics would probably infringe > against the photographers' copyright in the photos they're made up of, > if they weren't licensed through the graphic industry's "stock photo > archive" mechanism. You could probably defend on "fair use" with > respect to Flex/Bison and the vanilla GPL, since the fact that I can > get some random program with a parser in it from you without needing > my own copy of bison doesn't cost the FSF anything. But it's a > gamble, especially if that random program competes with something the > FSF makes $$$ off of; and I'd want that extra bit of estoppel in my > back pocket. Actually, on re-reading the GPL, I see exactly why they made that pair of exceptions. Where it's quite evident that a small to mid scale parsers that could have been written *without* the use of Bison is clearly a non-derivative work - Bison was not required, but was used as a mean of expediency. When you reach a large scale parser, such as one that meets all requirements to act as the parser for an ANSI C99 compiler, Bison stops being expedient - it'd likely take just as much time to hand craft the parser as it would to debug the Bison input. However, it makes maintaining the parser easier. But the fact is that it's the small to medium scale parsers that have a lower ratio of original to GPL'd code that are at risk of being declared derivative works. All of this because the GPL contains the following text in section 0: "The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does." That clause, to me, seems specifically tailored to cover programs such as Bison and Flex. (and is the reason that I try to use Byacc and when I need to, write tokenizers by hand) This frankly stinks of attempts to cover all possible code. (I actually started studying Copyright law in my free time because I was wondering how legal the GPL was and was also puzzled by some major online entities actually complaining about it) > The LGPL is a very different story. It's not just GPL with extra > estoppel, it's a booby trap. It goes a lot farther to put over its > own perverse definition of "derivative work", and it tries to compel > you to provide all the "data and utility programs needed for > reproducing the executable from it". I don't use the LGPL for my own > work, I wouldn't touch it with a ten-foot pole if it didn't have the > "GPL upgrade" clause in it, and I advise my employers and consulting > clients to go through the "GPL (v2 only!) upgrade" rigmarole with > respect to anything they so much as recompile. They don't all take > that advice, but that's not my problem. Since I tailor the license I apply to code I produce to meet the needs of the person or entity I am writing it for, I've never run into this. In truth, the LGPL is, IMHO, a piece of garbage. (as is the GPL - if you release code under the GPL you no longer have a legal right to it. Note the following text that appears in the GPL: " We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software." --IE: Once you release the code under the GPL, it becomes the *copyrighted* *property* of the FSF and you are just another person that the GPL is applied to. This means that if you later change your mind and decide to revoke the GPL on your code and replace it with say, the Larry Wall's "Artistic License" you are breaking the terms of the GPL and therefore lose all rights to modify and distribute your code. A similar clause appears in the LGPL: "We protec
Re: [patch 08/13] syslets: x86, add move_user_context() method
On Thu, 22 Feb 2007, Ingo Molnar wrote: > > * Davide Libenzi wrote: > > > On Wed, 21 Feb 2007, Ingo Molnar wrote: > > > > > From: Ingo Molnar <[EMAIL PROTECTED]> > > > > > > add the move_user_context() method to move the user-space > > > context of one kernel thread to another kernel thread. > > > User-space might notice the changed TID, but execution, > > > stack and register contents (general purpose and FPU) are > > > still the same. > > > > Also signal handling should/must be maintained, on top of TID. You > > don't want the user to be presented with a different signal handling > > after an sys_async_exec call. > > right now CLONE_SIGNAL and CLONE_SIGHAND is used for new async threads, > so they should inherit and share all the signal settings. Right. Sorry I missed the signal cloning flags (still has to go thru the whole code). > > So NTSK loads a non up2date FPUo, instead of the FPUc that was the > > "dirty" context to migrate (since TS_USEDFPU was set). I think you > > need an early __unlazy_fpu() in that case, that would turn the above > > into: > > yes. My plan is to to avoid all these problems by having a > special-purpose sched_yield_to(old_task, new_task) function. > > this, besides being even faster than the default scheduler (because the > runqueue balance does not change so no real scheduling decision has to > be done - the true scheduling decisions happen later on at async-wakeup > time), should also avoid all the FPU races: the FPU just gets flipped > between old_task and new_task (and TS_USEDFPU needs to be moved as well, > etc.). No intermediate task can come inbetween. > > can you see a hole in this sched_yield_to() method as well? Not sure till I see the code, but in that case we really need a sync©. This is really a fork-like for the FPU context IMO. The current "dirty" FPU context should follow both OTSK and NTSK. - 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: no backlight on radeon after recent kernel "upgrade"s
Richard Purdie writes: > Can you have a look at the differences between the defconfigs for > 2.6.20 and 2.6.21-rc1? this is probably the relevant part: --- config-2.6.20 2007-02-04 12:09:28.0 -0800 +++ config-2.6.21-rc1 2007-02-21 08:37:53.0 -0800 @@ -1270,16 +1302,25 @@ # # Graphics support # -CONFIG_FIRMWARE_EDID=y +CONFIG_BACKLIGHT_LCD_SUPPORT=y +CONFIG_BACKLIGHT_CLASS_DEVICE=y +CONFIG_LCD_CLASS_DEVICE=y +# CONFIG_BACKLIGHT_PROGEAR is not set CONFIG_FB=y +CONFIG_FIRMWARE_EDID=y CONFIG_FB_DDC=y CONFIG_FB_CFB_FILLRECT=y CONFIG_FB_CFB_COPYAREA=y CONFIG_FB_CFB_IMAGEBLIT=y +# CONFIG_FB_SVGALIB is not set # CONFIG_FB_MACMODES is not set -# CONFIG_FB_BACKLIGHT is not set +CONFIG_FB_BACKLIGHT=y CONFIG_FB_MODE_HELPERS=y CONFIG_FB_TILEBLITTING=y + +# +# Frambuffer hardware drivers +# # CONFIG_FB_CIRRUS is not set # CONFIG_FB_PM2 is not set # CONFIG_FB_CYBER2000 is not set @@ -1297,9 +1338,11 @@ # CONFIG_FB_MATROX is not set CONFIG_FB_RADEON=y CONFIG_FB_RADEON_I2C=y +CONFIG_FB_RADEON_BACKLIGHT=y # CONFIG_FB_RADEON_DEBUG is not set # CONFIG_FB_ATY128 is not set # CONFIG_FB_ATY is not set +# CONFIG_FB_S3 is not set # CONFIG_FB_SAVAGE is not set # CONFIG_FB_SIS is not set # CONFIG_FB_NEOMAGIC is not set @@ -1333,11 +1376,6 @@ # CONFIG_LOGO_LINUX_MONO is not set # CONFIG_LOGO_LINUX_VGA16 is not set CONFIG_LOGO_LINUX_CLUT224=y -CONFIG_BACKLIGHT_LCD_SUPPORT=y -CONFIG_BACKLIGHT_CLASS_DEVICE=y -CONFIG_BACKLIGHT_DEVICE=y -CONFIG_LCD_CLASS_DEVICE=m -CONFIG_LCD_DEVICE=y # # Sound > If the backlight changes are at fault, I'm guessing James' Kconfig > changes to the video Kconfig would be the culprit since > FB_RADEON_BACKLIGHT only used to be selectable if PMAC_BACKLIGHT was > enabled. On a thinkpad, the backlight is probably under ACPI > control. there was no FB_RADEON_BACKLIGHT in 2.6.20 and CONFIG_FB_BACKLIGHT wasn't set. > If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1 > with that option disabled? i'll try recompiling without this option and let you know what happened. > An ls /sys/class/backlight under 2.6.20 will tell us which driver it > was using... ls /sys/class/backlight/ 0 ./ 0 ../ 0 ibm/ --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm2: Oops in generic_make_request
Is this Problem still investigated? I got the same kernel bug a few minutes after booting my system with 2.6.20-mm2. As a student i am not yet as familiar with kernel programming as i want to be, but i will try, i promise. In the meantime, i always try to test the newest mm patches, and i have to say, this one is the first which doesent work right on my sys since 2.6.15-mm1. Thanks, keep up the good work an please help me with this Problem Greetz Oli On 18/02/07, Andrew Morton <[EMAIL PROTECTED]> wrote: > On Sun, 18 Feb 2007 18:58:05 +0100 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > On Sun, Feb 18, 2007 at 02:06:59PM +0100, Laurent Riffard wrote: > > > Le 18.02.2007 06:51, Andrew Morton a écrit : > > > >Temporarily at > > > > > > > > http://userweb.kernel.org/~akpm/2.6.20-mm2/ > > > > > > > >Will appear later at > > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20/2.6.20-mm2/ > > > > > > Hello, I've got a fully reproducible Oops. I just have to boot to > > > runlevel 2 and wait less than one minute. > > > > Maybe this oops is related too? > > Looks that way. > > > Can't yet tell if it's easily reproducible, this is on a JFS filesystem. > > > > BUG: unable to handle kernel NULL pointer dereference at virtual address 0004 > > printing eip: > > c02206aa > > *pde = > > Oops: [#1] > > PREEMPT > > last sysfs file: /devices/pci:00/:00:00.0/class > > CPU:0 > > EIP:0060:[]Not tainted VLI > > EFLAGS: 00010297 (2.6.20-mm2-1 #1) > > EIP is at __make_request+0x13a/0x390 > > eax: ebx: ecx: 042b0dd8 edx: 00010485 > > esi: c5f8cea0 edi: cfd587f8 ebp: c653dadc esp: c653dabc > > ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068 > > Process sh (pid: 4549, ti=c653c000 task=ccca2090 task.ti=c653c000) > > Stack: c137eae8 0001 cfd587e4 c5f8cea0 c5f893e4 c137eae8 c5f8cea0 0008 > >c653db28 c021e0ca cfa3ffa0 cee6a2e0 cfa3ffa0 0008 0100 > >00011250 cfedaf60 c653db10 0206 c653db18 c014a31e c653db48 > > Call Trace: > > [] show_trace_log_lvl+0x1a/0x30 > > [] show_stack_log_lvl+0xa9/0xd0 > > [] show_registers+0x206/0x350 > > [] die+0x10e/0x210 > > [] do_page_fault+0x2d2/0x600 > > [] error_code+0x74/0x7c > > [] generic_make_request+0x15a/0x200 > > [] submit_bio+0x58/0xe0 > > [] metapage_writepage+0x18f/0x1b0 > > [] __writepage+0xb/0x30 > > [] write_cache_pages+0x22f/0x300 > > [] generic_writepages+0x23/0x30 > > [] do_writepages+0x5c/0x60 > > [] __filemap_fdatawrite_range+0x67/0x80 > > [] filemap_flush+0x25/0x30 > > [] lmLogSync+0x19d/0x230 > > [] lmLog+0x5e/0x190 > > [] txCommit+0x8c0/0x1010 > > [] jfs_create+0x324/0x370 > > [] vfs_create+0xaf/0x100 > > [] open_namei+0x58c/0x640 > > [] do_filp_open+0x2c/0x50 > > [] do_sys_open+0x47/0xe0 > > [] sys_open+0x1c/0x20 > > [] syscall_call+0x7/0xb > > Michal Piotrowski is hitting it too, and has bisected it down to > git-block.patch. > > I have bisected it down to this patches > revert-md-avoid-possible-bug_on-in-md-bitmap-handling-for-git-block.patch > git-block.patch > git-block-fixup.patch > git-block-dupe-definitions.patch > git-block-xfs-barriers-broke.patch > Regards, > Michal > -- > Michal K. K. Piotrowski > LTG - Linux Testers Group (PL) > (http://www.stardust.webpages.pl/ltg/) > LTG - Linux Testers Group (EN) > (http://www.stardust.webpages.pl/linux_testers_group_en/) > - > To unsubscribe from this list: send the line "unsubscribe linux-kernel" > in > the body of a message 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: 2.6.20-mm2
On Tuesday 20 February 2007 2:07 pm, Rafael J. Wysocki wrote: > > Plus, I'd guess, the old rtc driver statically linked. > > Yes (mistakenly). Until someone merges the BSOD-for-Linux patch, I'll continue to assume that oopsing is the wrong response to "user" mistakes. ;) Legacy drivers can be such a PITA. > > What I see is a should-not-happen fault of some kind in a cleanup > > path that's been tested with non-PNP rtc drivers. A quick glance > > at the code left me puzzled. Would sleeping a second or two before > > calling rtc_device_unregister() change that behavior? > > [tries] > > No. Shoot. OK, I'll see if I can reproduce it myself. Is this system using a generic CMOS RTC? Or is HPET somehow involved? (That old RTC driver has HPET voodoo as well as normal RTC stuff.) - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[patch 6/6] rtc suspend()/resume() restores system clock
RTC class suspend/resume support, re-initializing the system clock on resume
from the clock used to initialize it at boot time.
- Inlining the same code used by ARM, which saves and restores the
delta between a selected RTC and the current system wall-clock time.
- Removes calls to that ARM code from AT91, OMAP, and S3C RTCs.
This goes on top of the patch series removing "struct class_device" usage
from the RTC framework. That makes class suspend()/resume() work.
Signed-off-by: David Brownell <[EMAIL PROTECTED]>
---
drivers/rtc/Kconfig | 24 +
drivers/rtc/class.c | 74 +++
drivers/rtc/rtc-at91rm9200.c | 30 -
drivers/rtc/rtc-omap.c | 17 -
drivers/rtc/rtc-s3c.c| 22
5 files changed, 91 insertions(+), 76 deletions(-)
Index: at91/drivers/rtc/Kconfig
===
--- at91.orig/drivers/rtc/Kconfig 2007-02-21 18:47:38.0 -0800
+++ at91/drivers/rtc/Kconfig2007-02-21 18:47:41.0 -0800
@@ -21,21 +21,31 @@ config RTC_CLASS
will be called rtc-class.
config RTC_HCTOSYS
- bool "Set system time from RTC on startup"
+ bool "Set system time from RTC on startup and resume"
depends on RTC_CLASS = y
default y
help
- If you say yes here, the system time will be set using
- the value read from the specified RTC device. This is useful
- in order to avoid unnecessary fsck runs.
+ If you say yes here, the system time (wall clock) will be set using
+ the value read from a specified RTC device. This is useful to avoid
+ unnecessary fsck runs at boot time, and to network better.
config RTC_HCTOSYS_DEVICE
- string "The RTC to read the time from"
+ string "RTC used to set the system time"
depends on RTC_HCTOSYS = y
default "rtc0"
help
- The RTC device that will be used as the source for
- the system time, usually rtc0.
+ The RTC device that will be used to (re)initialize the system
+ clock, usually rtc0. Initialization is done when the system
+ starts up, and when it resumes from a low power state.
+
+ This clock should be battery-backed, so that it reads the correct
+ time when the system boots from a power-off state. Otherwise, your
+ system will need an external clock source (like an NTP server).
+
+ If the clock you specify here is not battery backed, it may still
+ be useful to reinitialize system time when resuming from system
+ sleep states. Do not specify an RTC here unless it stays powered
+ during all this system's supported sleep states.
config RTC_DEBUG
bool "RTC debug support"
Index: at91/drivers/rtc/class.c
===
--- at91.orig/drivers/rtc/class.c 2007-02-21 18:47:39.0 -0800
+++ at91/drivers/rtc/class.c2007-02-21 18:47:41.0 -0800
@@ -32,6 +32,78 @@ static void rtc_device_release(struct de
kfree(rtc);
}
+#if defined(CONFIG_PM) && defined(CONFIG_RTC_HCTOSYS_DEVICE)
+
+/*
+ * On suspend(), measure the delta between one RTC and the
+ * system's wall clock; restore it on resume().
+ */
+
+static struct timespec delta;
+static time_t oldtime;
+
+static int rtc_suspend(struct device *dev, pm_message_t mesg)
+{
+ struct rtc_device *rtc = to_rtc_device(dev);
+ struct rtc_time tm;
+
+ if (strncmp(rtc->dev.bus_id,
+ CONFIG_RTC_HCTOSYS_DEVICE,
+ BUS_ID_SIZE) != 0)
+ return 0;
+
+ rtc_read_time(rtc, &tm);
+ rtc_tm_to_time(&tm, &oldtime);
+
+ /* RTC precision is 1 second; adjust delta for avg 1/2 sec err */
+ set_normalized_timespec(&delta,
+ xtime.tv_sec - oldtime,
+ xtime.tv_nsec - (NSEC_PER_SEC >> 1));
+
+ return 0;
+}
+
+static int rtc_resume(struct device *dev)
+{
+ struct rtc_device *rtc = to_rtc_device(dev);
+ struct rtc_time tm;
+ time_t newtime;
+ struct timespec time;
+
+ if (strncmp(rtc->dev.bus_id,
+ CONFIG_RTC_HCTOSYS_DEVICE,
+ BUS_ID_SIZE) != 0)
+ return 0;
+
+ rtc_read_time(rtc, &tm);
+ if (rtc_valid_tm(&tm) != 0) {
+ pr_debug("%s: bogus resume time\n", rtc->dev.bus_id);
+ return 0;
+ }
+ rtc_tm_to_time(&tm, &newtime);
+ if (newtime <= oldtime) {
+ if (newtime < oldtime)
+ pr_debug("%s: time travel!\n", rtc->dev.bus_id);
+ return 0;
+ }
+
+ /* restore wall clock using delta against this RTC;
Re: Block layer still stack abuser?
On Thursday February 22, [EMAIL PROTECTED] wrote: > On Thu, Feb 22, 2007 at 01:48:00PM +1100, Neil Brown wrote: > > Might this: > >http://lkml.org/lkml/2007/2/10/22 > > > > relate to your question? > > If you are talking about stacking block device (via dm or md), then a > > patch to fix this in in -mm but there are or were some potential > > issues in dm that seem to be holding it up. > > What are the current blocking issues? There are a lot of users of dm/md > double-stacking (e.g. mirroring + multipath) that are in deep trouble > currently and could be helped greatly with this patch. All I know is what is in that mail message that I linked to. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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/rfc 0/6] rtc framework: remove class_device, use class suspend()/resume()
Hi, Following this message (on the RTC list) are six patches: - Remove the /sys/class/rtc-dev class_device, and a class_interface - Use "struct rtc_device" in the external interface, not class_device - Simplify the sysfs attribute handling, removing a class_interface - Simplify the /proc/driver/rtc handling, removing the last class_interface - Remove the class_device in "struct rtc_device"; now suspend()/resume() work - Implement class suspend()/resume() so the system clock is updated on resume The main point of this series of patches is that last one, which I'll circulate just a bit more widely. (Although I think the first four are also nice cleanups!) It might be the first example of a framework that uses the "new" class level suspend()/resume() calls to offload drivers. Other than actually using that new PM infrastructure, this series should be interesting since it addresses one of the few remaining obstacles to having the "Generic Time-Of-Day" (GTOD) framework be fully generic, in the sense of working with whatever RTC is available on the platform (which includes ones accessed through I2C or SPI, so that spinlocked access is insufficient) and removing arch-specific RTC hooks. This has been lightly tested on one of the ARMs that doesn't yet have new-style dynamic tick working. I'm sure fault paths need tweaking yet. - Dave - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Block layer still stack abuser?
On Thu, Feb 22, 2007 at 01:48:00PM +1100, Neil Brown wrote: > Might this: >http://lkml.org/lkml/2007/2/10/22 > > relate to your question? > If you are talking about stacking block device (via dm or md), then a > patch to fix this in in -mm but there are or were some potential > issues in dm that seem to be holding it up. What are the current blocking issues? There are a lot of users of dm/md double-stacking (e.g. mirroring + multipath) that are in deep trouble currently and could be helped greatly with this patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] EXPORT_SYMBOL() time functions
On Wed, Feb 21, 2007 at 02:13:38PM +0100, Rolf Eike Beer wrote: > These functions were inlines before 8b9365d753d9870bb6451504c13570b81923228f. > Now EXPORT_SYMBOL() them to allow them to be used in modules again. Just because they happened to be inlined that doesn't mean modules should be using them. In fact no intree module uses them exactly because they're not intended to be used by this kind of code. Please show the code you want to use this for so we can see what you're really trying to do. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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.20-mm1: PTRACE=y, PROC_FS=n compile error
On Wed, Feb 21, 2007 at 02:15:10AM -0800, Roland McGrath wrote: > > This causes the following compile error with CONFIG_PTRACE=y, > > CONFIG_PROC_FS=n: > > Bah. I moved ptrace_may_attach to fs/proc/base.c so that CONFIG_PTRACE=n > could just omit kernel/ptrace.c entirely and still get the function for > fs/proc/base.c to use (and because that uses it many more times than ptrace > does). I'd forgotten that procfs could be disabled, since noone ever does. > > What do people suggest? It's not a very big function. Put it into some other place in kernel/ that's always build, e.g. kernel/sys.c and while you;re at it please give it a name that doesn't include the word ptrace. I remember mentioning that in my long utrace review mail.. :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] cciss: add reboot notifier support to driver
On Wed, Feb 21, 2007 at 03:12:51PM -0600, Mike Miller (OS Dev) wrote: > Patch 2/2 > > This patch adds reboot_notifier support to cciss. Changes in firmware make > this patch > essential. Without this patch there may be valid data left in the > controller's battery > backed write cache (BBWC) on shutdown. We found out the hard way that the > kernel does > not call our cleanup routines on shutdown or reboot. It seems that only rmmod > calls > the cleanup. > Please consider this for inclusion. > NAK. This should be using the shutdown method in struct pci_driver instead. I really wish we wouldn't export the reboot_notifier so people don't repeat this mistake over and over again.. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] sched: dynticks idle load balancing - v2
On Fri, Feb 16, 2007 at 06:08:42PM -0800, Suresh B wrote: > Changes since v1: > > - Move the idle load balancer selection from schedule() > to the first busy scheduler_tick() after restarting the tick. > This will avoid the unnecessay ownership changes when > softirq's(which are run in softirqd context in certain -rt > configurations) like timer, sched are invoked for every idle tick > that happens. > > - Misc cleanups. > > --- > Fix the process idle load balancing in the presence of dynticks. > cpus for which ticks are stopped will sleep till the next event wakes it up. > Potentially these sleeps can be for large durations and during which today, > there is no periodic idle load balancing being done. > > This patch nominates an owner among the idle cpus, which does the idle load > balancing on behalf of the other idle cpus. And once all the cpus are > completely idle, then we can stop this idle load balancing too. Checks added > in fast path are minimized. Whenever there are busy cpus in the system, there > will be an owner(idle cpu) doing the system wide idle load balancing. This is really ugly, sorry :( My suggestion for handling this was to increase the maximum balance interval for an idle CPU, and just implement a global shutdown when the entire system goes idle. The former should take care of the power savings issues for bare metal hardware, and the latter should solve performance problems for many idle SMP guests. It should take very little code to implement. If that approach doesn't cut it, then at least we can have some numbers to see how much better yours is so we can justify including it. If you are against my approach, then I can have a try at coding it up if you like? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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/2] cciss: add reboot notifier support to driver
On Wed, 21 Feb 2007 15:12:51 -0600 "Mike Miller (OS Dev)" <[EMAIL PROTECTED]>
wrote:
> @@ -3293,6 +3327,12 @@ #endif
> ((hba[i]->nr_cmds + BITS_PER_LONG -
>1) / BITS_PER_LONG) * sizeof(unsigned long));
>
> + if (notify_count == 0) {
> + register_reboot_notifier(&cciss_notifier);
> + notify_count=1;
> + }
> +
> +
> #ifdef CCISS_DEBUG
> printk(KERN_DEBUG "Scanning for drives on controller cciss%d\n", i);
> #endif /* CCISS_DEBUG */
> @@ -3500,6 +3540,7 @@ static void __exit cciss_cleanup(void)
> int i;
>
> pci_unregister_driver(&cciss_pci_driver);
> + unregister_reboot_notifier(&cciss_notifier);
Should we check that it was registered before going and unregistering
it? ie: do `modprobe cciss' on a machine which has no cciss hardware,
then do rmmod...
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 1/2] cciss: fix for 2TB support
On Wed, 21 Feb 2007 15:10:39 -0600 "Mike Miller (OS Dev)" <[EMAIL PROTECTED]>
wrote:
> Patch 1/2
>
> This patch changes the way we determine if a logical volume is larger than
> 2TB. The
> original test looked for a total_size of 0. Originally we added 1 to the
> total_size.
> That would make our read_capacity return size 0 for >2TB lv's. We assumed
> that we
> could not have a lv size of 0 so it seemed OK until we were in a clustered
> system. The
> backup node would see a size of 0 due to the reservation on the drive. That
> caused
> the driver to switch to 16-byte CDB's which are not supported on older
> controllers.
> After that everything was broken.
> It may seem petty but I don't see the value in trying to determine if the LBA
> is
> beyond the 2TB boundary. That's why when we switch we use 16-byte CDB's for
> all
> read/write operations.
> Please consider this for inclusion.
>
> ...
>
> + if (total_size == 0x) {
I seem to remember having already questioned this. total_size is sector_t,
which
can be either 32-bit or 64-bit. Are you sure that comparison works as
intended in both cases?
> + if(total_size == 0x) {
> cciss_read_capacity_16(cntl_num, i, 0,
> &total_size, &block_size);
> hba[cntl_num]->cciss_read = CCISS_READ_16;
Here 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: [patch 2/2] sched: dynticks idle load balancing - v2
On Wed, Feb 21, 2007 at 12:23:44PM -0800, Andrew Morton wrote:
> On Fri, 16 Feb 2007 18:08:42 -0800
> > +int select_nohz_load_balancer(int stop_tick)
> > +{
> > + int cpu = smp_processor_id();
> > +
> > + if (stop_tick) {
> > + cpu_set(cpu, nohz.cpu_mask);
> > + cpu_rq(cpu)->in_nohz_recently = 1;
> > +
> > + /*
> > +* If we are going offline and still the leader, give up!
> > +*/
> > + if (cpu_is_offline(cpu) && nohz.load_balancer == cpu) {
> > + if (cmpxchg(&nohz.load_balancer, cpu, -1) != cpu)
>
> So we require that architectures which implement CONFIG_NO_HZ also
> implement cmpxchg.
Just use atomic_cmpxchg, please.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 18/24] Xen-paravirt_ops: Some generic early printk & boot console fixups
On Wed, 21 Feb 2007 12:53:12 -0800 Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote: > Some generic early printk & boot console fixups > (already sent to lkml). hm, this patch series seems to have gone out of its way to cause problems. This particular (pathetically changelogged) patch is already in my tree, only in a later, much more comprehensive form. Similarly the HVC changes were already in Rusty's stuff and were supposed to be merged by Paulus, but haven't been yet. Can we just drop this one? Does the Xen work actually depend on it? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, Feb 21, 2007 at 06:26:57PM -0800, Andrew Morton wrote: > On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote: > > > > I can't say more until I've managed to understand your description, which > > > might take a while. > > > > It is intended for reallocation of a buffer. The code in lookup.c allocates > > some memory, and it may have to reallocate the buffer. The code tries to > > prevent some unneeded allocations by looking at what the smallest object the > > slabcache gives you is. > > > > I hope this explains it better. There's some discussion about this in the > > threads by Pekka Enberg. > > Problem is, it doesn't seem that we'll be merging unionfs any time soon so > we shouldn't be adding slab infrastructure on its behalf. And I'd prefer > not to have to carry slab changes in a filesystem tree. > > Although if the changes are generally ok-looking and are compact then it'd > be OK, but I do need to be alert for someone who comes along and uses that > infrastructure in an unrelated patch, which has happened before. When I > prep the patch for an upstream merge, oops, doesn't compile any more. Sounds reasonable to be weary of patches like that... > So for now, it'd be best to jsut forget about the optimisation. Well... > How useful is it, anyway? The code in lookup gets called frequently enough that I'm not sure. Whenever one touches a file on a read-only branch, a copyup is done. This may have to recreate the directory hierarchy leading up to the file - since the VFS doesn't have such code, unionfs builds up a stack of all the path components, and then it pops them off one at a time calling vfs_mkdir for each. The stack creation is where we do this "reallocation." Josef "Jeff" Sipek. -- I'm somewhere between geek and normal. - 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/
PREEMP_ACTIVE in cond_resched
cond_resched() checks and conditionally sets PREEMPT_ACTIVE flag for the current task. The comments says, /* * The BKS might be reacquired before we have dropped * PREEMPT_ACTIVE, which could trigger a second * cond_resched() call. */ My understanding is that cond_resched() would be indirectly invoked twice recursively, through the following path, cond_resched() -> schedule() -> reacquire_kernel_lock() -> down() -> might_sleep() -> might_resched() -> cond_resched(). However, the above path is possible only in a voluntary-preemptive kernel. In a full-preemptive kernel, I do not find any possible path to cause recursive cond_resched(). Does that mean we can actually remove the check and setting of PREEMPT_ACTIVE for a full-preemptive kernel? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 006 of 6] md: Add support for reshape of a raid6
On Thu, 22 Feb 2007 13:39:56 +1100 Neil Brown <[EMAIL PROTECTED]> wrote: > I must right code that Andrew can read. That's write. But more importantly, things that people can immediately see and understand help reduce the possibility of mistakes. Now and in the future. If we did all loops like that, then it'd be the the best way to do it in new code, because people's eyes and brains are locked into that idiom and we just don't have to think about it when we see it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Boot time Bluetooth BUG: warning: (value > m) at hid-core.c:793
On Tue, 20 Feb 2007 09:02:53 +0100 (CET), Jiri Kosina <[EMAIL PROTECTED]> wrote: > On Mon, 19 Feb 2007, Veronique & Vincent wrote: > > Hi again Marcel and Jiri, > > I've set up the hid-core.c to DEBUG mode... and it literally got pretty > > verbose... > thanks for the output. Is this really the full output? The important part > - report descriptor dump - seems to be missing in the output (it should > read something like "hid-core.c: report descriptor (size XY, read YZ) = > ... some hexadecimal numbers". This should be output by the time the HID > device is connected. Can I get something useful without a kernel recompile, with something like evtest? I have users on Fedora hitting this too. It very likely is a regression caused by the new unified HID. https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=227598 https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=228755 -- Pete - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Block layer still stack abuser?
On Friday February 16, [EMAIL PROTECTED] wrote: > I was wondering if the block layer has been changed into a more serialized > manner yet? I've been trying to google this, but so far no luck. I know there > was some talk about removing the stack based approach, but I can't find any > information about where this went. > > If it is currently fixed, a pointer to from which version would be nice. Might this: http://lkml.org/lkml/2007/2/10/22 relate to your question? If you are talking about stacking block device (via dm or md), then a patch to fix this in in -mm but there are or were some potential issues in dm that seem to be holding it up. NeilBrown - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird hard disk noise on shutdown (bug #7674)
Alan wrote: Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or turn on all the ATA debug and shutdown, the code should issue a cache flush followed by a standbynow1 command for each disk. Alan I believe it runs on suspend, but we don't run that code on normal shutdown, do we? Tejun Heo had a patch for sd that could (optionally) trigger a START STOP UNIT command to spin the disk down after synchronizing the cache before shutdown, but I haven't heard anything of it lately.. -- 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 006 of 6] md: Add support for reshape of a raid6
On Wednesday February 21, [EMAIL PROTECTED] wrote:
> On Tue, 20 Feb 2007 17:35:16 +1100
> NeilBrown <[EMAIL PROTECTED]> wrote:
>
> > + for (i = conf->raid_disks ; i-- ; ) {
>
> That statement should be dragged out, shot, stomped on then ceremonially
> incinerated.
An experiment in lateral thinking? I liked it, but there is no
accounting for taste.
>
> What's wrong with doing
>
> for (i = 0; i < conf->raid_disks; i++) {
>
> in a manner which can be understood without alcoholic fortification?
I guess... "Egoless programmer" and all that, "write for others to
read, not for the compiler", and as you say it comes to the same
number of bytes of code on common architectures.
>
> ho hum.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
I must right code that Andrew can read.
NeilBrown
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: High CPU usage with sata_nv
Matthew Fredrickson wrote: On Feb 20, 2007, at 9:43 PM, Robert Hancock wrote: Matthew Fredrickson wrote: I have noticed something that might be related as well. I am working on a device driver that would have periodic data errors due to exceptionally long interrupt handling latency. I have come to the point that I suspect that it's the sata_nv driver, and now that we can't do the hdparm -u1 option for sata, it seems to be a bigger problem. What kernel are you using? There were some complaints about latency problems (the ATA status register read taking a ridiculous amount of time to complete) on sata_nv previously, but 2.6.20 should eliminate that problem at least on nForce4 chipsets.. It's a 2.6.18 kernel. What we're seeing (by means of the interrupt pin on another card) is extremely large interrupt latency (measured from the time the interrupt pin goes low to the first couple lines of code in the IRQ handler to clear it) occasionally, in the order of 500-700 microseconds. I figured it was some other driver on the system disabling irqs for a long period of time, but it's difficult to trace what might be doing that. There were reports that an read of the interrupt status register on the sata_nv controller could take a huge amount of time (something like 14 milliseconds as I recall). I don't think it was ever really established what was causing that big delay (there was speculation it was trapping into SMM mode, but Nvidia denied that one). In 2.6.20 kernels we use a different operating mode, ADMA, on the nForce4 chipsets which usually avoids using that register. -- 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: [Unionfs] Re: [-mm patch] UNION_FS must depend on SLAB
For what it's worth, the new branch-management code also needs realloc(): right now I do a kfree/kalloc instead. So I'm all for having a true krealloc function. Erez. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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] UNION_FS must depend on SLAB
On Wed, 21 Feb 2007 21:00:39 -0500 Josef Sipek <[EMAIL PROTECTED]> wrote: > > I can't say more until I've managed to understand your description, which > > might take a while. > > It is intended for reallocation of a buffer. The code in lookup.c allocates > some memory, and it may have to reallocate the buffer. The code tries to > prevent some unneeded allocations by looking at what the smallest object the > slabcache gives you is. > > I hope this explains it better. There's some discussion about this in the > threads by Pekka Enberg. Problem is, it doesn't seem that we'll be merging unionfs any time soon so we shouldn't be adding slab infrastructure on its behalf. And I'd prefer not to have to carry slab changes in a filesystem tree. Although if the changes are generally ok-looking and are compact then it'd be OK, but I do need to be alert for someone who comes along and uses that infrastructure in an unrelated patch, which has happened before. When I prep the patch for an upstream merge, oops, doesn't compile any more. So for now, it'd be best to jsut forget about the optimisation. How useful is it, anyway? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
module-init-tools-3.3-pre10 available
Yo, After some delay[0] I have uploaded a new version of module-init-tools to http://www.kerneltools.org/ This release mostly has a bunch of build fixes, some memory leakage cleanups that will benefit systems that actually run out of memory (embedded, etc.) and various other things in the changelog. I plan on a non-pre release soon but need a bit more time to go over the current code and look at the tests, etc. Patches welcome, as usual. Jon. [0] Suspected mononucleosis...oh such a joyful experience :-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
yunfeng zhang wrote: Any comments or suggestions are always welcomed. Same question as always: what problem are you trying to solve? -- Politics is the struggle between those who want to make their country the best in the world, and those who believe it already is. Each group calls the other unpatriotic. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no backlight on radeon after recent kernel "upgrade"s
On Thu, 22 Feb 2007, Richard Purdie wrote: > The following sequence is reproducible: > > echo 7 > brightness (repeat until actual_brightness reads 7) > echo 0 > brightness (brightness reads 0, actual_brightness reads 4) > echo 0 > brightness (brightness reads 0, actual_brightness reads 0) As I said, it works fine on 2.6.20 on the hardware I have. I will see if I can test on 2.6.21, but it is something non-trivial for me to do right now. > I suspect this is interference from software on the machine as it does > show an onscreen display when I change the values in sysfs and the Yes, I am using something like that here too, and it doesn't break anything. > values on the OSD don't match what's really going on. The > actual_brightness does match the screen. So something is screwing with what gets written to the EC, and it does it AFTER ibm-acpi started processing the brightness change request. actual_brightness asks the *EC* what the current brightness value is, so it will never be wrong on a new-enough ThinkPad. > I guess this just means we need to get userspace to agree on one method > of access for this kind of thing. It makes me wondering where the > hardware brightness keys fit into things though... For ThinkPads: The Golden Rule: never talk to the EC or write to firmware-command-space in the CMOS NVRAM in userspace. If you do, bad things could happen and it is your fault. Here's how brightness control works in ThinkPads: 0. Brightness and backlight on/off state are decoupled. Turning the backlight on or off is done through DPMS or something else video-card specific. Newer models shut the backlight off by EC firmware (or maybe even on hardware) when the lid is closed, too. 1. The thinkpad does everything brightness-related in firmware (EC+BIOS). If you keep your hands off, it works correctly on every O.S. 2. The brightness up key exports hotkey events (all models) and a brightness up ACPI event (*60 and newer thinkpads, with 2.x BIOS). It is a bad idea to use those events to change the backlight brightness, because the firmware will be doing just that too. 3. It doesn't export anything for brightness down. You find it happened snooping the CMOS nvram. 4. Ibm-acpi doesn't care about the ACPI events much, it just asks the EC what the brightness level is when it needs to do something, then it issues both CMOS commands and EC writes to make damn sure the level is changed. The CMOS commands are step-style, so to go from 4 to 7, you issue 3x brightness up. > > Well, if you have the ACPI video module loaded, unload it. Does it work > > now? > > No change if unloaded. I am out of ideas. But blacklist that module on your ThinkPad, it just gets in the way, even if you are not using ibm-acpi. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-fbdev-devel] no backlight on radeon after recent kernel "upgrade"s
On Thu, Feb 22, 2007 at 01:11:18AM +, James Simmons wrote: > > *$> grep BACKLIGH /boot/config-2.6.20 > > # CONFIG_FB_BACKLIGHT is not set > > CONFIG_BACKLIGHT_LCD_SUPPORT=y > > CONFIG_BACKLIGHT_CLASS_DEVICE=m > > CONFIG_BACKLIGHT_DEVICE=y > > You need to explictly enable the backlight for your fbdev driver. It > doesn't do the selecting magically for you. > Jus do a make "favorite"config and go to the fbdev menu and select the > backlight option for your fbdev driver. I would think that we'd always want to enable the backlight. How are people supposed to Just Know that the kernel defaults to a black LCD? Joel -- Life's Little Instruction Book #407 "Every once in a while, take the scenic route." Joel Becker Principal Software Developer Oracle E-mail: [EMAIL PROTECTED] Phone: (650) 506-8127 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On 2/21/07, D. Hazelton <[EMAIL PROTECTED]> wrote: On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote: > I think you just misread. I said that the Evil Linker has cheerfully > shipped the source code of the modified POP server. He may not have > given you the compiler he compiled it with, wihout which the source > code is a nice piece of literature but of no engineering utility; but > that's the situation the GPL is DESIGNED TO PRODUCE. Actually, if memory serves, when you license a work under the GPL, part of the terms is that you have to provide the source and any scripts needed to produce a functioning executable. Absolutely. But not the toolchain, just the "scripts". This is part historical, since after all GNU got started when Sun started to monetize its toolchain independently of its O/S, RMS got annoyed enough to kick off another cloning project, and more competent compiler people caught on to the economic opportunity. Ever pay $5K for a CD full of GNU binaries for a commercial UNIX? I did, after deciding that getting all their shit to compile was more Morlock-work than I was up to. So like I say, it's part historical -- RMS didn't want to owe me a copy of Sun's toolchain along with that CD -- but it's no accident that it's still in there, because THAT'S HOW CYGNUS MADE MEGABUCKS. As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in clause 0) that the license only covers copying, modification and distribution. Unless they are confusing "Linking" with "copying" or "creating a derivative work" the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. Of course. The FSF smokescreen around "derivative work" exists not only to frighten potential commercial users of GPL libraries but to squelch people like Eric A. Young (principal OpenSSL author) who have the presumption to retain their own copyrights. Eric has a quite solid case (IMHO, IANAL) against the FSF and Eben Moglen personally under at least three different U. S. antitrust and racketeering laws, and it would be really entertaining to watch him take it up. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF "special" terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Half true. It's not a derivative work exactly, but it could conceivably be held to infringe against the copyright in Flex/Bison, if you could prove that the amount of _creative_expression_ copied into the output exceeds a "de minimis" standard and doesn't constitute a "fair use". Those nifty photomosaics would probably infringe against the photographers' copyright in the photos they're made up of, if they weren't licensed through the graphic industry's "stock photo archive" mechanism. You could probably defend on "fair use" with respect to Flex/Bison and the vanilla GPL, since the fact that I can get some random program with a parser in it from you without needing my own copy of bison doesn't cost the FSF anything. But it's a gamble, especially if that random program competes with something the FSF makes $$$ off of; and I'd want that extra bit of estoppel in my back pocket. The LGPL is a very different story. It's not just GPL with extra estoppel, it's a booby trap. It goes a lot farther to put over its own perverse definition of "derivative work", and it tries to compel you to provide all the "data and utility programs needed for reproducing the executable from it". I don't use the LGPL for my own work, I wouldn't touch it with a ten-foot pole if it didn't have the "GPL upgrade" clause in it, and I advise my employers and consulting clients to go through the "GPL (v2 only!) upgrade" rigmarole with respect to anything they so much as recompile. They don't all take that advice, but that's not my problem. Anyway, it's been fun watching this thread. If I've made a mistake somewhere in there, let me know - IANAL and I am just starting to really get into the meat of Copyright and related laws in independant study. Ditto. If you see a mistake in something I write, please please pretty please point it out, in public -- I am not a lawyer, absolutely everything I say could be wrong, and I don't really wan
Re: [-mm patch] UNION_FS must depend on SLAB
On Wed, Feb 21, 2007 at 02:19:44PM -0800, Andrew Morton wrote:
> On Tue, 20 Feb 2007 10:13:56 -0500
> Josef Sipek <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Feb 20, 2007 at 08:37:34AM +0200, Pekka Enberg wrote:
> > > On 2/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > > CC fs/unionfs/copyup.o
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c: In
> > > >function 'create_parents_named':
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620:
> > > >error: 'malloc_sizes' undeclared (first use in this function)
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620:
> > > >error: (Each undeclared identifier is reported only once
> > > >/home/bunk/linux/kernel-2.6/linux-2.6.20-mm2/fs/unionfs/copyup.c:620:
> > > >error: for each function it appears in.)
> > > >make[3]: *** [fs/unionfs/copyup.o] Error 1
> > >
> > > Hmm, why is unionfs playing around with malloc_sizes in the first place?
> > > Jeff?
> >
> > The code is in lookup.c:
> >
> > if (oldsize) {
> > int minsize = malloc_sizes[0].cs_size;
> >
> > if (!newsize || ((oldsize < newsize) && (newsize > minsize))) {
> > kfree(info->lower_paths);
> > info->lower_paths = NULL;
> > }
> > }
> >
> > That's the only user of malloc_sizes. It is supposed to be an optimization -
> > we get the smallest sized piece of memory even if we don't need all of it.
> > This way we don't reallocate & memcpy needlessly.
> >
>
> urgh, no, please don't poke around in slab internals like that.
I agree that it is a hack.
> I can't say more until I've managed to understand your description, which
> might take a while.
It is intended for reallocation of a buffer. The code in lookup.c allocates
some memory, and it may have to reallocate the buffer. The code tries to
prevent some unneeded allocations by looking at what the smallest object the
slabcache gives you is.
I hope this explains it better. There's some discussion about this in the
threads by Pekka Enberg.
Josef "Jeff" Sipek.
--
Linux, n.:
Generous programmers from around the world all join forces to help
you shoot yourself in the foot for free.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.20-rc5 1/1] MM: enhance Linux swap subsystem
Any comments or suggestions are always welcomed. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-fbdev-devel] [PATCH]
On Thu, 2007-02-22 at 01:35 +, James Simmons wrote: > > On Wed, 2007-02-21 at 21:23 +, James Simmons wrote: > > If this is an attempt to consolidate, I don't see the 'brightness' > > hook of backlight and lcd. > > > > If this is not a consolidation, why don't we just extend the lcd class? > > Its is a replacement for lcd. Is brightness universal for all display > types? Well, if you're adding a universal interface, you need hooks for more than that (brightness, contrast, hue, saturation, tint, etc). Then we just let the drivers cherry pick from the list on what it's going to support. Tony - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.20-git15 BUG: soft lockup detected on CPU#0! - timers?
Thomas Gleixner napisał(a):
> Michal,
>
> On Wed, 2007-02-21 at 16:38 +0100, Michal Piotrowski wrote:
>>> But you still have those softirq pending messages, right ?
>> Yes
>>
>> (+ new NOHZ: local_softirq_pending 02)
>
> Yike, that's the timer softirq.
>
> Can you add the patch below, maybe it gives us some useful info. Please
> enable lockdep (your last config had it already)
>
I hope this helps.
irq event stamp: 103630856
hardirqs last enabled at (103630855): [] _spin_unlock_irq+0x22/0x43
hardirqs last disabled at (103630856): []
tick_nohz_stop_sched_tick+0x13/0x1fd
softirqs last enabled at (103630824): [] __do_softirq+0xe4/0xea
softirqs last disabled at (103630819): [] do_softirq+0x64/0xd1
NOHZ: local_softirq_pending 20, 0001
(gdb) l *0xc031356a
0xc031356a is in _spin_unlock_irq (include2/asm/irqflags.h:48).
43 __asm__ __volatile__("cli" : : : "memory");
44 }
45
46 static inline void raw_local_irq_enable(void)
47 {
48 __asm__ __volatile__("sti" : : : "memory");
49 }
50
51 /*
52 * Used in the idle loop; sti takes one instruction cycle
(gdb) l *0xc013a00e
0xc013a00e is in tick_nohz_stop_sched_tick
(/mnt/md0/devel/linux-git/kernel/time/tick-sched.c:158).
153 ktime_t last_update, expires, now, delta;
154 int cpu;
155
156 local_irq_save(flags);
157
158 cpu = smp_processor_id();
159 ts = &per_cpu(tick_cpu_sched, cpu);
160
161 if (unlikely(ts->nohz_mode == NOHZ_MODE_INACTIVE))
162 goto end;
(gdb) l *0xc01265df
0xc01265df is in __do_softirq (/mnt/md0/devel/linux-git/kernel/softirq.c:251).
246
247 trace_softirq_exit();
248
249 account_system_vtime(current);
250 _local_bh_enable();
251 }
252
253 #ifndef __ARCH_HAS_DO_SOFTIRQ
254
255 asmlinkage void do_softirq(void)
(gdb) l *0xc0106a75
0xc0106a75 is in do_softirq
(/mnt/md0/devel/linux-git/arch/i386/kernel/irq.c:222).
217 irqctx->tinfo.previous_esp = current_stack_pointer;
218
219 /* build the stack frame on the softirq stack */
220 isp = (u32*) ((char*)irqctx + sizeof(*irqctx));
221
222 asm volatile(
223 " xchgl %%ebx,%%esp \n"
224 " call__do_softirq\n"
225 " movl%%ebx,%%esp \n"
226 : "=b"(isp)
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc1/git-config
http://www.stardust.webpages.pl/files/tbf/bitis-gabonica/2.6.21-rc1/git-dmesg
Regards,
Michal
--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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-fbdev-devel] [PATCH]
> On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
> > This is the new display intreface. Its goal is to provide a standard
> > interface to various types of displays. Currently we have auxdisplay,
> > output acpi device and the now defunct lcd class in the backlight directory.
> > Please apply.
>
> Is this an attempt to consolidate all display hardware and drivers?
All display types. Its LCD panels, LCD teletypes, TVs, CRTs etc. Right now
we have several solutions to the same problem (acpi output.c driver, auxdisplay
directory). A good idea what this aimed at take a look at
http://lcd4linux.sf.net
The bonus is the acpi and fbdev layer coudl use this as well.
> > + } else {
> > + new_dev->dev = NULL;
> > + kfree(new_dev);
>
> Set new_dev to NULL on failure.
Hum let me look. Okay, from what I see kfree doesn't set the the pointer
to null. Will fix.
> > + mutex_lock(&ddev->lock);
> > + device_del(ddev->dev);
> > + ddev->driver = NULL;
> > + index--;
>
> display0
> display1
> index = 2
> unregister display0
> index = 1
> display_device_register() as device1
> device1 <-- BUG, already used.
Ug. Will fix.
> If this is an attempt to consolidate, I don't see the 'brightness'
> hook of backlight and lcd.
>
> If this is not a consolidation, why don't we just extend the lcd class?
Its is a replacement for lcd. Is brightness universal for all display
types?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: GPL vs non-GPL device drivers
On Wednesday 21 February 2007 19:28, Michael K. Edwards wrote: > I think you just misread. I said that the Evil Linker has cheerfully > shipped the source code of the modified POP server. He may not have > given you the compiler he compiled it with, wihout which the source > code is a nice piece of literature but of no engineering utility; but > that's the situation the GPL is DESIGNED TO PRODUCE. Actually, if memory serves, when you license a work under the GPL, part of the terms is that you have to provide the source and any scripts needed to produce a functioning executable. *checks a local copy of GPLv2 for the exact wording* Third clause of the license: "For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable." So yes, someone could produce a work that compiles on a specific compiler, but there is then nothing stopping someone from fixing the problems that cause it to not compile using another compiler and releasing that source code - distributing it as a patch, AFAICT, falls outside coverage by the GPLv2. The build tool-chain, libraries and other works that are not a direct part of the program produced by compilation of the source code. (the wording of the GPL is: "However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.") As a side note: The distinct wording of the GPL actually *invalidates* the GNU/FSF claim that dynamically linking a work with, say, the readline library, means the work is a derivative of said library. The GPL states (in clause 0) that the license only covers copying, modification and distribution. Unless they are confusing "Linking" with "copying" or "creating a derivative work" the claim is invalid - because, as it has been shown, a mechanical process such as compilation or linking *cannot* create a derivative work. Related to that... Though a parser generated by Bison and a tokenizer generated by Flex both contain large chunks of GPL'd code, their inclusion in the source file that is to be compiled is mechanical - the true unique work is in writing the file that is processed by the tool to produce the output. Since the aggregation of the GPL'd code into the output source is done mechanically - via mechanical translation (which is what compilation is as well) - the result is *not* and under US copyright law *cannot* be a derivative work. What this means is that the GNU/FSF "special" terms applied to parsers generated by Bison and tokenizers generated by Flex is unnecessary - they are granting you a right you already have. Anyway, it's been fun watching this thread. If I've made a mistake somewhere in there, let me know - IANAL and I am just starting to really get into the meat of Copyright and related laws in independant study. DRH - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 00/13] Syslets, "Threadlets", generic AIO support, v3
On 2/21/07, Michael K. Edwards <[EMAIL PROTECTED]> wrote: You won't be able to do it later if you don't design for it now. Don't reinvent the square wheel -- there's a model to follow that was so successful that it has killed all alternate models in its sphere. Namely, IEEE 754. But please try not to make pipeline flushes suck as much as they did on the i860. To understand why I harp on IEEE 754 as a sane model for pipelined AIO, you might consider reading (at least parts of): http://www.cs.berkeley.edu/~wkahan/JAVAhurt.pdf People who write industrial-strength floating point programs rely on the IEEE floating point semantics to avoid having to check every result of every arithmetic step to see whether it is a valid input to the next step. NaNs and +/-0 and overflows and all that jazz are essential to efficient coding of things like matrix inversion, because the only alternative is simply to fail. But in-line indications of an exceptional result aren't enough, because it may or may not have been a coding error, and you may need fine-grained control over which "failure conditions" are within the realm of the expected and which are not. Here's a quotable bit from Kahan and Darcy's polemic: To achieve Floating-Point Predictability: Limit programmers' choices to what is reasonable and necessary as well as parsimonious, and Limit language implementors'choices so as always to honor the programmer's choices. To do so, language designers must understand floating-point well enough to validate their determination of "what is reasonable and necessary," or else must entrust that determination to someone else with the necessary competency. Now I ain't that "someone else", when it comes to AIO pipelining. But they're out there. Figure out how to create an AIO model that honors the RDBMS programmer's choices efficiently on a NUMA box without making him understand NUMA, and you really will have created something for the ages. Cheers, - 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/
-freg-struct-return?
We have a number of functions which return small structures (such as pte_t). It seems that the kernel is not compiled with -freg-struct-return, so all these small structures are being returned via the stack, even though they would fit into registers. Is there a reason for this? Would -freg-struct-return be preferred? It would make a good compliment to -mregparm. J - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
Alistair John Strachan <[EMAIL PROTECTED]> writes: > One warning to you though, I found the riser to be pretty flaky, causing > bizarre lockups and periodic crashes of Linux. Maybe this is a Linux > bug, but > it really didn't seem like it. I don't know how it could be a Linux bug. Perhaps mechanical problems with edge connector - PCI slot connections? -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message 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: ibm-acpi: fix initial status of backlight device
The brightness class core does not update the initial status of
the device's brightness at register time. Do it by ourselves
before we register the class device.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Richard Purdie <[EMAIL PROTECTED]>
---
NOTE: This patch needs an ACK from Richard Purdie before it can be merged,
as he might want to change the backlight class code instead.
drivers/acpi/ibm_acpi.c |7 +++
1 files changed, 7 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/ibm_acpi.c b/drivers/acpi/ibm_acpi.c
index 2429e11..6875421 100644
--- a/drivers/acpi/ibm_acpi.c
+++ b/drivers/acpi/ibm_acpi.c
@@ -1713,6 +1713,13 @@ static struct backlight_properties ibm_backlight_data = {
static int brightness_init(void)
{
+ int b;
+
+ b = brightness_get(NULL);
+ if (b < 0)
+ return b;
+ ibm_backlight_data.brightness = b;
+
ibm_backlight_device = backlight_device_register("ibm", NULL, NULL,
&ibm_backlight_data);
if (IS_ERR(ibm_backlight_device)) {
--
1.4.4.4
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: PCI riser cards and PCI irq routing, etc
[EMAIL PROTECTED] (Lennart Sorensen) writes:
> Well someone said the VIA uses INTA for the DN19 on their riser card,
> although is that INTA from the CPUs point of view or INTA from the slot
> the riser card is plugged into?
CPU/chipset it seems.
>> Device# IDSEL INT (first)
>> 0x08A19 n/a
>> 0x09 A20 n/a
>> 0x0A A21 INT D (and A, B, C)
>> 0x0B A22 n/a
>> 0x0C A23 n/a
>> 0x0D A24 IEEE1394 chip (INT B (single function), unused C, D, A)
>> 0x0E A25 n/a
>> 0x0F A26 n/a
>> 0x10 A27 USB (INT A, B, C, D - 3 UHCI and 1 OHCI = 4 functions)
>> 0x11 A28 VT823x (11.5 uses INT C so it means INT B, C, D, A)
>> 0x12 A29 onboard Ethernet (INT A, unused B, C, D)
>> 0x13 A30 INT A (and B, C, D of course)
>> 0x14 A31 INT B (the MB PCI slot is wired this way, and C, D, A of
>> course as there are 4 usable interrupt lines here)
>>
>> The on-board VGA is INT A (shares with Ethernet, and it's device #0
>> behind a bridge so it has to use INT A).
>
> Which bridge? Interrupts on the mainboard can do anything they want
> (and do).
Anyway, this is consistent with their manual, and it really doesn't
matter (what matters is "what you have to do with INTx signals on
device 0x14 to connect them to device 0x13).
> This would be true, if the bios assigned interrupts to devices that way
> all the time, but this is bus 0 and there are no rules.
That's a function of the PCB, the BIOS can alter IRQx-INTx assignments
(and does it) but can't alter PCB traces, so the INTx-deviceX
assignments are constant.
> After all if
> slot 0, 4, 8, 12, 16, and 20 all used INTA->INTA then that would make
> sense, but slot 20 (0x14) is using INTB->INTA so that isn't the case.
As you wrote, no rules.
> And why would slot 18 (0x12) and slot 19 (0x13) both use INTA?
Who knows? They made it this way, we have to use what we got.
> If the
> bios doesn't expect a device in slot 19 then it won't assing an irq
> correctly, and it will only be correct if the bios knows how it was
> wired.
Sure, but the BIOS expects a device here and expects it to use said
INT A (as seen by the chipset).
Look, I just got that EPIA-M board, connected it to PSU, put a strip
of schotch tape over IDSEL connector (MB PCI slot), tried connecting
IDSEL going to the device to different PCI ADxx lines and noted what
the BIOS thought after RESET. The table just shows that :-)
I initially mapped the MB slot INTs with a 4-port Ethernet card
(with DEC 21152 bridge chip) and then tested device/INT mapping
with a small, simple 1-function card.
I haven't tested devices 1-7 (can test, 0 is used by the chipset),
and I haven't investigated IO-APIC connections, that's right. But
it's almost certain both slots on original VIA riser card share
that set of 4 INTs (rotated) so it doesn't matter.
> Are there any bios options for enabling support for slot 19 devices on
> riser cards?
No, if the BIOS shows the device and (any valid) IRQ number at
startup ("Show summary" = yes in BIOS setup) then the card is
detected and supported, even if the riser card isn't the correct one
(= the card wouldn't work but it shows up).
You just have to connect that card's INT A to whatever the BIOS
wants and expects. That's it.
--
Krzysztof Halasa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [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 13/18] V4L: cx88: Fix lockup on suspend
Greg KH wrote: > -stable review patch. If anyone has any objections, please let us know. > > -- > From: Robert Hancock <[EMAIL PROTECTED]> > > Suspending with the cx88xx module loaded causes the system to lock up > because the cx88_audio_thread kthread was missing a try_to_freeze() > call, which caused it to go into a tight loop and result in softlockup > when suspending. Fix that. > > (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09) > > Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> > Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> > Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > Please drop this one... I shouldn't have sent it to 2.6.18.y nor 2.6.19.y ... tree-mixup :-/ Sorry about that... -Mike Krufky > --- > drivers/media/video/cx88/cx88-tvaudio.c |2 ++ > 1 file changed, 2 insertions(+) > > --- linux-2.6.18.7.orig/drivers/media/video/cx88/cx88-tvaudio.c > +++ linux-2.6.18.7/drivers/media/video/cx88/cx88-tvaudio.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -979,6 +980,7 @@ int cx88_audio_thread(void *data) > msleep_interruptible(1000); > if (kthread_should_stop()) > break; > + try_to_freeze(); > > /* just monitor the audio status for now ... */ > memset(&t, 0, sizeof(t)); > > -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/21] V4L: cx88: Fix lockup on suspend
Chuck Ebbert wrote: > Greg KH wrote: >> -stable review patch. If anyone has any objections, please let us know. >> >> -- >> Suspending with the cx88xx module loaded causes the system to lock up >> because the cx88_audio_thread kthread was missing a try_to_freeze() >> call, which caused it to go into a tight loop and result in softlockup >> when suspending. Fix that. >> >> (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09) >> >> Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> >> Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> >> Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> >> Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> >> >> --- >> drivers/media/video/cx88/cx88-tvaudio.c |2 ++ >> 1 file changed, 2 insertions(+) >> >> --- linux-2.6.19.4.orig/drivers/media/video/cx88/cx88-tvaudio.c >> +++ linux-2.6.19.4/drivers/media/video/cx88/cx88-tvaudio.c >> @@ -38,6 +38,7 @@ >> #include >> #include >> #include >> +#include >> #include >> #include >> #include >> @@ -974,6 +975,7 @@ int cx88_audio_thread(void *data) >> msleep_interruptible(1000); >> if (kthread_should_stop()) >> break; >> +try_to_freeze(); >> >> /* just monitor the audio status for now ... */ >> memset(&t, 0, sizeof(t)); >> > > drivers/media/video/cx88/cx88-tvaudio.c:41:27: error: linux/freezer.h: No > such file or directory > make[4]: *** [drivers/media/video/cx88/cx88-tvaudio.o] Error 1 > make[3]: *** [drivers/media/video/cx88] Error 2 > make[3]: *** Waiting for unfinished jobs > Yikes... This one shouldn't have been sent to 2.6.18.y nor 2.6.19.y ... tree-mixup :-/ Please drop this one. Thanks, Chuck. Sorry about that... -Mike Krufky - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-fbdev-devel] no backlight on radeon after recent kernel "upgrade"s
> I built 2.6.20-mm2 without backlight support
> $> grep BACKLIGH /boot/config-2.6.20-mm2
> # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> # CONFIG_FB_BACKLIGHT is not set
> # CONFIG_FB_RIVA_BACKLIGHT is not set
> # CONFIG_FB_RADEON_BACKLIGHT is not set
>
> that "eliminated" the problem. Also I can see the screen with pure
> 2.6.20 with backlight support (whatever it does since after
> loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
>
> *$> grep BACKLIGH /boot/config-2.6.20
> # CONFIG_FB_BACKLIGHT is not set
> CONFIG_BACKLIGHT_LCD_SUPPORT=y
> CONFIG_BACKLIGHT_CLASS_DEVICE=m
> CONFIG_BACKLIGHT_DEVICE=y
You need to explictly enable the backlight for your fbdev driver. It
doesn't do the selecting magically for you.
Jus do a make "favorite"config and go to the fbdev menu and select the
backlight option for your fbdev driver.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: no backlight on radeon after recent kernel "upgrade"s
> Richard Purdie <[EMAIL PROTECTED]> writes: > > > If FB_RADEON_BACKLIGHT wasn't set for 2.6.20, can you try 2.6.21-rc1 > > with that option disabled? > > i don't have my laptop with me but i am pretty sure > FB_RADEON_BACKLIGHT wasn't set for 2.6.20 (i think it showed up as a > new option when i did make oldconfig). i'll post the difference when i > get home tonight and also try disabling it. Correct. You need to enable the backlight for the radeon card. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no backlight on radeon after recent kernel "upgrade"s
On Wed, 2007-02-21 at 22:51 -0200, Henrique de Moraes Holschuh wrote: > On Thu, 22 Feb 2007, Richard Purdie wrote: > > I have a thinkpad with Intel GM graphics ;-). I need it to work so I try > > not to experiment too much on it. I've just tried the ibm-acpi driver > > and it doesn't work well :-(. > > 2.6.21-rc, or 2.6.20? 2.6.21-rc1 > If it is in 2.6.21, could you give me a report of how > it fares on 2.6.20? Maybe next week. I'm away over the weekend and I need it working now ;-). > > * 'echo 0 > brightness' lowered the intensity but by a level or two, not > > set it to level 0. A couple of more attempts and it did jump from 7 -> 1 > > and so on, it seems erratic. > > I know it used to work fine before 2.6.20. Let me check... works fine on a > T43, 2.6.20 (Radeon X300). I need more data to fix it :-) The following sequence is reproducible: echo 7 > brightness (repeat until actual_brightness reads 7) echo 0 > brightness (brightness reads 0, actual_brightness reads 4) echo 0 > brightness (brightness reads 0, actual_brightness reads 0) I suspect this is interference from software on the machine as it does show an onscreen display when I change the values in sysfs and the values on the OSD don't match what's really going on. The actual_brightness does match the screen. I guess this just means we need to get userspace to agree on one method of access for this kind of thing. It makes me wondering where the hardware brightness keys fit into things though... > > actual_brightness always seems to be correct, as does brightness so it > > looks like its not updating the hardware correctly. > > Well, if you have the ACPI video module loaded, unload it. Does it work > now? No change if unloaded. Cheers, Richard - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no backlight on radeon after recent kernel "upgrade"s
> On Wed, 2007-02-21 at 00:56 -0500, Yaroslav Halchenko wrote:
> > I didn't mention 2.6.20-mm1 and got to see -mm2 so it is the one which
> > Iv'e tried, but, once again, I experienced the same issue with 19-mm?
> > kernels.
> >
> > I built 2.6.20-mm2 without backlight support
> > $> grep BACKLIGH /boot/config-2.6.20-mm2
> > # CONFIG_BACKLIGHT_LCD_SUPPORT is not set
> > # CONFIG_FB_BACKLIGHT is not set
> > # CONFIG_FB_RIVA_BACKLIGHT is not set
> > # CONFIG_FB_RADEON_BACKLIGHT is not set
> >
> > that "eliminated" the problem. Also I can see the screen with pure
> > 2.6.20 with backlight support (whatever it does since after
> > loading lcd, backlight modules, my /sys/class/{lcd,backlight} are empty):
> >
> > *$> grep BACKLIGH /boot/config-2.6.20
> > # CONFIG_FB_BACKLIGHT is not set
> > CONFIG_BACKLIGHT_LCD_SUPPORT=y
> > CONFIG_BACKLIGHT_CLASS_DEVICE=m
> > CONFIG_BACKLIGHT_DEVICE=y
> >
> >
> > > Also, do you normally see files under /sys/class/lcd?
> > nope... after I load lcd module, no files under :-/ regardless either it
> > is mm or not. But there are files under /sys/class/backlight/ for mm2
> > compiled with backlight support (whenever the screen is dark as per my
> > original email)
>
> There should be no files appearing under /sys/class/lcd, so thats all
> normal. There is another report with similar symptoms which also sounds
> like enabling the following options are at fault:
Correct. LCD class was never used by anyone.
> # CONFIG_FB_RIVA_BACKLIGHT is not set
> # CONFIG_FB_RADEON_BACKLIGHT is not set
>
> I suspect these options only work on certain hardware and aren't
> generic. James, any idea what hardware these do/don't work with?
>
> Worst case, we set them to depend on PMAC_BACKLIGHT again I guess...
Ug. Previously it did the selecting for you. If you selected
backlight support the fbdev backlight would just come to life. This caused
problems for the case of having ACPI backlight and a fbdev driver with
backlight support. Two drivers controling the same hardware is not the
greatest idea. I made it so that people explictly had to pick the backlight
with a fbdev device. The other reason for this change was not every
one is using a LCD display. I have a system at home that uses a CRT.
Plus their is the case of "standard" PC graphics cards being used
in embedded devices. In this case even tho the graphics card has backlight
support the external lcd/backlight is routed through gpio independent of
the embedded graphics card. In such case we don't want to enable the
backlight for the graphics card but enable it.
In a nut shell the solution is select the backlight support for your
fbdev driver if you need it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: no backlight on radeon after recent kernel "upgrade"s
On Wed, 21 Feb 2007, Henrique de Moraes Holschuh wrote: > > * 'cat brightness' != 'cat actual_brightness' upon bootup (doesn't have > > Hmm, I see this in 2.6.20 too. And brightness is the one that is buggy. I > will look into it. Now, that was trivial to fix, and I will reply with a patch (which will have Cc's trimmed to just the MLs and Richard). But really, should not the backlight *class* be doing the initial update of the brightness? Looks like something that every device would need to do if the class doesn't do it, and unlike the "power it off on unregister" thing, I can't think of a reason not to do it for every backlight class device. Please ACK the ibm-acpi patch in my next message if you'd like me to submit it to Len Brown for merging into 2.6.21, or NACK it if you'd rather do it in the backlight class core. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] patch x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch queued to -stable tree
On Wed, Feb 21, 2007 at 01:43:42PM +0100, Blaisorblade wrote: > On Wednesday 21 February 2007 00:41, [EMAIL PROTECTED] wrote: > > This is a note to let you know that we have just queued up the patch titled > > > > Subject: x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should > > be accepted > > > > to the 2.6.18-stable tree. Its filename is > > Since you are still maintaining 2.6.18, I've just sent another patch for > that, > i.e. the backport of commit 14679eb3c50897889ba62f9a37e3bcd8a205b5e7. > Could you still merge it in this release, especially since this is the last > 2.6.18-stable you are doing? > Also, this patch should also be merged in 2.6.20, but I saw no mail about > this, so I wanted to make sure it's heading there too. > > > x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch > > > > A git repo of this tree can be found at > > > > http://www.kernel.org/git/?p=linux/kernel/git/gregkh/stable-queue.git;a=sum > >mary > > Hmm, this should be (note the missing gregkh in the path): > http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary Ah, good point, I'll go change my script that generates this, thanks for pointing it out. greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [stable] patch x86_64-fix-2.6.18-regression-ptrace_oldsetoptions-should-be-accepted.patch queued to -stable tree
On Wed, Feb 21, 2007 at 01:43:42PM +0100, Blaisorblade wrote: > On Wednesday 21 February 2007 00:41, [EMAIL PROTECTED] wrote: > > This is a note to let you know that we have just queued up the patch titled > > > > Subject: x86_64: fix 2.6.18 regression - PTRACE_OLDSETOPTIONS should > > be accepted > > > > to the 2.6.18-stable tree. Its filename is > > Since you are still maintaining 2.6.18, I've just sent another patch for > that, > i.e. the backport of commit 14679eb3c50897889ba62f9a37e3bcd8a205b5e7. > Could you still merge it in this release, especially since this is the last > 2.6.18-stable you are doing? Ok, I'll add it, thanks. > Also, this patch should also be merged in 2.6.20, but I saw no mail about > this, so I wanted to make sure it's heading there too. If you sent it to me, it's still in my queue, I have a lot of 2.6.20-stable stuff to catch up on still... thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: request_module: runaway loop modprobe net-pf-1 (is Re: Linux 2.6.21-rc1)
On Thu, Feb 22, 2007 at 06:16:23AM +0900, OGAWA Hirofumi wrote: > Greg KH <[EMAIL PROTECTED]> writes: > > > On Thu, Feb 22, 2007 at 04:12:04AM +0900, OGAWA Hirofumi wrote: > >> YOSHIFUJI Hideaki / ?$B5HF#1QL@ <[EMAIL PROTECTED]> writes: > >> > >> > In article <[EMAIL PROTECTED]> (at Tue, 20 Feb 2007 20:53:45 -0800 > >> > (PST)), Linus Torvalds <[EMAIL PROTECTED]> says: > >> > > >> >> But there's a ton of architecture updates (arm, mips, powerpc, x86, you > >> >> name it), ACPI updates, and lots of driver work. And just a lot of > >> >> cleanups. > >> > > >> > I cannot boot 2.6.21-rc1; it falls into OOM-Killer. > >> > > >> > Interesting error message I can see is: > >> >request_module: runaway loop modprobe net-pf-1 > >> > > >> > After bisecting, the commit > >> > Driver core: let request_module() send a /sys/modules/kmod/-uevent > >> > (id c353c3fb0700a3c17ea2b0237710a184232ccd7f) is to blame. > >> > > >> > Reverting it fixes the issue to me. > >> > >> /sbin/hotplug needs some module, but request_module() call /sbin/hotplug > >> loop? > >> Hm.. does the patch fix the problem? > > > > How does it loop? > > E.g. something calls the request_modle(), and if hotplug is using > socket(PF_UNIX) and af_unix is module, it also calls request_modle()? > > Just my guess though... Ugh, why does anyone make af_unix a module these days. I thought only Debian was that foolish... :) It will be interesting to see if this fixes the issue or not. thanks, greg k-h - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] fbdev driver for S3 Trio/Virge, updated
On Thu, 2007-02-22 at 00:53 +, James Simmons wrote:
> > > +/* image data is MSB-first, fb structure is MSB-first too */
> > > +static inline u32 expand_color(u32 c)
> > > +{
> > > + return ((c & 1) | ((c & 2) << 7) | ((c & 4) << 14) | ((c & 8) << 21)) *
> > > 0xFF;
> > > +}
> > > +
> > > +/* s3fb_iplan_imageblit silently assumes that almost everything is
> > > 8-pixel aligned */
> >
> > Hmn, same thing with vga16fb... Perhaps we should bring back the
> > fontwidth flag of 2.2 and 2.4 kernels.
>
> Ug no. It is possible to get 12,6 bit width fonts working with vga
> interleaved planes. I got it paritally working but never got back to it.
> Its in my queue of this to do. Now that I finished the display class I
> need to get around to makeing drm/fbdev work together :-)
>
Of course, not fontwidth exactly, but to allow the driver to specify the
alignment of the blit engine, in this case 8 pixels. I do believe X also
has similar functionality to compensate for the limitation of the
hardware.
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 00/13] Syslets, "Threadlets", generic AIO support, v3
On 2/21/07, Ingo Molnar <[EMAIL PROTECTED]> wrote: threadlets (and syslets) are parallel contexts and they behave so - queuing and execution semantics are then ontop of that, implemented either by glibc, or implemented by the application. There is no 'pipeline' of requests imposed - the structure of pending requests is totally free-form. For example in threadlet-test.c i've in essence implemented a 'set of requests' with the submission site only interested in whether all requests are done or not - but any stricter (or even looser) semantics and ordering can be used too. In short, you have a dataflow model with infinite parallelism, implemented using threads of control mapped willy-nilly onto the underlying hardware. This has not proven to be a successful model in the past. in terms of AIO, the best queueing model is i think what the kernel uses internally: freely ordered, with barrier support. (That is equivalent to a "queue of sets", where the queue are the barriers, and the sets are the requests within barriers. If there is no barrier pending then there's just one large freely-ordered set of requests.) That's a big part of why Linux scales poorly for workloads that involve a large volume of in-flight I/O transactions. Unless you essentially lock one application thread to each CPU core, with a complete understanding of its cache sharing and latency relationships to all the other cores, and do your own userspace I/O scheduling and dispatching state machine -- which is what all industrial-strength databases and other sorts of transaction engines currently do -- you get the same old best-effort context-thrashing scheduler we've had since Solaris 2.0. Let's do something genuinely better this time, OK? Cheers, - 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: First desktop motherboard supported by LinuxBIOS: GIGABYTE M57SLI-S4
Oops, forgot to include the relevant links in the previous email: [1] http://www.gigabyte.com.tw/Products/Motherboard/Products_Overview.aspx?ProductID=2287 [2] http://www.newegg.com/Product/Product.asp?Item=N82E16813128014 [3] http://linuxbios.org/Download_LinuxBIOS [4] http://www.fsf.org/campaigns/free-bios.html --- Brandon Howard <[EMAIL PROTECTED]> wrote: > Hi, > > The GIGABYTE M57SLI-S4 [1] is the first-ever desktop motherboard > supported by a Free & Open Source BIOS, thanks to AMD engineer > Yinghai > Lu who released GPL-licensed code last month. This state-of-the-art > motherboard is based on the NVIDIA nForce 570 SLI chipset and AMD's > latest Socket AM2. It contains tons of advanced features such as: > > Support for AMD Athlon 64 X2, Athlon 64 FX and Athlon 64 processors > 2X PCI Express x16 slots > 3X PCI Express x1 slots > 2X PCI slots > 3X 1394a (FireWire) ports > 10X USB 2.0 > 16GB maximum memory > SATA RAID > 6X SATA 3Gb/s slots. > > This motherboard can be obtained today from many retail and online > stores [2] and the source code for the BIOS can be downloaded from > the > LinuxBIOS SVN server [3]. > > This is a huge victory in the quest for a completely Free & Open > Source general-purpose computer that enables users to have full > control over their own hardware. The Free Software Foundation has > made > the campaign for a Free BIOS a top priority because it is a key > component in the software stack of personal computers [4]. The need > for a Free BIOS is even more pressing since DRM and Treacherous > Computing have found their way into some proprietary BIOSes and EFI. > From a practical perspective, LinuxBIOS removes the need for ugly > hacks and workarounds in the kernel that compensate for buggy BIOSes > > we can now fix the BIOS ourselves. > > I encourage everyone upgrading their desktop computers to consider > getting this motherboard or another one that is supported by > LinuxBIOS. > > -Brandon Any questions? Get answers on any topic at www.Answers.yahoo.com. Try it now. Bored stiff? Loosen up... Download and play hundreds of games for free on Yahoo! Games. http://games.yahoo.com/games/front - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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 01/21] V4L: cx88: Fix lockup on suspend
Greg KH wrote: > -stable review patch. If anyone has any objections, please let us know. > > -- > Suspending with the cx88xx module loaded causes the system to lock up > because the cx88_audio_thread kthread was missing a try_to_freeze() > call, which caused it to go into a tight loop and result in softlockup > when suspending. Fix that. > > (cherry picked from commit a96afb3e9428f2e7463344f12dbc85faf08e2e09) > > Signed-off-by: Robert Hancock <[EMAIL PROTECTED]> > Signed-off-by: Mauro Carvalho Chehab <[EMAIL PROTECTED]> > Signed-off-by: Michael Krufky <[EMAIL PROTECTED]> > Signed-off-by: Greg Kroah-Hartman <[EMAIL PROTECTED]> > > --- > drivers/media/video/cx88/cx88-tvaudio.c |2 ++ > 1 file changed, 2 insertions(+) > > --- linux-2.6.19.4.orig/drivers/media/video/cx88/cx88-tvaudio.c > +++ linux-2.6.19.4/drivers/media/video/cx88/cx88-tvaudio.c > @@ -38,6 +38,7 @@ > #include > #include > #include > +#include > #include > #include > #include > @@ -974,6 +975,7 @@ int cx88_audio_thread(void *data) > msleep_interruptible(1000); > if (kthread_should_stop()) > break; > + try_to_freeze(); > > /* just monitor the audio status for now ... */ > memset(&t, 0, sizeof(t)); > drivers/media/video/cx88/cx88-tvaudio.c:41:27: error: linux/freezer.h: No such file or directory make[4]: *** [drivers/media/video/cx88/cx88-tvaudio.o] Error 1 make[3]: *** [drivers/media/video/cx88] Error 2 make[3]: *** Waiting for unfinished jobs - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Weird hard disk noise on shutdown (bug #7674)
(I'm sorry if the thread breaks, i'm not subscribed) 2007/2/21, Alan <[EMAIL PROTECTED]>: Stick some printk calls in drivers/ata/libata-eh.c in ata_eh_suspend, or turn on all the ATA debug and shutdown, the code should issue a cache flush followed by a standbynow1 command for each disk. Alan Hi! Using netconsole, i was able to capture some printk output. Following some advices in the net (forum threads about similar problems), i did this to enable more verbose printk printing: echo 8 > /proc/sys/kernel/printk echo 1 > /proc/sys/vm/block_dump This was the result: http://bugzilla.kernel.org/attachment.cgi?id=10492&action=view However, i'm not still sure i enabled as much debugging info as i could in the kernel configuration. If you need more, please point me to precise configuration options. Thanks for your response. Francesco Pretto - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
First desktop motherboard supported by LinuxBIOS: GIGABYTE M57SLI-S4
Hi, The GIGABYTE M57SLI-S4 [1] is the first-ever desktop motherboard supported by a Free & Open Source BIOS, thanks to AMD engineer Yinghai Lu who released GPL-licensed code last month. This state-of-the-art motherboard is based on the NVIDIA nForce 570 SLI chipset and AMD's latest Socket AM2. It contains tons of advanced features such as: Support for AMD Athlon 64 X2, Athlon 64 FX and Athlon 64 processors 2X PCI Express x16 slots 3X PCI Express x1 slots 2X PCI slots 3X 1394a (FireWire) ports 10X USB 2.0 16GB maximum memory SATA RAID 6X SATA 3Gb/s slots. This motherboard can be obtained today from many retail and online stores [2] and the source code for the BIOS can be downloaded from the LinuxBIOS SVN server [3]. This is a huge victory in the quest for a completely Free & Open Source general-purpose computer that enables users to have full control over their own hardware. The Free Software Foundation has made the campaign for a Free BIOS a top priority because it is a key component in the software stack of personal computers [4]. The need for a Free BIOS is even more pressing since DRM and Treacherous Computing have found their way into some proprietary BIOSes and EFI. >From a practical perspective, LinuxBIOS removes the need for ugly hacks and workarounds in the kernel that compensate for buggy BIOSes we can now fix the BIOS ourselves. I encourage everyone upgrading their desktop computers to consider getting this motherboard or another one that is supported by LinuxBIOS. -Brandon Food fight? Enjoy some healthy debate in the Yahoo! Answers Food & Drink Q&A. http://answers.yahoo.com/dir/?link=list&sid=396545367 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [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-fbdev-devel] [PATCH]
On Wed, 2007-02-21 at 21:23 +, James Simmons wrote:
> This is the new display intreface. Its goal is to provide a standard
> interface to various types of displays. Currently we have auxdisplay,
> output acpi device and the now defunct lcd class in the backlight directory.
> Please apply.
Is this an attempt to consolidate all display hardware and drivers?
>
[snip]
> +struct class *display_class;
> +EXPORT_SYMBOL(display_class);
> +static int index;
> +
> +struct display_device *display_device_register(struct display_driver *driver,
> + struct device *dev, void
> *devdata)
> +{
> + struct display_device *new_dev = NULL;
> + int ret = -EINVAL;
> +
> + if (unlikely(!driver))
> + return ERR_PTR(ret);
> +
> + new_dev = kzalloc(sizeof(struct display_device), GFP_KERNEL);
> + if (likely(new_dev) && unlikely(driver->probe(new_dev, devdata))) {
> + new_dev->dev = device_create(display_class, dev, 0,
> + "display%d", index);
> +
> + if (!IS_ERR(new_dev->dev)) {
> + dev_set_drvdata(new_dev->dev, new_dev);
> + new_dev->driver = driver;
> + new_dev->parent = dev;
> + mutex_init(&new_dev->lock);
> + index++;
> + } else {
> + new_dev->dev = NULL;
> + kfree(new_dev);
Set new_dev to NULL on failure.
> + }
> + }
> + return new_dev;
> +}
> +EXPORT_SYMBOL(display_device_register);
> +
> +void display_device_unregister(struct display_device *ddev)
> +{
> + if (!ddev)
> + return;
> + mutex_lock(&ddev->lock);
> + device_del(ddev->dev);
> + ddev->driver = NULL;
> + index--;
display0
display1
index = 2
unregister display0
index = 1
display_device_register() as device1
device1 <-- BUG, already used.
[snip]
> +
> +struct display_device;
> +
> +/* This structure defines all the properties of a Display. */
> +struct display_driver {
> + int (*set_contrast)(struct display_device *, unsigned int);
> + int (*get_contrast)(struct display_device *);
> + void (*suspend)(struct display_device *, pm_message_t state);
> + void (*resume)(struct display_device *);
> + int (*probe)(struct display_device *, void *);
> + int (*remove)(struct display_device *);
> + int max_contrast;
If this is an attempt to consolidate, I don't see the 'brightness'
hook of backlight and lcd.
If this is not a consolidation, why don't we just extend the lcd class?
Tony
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] PXAFB: Support for backlight control
On Wed, 2007-02-21 at 15:53 +0100, Rodolfo Giometti wrote:
> Backlight control support for the PXA fram buffer.
>
> Signed-off-by: Rodolfo Giometti <[EMAIL PROTECTED]>
>
> ---
>
> Each platform should define the backlight properties in its own setup
> file in "linux/arch/arm/mach-pxa/" as follow:
>
>static int pxafb_bl_get_brightness(struct backlight_device *bl_dev)
>{
> return read_the_backlight_brightness();
>}
>
>static int pxafb_bl_update_status(struct backlight_device *bl_dev)
>{
>int perc, ret;
>
>if (bl_dev->props->power != FB_BLANK_UNBLANK ||
>bl_dev->props->fb_blank != FB_BLANK_UNBLANK)
>perc = 0;
>else
>perc = bl_dev->props->brightness;
>
> write_the_backlight_brightness(perc);
>
>return 0;
>}
>
>static struct backlight_properties wwpc1100_backlight_props = {
>.get_brightness = pxafb_bl_get_brightness,
>.update_status = pxafb_bl_update_status,
>.max_brightness = 100,
>};
>
> and then seting up the fb info as follow:
>
>wwpc1100_pxafb_info.modes = &special_modes;
>wwpc1100_pxafb_info.bl_props = &wwpc1100_backlight_props;
>set_pxa_fb_info(&wwpc1100_pxafb_info);
Reading through the patch its:
1) Not against any mainline kernel
2) Not against a recent kernel
There were a number of backlight class changes just merged into mainline
and you need to sync up any patch against them.
As mentioned by others, there is no need to tie the backlight driver
into the framebuffer any more. Have a look at
drivers/video/backlight/corgi_bl.c for an example (its used by PXA
devices).
I have said elsewhere I will take patches to make corgi_bl a more
generic driver (or maybe create a simple generic backlight driver) along
the lines of what Paul mentioned.
Regards,
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
