> i'd suggest we go with what we have now
Ok - I'll try sending this against 2.6.23-rc8-mm2
in a couple of hours, if it goes well.
> We cannot merge it via sched.git because it has some containers
> (or other?) dependencies, right?
This sched_load_balance flag patch collides with the cgroup
(ak
On 10/5/07, Eric W. Biederman <[EMAIL PROTECTED]> wrote:
> Stephen Hemminger <[EMAIL PROTECTED]> writes:
>
> > On Fri, 28 Sep 2007 22:47:16 -0400
> > Jeff Garzik <[EMAIL PROTECTED]> wrote:
> >
> >> Ayaz Abdulla wrote:
> >> > I am trying to track down a forcedeth driver issue described by bug 9047
>
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> My plan had been to send Andrew something on Wednesday
> next week (five days from now), either what we have now,
> or with the improved cpuset-to-sched API, if Nick and I
> can work through that (well, if Nick can figure out what
> I broke, while I'm o
On 10/5/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> The original idea (selectively compile out printk() instances based on log
> level to conserve space) is explicitly not addressed by this patch, and in
> fact this patch might actually make it harder to implement (by complicating
> the code).
Th
Ingo wrote:
> please resend the base patch to Andrew (or better yet, a combo patch
> that Andrew can apply and which just does it all).
I'm reluctant to right now, because I will be off the air
for three days, starting in one more day, and don't like
firing off stuff just before I vanish.
Though
* Paul Jackson <[EMAIL PROTECTED]> wrote:
> Yup - so far as I can tell, you didn't pick up the base patch that
> this current patch fixes. So, no, I wouldn't expect this patch to
> make any sense.
>
> As I stated in this current patch in the diffstat section after the
> '---' marker, this cu
This reverts commit f443675affe3f16dd428e46f0f7fd3f4d703eeab, which
breaks horribly if you aren't running an unreleased xf86-video-intel
driver out of git.
Conflicts:
drivers/char/agp/intel-agp.c
Signed-off-by: Kyle McMartin <[EMAIL PROTECTED]>
---
drivers/char/agp/intel-agp.c |5 -
On Sat, Oct 06, 2007 at 12:42:21AM -0400, Kyle McMartin wrote:
> commit f443675affe3f16dd428e46f0f7fd3f4d703eeab
> intel_agp: fix stolen mem range on G33
> G33 GTT stolen memory is below graphics data stolen memory and be
> seperate,
> so don't subtract it in stolen mem counting.
>
On Fri, Oct 05, 2007 at 08:20:01PM -0400, Matthew Reppert wrote:
> It works fine in the Ubuntu kernels (pre 2.6.22-13) and in mainline through
> 2.6.23-rc6; since 2.6.23-rc7 (and Ubuntu 2.6.22-13), the X server won't
> start up, and I get this at the end of my Xorg.log:
>
AOL. And I was in the mi
Hello,
Unfortunately, your patch is wrong,
and does not results in the same run-time behaviour.
You broke the code of "if (type & IORESOURCE_IO)"
Best Regards
Komuro
>Simplify some of the resource detection logic in yenta_socket.
>This patch results in the same run-time behaviour as the
>cu
Alan Cox wrote:
> Humm not a collision - thats a bug in the driver updating. Looks like the
> changes I made and combined with Christoph's lost a line somewhere when I
> was merging it all. Try the following
>
> Signed-off-by: Alan Cox <[EMAIL PROTECTED]>
>
> diff -u --new-file --exclude-from /usr/
Make some improvements for Documentation/watchdog/src/watchdog-simple.c.
CC: Wim Van Sebroeck <[EMAIL PROTECTED]>
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
Documentation/watchdog/src/watchdog-simple.c | 17 +
1 file changed, 13 insertions(+), 4 deletions(-)
Index: linu
On Fri, Oct 05, 2007 at 10:20:05AM -0700, Andrew Morton wrote:
> On Fri, 5 Oct 2007 20:30:28 +0800
> Fengguang Wu <[EMAIL PROTECTED]> wrote:
>
> > > commit c4e2d7ddde9693a4c05da7afd485db02c27a7a09
> > > Author: akpm
> > > Date: Sun Dec 22 01:07:33 2002 +
> > >
> > > [PATCH] Give kswapd
Hi Ingo,
After applying the fix to try_to_wake_up() I was still seeing some large
latencies for realtime tasks. Some debug code pointed out two additional
causes of these latencies. I have put fixes into my 'old' kernel and the
scheduler related latencies have gone away. I'm pretty confident th
> From: WANG Cong <[EMAIL PROTECTED]>
>
> Constify two char pointers and a struct in Documentation/spi/spidev_test.c.
>
> CC: David Brownell <[EMAIL PROTECTED]>
ACK
> CC: Anton Vorontsov <[EMAIL PROTECTED]>
> Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>
-
To unsubscribe from this list: send the
Constify two char pointers and a struct in Documentation/spi/spidev_test.c.
CC: David Brownell <[EMAIL PROTECTED]>
CC: Anton Vorontsov <[EMAIL PROTECTED]>
Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
---
Documentation/spi/spidev_test.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions
On Fri, Oct 05, 2007 at 12:17:41PM -0700, Christoph Lameter wrote:
>On Fri, 5 Oct 2007, WANG Cong wrote:
>
>>
>> This patch does the following cleanups for Documentation/vm/slabinfo.c:
>>
>> - Fix two memory leaks;
>
>For user space code? Memory will be released as soon as the program
>term
Ralf Baechle wrote:
To be consistent with the use of attributes in the rest of the kernel
replace all use of __attribute_pure__ with __pure and delete the
definition of __attribute_pure__.
Signed-off-by: Ralf Baechle <[EMAIL PROTECTED]>
Concern: __attribute_pure__ is very similar to __attribut
On Fri, 2007-10-05 at 17:28 +0200, Cordenner jean noel wrote:
> Hi,
>
Hi Jean Noel,
> This is an update of the i_version patch.
Just to make sure, is this vfs patch and next ext4 patch together going
to replace the 4 inode-version related patches currently in
ext4-patch-queue (and git tree)?
On Fri, 2007-10-05 at 17:28 +0200, Cordenner jean noel wrote:
> This patch update the i_version field of the inode and add a mount
> option to enable this feature. The other condition to enable this
> feature is that the inode size should be 256-bytes.
>
> Signed-off-by: Jean Noel Cordenner <[EMAI
I've got a new-ish system that I've been trying to get working that's
very close; the only things left are networking (which the latest e1000
driver from sf.net might fix) and graphics.
The system is a DG33TL micro ATX motherboard with a 2.13GHz Core 2 Duo
processor and 2GB RAM. The graphics ada
On Sat, 6 Oct 2007 01:01:10 +0200
"Miguel Ojeda" <[EMAIL PROTECTED]> wrote:
> On 10/5/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> > On Friday 05 October 2007 2:01:08 am Miguel Ojeda wrote:
> > >
> > > I think we all are trying to give ideas to improve the current logging
> > > API.
> > >
> > > I
On Fri, Oct 05, 2007 at 08:32:19PM +0200, Peter Zijlstra wrote:
>
> On Fri, 2007-10-05 at 13:50 -0400, Trond Myklebust wrote:
> > On Fri, 2007-10-05 at 12:57 +0200, Peter Zijlstra wrote:
> > > In this patch I totally ignored unstable, but I'm not sure that's the
> > > proper thing to do, I'd need
-hiroyasu ohyama
I wonder what corrected attached source makes good performance of
getting page slot cluster from page area discripter which is written
"si" in the source codes.
Because I think head of swap_list_t discripter doesn't suggest index of
swap area which is same priority that swap_li
On Oct 6 2007 02:23, Jan Engelhardt wrote:
>>
>>Not convinced WRT ASCII color codes, though. ASCII doesn't contain
>>codes for changing colors. Perhaps some specific "extended ASCII"?
>
>Start up QBasic, issue
> COLOR 1
>=> blue.
>
>Apply said patch, issue
> vt.printk_color=0x01
>=> yo
On Oct 6 2007 02:10, Krzysztof Halasa wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>>>I wonder how accurate is it.
>>
>> Since I do not use 512-glyph fonts, I do not know.
>
>Actually I meant "how accurate my remarks are" :-)
>
>Not convinced WRT ASCII color codes, though. ASCII doesn't co
Jan Engelhardt <[EMAIL PROTECTED]> writes:
>>I wonder how accurate is it.
>
> Since I do not use 512-glyph fonts, I do not know.
Actually I meant "how accurate my remarks are" :-)
Not convinced WRT ASCII color codes, though. ASCII doesn't contain
codes for changing colors. Perhaps some specific
On Fri, 5 Oct 2007 13:55:52 +0200 (CEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> It is already possible to deactivate the vc bell on a per-tty basis,
> by using echo -en "\e[11;0]", but this is reset on reset(1).
>
> This adds a sysfs parameter to globally control the vc bell, as well
> as
On Oct 6 2007 01:22, Krzysztof Halasa wrote:
>Jan Engelhardt <[EMAIL PROTECTED]> writes:
>
>> +The value you need to enter here is the ASCII color value
>
>ASCII color value? ANSI perhaps?
ANSI:
\e[31m R--
\e[32m G--
\e[33m RG- (yellow)
\e[34m --B
\e[35m R-B (magenta)
\e[36m -GB (cyan)
\e[37
Andrew wrote:
> I'm getting 100% rejects from this - probably whatever patch it is
> patching got lost or unrecognisably mangled.
Yup - so far as I can tell, you didn't pick up the base patch that
this current patch fixes. So, no, I wouldn't expect this patch to
make any sense.
As I stated in th
On Thu, 4 Oct 2007 09:15:59 -0700
>
> From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
> Subject: [PATCH] Rename is_cgroup_init()
>
> is_container_init() was accidentally renamed to is_cgroup_init() when
> renaming "container" to "control group". This patch restores the
> original name.
>
> Signed-o
Alan Cox wrote:
On Fri, 05 Oct 2007 15:11:52 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
Jan Engelhardt wrote:
15 partitions (at least for sd_mod devices) are too few.
Now when we have 20-bit minors, can't we simply recycle some of the
higher bits for additional partitions, across the b
On Fri, 2007-10-05 at 15:37 -0500, Timur Tabi wrote:
> linux-os (Dick Johnson) wrote:
>
> > It makes no sense because a bitfield is something having to
> > do with a 'C' compiler and it must NEVER be used as a template
> > to address hardware! 'C' gives no guarantee of the ordering
> > within mac
On Fri, 05 Oct 2007 15:11:52 -0700
"H. Peter Anvin" <[EMAIL PROTECTED]> wrote:
> Jan Engelhardt wrote:
> > 15 partitions (at least for sd_mod devices) are too few.
>
> Now when we have 20-bit minors, can't we simply recycle some of the
> higher bits for additional partitions, across the board?
Jan Engelhardt <[EMAIL PROTECTED]> writes:
> + The value you need to enter here is the ASCII color value
ASCII color value? ANSI perhaps?
> + composed (OR'ed) by one foreground color, one background
> + color and any number of attributes as follows:
I'm certainly not a native Englis
Since 2.6.23 still isn't out, and I've managed to reduce my patch
review backlog a bit, it's probably a good idea to give another update
about what I have queued for 2.6.24 already and what I hope to get to
before the merge window opens.
Core:
- My user_mad P_Key index support patch. Merged thi
Timur Tabi <[EMAIL PROTECTED]> writes:
> Andreas Schwab wrote:
>> Timur Tabi <[EMAIL PROTECTED]> writes:
>>
>>> The CPU shift operation, yes. I'm talking about shift operations on
>>> external memory-mapped devices.
>>
>> That is a property of how the device is wired to the bus. The cpu will
>>
On Wed, 03 Oct 2007 18:26:06 +0400
Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> There are two places that do so - the cgroups subsystem
> and the autofs code.
>
> Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
>
> ---
>
> diff --git a/fs/autofs/root.c b/fs/autofs/root.c
> index 592f640..5e
On Wed, 03 Oct 2007 04:44:01 -0700
Paul Jackson <[EMAIL PROTECTED]> wrote:
> From: Paul Jackson <[EMAIL PROTECTED]>
>
> Thanks to Randy Dunlap for the review that caught
> some of the following.
>
> Some bug fixes and coding style fixes:
> 1) only one statement per line, please.
> 2) don't nee
> I tested this by simulating a slow passive side responder, and it worked as
> expected for those tests. Using an MRA does add another MAD to the CM
> exchange,
> which is why it is sent only after seeing a duplicate request.
> Alternatively,
> we can take the OFED module parameter patch
On 10/5/07, Rob Landley <[EMAIL PROTECTED]> wrote:
> On Friday 05 October 2007 2:01:08 am Miguel Ojeda wrote:
> >
> > I think we all are trying to give ideas to improve the current logging API.
> >
> > If something works, it's great; but it doesn't mean that it can't be
> > improved, right?
>
> I'm
Jan Engelhardt wrote:
On Oct 5 2007 15:11, H. Peter Anvin wrote:
Jan Engelhardt wrote:
15 partitions (at least for sd_mod devices) are too few.
Now when we have 20-bit minors, can't we simply recycle some of the
higher bits for additional partitions, across the board? 63
partitions seem to h
On Fri, 2007-10-05 at 17:31 -0400, Chris Bergeron wrote:
> Hello all,
>
> I've just installed a multiport serial card released by an outfit called
> Syba. This is an 8 port serial-only card with an Octopus style breakout
> cable. The main chipset on it is an ITE IT8871F.
>
> I've got two ques
From: Randy Dunlap <[EMAIL PROTECTED]>
Update dontdiff, based on .gitignore patches from
Pete Zaitcev and Adrian Bunk.
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
Documentation/dontdiff |7 ++-
1 file changed, 6 insertions(+), 1 deletion(-)
--- linux-2.6.23-rc9-git3.orig/Documen
JBD2: JBD2 replace jbd2_kmalloc with kmalloc
From: Mingming Cao <[EMAIL PROTECTED]>
This patch cleans up jbd_kmalloc and replace it with kmalloc directly
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/jbd2/journal.c | 11 +--
fs/jbd2/transaction.c |4 ++--
include/lin
JBD: JBD replace jbd_kmalloc with kmalloc
From: Mingming Cao <[EMAIL PROTECTED]>
This patch cleans up jbd_kmalloc and replace it with kmalloc directly
Signed-off-by: Mingming Cao <[EMAIL PROTECTED]>
---
fs/jbd/journal.c | 11 +--
fs/jbd/transaction.c |4 ++--
include/linux/jb
JBD2: jbd2 slab allocation cleanups
From: Mingming Cao <[EMAIL PROTECTED]>
JBD2: Replace slab allocations with page allocations
JBD2 allocate memory for committed_data and frozen_data from slab. However
JBD2 should not pass slab pages down to the block layer. Use page allocator
pages instead. Th
JBD: JBD slab allocation cleanups
From: Mingming Cao <[EMAIL PROTECTED]>
JBD: Replace slab allocations with page allocations
JBD allocate memory for committed_data and frozen_data from slab. However
JBD should not pass slab pages down to the block layer. Use page allocator
pages instead. This w
On Fri 5 Oct 2007 09:13, Ralf Baechle pondered:
> And btw why does Analog list half their employees in the MAINTAINERS
> entry?
> Seems a little over the top ...
Yeah, the original submission got a little carried away...
We can cut that down to just Bryan and the mailing list I think.
-Robin
-
T
On Thu, 2007-10-04 at 07:52 +0100, Christoph Hellwig wrote:
> On Thu, Oct 04, 2007 at 01:50:36AM -0400, Theodore Ts'o wrote:
> > From: Mingming Cao <[EMAIL PROTECTED]>
> >
> > JBD: Replace slab allocations with page cache allocations
>
> It's page allocations, not page cache allocations.
>
> > A
Andrew Morton wrote:
> Well yes, but DMA_BIT_MASK(0) invokes undefined behaviour, generates a
> compiler warning and evaluates to 0x (with my setup).
>
> That won't be a problem in practice, but it is strictly wrong and doesn't set
> a good exmaple for the children ;)
>
It's int
On Oct 5 2007 15:11, H. Peter Anvin wrote:
> Jan Engelhardt wrote:
>> 15 partitions (at least for sd_mod devices) are too few.
>
> Now when we have 20-bit minors, can't we simply recycle some of the
> higher bits for additional partitions, across the board? 63
> partitions seem to have been suf
On Fri, 05 Oct 2007 14:28:45 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Andreas Schwab wrote:
> > #define DMA_BIT_MASK(n) ((u64)-1 >> (64 - (n)))
> >
>
> Yeah, that's cleaner.
>
Well yes, but DMA_BIT_MASK(0) invokes undefined behaviour, generates a
compiler warning and ev
Stephen Hemminger <[EMAIL PROTECTED]> writes:
> On Fri, 28 Sep 2007 22:47:16 -0400
> Jeff Garzik <[EMAIL PROTECTED]> wrote:
>
>> Ayaz Abdulla wrote:
>> > I am trying to track down a forcedeth driver issue described by bug 9047
>> > in bugzilla (2.6.23-rc7-git1 forcedeth w/ MCP55 oops under heavy
Jan Engelhardt wrote:
15 partitions (at least for sd_mod devices) are too few.
Now when we have 20-bit minors, can't we simply recycle some of the
higher bits for additional partitions, across the board? 63 partitions
seem to have been sufficient; at least I haven't heard anyone complain
ab
Forwarded Message
From: Valerie Clement <[EMAIL PROTECTED]>
To: Linux Kernel Mailing List
Subject: 2.6.23-rc9: Oops in cache_alloc_refill() mm/slab.c
Date: Thu, 04 Oct 2007 18:13:46 +0200
While running ffsb tests on my ext4 filesystem, I got an Oops in
cache_alloc_refill().
I
Jiri Kosina wrote:
On Fri, 5 Oct 2007, H. Peter Anvin wrote:
Jiri, what particular video mode are you running in? In other words,
what is your vga= parameter set to? In fact, what does your entire
kernel command line look like?
Hi,
the videomode is standard 80x25 VGA.
The kernel commandl
Hello all,
I've just installed a multiport serial card released by an outfit called
Syba. This is an 8 port serial-only card with an Octopus style breakout
cable. The main chipset on it is an ITE IT8871F.
I've got two questions on this: Is there a driver I should try force
loading on it (a
Andreas Schwab wrote:
Timur Tabi <[EMAIL PROTECTED]> writes:
The CPU shift operation, yes. I'm talking about shift operations on
external memory-mapped devices.
That is a property of how the device is wired to the bus. The cpu will
always put a value of 128 on the bus such that D7 = 1 and D
From: Peter Zijlstra <[EMAIL PROTECTED]>
Date: Fri, 05 Oct 2007 22:32:00 +0200
> Focus on the slab allocator usage, instrument it, record a trace,
> generate a statistical model that matches, and write a small
> programm/kernel module that has the same allocation pattern. Then verify
> this statis
On Sat, 6 Oct 2007, Michael Tokarev wrote:
[snip]
> That to say - it may be some miscompilations, but may be some probs with
> hardware itself. If you can, try to reproduce the same on another board
> (I just tried to boot 2.6.23-rc5 on this machine, compiled for PIII CPU
> using gcc-4.1.2 (no ot
Timur Tabi <[EMAIL PROTECTED]> writes:
> The CPU shift operation, yes. I'm talking about shift operations on
> external memory-mapped devices.
That is a property of how the device is wired to the bus. The cpu will
always put a value of 128 on the bus such that D7 = 1 and D0-D6 = 0.
Andreas.
-
Jiri Kosina wrote:
On Fri, 5 Oct 2007, H. Peter Anvin wrote:
Jiri, what particular video mode are you running in? In other words,
what is your vga= parameter set to? In fact, what does your entire
kernel command line look like?
Hi,
the videomode is standard 80x25 VGA.
The kernel commandl
Andreas Schwab wrote:
> #define DMA_BIT_MASK(n) ((u64)-1 >> (64 - (n)))
>
Yeah, that's cleaner.
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.ht
"Robert P. J. Day" <[EMAIL PROTECTED]> writes:
> On Fri, 5 Oct 2007, Andrew Morton wrote:
>
>> -#define DMA_BIT_MASK(n) ((1ULL<<(n))-1)
>> +#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
>
> or you could take advantage of the macros in kernel.h and write that
> as:
>
> +#d
Robert P. J. Day wrote:
> or you could take advantage of the macros in kernel.h and write that
> as:
>
> +#define DMA_BIT_MASK(n) (((n) == 64) ? ULLONG_MAX : ((1ULL<<(n))-1))
>
But that's a more indirect way of expressing "I want all 1's".
J
-
To unsubscribe from this list: send the l
"Kok, Auke" <[EMAIL PROTECTED]> writes:
> maximilian attems wrote:
>> Linux tau 2.6.23-rc8-mm2-686 #1 SMP Wed Oct 3 23:56:32 CEST 2007 i686
>> GNU/Linux
>>
>> eth0 renamed to eth1
>> sysfs: duplicate filename 'eth1' can not be created
>> WARNING: at fs/sysfs/dir.c:433 sysfs_add_one()
>> [] dump_
Timur Tabi <[EMAIL PROTECTED]> writes:
> Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD.
> What does it mean for a C-level bitfield ordering to be little-endian if
> the processor is BIG_ENDIAN?
Byte endianess and bit endianness are orthogonal concecpts. A cpu can
have i
Hi Guennadi,
On Fri, 5 Oct 2007 22:22:08 +0200 (CEST), Guennadi Liakhovetski wrote:
> Ok, after a day of biseting, it turns out to be a compiler problem. The
> gcc-3.3.5 produces at least these two problems (Oops on i2c-viapro probe
> and disabled IRQs in USB), whereas 4.1.2 has no problem so fa
On Friday, 5 October 2007 09:08, Pavel Machek wrote:
> Hi!
>
> > > This commit is certainly OK, as it should merely preserve status quo.
> > > Also note that Pavel wrote in his initial post that the problem became
> > > apparent way after -rc1. Full quote:
> > >
> > > | I noticed empty suspend s
Anton Altaparmakov wrote:
---LSB-- ---2SB-- ---3SB-- ---MSB-- [bytes] LITTLE_ENDIAN
L234567M L234567M L234567M L234567M [bits] LITTLE_ENDIAN_BITFIELD
No it is not. That makes no sense.
Why not? I honestly don't know what x86 does, but I would think that if I
write a 32-bit value to a me
On Fri, 2007-10-05 at 15:23 -0400, Trond Myklebust wrote:
> On Fri, 2007-10-05 at 15:20 -0400, Trond Myklebust wrote:
> > On Fri, 2007-10-05 at 20:32 +0200, Peter Zijlstra wrote:
> > > Well, the thing is, we throttle pageout in throttle_vm_writeout(). As it
> > > stand we can deadlock there becau
On Fri, 5 Oct 2007, Andrew Morton wrote:
> -#define DMA_BIT_MASK(n) ((1ULL<<(n))-1)
> +#define DMA_BIT_MASK(n) (((n) == 64) ? ~0ULL : ((1ULL<<(n))-1))
or you could take advantage of the macros in kernel.h and write that
as:
+#define DMA_BIT_MASK(n) (((n) == 64) ? ULLONG_MAX : ((1U
On Fri, 5 Oct 2007, H. Peter Anvin wrote:
> Jiri, what particular video mode are you running in? In other words,
> what is your vga= parameter set to? In fact, what does your entire
> kernel command line look like?
Hi,
the videomode is standard 80x25 VGA.
The kernel commandline is
On 5 Oct 2007, at 20:35, Timur Tabi wrote:
Jan Engelhardt wrote:
On Oct 5 2007 13:27, Timur Tabi wrote:
What's the difference between __LITTLE_ENDIAN and
__LITTLE_ENDIAN_BITFIELD? Can
someone give me an example when __BIG_ENDIAN and
__LITTLE_ENDIAN_BITFIELD would
both be defined simultaneou
After a dvb card driver is unloaded and then loaded again, it is no longer
possible to access the dvr device.
Example:
cat /dev/dvb/adapter0/dvr0
kill with ^C
rmmod cx88-dvb
modprobre cx88-dvb
cat /dev/dvb/adapter0/dvr0
cat: /dev/dvb/adapter0/dvr0: No such device
On kernel 2.6.21, this worked f
On Fri, 05 Oct 2007 13:43:54 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > From: Andrew Morton <[EMAIL PROTECTED]>
> >
> > Now that we have DMA_BIT_MASK(), these macros are pointless.
> >
>
> Except, unfortunately, DMA_64BIT_MASK. I guess we could special cas
On Friday, 5 October 2007 18:27, Guennadi Liakhovetski wrote:
> On Fri, 5 Oct 2007, Rafael J. Wysocki wrote:
>
> > On Friday, 5 October 2007 16:18, Guennadi Liakhovetski wrote:
> > > Why does APM depend on PM_SLEEP?
> >
> > Because APM uses the suspend core functions in drivers/base/power .
>
>
From: maximilian attems <[EMAIL PROTECTED]>
Date: Fri, 5 Oct 2007 15:11:15 +0200
> net eth1: device_rename: sysfs_create_symlink failed (-17)
...
> no idea if aboves belongs to netdev or sysfs dep.
I think the report belongs to udev.
It tries to rename network devices even if they already
have
On Fri, 5 Oct 2007, Guennadi Liakhovetski wrote:
> On Fri, 5 Oct 2007, Hugh Dickins wrote:
> > On Fri, 5 Oct 2007, Guennadi Liakhovetski wrote:
> > > Am I running crazy here (some 2.6.23-rc6-ish)?
> > >
> > > $ zcat /proc/config.gz | grep TMPFS
> > > # CONFIG_TMPFS is not set
> > > $ grep tmpfs /p
Guennadi Liakhovetski wrote:
> Hi
>
> Ok, after a day of biseting, it turns out to be a compiler problem. The
> gcc-3.3.5 produces at least these two problems (Oops on i2c-viapro probe
> and disabled IRQs in USB), whereas 4.1.2 has no problem so far. Up to now
> 3.3.5 had no problem compiling 2
> I always found that quite convenient. Putting at least a summary in
> Documentation
> would probably user-friendly. It tends to be hard to find stuff in
> specifications,
> especially if you're not very familiar with the standard.
There are over 100 commands, and the status bits can only be re
1) I just rebased libata-dev.git and all its branches. If you are
unfamiliar with git rebasing, this means you must either re-clone, or
force-update your branch like this:
# grab latest nv-swncq branch
URL=git://git.kernel.org/pub/scm/linux/kernel/git/jgarzik/libata-dev.git
cd /local/repo/li
Andrew Morton wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
>
> Now that we have DMA_BIT_MASK(), these macros are pointless.
>
Except, unfortunately, DMA_64BIT_MASK. I guess we could special case
it, assuming this works in all the contexts the macro is used in (ie,
compile-time constant?):
On Thu, 4 Oct 2007, Pallipadi, Venkatesh wrote:
> >-Original Message-
> >From: [EMAIL PROTECTED]
> >[mailto:[EMAIL PROTECTED] On Behalf Of
> >Thomas Gleixner
> >Sent: Monday, October 01, 2007 11:19 PM
> >To: Andi Kleen
> >Cc: Arjan van de Ven; David Bahi; LKML;
> >[EMAIL PROTECTED]; Andr
linux-os (Dick Johnson) wrote:
It makes no sense because a bitfield is something having to
do with a 'C' compiler and it must NEVER be used as a template
to address hardware! 'C' gives no guarantee of the ordering
within machine words. The only way you can access them is
using 'C'. They don't ha
Keir Fraser wrote:
> The PREEMPT_BITS limitation is a good argument for at least taking the pte
> locks in small batches though (small batches is preferable to one-by-one
> since we will want to batch the make-readonly-and-pin hypercall requests to
> amortise the cost of the hypervisor trap).
Hm,
On Fri, 5 Oct 2007, Timur Tabi wrote:
> Andreas Schwab wrote:
>
>> The bit mapping on your device is strictly internal to the device and
>> has nothing to do with bit order on the C level.
>
> Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD.
What does it mean for a C-l
On Thu, 2007-10-04 at 17:02 -0400, Chuck Ebbert wrote:
> On 10/04/2007 04:55 PM, David Miller wrote:
> >
> > Anything, I do mean anything, can be simulated using small test
> > programs.
>
> How do you simulate reading 100TB of data spread across 3000 disks,
> selecting 10% of it using some crit
On Fri, 2007-10-05 at 07:54 -0700, Badari Pulavarty wrote:
> On Fri, 2007-10-05 at 15:41 +0200, Valerie Clement wrote:
> > Badari Pulavarty wrote:
> > > On Thu, 2007-10-04 at 18:13 +0200, Valerie Clement wrote:
> > >> While running ffsb tests on my ext4 filesystem, I got an Oops in
> > >> cache_al
Hi Jan,
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Jan
> Engelhardt
> Sent: Friday, October 05, 2007 2:14 PM
> To: Linux Kernel Mailing List
> Cc: Andrew Morton
> Subject: [PATCH] Cute feature: colored printk output
>
>
> Colored kernel mes
Hi
Ok, after a day of biseting, it turns out to be a compiler problem. The
gcc-3.3.5 produces at least these two problems (Oops on i2c-viapro probe
and disabled IRQs in USB), whereas 4.1.2 has no problem so far. Up to now
3.3.5 had no problem compiling 2.6.20+ kernels here, for example, for P-I
From: Randy Dunlap <[EMAIL PROTECTED]>
For cases in which CONFIG_PCIEAER=y (such as distro kernels), allow users
to disable PCIE Advanced Error Reporting by using "pci=noaer" on the
kernel command line.
This can be used to work around hardware or (kernel) software problems.
Signed-off-by: Randy
Stephen Smalley <[EMAIL PROTECTED]> writes:
> On Fri, 2007-10-05 at 09:27 -0700, Casey Schaufler wrote:
>> --- Kyle Moffett <[EMAIL PROTECTED]> wrote:
>>
>> > On Oct 05, 2007, at 00:45:17, Eric W. Biederman wrote:
>> > > Kyle Moffett <[EMAIL PROTECTED]> writes:
>> > >
>> > >> On Oct 04, 2007, at
--- Stephen Smalley <[EMAIL PROTECTED]> wrote:
> ...
>
> > Good suggestion. In fact, that is exactly how I approached my
> > first two attempts at the problem. What you get if you take that
> > route is an imposing infrastructure that has virually nothing
> > to do and that adds no value to the
Hi Bart,
On Fri, 5 Oct 2007 11:32:35 +0200, Bart Van Assche wrote:
> From: Bart Van Assche
>
> Add support for the PCF8575 I2C chip.
Please read MAINTAINERS and send your patch to the right list.
Thanks,
--
Jean Delvare
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
Andreas Schwab wrote:
The bit mapping on your device is strictly internal to the device and
has nothing to do with bit order on the C level.
Then I don't understand that point of defining __LITTLE_ENDIAN_BITFIELD. What
does it mean for a C-level bitfield ordering to be little-endian if the
Timur Tabi <[EMAIL PROTECTED]> writes:
> I'm writing a driver that talks to hardware that has a shift register.
> The register can be shifted either left or right, so all the bits
> obviously have to be in order, but it can be either order.
Bit addressing is strictly internal to the cpu, the smal
On Fri, 05 Oct 2007 12:40:05 -0700
Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> Well, isn't the correct fix to make Xen take all the pagetable locks
> while pinning/unpinning? Adding exception handling to
> test_and_clear_bit would solve this particular race, but are there
> others (either no
On Oct 5 2007 15:43, Lennart Sorensen wrote:
>On Fri, Oct 05, 2007 at 09:32:11PM +0200, Jan Engelhardt wrote:
>> Ah you seem to be a proponent of http://www.blackgoogle.com/
>> then :-) Unfortunately, it seems like Xft uses Grayscale AA
>> (http://antigrain.com/research/font_rasterization/index.h
1 - 100 of 288 matches
Mail list logo
