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.
> 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
> > >
* 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.
>
>
> 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
* 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
> > 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
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
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
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
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
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
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
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
* 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
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
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
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.
* 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
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
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
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
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
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
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
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),
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
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
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
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
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
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 ->
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
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.
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
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
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--
--
|
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
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
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
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
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.
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 @@
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
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
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
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
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
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
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
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
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
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
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) {
> +
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
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);
> > +
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
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
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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/
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
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
> 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.
> >
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
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
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
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
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
[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)
>> 0x08
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
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
> 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
> 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
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
> 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
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
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
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
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
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;
> > > +}
> > > +
> > > +/*
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
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]
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
(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,
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
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.
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
1 - 100 of 1130 matches
Mail list logo
