[cc'ing folks whose proc files are affected]
kallsyms_lookup() can call module_address_lookup() which iterates over
modules list without module_mutex taken. Comment at the top of
module_address_lookup() says it's for oops resolution so races are
irrelevant, but in some cases it's reachable from
Alexey Dobriyan wrote:
[cc'ing folks whose proc files are affected]
kallsyms_lookup() can call module_address_lookup() which iterates over
modules list without module_mutex taken. Comment at the top of
module_address_lookup() says it's for oops resolution so races are
irrelevant, but in some
On Thu, Mar 15, 2007 at 04:53:59PM +, Paulo Marques wrote:
> Alexey Dobriyan wrote:
> >[cc'ing folks whose proc files are affected]
> >
> >kallsyms_lookup() can call module_address_lookup() which iterates over
> >modules list without module_mutex taken. Comment at the top of
>
Actually thinking about this a little more I don't think we should put
this in. Instead this loop should be moved up to fs/read_write.c because
these are checks that we want for all filesystems/drivers that use
vectored I/O. We'll still need tiny loops to calculate the total
I/O length for now
On 3/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
On 3/14/07, STenyaK (Bruno González) <[EMAIL PROTECTED]> wrote:
>
>
> On 3/14/07, Anssi Hannula <[EMAIL PROTECTED]> wrote:
> > >> Do we have any idea if there any users of FF out there?
> > >
> > > At least me :). I'm using it for wheel and
On 3/14/07, STenyaK (Bruno González) <[EMAIL PROTECTED]> wrote:
On 3/14/07, Dmitry Torokhov <[EMAIL PROTECTED]> wrote:
> > I have a question: if the force is to be 3D, why only 3 possible values?
> > What would they be, 3 torques or 3 forces? In the case of car sims (ff
> > steering wheels),
On 3/15/07, johann deneux <[EMAIL PROTECTED]> wrote:
On 3/14/07, STenyaK (Bruno González) <[EMAIL PROTECTED]> wrote:
> Ideally, afaik we should use:
> -3 values for translation force (linear force): x,y,z components of
> the force vector.
> -4 values for rotation force (torque): x,y,z,w
> On Fri, 9 Mar 2007 16:41:53 +0100 CIJOML <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I am trying change Freecom DVB-T dongle with Leadtek DVB-T dongle and I got
> this OOPS:
>
> --
>
> usb 2-3: new high speed USB device using ehci_hcd and address 2
> usb 2-3:
Dne čtvrtek 15 březen 2007 09:03 Andrew Morton napsal(a):
> > On Fri, 9 Mar 2007 16:41:53 +0100 CIJOML <[EMAIL PROTECTED]> wrote:
> > Hi,
> >
> > I am trying change Freecom DVB-T dongle with Leadtek DVB-T dongle and I
> > got this OOPS:
> >
> > --
> >
> > usb 2-3:
Am Donnerstag, 15. März 2007 12:26 schrieb CIJOML:
> Hi,
>
> 2.6.20 is fine
>
> Michal
Could you narrow it down a bit? Does rc2 work?
Regards
Oliver
--
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
This signature is a legal requirement
-
To
Hi,
I already sent this e-mail to Luc and on the pwc mailing list,
and got no answer. I'm trying again with the hope that this patch
would go in the kernel...
I have a Cisco VT Camera, and it was just collecting dust. I
decided to try connecting it to my Linux box at
From: Christoph Hellwig <[EMAIL PROTECTED]>
Date: Thu, 15 Mar 2007 19:18:34 +
> On Thu, Mar 15, 2007 at 12:38:13PM +, Jan Beulich wrote:
> > While the kernel headers provide for this, there don't appear to be any
> > in-tree users (which seems contrary to general Linux policies). Would
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
> If there really was a grouping that was always guaranteed to match the
> way you wanted to group tasks for e.g. resource control, then yes, it
> would be great to use it. But I don't see an obvious candidate. The
> pid namespace is not
On 3/15/07, Srivatsa Vaddagiri <[EMAIL PROTECTED]> wrote:
On Thu, Mar 15, 2007 at 04:24:37AM -0700, Paul Menage wrote:
> If there really was a grouping that was always guaranteed to match the
> way you wanted to group tasks for e.g. resource control, then yes, it
> would be great to use it. But
On Thu, Mar 15, 2007 at 12:12:50PM -0700, Paul Menage wrote:
> There are some things that benefit from having an abstract
> container-like object available to store state, e.g. "is this
> container deleted?", "should userspace get a callback when this
> container is empty?".
IMO we can still get
On 03/14/2007 02:18 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
On 03/14/2007 01:31 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Sounds good. I don't see this in your patchset you sent yesterday
though; did you add it after sending out those patches?
Yes.
if so, could you forward
Dan Hecht wrote:
> So, yes, it is per-vcpu. But, the sched_clock() samples are rebased
> when processes are migrated between runqueues; search sched.c for
> most_recent_timestamp. It's not perfect since most_recent_timestamp
> between cpu0 and cpu1 do not correspond to the exact same instant,
Paul Mackerras wrote:
> A cycle on one thread of a machine with SMT/hyperthreading when the
> other thread is idle *isn't* equivalent to a cycle when the other
> thread is busy. We run into this on POWER5, where we have hardware
> that counts cycles when each of the two threads in each core gets
Dan Hecht wrote:
Available time is defined to be (real_time - stolen_time). i.e. time in
which the vcpu is either running or not ready to run [because it is
halted, and nothing is pending]).
From the guest perspective, steal time is:
"Time I would have liked to run"
--
Politics is the
Dan Hecht wrote:
> Available time is defined to be (real_time - stolen_time). i.e. time
> in which the vcpu is either running or not ready to run [because it is
> halted, and nothing is pending]).
Hm, the Xen definition of stolen time is "time VCPU spent in runnable
(vs running) or offline
On 03/15/2007 12:53 PM, Jeremy Fitzhardinge wrote:
Dan Hecht wrote:
Available time is defined to be (real_time - stolen_time). i.e. time
in which the vcpu is either running or not ready to run [because it is
halted, and nothing is pending]).
Hm, the Xen definition of stolen time is "time
Dan Hecht wrote:
Yes, the part in the "i.e." above is describing available time. So, it
is essentially is the same definition of stolen time VMI uses:
stolen time == ready to run but not running
available time == running or not ready to run
S390 too. We were quite careful to make
On 03/15/2007 01:14 PM, Rik van Riel wrote:
Dan Hecht wrote:
Yes, the part in the "i.e." above is describing available time. So,
it is essentially is the same definition of stolen time VMI uses:
stolen time == ready to run but not running
available time == running or not ready to run
Paravirt-ops guests which move the fixmap also end up moving the syscall
VDSO. This fails if it is prelinked at a fixed address, which is why
COMPAT_VDSO is broken under CONFIG_VMI (and also under CONFIG_XEN).
Several options are available to try to address this. Jan had cooked up
a patch
plz allow me to explain more.
"Why register-stack/memory-stack upside down is bad" is a bit complicated.
So...this is a test and result for explaining bug.
This is a sample code and its result on 2.6.21-rc3.
Note: base address of memory'stack can be randomly change.
== sample code ==
[EMAIL
Hello,
This patch (against 2.6.21-rc3-mm1) balances parenthesis in blackfin
header files.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
include/asm-blackfin/mach-bf535/bf535.h |4 ++--
include/asm-blackfin/scatterlist.h |2 +-
2 files changed, 3 insertions(+), 3
On 3/15/07, Mariusz Kozlowski <[EMAIL PROTECTED]> wrote:
This patch (against 2.6.21-rc3-mm1) balances parenthesis in blackfin
header files.
Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
thanks, added to our repo
-mike
-
To unsubscribe from this list: send the line "unsubscribe
This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Chris Wedgwood <[EMAIL
This patch allows for ibm-acpi to coexist (with diminished functionality) with
other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
not able to register ACPI notifiers for.
Signed-off-by: Henrique de Moraes Holschuh <[EMAIL PROTECTED]>
Cc: Chris Wedgwood <[EMAIL
On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> This patch allows for ibm-acpi to coexist (with diminished
> functionality) with other drivers like ACPI_BAY.
Given the ACP_IBM_BAY implementation is more complete (or seems to be,
please comment if that isn't the
On Thu, 15 Mar 2007 14:51:14 -0300
Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> This patch allows for ibm-acpi to coexist (with diminished functionality) with
> other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
> not able to register ACPI notifiers for.
On Thu, 15 Mar 2007, Chris Wedgwood wrote:
> On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> > This patch allows for ibm-acpi to coexist (with diminished
> > functionality) with other drivers like ACPI_BAY.
>
> Given the ACP_IBM_BAY implementation is more complete
On Thu, 15 Mar 2007 12:17:21 -0700
Chris Wedgwood <[EMAIL PROTECTED]> wrote:
> On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
>
> > This patch allows for ibm-acpi to coexist (with diminished
> > functionality) with other drivers like ACPI_BAY.
>
> Given the
On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
> this patch gives me the following compile error:
>
> drivers/acpi/ibm_acpi.c: In function ???ibm_init???:
> drivers/acpi/ibm_acpi.c:2605: warning: implicit declaration of function
> ???ibm_exit???
> drivers/acpi/ibm_acpi.c: At top level:
>
On Thu, 15 Mar 2007, Kristen Carlson Accardi wrote:
> I haven't followed the ibm_acpi development lately, but when I first
> wrote the bay driver, it had a couple features that ibm_acpi didn't have,
> and then of course, is missing some it does have. What used to be the
> case is that if bay was
On Thu 15. Mar - 12:37:32, Kristen Carlson Accardi wrote:
> On Thu, 15 Mar 2007 12:17:21 -0700
> Chris Wedgwood <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Mar 15, 2007 at 02:51:14PM -0300, Henrique de Moraes Holschuh wrote:
> >
> > > This patch allows for ibm-acpi to coexist (with diminished
> > >
On Mon, 12 Mar 2007 18:22:45 + Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> Following this email are three patches which represent the
> current state of the lumpy reclaim patches; collectively lumpy V5.
So where do we stand with this now?Does it make anything get better?
I (continue to)
On Thu, 15 Mar 2007 14:35:17 EDT, Rik van Riel said:
> [EMAIL PROTECTED] wrote:
> > On Wed, 14 Mar 2007 22:33:17 BST, Andreas Mohr said:
> >
> >> it'd seem we need some kind of state management here to figure out good
> >> intervals of when to call mark_page_accessed() *again* for this page. E.g.
On Mon, 12 Mar 2007, [EMAIL PROTECTED] wrote:
>
> From: Sukadev Bhattiprolu <[EMAIL PROTECTED]>
> Subject: [PATCH 2/2] Replace pid_t in autofs with struct pid reference.
>
> Make autofs container-friendly by caching struct pid reference rather
> than pid_t and using pid_nr() to retreive a
On Wed, 2007-03-14 at 01:08 -0400, Steven Rostedt wrote:
> [Hopefully fixed email client to make it to the list this time]
> [This series has changed by using git-diff -M]
> Seems appropriate, but I really don't care what it's called. One thing about
> this name, is that typing arch/x86 doesn't
[EMAIL PROTECTED] wrote:
On the other hand, Andreas suggested only marking it once every 32 calls,
but that required a helper variable. Statistically, jiffies%32 should
end up about the same as a helper variable %32.
This of course, if just calling mark_page_accessed() is actually expensive
On Thu, 15 Mar 2007, Steven Rostedt wrote:
> On Thu, 2007-03-15 at 17:06 +0100, Andi Kleen wrote:
>
> > Well I just see a lot of pain from these patches but I doubt
> > they will avoid any bugs. If people don't compile test both
> > archs they will always likely break on another. There are lots
On Thu, 15 Mar 2007 11:06:21 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> > On Tue, 13 Mar 2007 18:33:20 +0200 Dan Aloni <[EMAIL PROTECTED]> wrote:
> > Hello,
> >
> > This question is relevent to 2.6.20.
> >
> > I noticed that if the RSS for the stack size is say, 8MB, running
> > a
On Thursday 15 March 2007 15:16, Peter Osterlund wrote:
> If bytes get lost in the communication with a serial mouse using the
> MS protocol, the kernel driver could do a better job getting back in
> sync. The first byte in a packet has bit 6 set, and no other bytes
> have that bit set. Therefore,
Robert P. J. Day writes:
> Delete apparently unused header file arch/ppc/syslib/cpc710.h.
I suggest you send this to [EMAIL PROTECTED] and Matt Porter
<[EMAIL PROTECTED]> for review.
Paul.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On 3/7/07, Davide Libenzi wrote:
Let's do this. How about you throw this way one of the case that would
possibly break, and I test it?
Since you make such claims I assume your signalfd() implementation
considers a signal delivered once it is reported to an epoll() caller.
Right?
This is not
On Thursday 15 March 2007 21:24, Norberto Bensa wrote:
> Hello,
>
> is this output, normal? I meant, why counters on CPU1 is zero? Isn't this
> balanced?
yes, it is normal.
If you had an interrupt-limited workload then irqbalance
would pick things up and spread them out.
-Len
> $ cat
On Thu, Mar 15, 2007 at 12:34:07PM -0400, Chuck Ebbert wrote:
> I've been holding off sending these in for -stable until they're
> merged, but now I wonder when that will happen.
Feel free to send them to stable@ when they go to Linus as it sounds
like they are almost there.
Thanks,
greg k-h
-
On Thu, 15 Mar 2007, Ulrich Drepper wrote:
> On 3/7/07, Davide Libenzi wrote:
> > Let's do this. How about you throw this way one of the case that would
> > possibly break, and I test it?
>
> Since you make such claims I assume your signalfd() implementation
> considers a signal delivered once
Hello Mel,
> > > > > Today after +- 24h of uptime I found some more page allocation
> > > > > failures ('eth1: Can't allocate skb for Rx'). You'll find more here:
> > > > >
> > > > > http://tuxland.pl/misc/2.6.21-rc3-mm1-page-allocation-failure.txt
> > > > >
> > > > > System wasn't doing
Hi Andrew,
On Sun, 11 Mar 2007 13:30:49 +0200 (EET) Pekka J Enberg
<[EMAIL PROTECTED]> wrote:
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
n all system calls must return long.
Fixed.
On 3/16/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
so the modification of vm_flags
On Thu, 2007-03-15 at 18:12 -0400, Mariusz Kozlowski wrote:
> Hello,
>
> This patch (against 2.6.21-rc3-mm1) balances parenthesis in blackfin
> header files.
>
> Signed-off-by: Mariusz Kozlowski <[EMAIL PROTECTED]>
>
> include/asm-blackfin/mach-bf535/bf535.h |4 ++--
>
(added linux-usb-devel@lists.sourceforge.net to CC)
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
> >> I have multiple AMD 64-bit servers in several configurations, with
> >> several different motherboards, which fail to recognize a USB keyboard
> >> when booted from a "stock" Linux
On 3/15/07, Jiri Kosina <[EMAIL PROTECTED]> wrote:
(added linux-usb-devel@lists.sourceforge.net to CC)
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
> >> I have multiple AMD 64-bit servers in several configurations, with
> >> several different motherboards, which fail to recognize a USB
On Thu, 15 Mar 2007, Jiri Kosina wrote:
> (added linux-usb-devel@lists.sourceforge.net to CC)
>
> On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
>
I have multiple AMD 64-bit servers in several configurations, with
several different motherboards, which fail to recognize a USB
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
> >> Ouch! I can't do anything by copy from a screen! There is no way to get
> >> `dmesg` without the keyboard! That's why I sent a request to
> >> linux-kernel, hoping that the problem would sound familiar. All I can do
> >> is boot the system
On Thu, 15 Mar 2007, Alan Stern wrote:
> On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
>
Ouch! I can't do anything by copy from a screen! There is no way to get
`dmesg` without the keyboard! That's why I sent a request to
linux-kernel, hoping that the problem would sound
On 3/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
echo "Loading uhci-hcd.ko module"
insmod /lib/uhci-hcd.ko
echo "Loading ehci-hcd.ko module"
insmod /lib/ehci-hcd.ko
I don't see you loading OHCI and I thought AMD boxes used that flavor.
echo "Loading usbhid.ko module"
insmod
On Thu, 15 Mar 2007, Dmitry Torokhov wrote:
> On 3/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
> > echo "Loading uhci-hcd.ko module"
> > insmod /lib/uhci-hcd.ko
> > echo "Loading ehci-hcd.ko module"
> > insmod /lib/ehci-hcd.ko
>
> I don't see you loading OHCI and I thought AMD
On Thu, 15 Mar 2007, Alan Stern wrote:
> On Thu, 15 Mar 2007, Dmitry Torokhov wrote:
>
>> On 3/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
>>> echo "Loading uhci-hcd.ko module"
>>> insmod /lib/uhci-hcd.ko
>>> echo "Loading ehci-hcd.ko module"
>>> insmod /lib/ehci-hcd.ko
>>
>> I
On Thu, 15 Mar 2007, Dmitry Torokhov wrote:
> On 3/15/07, linux-os (Dick Johnson) <[EMAIL PROTECTED]> wrote:
>> echo "Loading uhci-hcd.ko module"
>> insmod /lib/uhci-hcd.ko
>> echo "Loading ehci-hcd.ko module"
>> insmod /lib/ehci-hcd.ko
>
> I don't see you loading OHCI and I thought AMD boxes
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
[...]
> The initrd "linuxrc" file that loads the modules is here. One can see
> the order in which the modules are loaded. We had to make our own shell
> to replace 'nash' because the SCSI drivers spawned "children" that
> confused nash with
On Thu, 15 Mar 2007, Jiri Kosina wrote:
> On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
>
> [...]
>> The initrd "linuxrc" file that loads the modules is here. One can see
>> the order in which the modules are loaded. We had to make our own shell
>> to replace 'nash' because the SCSI
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
> Yes! I will try it in the morning. It's now past quitting time and,
> following this thread, you will note that the ohci module needed to be
> loaded for this AMD unit so the keyboard now works! I will remove the
Oh I see, looks like I
On Thu, 15 Mar 2007, linux-os (Dick Johnson) wrote:
> It's not the same hardware and all the machines that I tried that
> have keyboards end up WORKING with the USB keyboard as well! But
> Dmitry Torokhov was right! I just burned a CD with all three modules,
> and the keyboard works! I didn't
Applied.
On Thursday 15 March 2007 15:15, Henrique de Moraes Holschuh wrote:
> This patch allows for ibm-acpi to coexist (with diminished functionality) with
> other drivers like ACPI_BAY. ibm-acpi will simply disable the functions it is
> not able to register ACPI notifiers for.
>
>
This patch (as868) adds a helper routine for device drivers that need
to set up a callback to perform some action in a different process's
context. This is intended for use by attribute methods that want to
unregister themselves or their parent device. Attribute method calls
are mutually
On Sun, 11 Mar 2007 20:04:56 +0300 Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> Differences from version 4:
> Updated in-code comments. Largely rewritten changelog.
> Lockdep please. --akpm
> ->read_proc, ->write_proc aren't special, Extend protection to
> most methods for
On Thu, Mar 15, 2007 at 01:42:39PM +, Ian Campbell wrote:
> On Thu, 2007-03-15 at 18:56 +0530, Vivek Goyal wrote:
> >
> > Ideal place for this probably should have been arch dependent
> > crash_dump.h file. But we don't have one and no point introducing one
> > just for this macro.
>
>
On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > But I think changing this macro might run into issues. It is
> > > > > being used at few places in
On Thu, Mar 15, 2007 at 01:42:39PM +, Ian Campbell wrote:
> On Thu, 2007-03-15 at 18:56 +0530, Vivek Goyal wrote:
> >
> > Ideal place for this probably should have been arch dependent
> > crash_dump.h file. But we don't have one and no point introducing one
> > just for this macro.
>
>
On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > But I think changing this macro might run into issues. It
On Fri, Mar 16, 2007 at 08:48:08AM +0900, Horms wrote:
> On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> > On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> > > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal wrote:
> > > > > > But I think changing this macro might run
On Fri, Mar 16, 2007 at 11:40:07AM +0900, Magnus Damm wrote:
> On 3/16/07, Horms <[EMAIL PROTECTED]> wrote:
> >On Thu, Mar 15, 2007 at 06:56:16PM +0530, Vivek Goyal wrote:
> >> On Thu, Mar 15, 2007 at 12:22:57PM +, Ian Campbell wrote:
> >> > On Thu, 2007-03-15 at 11:17 +0530, Vivek Goyal
Zachary Amsden wrote:
> Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
> by fixing up the ELF object.
>
So does it actually work? Can you boot the broken distros with this in
place?
> Signed-off-by: Zachary Amsden <[EMAIL PROTECTED]>
>
> Index:
On Tue, 13 Mar 2007 16:30:27 -0700 Jeremy Fitzhardinge wrote:
> smp_call_function and smp_call_function_single are almost complete
> duplicates of the same logic. This patch combines them by
> implementing them in terms of the more general
> smp_call_function_mask().
The kernel-doc is still not
Jeremy Fitzhardinge wrote:
Zachary Amsden wrote:
Invoke black magic to relocate the VDSO even when COMPAT_VDSO is enabled
by fixing up the ELF object.
So does it actually work? Can you boot the broken distros with this in
place?
Well testing that is not so fun. I installed
Zachary Amsden wrote:
> Well testing that is not so fun. I installed SUSE Pro 9.0, and
> strings on ld.so contains the magic at_sysinfo assert! But it doesn't
> install TLS libraries, so I'll have to install them by hand.
>
> In works - in theory. Look, a puppy!
>
> Scratchbox is rumored to
Jeremy Fitzhardinge wrote:
+} else if (strcmp(secstrings+sechdrs[i].sh_name,
".dynamic") == 0) {
+Elf32_Dyn *dyn = (void *)hdr + sechdrs[i].sh_offset;
+int tag;
+while ((tag = (++dyn)->d_tag) != DT_NULL)
Um, no.
Walk
Valerie Henson writes:
> From: Guido Classen <[EMAIL PROTECTED]>
>
> This small patch fixes two issues with the Lite-On 82c168 PNIC adapters.
> I've tested it with two cards in different machines both chip rev 17
>
> The first is the wrong register address CSR6 for writing the MII register
[EMAIL PROTECTED] wrote:
The natsemi drivers include functions for enabling and disabling
interrupts from the chip but these are not used in all code paths. This
patch changes the code paths that touch the interrupt enable register to
use the functions. In all cases this adds an extra PCI read
On Thu, Mar 15, 2007 at 02:39:39PM +0900, takada wrote:
> Hiroshi Miura posted `Geode out-of-order store enables' patch in Jun, 2003.
> There is http://lkml.org/lkml/2003/6/5/57 .
> OOSTORE was enabled at this point in time. It seems to have disappeared
> somewhere.
I believe the patch was
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/natsemi.c | 58 --
drivers/net/netxen/netxen_nic.h |1 +
On Thu, Mar 15, 2007 at 10:22:44AM -0400, Woody Suwalski wrote:
> Sergei Shtylyov wrote:
> > I wonder is there are some W83C554 users anywhere -- that chipset
> >also supports UltraDMA...
> >
> >MBR, Sergei
> Sergei,
>
> ARM Netwinder machines are running hard disk IDE on SL82c105.
> Could you
Hello.
Russell King wrote:
I wonder is there are some W83C554 users anywhere -- that chipset
also supports UltraDMA...
Sergei,
ARM Netwinder machines are running hard disk IDE on SL82c105.
Could you send me the actual source file to try (or a patch)?
That's actually a W83C553 which
[PATCH] ide: don't allow DMA to be enabled if CONFIG_IDEDMA_{ICS,PCI}_AUTO=n
For CONFIG_IDEDMA_{ICS,PCI}_AUTO=n and/or "ide=nodma" option the host/device
are not programmed for DMA and it is also explicitly disabled by ide_set_dma()
(->ide_dma_check returns "-1"). However the code responsible
[PATCH] ide: remove CONFIG_IDEDMA_{ICS,PCI}_AUTO config options
All modern distributions have been setting these options to "y" for ages.
(additionally "n" cases have been obsoleted for few years). Therefore use
DMA by default and remove CONFIG_IDEDMA_{ICS,PCI}_AUTO (also remove no longer
needed
On Wednesday 14 March 2007, Sergei Shtylyov wrote:
> Hello, I wrote:
>
> >>> Bartlomiej Zolnierkiewicz wrote:
>
> [PATCH] sl82c105: add ->speedproc support
>
> * add sl82c105_tunepio() wrapper for sl82c105_tune_drive()
> (just to get the error value)
>
> * add
If you try to load both the pata_atiixp and the ahci driver
(for the same ATI SB600 adapter), very strange things happen.
The AHCI driver churns for three minutes or so, spewing
messages like this, then nothing works:
<6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
<4>ata3.00: qc
This patch fixes:
* the dependency of scc_pata on BLK_DEV_IDEDMA_PCI
* incorrect link to ide-core
* move scc_pata from ide/ppc to ide/pci
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
diff -Nrpu -X linux-2.6.21-rc3/Documentation/dontdiff
This patch moves scc_pata from ide/ppc to ide/pci in order to
build it in normal module.
Signed-off-by: Kou Ishizaki <[EMAIL PROTECTED]>
Signed-off-by: Akira Iguchi <[EMAIL PROTECTED]>
---
diff -Nrpu -X linux-2.6.21-rc3/Documentation/dontdiff
linux-2.6.21-rc3/drivers/ide/pci/scc_pata.c
Chuck Ebbert wrote:
If you try to load both the pata_atiixp and the ahci driver
(for the same ATI SB600 adapter), very strange things happen.
The AHCI driver churns for three minutes or so, spewing
messages like this, then nothing works:
<6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl
Hello,
Justin Piszcz wrote:
> DISCLAIMER: This patch is still experimental. AUTHOR: Rudolf Marek has
> written the coretemp module for Intel Core Duo/Solo
> processors.
>
> Without this patch, you cannot monitor your CPU temperature, at least
> not on a DG965 motherboard.
[snip]
> Commentary:
>
Hi Nicolas,
On Thu, 15 Mar 2007 19:27:21 +0800, Nicolas Boichat wrote:
> I ported this patch to the latest git, I hope this can help to get it
> merged.
>
> I'm just wondering if it is right to export the functions msr_read and
> msr_write from arch/i386/kernel/msr.c, or if it would be better to
701 - 794 of 794 matches
Mail list logo
