* Mitchell Erblich <[EMAIL PROTECTED]> wrote:
> First, RT/RR tasks are not deprecated. [...]
I'm confused, do you say this in reference to anything i said? I did not
say that RR tasks are deprecated and you were top-posting so i cannot
connect it to anything specific. I only said RR tasks are
> > + case PARAVIRT_PATCH(make_pgd):
> > + case PARAVIRT_PATCH(pgd_val):
> > + case PARAVIRT_PATCH(make_pte):
> > + case PARAVIRT_PATCH(pte_val):
> > + case PARAVIRT_PATCH(make_pmd):
> > + case PARAVIRT_PATCH(pmd_val):
> > + case PARAVIRT_PATCH(make_pud):
> > + case
From: Jeff Garzik <[EMAIL PROTECTED]>
Date: Thu, 09 Aug 2007 02:31:11 -0400
> Either way, I'll want you to push to Linus before I do, when the next
> merge window opens.
No problem.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTE
Glauber de Oliveira Costa wrote:
>>> +/*
>>> + * integers must be use with care here. They can break the
>>> PARAVIRT_PATCH(x)
>>> + * macro, that divides the offset in the structure by 8, to get a number
>>> + * associated with the hook. Dividing by four would be a solution, but it
>>> + * would
On Sat, Aug 04, 2007 at 06:37:33PM +0200, Ingo Molnar wrote:
> * Linus Torvalds <[EMAIL PROTECTED]> wrote:
>> The fact is, ext3 *sucks* at fsync. I hate hate hate it. It's
>> totally unusable, imnsho.
> yeah, it's really ugly. But otherwise i've got no real complaint
> about ext3 - with the oblig
On Thu, 2007-08-09 at 11:23 +0900, Miao Xie wrote:
> Hi everyone,
>
>I find a function(clockevents_unregister_notifier) which is not
> called by anything in tree.
>
> Signed-off-by: Miao Xie <[EMAIL PROTECTED]>
Acked-by: Thomas Gleixner <[EMAIL PROTECTED]>
-
To unsubscribe from this list:
On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> > Does it really matter?
> >
>
> Well, yes, if alignment is an issue.
Of course, But the question rises from the context that they are both
together at the beginning. So they are not making anybody non-aligned.
Then the question: Why w
Glauber de Oliveira Costa wrote:
> On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
>
>>> Does it really matter?
>>>
>>>
>> Well, yes, if alignment is an issue.
>>
> Of course, But the question rises from the context that they are both
> together at the beginning. So they ar
On Fri, 03 Aug 2007 12:37:12 -0600 Jonathan Corbet <[EMAIL PROTECTED]> wrote:
> Here's the second (and probably final) posting of the msleep() with
> hrtimers patch. The problem being addressed here is that the current
> msleep() will stop for a minimum of two jiffies, meaning that, on a
> HZ=100
Hi Mark,
On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote:
> Hi Joerg:
>
> * Joerg Sommrey <[EMAIL PROTECTED]> [2007-08-08 17:17:16 +0200]:
> > Hi Mark,
> >
> > just to eliminate as many impacts as possible, I did:
> > - reinstall the unmodified sensors.conf from Tyan's support pa
jidong xiao wrote:
> On 8/9/07, H. Peter Anvin <[EMAIL PROTECTED]> wrote:
>> No. There is no requirement that the pointer is page-aligned. The last
>> page of the address space is (in the Linux kernel) invalid by
>> definition, so there are in effect three kinds of pointers in the Linux
>> kernel
(I'm not subscribed to lkml, please CC me in your replies)
Anyone have an HP Pavilion DV6000 series laptop (mine's a dv6408nr to
be exact) that successfully brings up both cores of its AMD Turion 64
X2 TL-56 and is stable? I get the feeling that there's a problem with
the APIC, or ACPI or even bo
The config system doesn't show the power supply class menu if arch=arm, this
patch fixes it.
Signed-off-by: Mike Rapoport <[EMAIL PROTECTED]>
diff --git a/arch/arm/Kconfig b/arch/arm/Kconfig
index d614529..9f7c6de 100644
--- a/arch/arm/Kconfig
+++ b/arch/arm/Kconfig
@@ -1026,6 +1026,8 @@ source
Mikko Rapeli wrote:
> Hello,
>
> Since 2.6.23-rc1 I can't boot an old k6 (with a funky IDE drive worth testing
> with libata). The boot hangs without a sound or letter prints on the
> screen right after grub, while 2.6.22.1 works fine.
>
So it's not printing "Uncompressing kernel... " at all?
>
On Thu, Aug 09 2007, Adrian Bunk wrote:
> This patch fixes the following 2.6.23 regression:
>
> <-- snip -->
>
> ...
> scripts/kconfig/conf -d arch/cris/Kconfig
> arch/cris/Kconfig:183: can't open file "drivers/cdrom/Kconfig"
> make[2]: *** [defconfig] Error 1
>
> <-- snip -->
>
> Signed-of
On 8/8/07, Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > +#ifdef CONFIG_PARAVIRT
> > +#include
> > +# ifdef CONFIG_X86_VSMP
> > +static inline int raw_irqs_disabled_flags(unsigned long flags)
> > +{
> > + return !(flags & X86_EFLAGS_IF) || (flags & X86_EFLAGS_AC);
> > +}
> > +# else
> > +stati
Linus Torvalds wrote:
On Wed, 8 Aug 2007, Chris Snook wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
Am Mittwoch 08 August 2007 23:36 schrieb Jesper Juhl:
> On 19/07/2007, Greg Kroah-Hartman <[EMAIL PROTECTED]> wrote:
> > From: Hans J. Koch <[EMAIL PROTECTED]>
> >
> > Documentation for the UIO interface
> >
> ...
> > +If you use UIO for your card's driver, here's what you get:
> > +
> ...
> > +
>
Herbert Xu wrote:
Chris Snook <[EMAIL PROTECTED]> wrote:
Some architectures currently do not declare the contents of an atomic_t to be
volatile. This causes confusion since atomic_read() might not actually read
anything if an optimizing compiler re-uses a value stored in a register, which
can b
On Thu, Aug 09, 2007 at 12:25:02AM -0700, H. Peter Anvin wrote:
> So it's not printing "Uncompressing kernel... " at all?
Yes, nothing comes up. Machine responds to three-finger-salute and
numlock status can be changed, though.
> It might be an issue with the new setup code. What happens if you
On Thu, Aug 09, 2007 at 01:03:39AM +0200, Jesper Juhl wrote:
> >
> I think the only way to avoid it is to not provide something like UIO.
Problem is, things like UIO provide a real solution for a wide range of
different types of devices. Like the one provided in the kernel right
now, and a bunch
hello,
i have a linux kernel usb module driver and would like to probe it,
i'v worked by the usbled.c file and didn't understand who the
led_probe(struct usb_interface *interface, const struct usb_device_id *id)
function receive it's paramerts, the struct have the
.probe = led_probe,
file
> Hi,
>
> I see there is a bit of complaining on this original resend temporary
> patch. But, since it seems to do a good job for some people, here is
> my proposal to limit the 'range of fire' a little bit.
>
> Marcin and Jean-Baptiste: try to test this with 2.6.23-rc2, please.
> (Unless Ingo or
On Thu, Aug 09, 2007 at 03:31:10AM -0400, Chris Snook wrote:
> Linus Torvalds wrote:
> > I'd be *much* happier with "atomic_read()" doing the "volatile" instead.
> > The fact is, volatile on data structures is a bug. It's a wart in the C
> > language. It shouldn't be used. Volatile accesses in *c
Changelog between this version and previous version (v3 of x86_64 EFI
support patch).
1. The include files of efifb.c is cleaned up.
2. Make CONFIG_FB_EFI do not depend on CONFIG_EFI.
---
This patch adds Graphics Output Protocol support to the kernel.
UEFI2.0 spec deprecates Universal Graphics A
Because supporting booting Linux kernel and supporting UEFI runtime
service on x86_64 UEFI platform are two separate steps. I decide to
push the booting support patches firstly, so that, the essential part
of UEFI64 support can go into mainstream kernel firstly.
---
Following sets of patches add
Hi Rafal, thank you for your help!
On Wednesday 08 August 2007 22:08:18 Rafał Bilski wrote:
> > Hello again,
>
> Hi,
>
> > I 'm now using libata on the same system described before (see attached
> > dmesg.txt). When writing to both disks I think the problem is now worse
> > (pata_oprof_bad.txt, p
This patch adds document for EFI x86_64 boot support. The setup and
operation guide of EFI based system is documented in
Documentation/x86_64/uefi.txt.
Signed-off-by: Chandramouli Narayanan <[EMAIL PROTECTED]>
Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
uefi.txt | 29
On 09/08/07, Mitchell Erblich <[EMAIL PROTECTED]> wrote:
> sched_rt.c : requeue_task_rt()
>
> The comment states the problem requeue no dequeue.
> Put task to the end of the run list without the overhead of dequeue
> followed by enqueue.
>
> dequeue_task_rt() updates stats. Where without calling
>
> On Wed, Aug 08, 2007 at 07:16:23PM +0200, Andreas Gruenbacher wrote:
> > Split up struct nameidata into struct vfs_lookup with the lookup result
> > and intent and the remaining fields for performing an actual lookup.
>
> Looks good as a start, but please don't put a struct path in there,
> as t
* Dmitry Adamushko <[EMAIL PROTECTED]> wrote:
> I guess, the following thing would do a better job:
>
> - we do need reschedule() _only_ if there are other task on the _same_
> queue (for this prio level) :
ah, indeed.
> --- kernel/sched_rt-prev.c 2007-08-09 09:55:10.0 +0200
> ++
On 08/08/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Mitchell Erblich <[EMAIL PROTECTED]> wrote:
>
> > After
> > p->time_slice = static_prio_timeslice(p->static_prio);
> >
> > Why isn't their a check like
> > if (rq->nr_running == 1)
> > return;
> >
> > Which world remove the
Andi Kleen wrote:
>>Not everyone likes frame buffer
>
>
> You don't need the frame buffer; cards typically have text mode
> fonts upto 80x50. The node numbers vary, but you can find out yours
> with vga=ask
>
>
>>but even with it any OOPs in
>>network code which happens in softirq, io schedul
FYI, that's the patch i applied:
--->
Subject: sched: optimize task_tick_rt() a bit
From: Dmitry Adamushko <[EMAIL PROTECTED]>
Mitchell Erblich suggested a change to not requeue SCHED_RR
tasks if there's only a single task on the runqueue, by
checking for rq->nr_running =
On 09/08/07, Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> FYI, that's the patch i applied:
Thanks. Added my SOB below.
>
> --->
> Subject: sched: optimize task_tick_rt() a bit
> From: Dmitry Adamushko <[EMAIL PROTECTED]>
>
> Mitchell Erblich suggested a change to not requeue
On Thu, 9 Aug 2007, Huang, Ying wrote:
> Changelog between this version and previous version (v3 of x86_64 EFI
> support patch).
>
> 1. The include files of efifb.c is cleaned up.
> 2. Make CONFIG_FB_EFI do not depend on CONFIG_EFI.
BTW, the recommended place to put changelogs (so the tools will
On 09/08/07, Mitchell Erblich <[EMAIL PROTECTED]> wrote:
> 1) * Possible wasted stats overhead during dequeue..
> sched_rt.c:
> Is RT check needed within a RT func?
> dequeue_task_rt() calls update_curr_rt()
> which checks for priority of RR or FIFO.
> [ ... ]
> Thus, I think those two lines could
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23-rc2/2.6.23-rc2-mm1/
- Added new NFSD development tree as git-nfsd ("J. Bruce Fields"
<[EMAIL PROTECTED]>)
- There is a new e1000 driver in git-netdev-all, called e1000e. I'm sure
the developers would like it tested. Plea
Jerry Jiang <[EMAIL PROTECTED]> wrote:
> On Wed, 8 Aug 2007 21:18:25 -0700 (PDT)
>> On Wed, 8 Aug 2007, Chris Snook wrote:
>> > Some architectures currently do not declare the contents of an atomic_t to
>> > be
>> > volatile. This causes confusion since atomic_read() might not actually
>> > read
On Wed, Aug 08, 2007 at 01:42:43PM +0200, Jarek Poplawski wrote:
> Read below please:
>
> On Wed, Aug 08, 2007 at 01:09:36PM +0200, Marcin Ślusarz wrote:
> > 2007/8/7, Jarek Poplawski <[EMAIL PROTECTED]>:
> > > So, the let's try this idea yet: modified Ingo's "x86: activate
> > > HARDIRQS_SW_RESEN
On Thu, 09 Aug 2007 11:10:16 +0200
Bodo Eggert <[EMAIL PROTECTED]> wrote:
> >
> > Why the *volatile-accesses-in-code* is acceptable, does C standard make it
> > clear?
>
> http://lwn.net/Articles/233482/
I have read this article before, but What Linus said only focusing on
the conclusion-- The
This is not really a patch series, just random pending stuff. None of
it is 2.6.23 material I think.
Thanks,
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-
From: Miklos Szeredi <[EMAIL PROTECTED]>
Subtype handling was done in do_kern_mount(), but "unprivileged
mounts: allow unprivileged mounts" patch made do_new_mount() use
vfs_kern_mount(). This broke the filesystem subtype handling.
Fix this by moving the subtype handling from do_kern_mount() int
From: Miklos Szeredi <[EMAIL PROTECTED]>
utimensat() (and possibly other callers of do_utimes()) didn't check
if the nanosecond value was within the allowed range.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/utimes.c
=
From: Miklos Szeredi <[EMAIL PROTECTED]>
vfs_permission(MAY_EXEC) checks if the filesystem is mounted with
"noexec", so there's no need to repeat this check in sys_uselib() and
open_exec().
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/exec.c
=
On Thu, 2007-08-09 at 11:13 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
> > Nope, you would just fulfill in a completely generic way all outstanding
> > requests when you are ready. All requests are all nicely grouped and
> > visible in sysfs. There would be no need of codi
On Thu, 09 Aug 2007 11:13:12 +0200,
Javier Pello <[EMAIL PROTECTED]> wrote:
> On Tue, 07 Aug 2007, Kay Sievers wrote:
> > Nope, you would just fulfill in a completely generic way all outstanding
> > requests when you are ready. All requests are all nicely grouped and
> > visible in sysfs. There wo
From: Miklos Szeredi <[EMAIL PROTECTED]>
Define a new function fuse_refresh_attributes() that conditionally
refreshes the attributes based on the validity timeout.
In fuse_permission() only refresh the attributes for checking the
execute bits if necessary.
Signed-off-by: Miklos Szeredi <[EMAIL P
From: Miklos Szeredi <[EMAIL PROTECTED]>
The patch titled "fuse: fix permission checking on sticky directories"
removed all but the S_IFMT bits from i_mode.
However some of these are unfortunately used by the VFS, such as the
execute, suid and sgid bits.
So only remove the sticky bit, which is u
From: Miklos Szeredi <[EMAIL PROTECTED]>
permission() checks that MAY_EXEC is only allowed on regular files if
at least one execute bit is set in the file mode.
generic_permission() already ensures this, so the extra check in
permission() is superfluous.
If the filesystem defines it's own ->perm
From: Miklos Szeredi <[EMAIL PROTECTED]>
It looks like in the end all pruners want parents removed.
So remove unused code and function arguments.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/dcache.c
===
--
From: Miklos Szeredi <[EMAIL PROTECTED]>
Fix following warnings introduced by
fs-introduce-write_begin-write_end-and-perform_write-aops-revoke.patch
fs/revoked_inode.c:381: warning: ârevoked_write_beginâ defined but not used
fs/revoked_inode.c:388: warning: ârevoked_write_endâ defined bu
From: Miklos Szeredi <[EMAIL PROTECTED]>
Currently hostfs_getattr() just defines the default behavior.
Signed-off-by: Miklos Szeredi <[EMAIL PROTECTED]>
---
Index: linux/fs/hostfs/hostfs_kern.c
===
--- linux.orig/fs/hostfs/hostfs_ke
Signed-off-by: Joachim Fenkes <[EMAIL PROTECTED]>
---
This patch should apply cleanly on top of Stefan's recent patchset. Please
review and apply for 2.6.23. Thanks.
drivers/infiniband/hw/ehca/ehca_hca.c | 10 +++---
1 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/drivers/in
On Tue, 07 Aug 2007, Cornelia Huck wrote:
> So it is indeed that this driver wants to fail its probe if it
> cannot get the firmware.
That's right. The driver unbinds itself from the device if it doesn't
get the firmware.
> A possibilty to achieve a similar effect would be to use
> request_firmw
Hi Adrian,
On Sun, 29 Jul 2007 16:57:08 +0200, Adrian Bunk wrote:
> After the i2c-isa removal some code can become static.
>
> Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
>
> ---
>
> drivers/i2c/i2c-core.c |7 +++
> include/linux/i2c.h|2 --
> 2 files changed, 3 insertions(+
On Tue, 07 Aug 2007, Kay Sievers wrote:
> Nope, you would just fulfill in a completely generic way all outstanding
> requests when you are ready. All requests are all nicely grouped and
> visible in sysfs. There would be no need of coding your own device
> specific rebind. No timeout is needed or w
On Thursday 09 August 2007 01:52:37 Frank Hale wrote:
> I have the latest BIOS update for my laptop which is buggy I suppose.
> There has been only one update this year if my memory serves me
> correctly. Is there any hope to fix this or am I at the mercy of the
> hardware vendor which apparenlty d
Eric W Biederman wrote:
> >> This is the classic skip the 16bit code and enter the kernel
> >> in 32bit mode filling in the fields that the 16bit mode code would
> >> have filled in the same way approach.
> > ..
> >
> > For in tree code it can be just updated. But weirdo-EFI-boot loader
> > can
Chris Holvenstot wrote:
I think that I may have spotted a minor bug in the 2.6.23 kernel and its
relationship with the EXT3 file system. I apologize in advance if I am
mistaken, reporting a problem that is already known (I did not spot it
in Bugzilla) or if I am reporting it to the wrong forum.
On 8/8/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
> On Wed, 2007-08-08 at 14:16 -0700, Darren Hart wrote:
>
> > It seems to me that this patch will reduce the frequency of irqd/softirqd
> > starvation, but the core problem still exists: softirq tasks can't migrate
> > to
> > other CPUs to perfo
On Thu, 2007-08-09 at 16:50 +1000, Neil Brown wrote:
> On Tuesday August 7, [EMAIL PROTECTED] wrote:
> > On 8/7/07, Neil Brown <[EMAIL PROTECTED]> wrote:
> > > On Monday August 6, [EMAIL PROTECTED] wrote:
> > > > On Tue, 2007-08-07 at 16:07 +1000, Neil Brown wrote:
> > > > > Suppose that in a progr
On Thursday 09 August 2007 03:42:54 Nick Piggin wrote:
> On Wed, Aug 08, 2007 at 12:26:55PM +0200, Andi Kleen wrote:
> >
> > > *
> > > * (the type definitions are in asm/spinlock_types.h)
> > > */
> > >
> > > +#if (NR_CPUS > 256)
> > > +#error spinlock supports a maximum of 256 CPUs
> > >
When someone wants to deal with some other taks's namespaces
it has to lock the task and then to get the desired namespace
if the one exists. This is slow on read-only paths and may be
impossible in some cases.
E.g. Oleg recently noticed a race between unshare() and the
(sent for review in contai
On Sat, Aug 04, 2007 at 10:44:26AM +0200, Matthias Hensler wrote:
> On Fri, Aug 03, 2007 at 11:34:07AM -0700, Andrew Morton wrote:
> [...]
> I am also willing to try the patch posted by Richard.
I want to give some update here:
1. We finally hit the problem on a third system, with a total differe
Hallo,
I thought a bit about the zero page problem. I really would prefer to not
having it used in a boot loader right now because it's not extensible anymore
when external users start (ab)using it.
When I asked for separate EFI->e820 functions I was really thinking
of the kernel to do the conve
Hello,
Happens every time I reattach usb pen drive.
usb 1-2: new high speed USB device using ehci_hcd and address 10
usb 1-2: configuration #1 chosen from 1 choice
scsi6 : SCSI emulation for USB Mass Storage devices
usb 1-2: new device found, idVendor=13fe, idProduct=1a00
usb 1-2: new dev
On Wed, Aug 08, 2007 at 08:15:32PM +0200, Martin Wilck wrote:
> Vivek Goyal wrote:
>
> > But the issue here seems to be that LAPIC state got clear but IRR bit
> > at IOAPIC bit is not cleared because IOAPIC vector information was deleted
> > in first kernel and now upon receiving EOI, it does not
Since the network device documentation needs a rewrite, I was thinking
of using basic html format instead of just plain text. But since this would
be starting an new precedent for kernel documentation, some it seemed
like a worthwhile topic for discussion.
Advantages of html:
* basic formatting
On Aug 9 2007 11:31, Stephen Hemminger wrote:
>
>Since the network device documentation needs a rewrite, I was thinking
>of using basic html format instead of just plain text. But since this would
>be starting an new precedent for kernel documentation, some it seemed
>like a worthwhile topic for d
> Note that Gujin has a simple problem by using that 32 bits entry point:
There is really no 32bit entry point today usable for external users. Or rather
it might by chance work today, but if we change the zero page (and there
is no guarantee it'll not be changed). I can pretty much guarantee it
If a Guest makes hypercall which sets a GDT entry to not present, we
currently set any segment registers using that GDT entry to 0.
Unfortunately, this is not sufficient: there are other ways of
altering GDT entries which will cause a fault.
The correct solution to do what Linux does: let them set
lguest uses a host-supplied wallclock-based clocksource when the TSC
is not reliable. As this is already in nanoseconds, I naively used a
multiplier of 1 and a shift of 0.
But update_wall_time() in its infinite wisdom decides to adjust the
clock a little (where does it think it's getting a more a
From: Ronald G. Minnich <[EMAIL PROTECTED]>
[ FC7 maps shared libraries very low, where the launcher maps guest's
physical memory. Quick fix is to link Launcher static, real fix is for
2.6.24. ]
-static is a simple fix. I expect this problem will be more common than we
like, as different distro'
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
>
> If they're not doing anything, sure. Plenty of loops actually do some sort
> of real work while waiting for their halt condition, possibly even work
> which is necessary for their halt condition to occur, and you definitely
> don'
LTP run reproducably hangs during rwtest01 test
rwtest -N rwtest01 -c -q -i 60s -f sync 10%25000:rs-sync=$$
Calltrace is always the same:
INFO: trying to register non-static key
__lock_acquire+0x210/0xc9e
lock_acquire+0x87/0xa3
_spin_lock_irqsave+0x2f/0x5f
prop_norm
The README file in the cramfs subdirectory says:
"All data is currently in host-endian format; neither mkcramfs nor the
kernel ever do swabbing."
If somebody tries to mount a cramfs with the wrong endianess,
cramfs only complains about a wrong magic but doesn't inform
the user that only the endia
--- Andi Kleen <[EMAIL PROTECTED]> wrote:
> > Note that Gujin has a simple problem by using that 32 bits entry point:
>
> There is really no 32bit entry point today usable for external users.
That is why I added the 16 bits entry point support (selected by default),
my target with Gujin was not
> Chris Snook wrote:
>
>The problem here is that your clock is wrong either at mount (boot)
>time or unmount (shutdown) time. There's nothing wrong with ext3,
>except that it happens to be noticing this condition.
Chris -
I appreciate the response but on the face of it I do not know if I
believ
Herbert Xu wrote:
On Thu, Aug 09, 2007 at 03:47:57AM -0400, Chris Snook wrote:
If they're not doing anything, sure. Plenty of loops actually do some sort
of real work while waiting for their halt condition, possibly even work
which is necessary for their halt condition to occur, and you defini
On Thu, 2007-08-09 at 11:36 +0200, Javier Pello wrote:
> On Tue, 07 Aug 2007, Cornelia Huck wrote:
>
> > So it is indeed that this driver wants to fail its probe if it
> > cannot get the firmware.
>
> That's right. The driver unbinds itself from the device if it doesn't
> get the firmware.
>
> >
On Wed, 8 Aug 2007 22:05:13 +0200 (CEST)
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
>
> On Aug 8 2007 09:48, Andrew Morton wrote:
> >> > On Mon, 6 Aug 2007 09:54:03 -0400
> >> > Jeff Layton <[EMAIL PROTECTED]> wrote:
> >> >
> >> > Is there any way in which we can prevent these problems? Say
> >>
On Thu, 2007-08-09 at 06:39 +0300, jonatan perry wrote:
> Hello,
> I would like to know who the USB system works under linux, I mean,
> I would like to write a kernel module who will create a virtual USB
> device, so that the kernel will think that a hardware USB device is
> exists, were can I star
On Wed, 8 Aug 2007 23:31:14 +0200
Adrian Bunk <[EMAIL PROTECTED]> wrote:
>
> CONFIG_MMC_ARMMMCI=m/y results in the following compile error:
>
> <-- snip -->
>
> ...
> CC [M] drivers/mmc/host/mmci.o
> /home/bunk/linux/kernel-2.6/linux-2.6.23-rc1-mm2/drivers/mmc/host/mmci.c:
> In function
>
Glauber de Oliveira Costa wrote:
On 8/8/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
Add a generic lg.h file to call the architecture specific one.
diff --git a/drivers/lguest/lg.h b/drivers/lguest/lg.h
new file mode 100644
index 000..4c4356e
--- /dev/null
+++ b/drivers/lguest/lg.h
@@ -0,0
--
On Wed, 8 Aug 2007, Jeremy Fitzhardinge wrote:
> Steven Rostedt wrote:
> > /*
> > * x86 arch doesn't have an easy way to find out where
> > * gs is located. So we need to read the MSR. But first
> > * we need to save off the rcx, rax and rdx.
> >
> Why don't you store it in g
Hi All,
We are running vanilla 2.6.22 linux kernel in i.MX 21 lite kit,
patched for our board and utilizing the generic touchscreen driver
drivers/input/touchscreen/ads7846.c for our touch screen. We have
changed the register values in spi_imx.c for i.MX21. The code seems to
run but we are not
Hello all,
This patch is intended to fix compilation errors when I tried to add in
power management to my Atmel AT91SAM9260 board. First, there is no
separate memory controller in the 9260 as there is in the 9200, so calls
to do anything with it in pm.c fail.
Secondly, at91_suspend_entering_slow_
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> Hi Steven,
>
> I am just being pedantic here (and I should have beaten up on Rusty
> before now ... :-)
>
> On Thu, 09 Aug 2007 00:36:30 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > --- a/include/asm-i386/lg.h
> > +++ b/include/asm-i38
--
On Thu, 9 Aug 2007, Stephen Rothwell wrote:
> Hi Steven,
>
> On Thu, 09 Aug 2007 00:36:31 -0400 Steven Rostedt <[EMAIL PROTECTED]>
> wrote:
> >
> > Well, some may be merged with x86_64 later, but for now we move them
> > out of the way. Later on we can start seeing how we can combine
> > som
Stephen Rothwell wrote:
On Wed, 08 Aug 2007 20:32:15 -0400 Steven Rostedt <[EMAIL PROTECTED]>
wrote:
diff --git a/drivers/lguest/i386/lg.h b/drivers/lguest/i386/lg.h
index 64f0abe..c5ea14c 100644
--- a/drivers/lguest/i386/lg.h
+++ b/drivers/lguest/i386/lg.h
@@ -20,6 +20,8 @@
#include
#include
Am Donnerstag 09 August 2007 01:40 schrieb Alan Cox:
> > On the other hand, given that we've always said that closed-source stuff in
> > userspace is OK, the only way to not let *that* horse out of the barn is to
> > not merge UIO at all.
>
> It really makes no difference whether it is merged or n
On 8/9/07, Chris Holvenstot <[EMAIL PROTECTED]> wrote:
> > Chris Snook wrote:
> >
> >The problem here is that your clock is wrong either at mount (boot)
> >time or unmount (shutdown) time. There's nothing wrong with ext3,
> >except that it happens to be noticing this condition.
>
> 1. This happens
--
On Thu, 9 Aug 2007, Jeremy Fitzhardinge wrote:
> Glauber de Oliveira Costa wrote:
> > On 8/9/07, Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> >
> >>> Does it really matter?
> >>>
> >>>
> >> Well, yes, if alignment is an issue.
> >>
> > Of course, But the question rises from the context tha
On Wed, Aug 08, 2007 at 05:28:46PM -0700, Joe Perches wrote:
> Some uses of printk are missing KERN_ on the second
> and subsequent lines.
>
> For instance:
>
> printk(KERN_INFO "line1: %d\nline2: %d\n", val1, val2);
>
> Line1 is marked log_level: info
> Line2 is marked log_level: unknown
>
>
Hi Joerg:
> On Wed, Aug 08, 2007 at 11:56:42PM -0400, Mark M. Hoffman wrote:
> > Thanks for sending all that. I see one bug clearly, and I'm pretty close to
> > seeing the other one. But for tonight, I need sleep.
There's just one bug after all. The second was a figment of my sleep-deprived
im
Jan Engelhardt <[EMAIL PROTECTED]> wrote:
> On Aug 9 2007 11:31, Stephen Hemminger wrote:
>>Since the network device documentation needs a rewrite, I was thinking
>>of using basic html format instead of just plain text. But since this would
>>be starting an new precedent for kernel documentation,
On Thu, 02 Aug 2007 20:20:44 +0200
Gabriel C <[EMAIL PROTECTED]> wrote:
> This patch fixes the following section mismatch warnings
>
> ...
>
> WARNING: vmlinux.o(.init.text+0x29d40): Section mismatch: reference
> to .exit.text:wbsd_release_resources (between 'wbsd_init' and
> 'wbsd_probe') WARNI
On Thursday 09 August 2007 02:15:33 Andi Kleen wrote:
> On Wed, Aug 08, 2007 at 05:08:44PM -0400, Chris Snook wrote:
> > Heiko Carstens wrote:
> > >On Wed, Aug 08, 2007 at 03:21:31AM -0700, David Miller wrote:
> > >>From: Heiko Carstens <[EMAIL PROTECTED]>
> > >>Date: Wed, 8 Aug 2007 11:33:00 +0200
--
On Thu, 9 Aug 2007, Robert de Vries wrote:
> On 8/8/07, Steven Rostedt <[EMAIL PROTECTED]> wrote:
>
> Wouldn't a developer of a real-time system configure the system so
> that interrupts do not interfere with the real-time tasks running on a
> specific CPU?
You would think. But that's somethin
1 - 100 of 568 matches
Mail list logo
