Grant Grundler wrote:
> On Sun, May 27, 2007 at 06:03:29PM -0700, Roland Dreier wrote:
> ...
>> > I can imagine many systems where the cpu simply doesn't have enough
>> > interrupt pins to uniquely identify every possible MSI interrupt
>> > source.
>>
>> I have a hard time imagining a PCI host
Roland Dreier wrote:
>
> I have a hard time imagining a PCI host bus controller that converts
> MSI interrupts back to wire interrupts that go to pins on the CPU.
> For one thing it would be hard to maintain the guarantee that
> MSI interrupts can't pass DMAs. And it would be an absolutely silly
Nick Piggin wrote:
Eric W. Biederman wrote:
When we initialize the ramdisk by writing to /dev/ram0 usually in
init/do_mounts_rd.c we don't allocate buffer heads but we do set
the dirty bit, and the page is in the page cache. So when we
later call getblk it reuses the same page and then calls
Eric W. Biederman wrote:
Nick Piggin <[EMAIL PROTECTED]> writes:
Eric W. Biederman wrote:
The problem: When we are trying to free buffers try_to_free_buffers
will look at ramdisk pages with clean buffer heads and remove the
dirty bit from the page. Resulting in ramdisk pages with data
Hi,
I found a bug on CPU hotplug. If oprofile is running, CPU hot remove causes
system hang. I only confirm that this problem occurs on my ia64 box. I'm glad
if someone report about other arch.
How to reproduce
1) start oprofile
# opcontrol --start
2) offline a CPU.
#
Hi,
--On 28 May 2007 12:45:59 PM +1000 David Chinner <[EMAIL PROTECTED]> wrote:
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out
Alan Cox writes:
> On Thu, 24 May 2007 09:45:37 -0400
> David Woodhouse <[EMAIL PROTECTED]> wrote:
>
> > On Thu, 2007-05-24 at 14:41 +0100, Alan Cox wrote:
> > > Most people copied the x86 behaviour which makes it easy to transplant.
> > > Some are just smoking something (see ioctls.h for sh-64
Nick Piggin <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> The problem: When we are trying to free buffers try_to_free_buffers
>> will look at ramdisk pages with clean buffer heads and remove the
>> dirty bit from the page. Resulting in ramdisk pages with data that
>> get removed
On Mon, May 28, 2007 at 12:57:53PM +1000, Neil Brown wrote:
> On Monday May 28, [EMAIL PROTECTED] wrote:
> > On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> > > Thanks everyone for your input. There was some very valuable
> > > observations in the various emails.
> > > I will try to
On Fri, May 25, 2007 at 10:50:38AM -0700, Linus Torvalds wrote:
>
>
> On Fri, 25 May 2007, Andrew Morton wrote:
> >
> > > > There is an additional factor - dumps contain data which variously is -
> > > > copyright third parties, protected by privacy laws, just personally
> > > > private,
On Sun, May 27, 2007 at 06:03:29PM -0700, Roland Dreier wrote:
...
> > I can imagine many systems where the cpu simply doesn't have enough
> > interrupt pins to uniquely identify every possible MSI interrupt
> > source.
>
> I have a hard time imagining a PCI host bus controller that converts
>
On 5/28/07, pradeep singh <[EMAIL PROTECTED]> wrote:
Hi All,
Is it possible to change the normal kernel execution path using a
loadable module, without actually patching the kernel?
e.g
fun1()->fun2()->fun3()->fun4()->fun5()->fun6()
Can i change this method invocation sequence to a custom
Eric W. Biederman wrote:
The problem: When we are trying to free buffers try_to_free_buffers
will look at ramdisk pages with clean buffer heads and remove the
dirty bit from the page. Resulting in ramdisk pages with data that
get removed from the page cache. Ouch!
Buffer heads appear on
On Fri, May 25, 2007 at 09:33:54AM -0700, Andrew Morton wrote:
> On Fri, 25 May 2007 14:34:56 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > * Chris Newport <[EMAIL PROTECTED]> wrote:
> >
> > > There is a fundamental problem in getting a decent log to debug a
> > > crashed kernel. Maybe we
Pavel Machek wrote:
On Sat 2007-05-26 18:42:37, Bill Davidsen wrote:
I was testing susp2disk in 2.6.21.1 under FC6, to
support reliable computing environment (RCE) needs. The
idea is that if power fails, after some short time on
UPS the system does susp2disk with a time set, and boots
Hi,
And then there's the supercompact form.
while (len--) {
hash = partial_name_hash(tolower(*name++), hash);
}
But I do not like the last one at all. The first one is the best, because
it clearly separates the condition and iteration parts of the expression,
while STILL being only
On Monday May 28, [EMAIL PROTECTED] wrote:
> On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
> >
> > Thanks everyone for your input. There was some very valuable
> > observations in the various emails.
> > I will try to pull most of it together and bring out what seem to be
> > the
From: Roland Dreier <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 18:03:29 -0700
> I have a hard time imagining a PCI host bus controller that converts
> MSI interrupts back to wire interrupts that go to pins on the CPU.
> For one thing it would be hard to maintain the guarantee that
> MSI
> Hi,
> Remove useless tolower in isofs
>
> Signed-off-by: dave young <[EMAIL PROTECTED]>
>
> inode.c |2 +-
> 1 file changed, 1 insertions(+), 1 deletions(-)
>
> diff -dur linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
> --- linux/fs/isofs/inode.c 2007-05-28 08:54:33.0 +
On Sun, May 27, 2007 at 12:28:24PM +0200, Matthias Kaehlcke wrote:
> thanks for your comment, here's a patch that uses
> list_for_each_entry(), additionally to the initial patch it
> substitutes some list_for_each() loops by list_for_each_entry()
Thanks! I added this to my list of patches for
Roland Dreier wrote:
> > > At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> > > so that's not an option for you. The current Linux implementation
> > > does not support more than one MSI interrupt, so you just get one
> > > interrupt with pci_enable_msi().
> >
> >
On Mon, May 28, 2007 at 11:30:32AM +1000, Neil Brown wrote:
>
> Thanks everyone for your input. There was some very valuable
> observations in the various emails.
> I will try to pull most of it together and bring out what seem to be
> the important points.
>
>
> 1/ A BIO_RW_BARRIER request
From: Denis Cheng
thus the definition of dst_discard_in and dst_discard_out is the same,
we can define a dst_discard function and map the _in and _out to it,
this can reduce space in vmlinux.
Signed-off-by: Denis Cheng <[EMAIL PROTECTED]>
---
diff --git a/net/core/dst.c b/net/core/dst.c
index
This has been working up and including -rc2:
{pts/1}% sudo make -C ~/src/linux-git O=$HOME/build/linux-2.6.22 M=PWD V=1
modules_install
make: Entering directory `/home/bor/src/linux-git'
make -C /home/bor/build/linux-2.6.22 \
KBUILD_SRC=/home/bor/src/linux-git \
Hi,
I found a bug on signal subsystem. If there is some multithread program
and one of the thread is blocking on the system call, it returns with
wrong errno on receiving SIGSTOP and following SIGCONT.
Arch dependency
===
succeed to reproduce: i386, ia64
Unknown: any
> > At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> > so that's not an option for you. The current Linux implementation
> > does not support more than one MSI interrupt, so you just get one
> > interrupt with pci_enable_msi().
>
> This would mean MSI or MSI-X ? A
On Sun, May 27, 2007 at 06:44:49PM -0700, David Brownell wrote:
> On Sunday 27 May 2007, Matthew Garrett wrote:
> > Actually, it seems to be worse than that - the PNP entry for my cmos
> > clock doesn't appear to mention an irq, so the wakealarm entry doesn't
> > work. I can happily wake it
On Sunday 27 May 2007, Matthew Garrett wrote:
> f5f72b46c349fefcfd4421b2213c6ffb324c5e56 appears to break the userspace
> interface to the CMOS alarm. This could previously be accessed via
> /proc/acpi/alarm ...
I was a bit surprised the ACPI team didn't have more comments on
that issue,
On Sunday 27 May 2007, Matthew Garrett wrote:
> On Mon, May 28, 2007 at 12:39:11AM +0100, Matthew Garrett wrote:
>
> > but will disable /proc/acpi/wakeup. It'll also be impossible to load
> > CONFIG_RTC_CMOS because CONFIG_RTC has grabbed the io ports, so it's not
> > possible to use the new
Roland Dreier wrote:
> > >> Another question would be if the device supports multiple messages, MSIX
> > >> should be used ?
> > >
> > > Yes. Assuming the device supports multiple MSI-X messages.
>
> At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> so that's not an
Hi,
I found a bug on CPU hotplug. If `pfmon --system-wide' is running,
CPU hot remove causes system hang. On the other hand, CPU hot add
during that command seems to work fine.
I detected this problem on my ia64 box, and I don't know that this
problem is also occur on any arch or freezer based
On 2007.05.26 14:42:30 +0200, Maximilian Engelhardt wrote:
> Hello,
>
> when using the prism54 driver including in the 2.6.22-rc3 kernel I get this
> Oops when putting the card into monitor mode:
>
> BUG: unable to handle kernel NULL pointer dereference at virtual address
> 01d8
>
On Friday May 25, [EMAIL PROTECTED] wrote:
> 2007/5/25, Neil Brown <[EMAIL PROTECTED]>:
> > - Are there other bit that we could handle better?
> > BIO_RW_FAILFAST? BIO_RW_SYNC? What exactly do they mean?
> >
> BIO_RW_FAILFAST: means low-level driver shouldn't do much (or no)
> error
Thanks everyone for your input. There was some very valuable
observations in the various emails.
I will try to pull most of it together and bring out what seem to be
the important points.
1/ A BIO_RW_BARRIER request should never fail with -EOPNOTSUP.
This is certainly a very attractive
Roland Dreier wrote:
> > >> Another question would be if the device supports multiple messages, MSIX
> > >> should be used ?
> > >
> > > Yes. Assuming the device supports multiple MSI-X messages.
>
> At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
> so that's not an
Ingo Molnar wrote:
i'm pleased to announce release -v14 of the CFS scheduler patchset.
The CFS patch against v2.6.22-rc2, v2.6.21.1 or v2.6.20.10 can be
downloaded from the usual place:
http://people.redhat.com/mingo/cfs-scheduler/
In comment before distribute_fair_add(), we
On Sun, May 27, 2007 at 01:35:56AM +0100, Jeremy Fitzhardinge wrote:
> Michal Piotrowski wrote:
> > File systems
> >
> > Subject: 2.6.21-git10/11: files getting truncated on xfs
> > References : http://lkml.org/lkml/2007/5/9/410
> > Submitter : Jeremy Fitzhardinge <[EMAIL PROTECTED]>
> >
> >> Another question would be if the device supports multiple messages, MSIX
> >> should be used ?
> >
> > Yes. Assuming the device supports multiple MSI-X messages.
At least on my device (PCI ID 1131:7162) there is no MSI-X capability,
so that's not an option for you. The current Linux
On Fri, 25 May 2007 22:12:55 +0900 Kawai, Hidehiro wrote:
> This patch adds the documentation for /proc//coredump_filter.
>
> Signed-off-by: Hidehiro Kawai <[EMAIL PROTECTED]>
> ---
> Documentation/filesystems/proc.txt | 38 +++
> 1 files changed, 38 insertions(+)
>
>
> I'm talking about embedded ARM chips and the like, and yes they
> very possibly will be using PCI-E controllers at some point.
As an example the AMCC PowerPC 440SPe, which is an embedded SoC with
an onboard PCIe controller that supports three ports, has 24 MSI
interrupts that external PCIe
Hi,
Remove useless tolower in isofs
Signed-off-by: dave young <[EMAIL PROTECTED]>
inode.c |2 +-
1 file changed, 1 insertions(+), 1 deletions(-)
diff -dur linux/fs/isofs/inode.c linux.new/fs/isofs/inode.c
--- linux/fs/isofs/inode.c 2007-05-28 08:54:33.0 +
+++
> Presumably we need something like IRQF_MSI which can be set as
> appropriate depending on the architecture?
Unfortunately I don't think it's that simple -- drivers would have to
do something like
if (IRQF_MSI == IRQF_SHARED) {
// lose MSI optimizations, do an MMIO
On Sun, May 27, 2007 at 07:44:02PM +0100, Matthew Garrett wrote:
> Anyway. I've tested the following patch on a dual-core x86. No obvious
> issues yet, but I'll try to put it through a few hundred cycles.
This /mostly/ works - I've had my test machine cycling through a suspend
cycle every 10
> > i presume then i shouldn't be using IRQF_SHARED, if using MSI.
>
> That's actually a really good question.
>
> It is likely architecture dependant whether the PCI controller wires
> unique MSI interrupts to shared cpu interrupt lines.
Yes, but current Linux drivers assume that MSI
On Monday 28 May 2007, Michael Buesch wrote:
> Ok, another question: On which CPU architecture are you?
[EMAIL PROTECTED]:~$ uname -m
i686
Maxi
signature.asc
Description: This is a digitally signed message part.
On Mon, May 28, 2007 at 12:39:11AM +0100, Matthew Garrett wrote:
> but will disable /proc/acpi/wakeup. It'll also be impossible to load
> CONFIG_RTC_CMOS because CONFIG_RTC has grabbed the io ports, so it's not
> possible to use the new interface. This situation doesn't appear to be
>
Ok, another question: On which CPU architecture are you?
--
Greetings Michael.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
On Sunday 27 May 2007, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:41, Maximilian Engelhardt wrote:
> > On Sunday 27 May 2007, Rafael J. Wysocki wrote:
> > > On Sunday, 27 May 2007 18:01, Maximilian Engelhardt wrote:
> > > > On Saturday 26 May 2007, Nigel Cunningham wrote:
> > > > > Hi.
>
On Sun, 27 May 2007 18:11:25 +0100 Andy Whitcroft <[EMAIL PROTECTED]> wrote:
> +#gotos aren't indented
> + if($line=~/^\s*[A-Za-z\d_]+:/ and !($line=~/^\s*default:/)){
> + print "Gotos should not be indented\n";
> + print "$herecurr";
> +
On Sun, May 27, 2007 at 08:03:51PM +0100, Matthew Garrett wrote:
> (It doesn't really help that rtc-cmos doesn't load on this machine, but
> I'll try to track that down later - right now I suspect some sort of PNP
> issue)
Ah, no, it's because the ioports for the rtc-cmos driver are already
si funca bien
_
De todo para la Mujer Latina http://latino.msn.com/mujer/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Hi Bill
> > A collegue of mine has an Intel mainboard with the i865 chipset onboard
> > (DQ965). All kernels up to and including 2.6.22-rc2 do not detect the IDE
> > CDROM/DVDROM when booting. The SATA hard drive is found without any
> > problems.
> >
> Let me belatedly ask if the device shows
From: "Antonino A. Daplas" <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 17:43:41 +0800
> Add function helper, fb_is_display_device(). Given struct fb_info, it will
> return a nonzero value if the device is the primary display.
>
> Currently, only the i386 is supported, other platforms only have
From: "Antonino A. Daplas" <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 17:44:46 +0800
> Move arch-specific bits of fb_mmap() to their respective subdirectories
>
> Signed-off-by: Antonino Daplas <[EMAIL PROTECTED]>
The sparc and sparc64 bits look good.
Acked-by: David S. Miller <[EMAIL
On 5/28/07, Tilman Schmidt <[EMAIL PROTECTED]> wrote:
Am 26.05.2007 18:01 schrieb Andrew Morton:
> On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>> This breaks network initialization on my SuSE 10.0 box [...]
>
> Thanks. I think others have seen similar things
[ It's NFS - CCing Trond ]
Hi Stefan,
What was the last kernel that worked for you without giving this
problem? Also is it possible for you to try the latest kernel
(http://kernel.org/) to see if the problem is still reproducible?
Parag
Stefan Helbing wrote:
Hello,
I'm really unsure if
On Sun, 2007-05-27 at 23:04 +0100, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
>
> > What exactly is the problem we see here? The timeout of the firmware loader?
> > What goes wrong with frozen userspace, usually there is only a netlink
> > message sent
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > 2.6.21.1:
> > [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> > [ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
> > [ 4] local 192.168.1.2 port 5001 connected
Am 26.05.2007 18:01 schrieb Andrew Morton:
> On Sat, 26 May 2007 17:59:15 +0200 Tilman Schmidt <[EMAIL PROTECTED]> wrote:
>> This breaks network initialization on my SuSE 10.0 box [...]
>
> Thanks. I think others have seen similar things and it was attributed to
>
On Sun, May 27, 2007 at 11:49:30PM +0200, Kay Sievers wrote:
> What exactly is the problem we see here? The timeout of the firmware loader?
> What goes wrong with frozen userspace, usually there is only a netlink
> message sent from the kernel, which should be received and handled
> just fine
On Sun, May 27, 2007 at 11:45:03PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> > If we remove process freezing in STR, this should just work[1] without the
> > need to complicate things.
>
> Under the (optimistic, IMO) assumption that the relevant
On Sunday, 27 May 2007 23:49, Kay Sievers wrote:
> On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
> > On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> > >
> > > Use a hibernation and suspend notifier to disable the
On Fri, May 25, 2007 at 06:38:15AM +, Pavel Machek wrote:
> Hi!
> > Because, as Len has pointed out, you end up with two different ideas
> > about what the trip points are - the kernel's and the hardware's. That
> > works fine until some event in the firmware either forcibly
> >
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
> > On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > > 2.6.21.1:
> > > [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> > > [ 5] 0.0-60.6 sec 1.13 MBytes
On Sun, May 27, 2007 at 06:11:25PM +0100, Andy Whitcroft wrote:
> +# (c) 2001, Dave Jones. <[EMAIL PROTECTED]> (the file handling bit)
dead email address.
Dave
--
http://www.codemonkey.org.uk
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
On 5/27/07, Matthew Garrett <[EMAIL PROTECTED]> wrote:
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and
On Sunday, 27 May 2007 22:45, Michael-Luke Jones wrote:
> On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
>
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware
> > requesting
> > mechanism before a hibernation/suspend and
From: David Miller <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 14:16:22 -0700 (PDT)
> So even writes to so-called 'read-only' sections of the kernel image
> will work and therefore I don't understand what the bug could be other
> than the compiler "optimizing" away the write to the constant string
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
> > When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in
> > normal use I didn't notice any problems. It did work fine as I would
> > expect it. I think the wget and ping
On Sat, 26 May 2007 16:32:54 +1000 Nigel Cunningham wrote:
> Hi all.
>
> As promised I took another look at the patch and at what Randy had
> prepared to fix the IA64 compilation error. I did some more work on it,
> and believe that the following is the tidiest correct solution I can
> come up
Linus, please pull from the for-linus branch at
git://git.kernel.org/pub/scm/linux/kernel/git/ieee1394/linux1394-2.6.git
for-linus
to receive the following IEEE 1394 subsystem updates:
(old stack)
- fix regression in 2.6.22-rc1: raw1394 asynchronous transmit was broken,
- fix
On Sunday, 27 May 2007 22:49, Matthew Garrett wrote:
> On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> > From: Rafael J. Wysocki <[EMAIL PROTECTED]>
> >
> > Use a hibernation and suspend notifier to disable the firmware requesting
> > mechanism before a hibernation/suspend
On Sunday, 27 May 2007 22:41, Maximilian Engelhardt wrote:
> On Sunday 27 May 2007, Rafael J. Wysocki wrote:
> > On Sunday, 27 May 2007 18:01, Maximilian Engelhardt wrote:
> > > On Saturday 26 May 2007, Nigel Cunningham wrote:
> > > > Hi.
> > > >
> > > > On Sat, 2007-05-26 at 14:49 +0200,
Hi!
> >It is very dangerous to attempt a resume with a
> >different kernel than the one
> >that has gone to sleep.
> >Different kernels may be compiled with different
> >options that affect where or
> >how in-memory structures are saved.
> >
> If the mainline resume is depending on that no
On Sunday 27 May 2007 23:13:32 Michael Buesch wrote:
> On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > 2.6.21.1:
> > [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> > [ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
> > [ 4] local 192.168.1.2 port 5001
Hi!
> Personally I think the kernel suspend should write a signature - similar to a
> hash of the bzImage - into the suspend image so it won't even attempt a resume
> if there's a mismatch. (Yes, I made this mistake once whilst playing with
> suspend).
We have such 'hash' but it is not
From: Jan Engelhardt <[EMAIL PROTECTED]>
Date: Sun, 27 May 2007 18:44:18 +0200 (MEST)
>
> On May 26 2007 15:47, David Miller wrote:
> >> I have set the OBP to run at 115200, also set agetty on ttyS0 to do the
> >> same, and also added console=ttyS0,115200 to silo.conf (and also tried
> >>
On Sat 2007-05-26 18:42:37, Bill Davidsen wrote:
> I was testing susp2disk in 2.6.21.1 under FC6, to
> support reliable computing environment (RCE) needs. The
> idea is that if power fails, after some short time on
> UPS the system does susp2disk with a time set, and boots
> back every so
On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> 2.6.21.1:
> [ 5] local 192.168.1.2 port 58414 connected with 192.168.1.1 port 5001
> [ 5] 0.0-60.6 sec 1.13 MBytes157 Kbits/sec
> [ 4] local 192.168.1.2 port 5001 connected with 192.168.1.1 port 57837
> [ 4] 0.0-63.1 sec
Pavel Machek pisze:
> Hi!
>
>> As promised I took another look at the patch and at what Randy had
>> prepared to fix the IA64 compilation error. I did some more work on it,
>> and believe that the following is the tidiest correct solution I can
>> come up with. It differs from the version that
Hi!
> > >> I shouldn't have to upgrade my BIOS to work with a new kernel any more
> > >> than I should have to upgrade my browser.
> > >
> > >We don't agree there, as you are not talking about a stable kernel series.
> >
> > Ah, so you're planning on submitting these patches for 2.7 then? 2.6
>
Hi!
> >Well, in 2.6.73.1 we add 'trivial' one line to add new
> >pci id, and in
> >2.6.73.2 we have data corruption, because that driver
> >needed some
> >quirk we did not know about...?
>
> False argument. -stable should only be merging patches
> that are already upstream, and known.
Well,
Hi!
> As promised I took another look at the patch and at what Randy had
> prepared to fix the IA64 compilation error. I did some more work on it,
> and believe that the following is the tidiest correct solution I can
> come up with. It differs from the version that caused the compilation
> error
On Sat, 26 May 2007, Jan Engelhardt wrote:
> +Testing for a flag, as done in the following example, is redundant and
> +can be shortened.
> +
> + if ((v & GFP_KERNEL) == GFP_KERNEL)
> + return;
> +
> +should become
> +
> + if (v & GFP_KERNEL)
> + return;
This
Hi!
> When I try software suspend on my laptop it always returns to my running
> system after some time.
> This is what's logged by the kernel:
>
> swsusp: Basic memory bitmaps created
> Stopping tasks ...
> Stopping kernel threads timed out after 20 seconds (1 tasks refusing to
> freeze):
>
Hi!
>
> > I doubt it is impossible, would you mind sharing your knowledge why you
> > think it is impossible or point to some related discussion, pls.
>
> Because, as Len has pointed out, you end up with two different ideas
> about what the trip points are - the kernel's and the hardware's.
On Sun, May 27, 2007 at 10:31:53PM +0200, Rafael J. Wysocki wrote:
> From: Rafael J. Wysocki <[EMAIL PROTECTED]>
>
> Use a hibernation and suspend notifier to disable the firmware requesting
> mechanism before a hibernation/suspend and enable it after the operation.
This avoids the problem of
On Sunday 27 May 2007 22:36:39 Maximilian Engelhardt wrote:
> When I ran 2.6.21.1 or 2.6.22-rc3 without any debugging tools just in normal
> use I didn't notice any problems. It did work fine as I would expect it.
> I think the wget and ping tests here are as they should be.
>
> With
On 27 May 2007, at 21:31, Rafael J. Wysocki wrote:
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the firmware
requesting
mechanism before a hibernation/suspend and enable it after the
operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL
On Sunday 27 May 2007, Rafael J. Wysocki wrote:
> On Sunday, 27 May 2007 18:01, Maximilian Engelhardt wrote:
> > On Saturday 26 May 2007, Nigel Cunningham wrote:
> > > Hi.
> > >
> > > On Sat, 2007-05-26 at 14:49 +0200, Maximilian Engelhardt wrote:
> > > > On Saturday 26 May 2007, Nigel Cunningham
Replacing pci_find_device with pci_get_device in the
drivers/isdn subtree.
Signed-off-by: Karsten Keil <[EMAIL PROTECTED]>
Signed-off-by: Surya Prabhakar <[EMAIL PROTECTED]>
---
drivers/isdn/hisax/avm_pci.c | 19 ++
drivers/isdn/hisax/bkm_a4t.c | 15 +---
On Sunday 27 May 2007, Michael Buesch wrote:
> On Sunday 27 May 2007 21:25:17 Maximilian Engelhardt wrote:
> > 2.6.22-rc3:
> >
> > [ 5] local 192.168.1.2 port 46557 connected with 192.168.1.1 port 5001
> > [ 5] 0.0-60.4 sec 58.9 MBytes 8.18 Mbits/sec
> > [ 4] local 192.168.1.2 port 5001
On Sat, May 26, 2007 at 06:35:24PM +0200, Thomas Gleixner wrote:
> On Sat, 2007-05-26 at 18:17 +0200, Folkert van Heusden wrote:
> > > > Seems to be hrtimers related - CC'ed Thomas.
> > > I doubt that. The tick interrupt just finds out, that the machine is
> > > stuck in rmmod.
> > > > > Also the
David Miller wrote:
> From: "H. Peter Anvin" <[EMAIL PROTECTED]>
> Date: Sat, 26 May 2007 19:34:26 -0700
>
>> There are systems which only get a single bit indication that an MSI has
>> happened.
>>
>> Presumably we need something like IRQF_MSI which can be set as
>> appropriate depending on the
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the firmware requesting
mechanism before a hibernation/suspend and enable it after the operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
drivers/base/firmware_class.c | 36
Grant Grundler wrote:
> On Sun, May 27, 2007 at 05:01:02AM +0400, Manu Abraham wrote:
>> David Miller wrote:
>>> True, on sparc64 PCI-E controllers, for example, the MSI vector is
>>> received by the PCI-E host controller, and the host controller turns
>>> this into a cpu format interrupt packet
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make it possible to register hibernation and suspend notifiers, so that
subsystems can perform hibernation-related or suspend-related operations that
should not be carried out by device drivers' .suspend() and .resume() routines.
Signed-off-by: Rafael
Hi,
The first of the following three patches introduces notifier chaing that can be
used by subsystems to prefore some hibernation-related or suspend-related
operations independent of device drivers' .suspend() and .resume() callbacks.
The next two patches use this mechanism for
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Use a hibernation and suspend notifier to disable the user mode helper before
a hibernation/suspend and enable it after the operation.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
kernel/kmod.c | 31 +--
1 file
Linus,
Please pull the hwmon subsystem fixes for Linux 2.6.22 from:
git://jdelvare.pck.nerim.net/jdelvare-2.6 hwmon-for-linus
drivers/hwmon/Kconfig |2 +-
drivers/hwmon/applesmc.c |7 ++-
drivers/hwmon/coretemp.c | 32 +---
drivers/hwmon/ds1621.c
1 - 100 of 420 matches
Mail list logo
