Michael H. Warfield wrote:
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote:
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are
On Sat, 2007-11-24 at 23:59 +0100, Laurent Riffard wrote:
> Le 24.11.2007 14:26, James Bottomley a écrit :
> > OK, could you post dmesgs again, please. I actually tested this
> with an
> > aic79xx card, and for me it does cause Domain Validation to succeed
> > again.
>
> James,
>
> Here is a
On Sat, Nov 24, 2007 at 10:38:45PM -0800, Andrew Morton wrote:
> On Sun, 18 Nov 2007 22:32:52 +0100 (MET) Patrick McHardy <[EMAIL PROTECTED]>
> wrote:
>
> > These patches add support for using the HIFN rng.
>
> Dumb question: what is HIFN?
They make crypto hardware: www.hifn.com.
Cheers,
--
On Sun, 18 Nov 2007 22:32:52 +0100 (MET) Patrick McHardy <[EMAIL PROTECTED]>
wrote:
> These patches add support for using the HIFN rng.
Dumb question: what is HIFN?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More
On Sun, 25 Nov 2007 03:52:33 +0100 Jeroen <[EMAIL PROTECTED]> wrote:
> Hi,
>
> I'm migrating my server from windows 2003 server to Ubuntu, but I am
> stumbling over the "Low Power State Link Speed" option for my NIC
> (forcedeth)
>
> I need to disable this option in my windows driver otherwise
On Sat, 17 Nov 2007 23:20:36 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote:
> Completely reproducible... 2.6.23-rc3 kernel boots, and normal messages
> are seen on console as far as disks found and partitions on each. However,
> once /dev is populated and the boottime scripts attempt to check
(cc's added)
On Fri, 23 Nov 2007 20:28:41 -0800 (PST) [EMAIL PROTECTED] wrote:
> Build kernel-2.6.24-rc3. pmi_watchdog can not reset the kernel panic
> machine. The watchdog can never to record panic information to IPMI SEL.
>
> 1. I disable auto reset when kernel panic by echo "0" >
>
On Tue, 20 Nov 2007 17:04:32 -0700 "Raymano Garibaldi" <[EMAIL PROTECTED]>
wrote:
> Is there any other information that I can provide which might help in
> resolving this bug?
Let's cc the USB developers.
> On 11/18/07, Raymano Garibaldi <[EMAIL PROTECTED]> wrote:
> > The last time I tried
From: Casey Schaufler <[EMAIL PROTECTED]>
This patch takes advantage of the increase in capability bits
to allocate capabilities for Mandatory Access Control. Whereas
Smack was overloading a previously allocated capability it is
now using a pair, one for overriding access control checks and
the
just for the entertainment value, i ran "make headers_install" on my
x86 box using the newer "sunifdef" utility, which has the advantage
that it will remove parts of compound preprocessor conditionals.
here's the diff output between the old and the new generated header
directories:
diff -r
On Mon, 19 Nov 2007 09:27:36 -0800 Stephen Hemminger <[EMAIL PROTECTED]> wrote:
> On Mon, 19 Nov 2007 12:22:20 -
> "Simon Arlott" <[EMAIL PROTECTED]> wrote:
>
> > On Sat, November 17, 2007 18:40, Francois Romieu wrote:
> > > Kai Ruhnau <[EMAIL PROTECTED]> :
> > > [...]
> > >> I have a
On Sat, 2007-11-24 at 23:36 +0300, Andrey Borzenkov wrote:
> I have no COM port on notebook (without port replicator which I do not have)
> so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
> created) but I just noticed that serial modules are still loaded. Well, this
>
Kyle Moffett wrote:
> On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote:
>> Andrew Morgan wrote:
>>> It feels to me as if a MAC "override capability" is, if true to its
>>> name, extra to the MAC model; any MAC model that needs an 'override'
>>> to function seems under-specified... SELinux clearly
According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
active. So it should be set when enable the MSI.
The patch base on kernel 2.6.24-rc3
Signed-off-by: Andy Currid <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
---
According to the HyperTransport spec, 'En' indicate if the MSI Mapping is
active. So it should be set when enable the MSI.
The patch base on kernel 2.6.24-rc3
Signed-off-by: Andy Currid <[EMAIL PROTECTED]>
Signed-off-by: Peer Chen <[EMAIL PROTECTED]>
---
---
Hi,
I'm migrating my server from windows 2003 server to Ubuntu, but I am
stumbling over the "Low Power State Link Speed" option for my NIC
(forcedeth)
I need to disable this option in my windows driver otherwise the trough pout is
horrible because the link fluctuates constantly from 100/1000.
Date: Sun, 25 Nov 2007 03:02:20 +0100
Subject: [PATCH] IP22ZILOG: fix lockup and sysrq
- fix lockup when switching from early console to real console
- make sysrq reliable
- fix panic, if sysrq is issued before console is opened
Signed-off-by: Thomas Bogendoerfer <[EMAIL PROTECTED]>
---
On Nov 24, 2007, at 06:39:34, Crispin Cowan wrote:
Andrew Morgan wrote:
It feels to me as if a MAC "override capability" is, if true to
its name, extra to the MAC model; any MAC model that needs an
'override' to function seems under-specified... SELinux clearly
feels no need for one,
On Sunday 25 November 2007 01:27:54 Francois Romieu wrote:
> Francois Romieu <[EMAIL PROTECTED]> :
> > Alistair John Strachan <[EMAIL PROTECTED]> :
> > [...]
> >
> > > The "choke" affects other devices on the system too, notably libata,
> > > which does not recover gracefully. In my logs, I see a
On Sunday 25 November 2007 00:25:10 Francois Romieu wrote:
> Alistair John Strachan <[EMAIL PROTECTED]> :
> [...]
>
> > The "choke" affects other devices on the system too, notably libata,
> > which does not recover gracefully. In my logs, I see a stream of:
> >
> > DMA: Out of SW-IOMMU space for
Francois Romieu <[EMAIL PROTECTED]> :
> Alistair John Strachan <[EMAIL PROTECTED]> :
> [...]
> > The "choke" affects other devices on the system too, notably libata, which
> > does not recover gracefully. In my logs, I see a stream of:
> >
> > DMA: Out of SW-IOMMU space for 7222 bytes at device
This fixes only symptom, not illness.
This check represent what code think about filesystem layout.
On what actually kind of UFS system did you test this patch?
When I sometime ago fixed similar issue for openstep ufs,
actully this was darwin's ufs which has the same layout,
I just set
Alan Cox <[EMAIL PROTECTED]> :
[...]
> You seem to have a leak, which actually isn't suprising
>
> rtl8169_xmit_frags allocates a set of maps for a fragmented packet
>
> rtl8169_start_xmit allocates a buffer
>
> When we finish the transit we free the main buffer (always using
<<< No Message Collected >>>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
> when these messages appear, removing r8169 would appear to be key. Indeed, if
> there is no significant libata activity, the problem still occurs on the NIC
> within approximately the same amount of transfer.
You seem to have a leak, which actually isn't suprising
rtl8169_xmit_frags
Alistair John Strachan <[EMAIL PROTECTED]> :
[...]
> The "choke" affects other devices on the system too, notably libata, which
> does not recover gracefully. In my logs, I see a stream of:
>
> DMA: Out of SW-IOMMU space for 7222 bytes at device :04:00.0
> DMA: Out of SW-IOMMU space for 7222
[ I removed Frans from cc: since it is off-topic to the original bugreport ]
On Saturday 24 November 2007, Rafael J. Wysocki wrote:
> On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
> [--snip--]
> > Rafael, I see that you've filled a bug for this bugreport into kernel
> >
Hi,
I have recently assembled a Core 2 Duo system with 4GB RAM and I believe there
might be a bug in the r8169 driver in >4GB RAM configurations.
Initially I can use one of two active r8169 NICs on the motherboard with this
quantity of RAM with other devices, without issue. But after some
Ok. I have kicked around a lot implementation ideas and took a good hard
look at my /proc/net implementation. The patch below should close all
of the holes with /proc/net that I am aware of.
Bind mounts work and properly capture /proc/net/
stat of /proc/net and /proc/net/ return the same
On Saturday 24 November 2007 15:14, Denys Vlasenko wrote:
> 3.gc
> The meat of the patchset is here.
> Introduce config option DISCARD_UNUSED_SECTIONS.
> If it is selected:
> Pass -ffunction-sections -fdata-sections to gcc and
> --gc-sections --print-gc-sections to ld.
>
On Saturday 24 November 2007 15:14, Denys Vlasenko wrote:
> 2.modpost
> Update scripts/mod/* machinery to correctly handle the case
> when we have more than 64k sections.
Signed-off-by: Denys Vlasenko <[EMAIL PROTECTED]>
--
vda
diff -urpN linux-2.6.gc1/scripts/mod/file2alias.c
On Sunday, 25 of November 2007, Rafael J. Wysocki wrote:
> On Saturday, 24 of November 2007, Pavel Machek wrote:
> > Hi!
> >
> > > > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > > > clockevents drivers?
> > > >
> > > > Ok, I guess I'm lost. If I offline second
Hi Sam,
On Sunday 18 November 2007 15:00, Sam Ravnborg wrote:
> On Tue, Sep 11, 2007 at 09:05:33PM +0100, Denys Vlasenko wrote:
> > Build system: section garbage collection for vmlinux
> >
> > Newer gcc and binutils can do dead code and data removal
> > at link time. It is achieved using
On Saturday, 24 of November 2007, Pavel Machek wrote:
> Hi!
>
> > > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > > clockevents drivers?
> > >
> > > Ok, I guess I'm lost. If I offline second CPU, I immediately get
> > > 1000Hz timer tick... is that expected?
> >
On Nov 24, 2007 12:36 PM, Andrey Borzenkov <[EMAIL PROTECTED]> wrote:
> I have no COM port on notebook (without port replicator which I do not have)
> so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
> created) but I just noticed that serial modules are still loaded.
Le 24.11.2007 14:26, James Bottomley a écrit :
> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
>> Le 24.11.2007 07:42, James Bottomley a écrit :
>>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
[snip]
I can confirm :
[PATCH] x86_64: not set boot cpu in cpu_present_map again
in init/main.c boot_cpu_init() already does that before setup_arch
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c
index 30d94d1..9905c45 100644
---
[PATCH] x86_64: not set boot cpu in cpu_online_map at x86_64_start_kernel
in init/main.c boot_cpu_init() does that later
Signed-off-by: Yinghai Lu <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/head64.c b/arch/x86/kernel/head64.c
index 6b34693..82b9f03 100644
--- a/arch/x86/kernel/head64.c
Hi!
> > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > clockevents drivers?
> >
> > Ok, I guess I'm lost. If I offline second CPU, I immediately get
> > 1000Hz timer tick... is that expected?
>
> Hmm. No. I have no idea why this is happening.
>
> 34196 total
On Thu 2007-11-22 21:29:51, Thomas Gleixner wrote:
> On Thu, 22 Nov 2007, Pavel Machek wrote:
> > > but perhaps somehow we miss this fact and fail to turn off the lapic
> > > clockevents drivers?
> >
> > Ok, I guess I'm lost. If I offline second CPU, I immediately get
> > 1000Hz timer tick... is
> Very strange indeed. Another possibility is that there is a hardware
> monitoring chip connected to one of the Radeon adapter's I2C buses, and
> that holding the I2C lines prevents reading from it, so whatever is
> responsible for controlling the temperature prefers to play it safe and
> shuts
On Sat, 24 Nov 2007 15:18:26 +0100, Michael Buesch wrote:
> On Friday 23 November 2007 23:29:28 Jean Delvare wrote:
> > Out of curiosity, what kind of crash was it? I admit that I can't see
> > how the code could crash.
>
> It's not the code that crashes. It's the hardware that turns off the
Kjartan Maraas wrote:
to., 04.10.2007 kl. 10.02 +1000, skrev Rusty Russell:
On Wed, 2007-10-03 at 10:37 +0100, Chris Malley wrote:
Hi guys
Would it not be clearer to #include and use
the relevant named members of struct setup_header / struct boot_params
rather than the hard-coded values
Compliment va_copy() with va_end().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested on i386 with allyesconfig & allmodconfig.
diff --git a/kernel/audit.c b/kernel/audit.c
index f93c271..836626c 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -1245,6 +1245,7 @@ static
to., 04.10.2007 kl. 10.02 +1000, skrev Rusty Russell:
> On Wed, 2007-10-03 at 10:37 +0100, Chris Malley wrote:
> > Hi guys
> >
> > Would it not be clearer to #include and use
> > the relevant named members of struct setup_header / struct boot_params
> > rather than the hard-coded values 0x202,
thanks, applied.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Compliment va_start() with va_end().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
ieee754.c |2 ++
ieee754dp.c |2 ++
ieee754sp.c |2 ++
3 files changed, 6 insertions(+)
diff --git a/arch/mips/math-emu/ieee754.c b/arch/mips/math-emu/ieee754.c
index 946aee3..cb1b682
On Sat, 24 Nov 2007, Michael Kerrisk wrote:
> > +asmlinkage long sys_timerfd_create(int clockid, int flags)
> > {
> > - int error;
> > + int error, ufd;
> > struct timerfd_ctx *ctx;
> > struct file *file;
> > struct inode *inode;
> > - struct itimerspec ktmr;
> > -
> > - if
Make a single va_start() -> va_end() path + fixing:
CHECK /home/kernel/src/net/irda/parameters.c
/home/kernel/src/net/irda/parameters.c:466:2: warning: Using plain integer as
NULL pointer
/home/kernel/src/net/irda/parameters.c:520:2: warning: Using plain integer as
NULL pointer
Compliment va_start() with va_end().
Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
---
Compile-tested on i386 with allyesconfig & allmodconfig.
utdebug.c |2 ++
utmisc.c |4
2 files changed, 6 insertions(+)
diff --git a/drivers/acpi/utilities/utdebug.c
On Sat, Nov 24, 2007 at 08:11:45PM +, Phil Endecott wrote:
> J. Bruce Fields wrote:
>> On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote:
>>> Dear Experts,
>>>
>>> NFS doesn't work with inotify (and it looks like it can't, certainly not
>>> before NFS v4.1). However, if I give an
I have no COM port on notebook (without port replicator which I do not have)
so COM is disabled in BIOS. No ttyS* is detected during boot (and no device
created) but I just noticed that serial modules are still loaded. Well, this
partially defeats the purpose of disabling COM port - the intention
This message contains a list of some regressions from 2.6.23 which have been
reported since 2.6.24-rc1 was released and for which there are no fixes in the
mainline that I know of. If any of them have been fixed already, please let me
know.
If you know of any other unresolved regressions from
> Stefan Richter wrote:
>> I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI
>> motherboard and i386 kernel and one with i945 based Apple motherboard
>> and x86-64 kernel. Before that I ran linux 2.6.23.
>>
>> On both PCs, "sensors" exits with
>>> No sensors found!
>
> now
J. Bruce Fields wrote:
On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote:
Dear Experts,
NFS doesn't work with inotify (and it looks like it can't, certainly not
before NFS v4.1). However, if I give an NFS filename to
inotify_add_watch(), I don't get an error.
If it indicated
On Fri, Nov 23, 2007 at 11:20:55PM +, Phil Endecott wrote:
> Dear Experts,
>
> NFS doesn't work with inotify (and it looks like it can't, certainly not
> before NFS v4.1). However, if I give an NFS filename to
> inotify_add_watch(), I don't get an error.
>
> If it indicated an error in this
On Saturday, 24 of November 2007, Frans Pop wrote:
> On Saturday 24 November 2007, Bartlomiej Zolnierkiewicz wrote:
> > Unfortunately I'm unable to reproduce this with:
> >
> > * VirtualBox 1.5.2 from http://www.virtualbox.org
> > (VirtualBox-1.5.2_25433_fedora7-1.i586.rpm)
> >
> > * Fedora 7
On Sat, 24 Nov 2007 10:48:39 -0800
David Brownell <[EMAIL PROTECTED]> wrote:
> On Saturday 24 November 2007, Haavard Skinnemoen wrote:
> > >
> > > Why is this needed and is it perhaps something that can be moved
> > > to the MMC core?
> >
> > We used to have lots of problems with overruns and
atl1: disable broken 64-bit DMA
[ Upstream commit: 5f08e46b621a769e52a9545a23ab1d5fb2aec1d4 ]
The L1 network chip can DMA to 64-bit addresses, but multiple descriptor
rings share a single register for the high 32 bits of their address, so
only a single, aligned, 4 GB physical address range can
--- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> Andrew Morgan wrote:
> > Its not so much why you are wrong, as being clear that we're not using a
> > generic name and inadvertently limiting ourselves to a SMACK-like model...
> >
> It seems we all agree that it is a bad idea to tie a POSIX
On Saturday, 24 of November 2007, Stefano Brivio wrote:
> On Sat, 24 Nov 2007 19:48:58 +0100
> "Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
>
> > NO_HZ? Highres timers?
>
> CONFIG_HZ_1000=y
> # CONFIG_HIGH_RES_TIMERS is not set
>
> > I understand that the previous kernels behave correctly.
Len Brown ha scritto:
On Sunday 21 October 2007 05:43, [EMAIL PROTECTED] wrote:
have emerged lm_sensors but can't get it running - it keeps saying "No
sensors found!" and complaining about kernel drivers not properly setup.
I have attached the output of sensors-detect, from which it seems that
Len Brown ha scritto:
On Thursday 22 November 2007 02:24, [EMAIL PROTECTED] wrote:
It is also important to note that this bug always comes with bug 8740
http://bugzilla.kernel.org/show_bug.cgi?id=8740 (also confirmed and also
an ACPI issue).
No, 8740 is not an ACPI issue.
On Saturday 24 November 2007, Haavard Skinnemoen wrote:
> >
> > Why is this needed and is it perhaps something that can be moved to
> > the MMC core?
>
> We used to have lots of problems with overruns and underruns and those
> parameters were useful to limit the transfer rate. Now that the
On Saturday, 24 of November 2007, Bartlomiej Zolnierkiewicz wrote:
[--snip--]
> Rafael, I see that you've filled a bug for this bugreport into kernel
> bugzilla tracker (one day after the bugreport):
>
> http://bugzilla.kernel.org/show_bug.cgi?id=9442
>
> Since we try to address
On Sat, 24 Nov 2007 19:48:58 +0100
"Rafael J. Wysocki" <[EMAIL PROTECTED]> wrote:
> NO_HZ? Highres timers?
CONFIG_HZ_1000=y
# CONFIG_HIGH_RES_TIMERS is not set
> I understand that the previous kernels behave correctly. All of them?
2.6.21 behaved correctly. Sorry but git-bisect would take a
Rafael J. Wysocki wrote:
> On Saturday, 24 of November 2007, Udo van den Heuvel wrote:
>> Hello,
>>
>> What happened in the attached messages?
>> It was on a VIA Epia EN12000, while compiling.
>> Yes, the machine has been stable before and after that issue.
>> So I suspect no hardware issues.
>
>
On Fri, Nov 23, 2007 at 01:01:15PM +0100, Andi Kleen wrote:
> On Fri, Nov 23, 2007 at 03:03:29PM +1100, David Chinner wrote:
> > On Fri, Nov 23, 2007 at 03:53:17AM +0100, Andi Kleen wrote:
> > > On Fri, Nov 23, 2007 at 12:15:39AM +1100, David Chinner wrote:
> > > > On Thu, Nov 22, 2007 at
On Saturday, 24 of November 2007, Udo van den Heuvel wrote:
> Hello,
>
> What happened in the attached messages?
> It was on a VIA Epia EN12000, while compiling.
> Yes, the machine has been stable before and after that issue.
> So I suspect no hardware issues.
Which kernel is this?
Rafael
-
To
On Saturday, 24 of November 2007, Stefano Brivio wrote:
> It looks like the jiffies counter sometimes jumps back and forth of some
> hundreds seconds in 2.6.24-rc3. I observed that this happens when I use the
> su(1) command, e.g.:
>
> Nov 24 06:17:17 morte [190769.065301] wmaster0: STA
Gabriel C wrote:
> James Bottomley wrote:
>> On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
>>> James Bottomley wrote:
On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
> Le 24.11.2007 07:42, James Bottomley a écrit :
>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard
On Sat, Nov 24, 2007 at 06:35:25PM +0100, Pierre Ossman wrote:
> On Sat, 24 Nov 2007 17:22:36 +
> Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> > On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> > > It most certainly does not. gcc will assume that an int* has int
> > >
Simon, can you test this patch? I think it's the most straightforward
2.6.24 fix.
diff -r c60016ba6237 net/core/netpoll.c
--- a/net/core/netpoll.cTue Nov 13 09:09:36 2007 -0800
+++ b/net/core/netpoll.cFri Nov 23 13:10:28 2007 -0600
@@ -203,6 +203,12 @@ static void
On Sat, 24 Nov 2007 18:00:23 +0100
Pierre Ossman <[EMAIL PROTECTED]> wrote:
> On Fri, 23 Nov 2007 13:20:13 +0100
> Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
>
> > This is a driver for the MMC controller on the AP7000 chips from
> > Atmel. It should in theory work on AT91 systems too with
On Sat, 24 Nov 2007 18:56:57 +0100
Frans Pop <[EMAIL PROTECTED]> wrote:
> Stefano Brivio wrote:
> > It looks like the jiffies counter sometimes jumps back and forth of some
> > hundreds seconds in 2.6.24-rc3. I observed that this happens when I use
> > the su(1) command, e.g.:
>
> Can you please
James Bottomley wrote:
> On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
>> James Bottomley wrote:
>>> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
Le 24.11.2007 07:42, James Bottomley a écrit :
> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
>> Le
On Saturday, 24 of November 2007, Jan-Simon Möller wrote:
> Am Freitag 23 November 2007 08:21:09 schrieb Andrew Morton:
> > On Tue, 13 Nov 2007 21:55:15 +0100 Jan-Simon M__ller <[EMAIL PROTECTED]>
> > wrote:
> > > Hi!
> >
> > You removed from cc the guys who are most likely to fix this. Please
>
kosaki wrote:
> Hi, Andrew
>
>>> Hi, Andrew
>>>
>>> I got following result in 'sync' command.
>>> It was too slow. (memory controller config is off ;)
>>> I attaches my .config.
>>> ==
> (snip)
>> Well I wonder how we did that.
>>
>> It seems OK here from a quick test (i386, ext3-on-IDE).
>>
>>
On Sat, 2007-11-24 at 18:54 +0100, Gabriel C wrote:
> James Bottomley wrote:
> > On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
> >> Le 24.11.2007 07:42, James Bottomley a écrit :
> >>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
> Le 23.11.2007 12:38, Hannes
Stefano Brivio wrote:
> It looks like the jiffies counter sometimes jumps back and forth of some
> hundreds seconds in 2.6.24-rc3. I observed that this happens when I use
> the su(1) command, e.g.:
Can you please explain what exactly the problem is here?
Are you perhaps referring to the number
James Bottomley wrote:
> On Sat, 2007-11-24 at 13:57 +0100, Laurent Riffard wrote:
>> Le 24.11.2007 07:42, James Bottomley a écrit :
>>> On Fri, 2007-11-23 at 18:52 +0100, Laurent Riffard wrote:
Le 23.11.2007 12:38, Hannes Reinecke a écrit :
> Hannes Reinecke wrote:
>> Laurent Riffard
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
> Nothing does, even memcpy doesn't check alignment of the source, or
> alignment at all in some assembly implementations (only word-copy,
> without checking if at word-boundary).
An out-of-line implementation can only
Probing intermittent failures in Domain Validation, even with the fixes
applied leads me to the conclusion that there are further problems with
this commit:
commit fc5eb4facedbd6d7117905e775cee1975f894e79
Author: Hannes Reinecke <[EMAIL PROTECTED]>
Date: Tue Nov 6 09:23:40 2007 +0100
Stefan Richter wrote:
> I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI
> motherboard and i386 kernel and one with i945 based Apple motherboard
> and x86-64 kernel. Before that I ran linux 2.6.23.
>
> On both PCs, "sensors" exits with
>> No sensors found!
now logged at
On Sat, 24 Nov 2007 17:22:36 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
> On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> > It most certainly does not. gcc will assume that an int* has int alignment.
> > memcpy() is a builtin, which gcc can translate to pretty much anything.
I just booted 2.6.24-rc3 on two different PCs, one with i945 based MSI
motherboard and i386 kernel and one with i945 based Apple motherboard
and x86-64 kernel. Before that I ran linux 2.6.23.
On both PCs, "sensors" exits with
> No sensors found!
> Make sure you loaded all the kernel drivers you
It looks like the jiffies counter sometimes jumps back and forth of some
hundreds seconds in 2.6.24-rc3. I observed that this happens when I use the
su(1) command, e.g.:
Nov 24 06:17:17 morte [190769.065301] wmaster0: STA 00:14:c1:35:8d:eb Average
rate: 232 (6730/29)
Nov 24 06:17:22 morte
The first "p->exit_state != EXIT_ZOMBIE" check doesn't make too much sense. The
exit_state was EXIT_ZOMBIE when the function was called, and another thread can
change it to EXIT_DEAD right after the check.
The second condition is not possible, detached non-traced threads were already
filtered out
On Sat, Nov 24, 2007 at 05:19:31PM +0100, Pierre Ossman wrote:
> On Sat, 24 Nov 2007 15:50:52 +
> Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> >
> > Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> > in any case. Intelligent ones, like the one provided in glibc,
The Coverity checker spotted the following check-after-use in
fs/cifs/cifsacl.c:
<-- snip -->
...
static void parse_dacl(struct cifs_acl *pdacl, char *end_of_acl,
struct cifs_sid *pownersid, struct cifs_sid *pgrpsid,
struct inode *inode)
{
...
On Fri, 23 Nov 2007 13:20:13 +0100
Haavard Skinnemoen <[EMAIL PROTECTED]> wrote:
> This is a driver for the MMC controller on the AP7000 chips from
> Atmel. It should in theory work on AT91 systems too with some
> tweaking, but since the DMA interface is quite different, it's not
> entirely clear
Surprise, other 2 wait_task_() functions also abuse task_pid_nr_ns(). May cause
read-after-free or report nr == 0 in wait_task_continued(). wait_task_zombie()
doesn't have this problem, but still it is better to cache pid_t rather than
call task_pid_nr_ns() 3 times on the saved pid_namespace.
On Sat, 24 Nov 2007 15:50:52 +
Luciano Rocha <[EMAIL PROTECTED]> wrote:
>
> Dumb memcpy (while (len--) { *d++ = *s++ }) will have alignment problems
> in any case. Intelligent ones, like the one provided in glibc, first copy
> bytes till output is aligned (C file) *or* size is a multiple
On Nov 24, 2007 12:28 AM, Eric Dumazet <[EMAIL PROTECTED]> wrote:
> OK, but maybe for consistency, we might accept the two mechanisms.
It's not a question of the kernel interface. The issue with all these
extensions is the userlevel interface. Ideally no new userlevel
interface is needed. This
On Sat, Nov 24, 2007 at 02:34:41PM +0100, Pierre Ossman wrote:
> On Fri, 23 Nov 2007 00:15:53 + (GMT)
> Daniel Drake <[EMAIL PROTECTED]> wrote:
>
> > Being spoilt by the luxuries of i386/x86_64 I've never really had a good
> > grasp on unaligned memory access problems on other architectures
On Sat, 24 Nov 2007, Pierre Ossman wrote:
> On Wed, 21 Nov 2007 12:33:45 +0100
> Andre Haupt <[EMAIL PROTECTED]> wrote:
>
> > I think, the status paramter should be unsigned. Is this correct?
> > This also fixes a sparse warning about different signedness.
> > Only compile tested, because i do
Imho, the current usage of security_task_wait() is not logical.
Suppose we have the single child p, and security_task_wait(p) return -EANY.
In that case waitpid(-1) returns this error. Why? Isn't it better to return
ECHLD? We don't really have the reapable childs.
Now suppose that child was
wuhm schrieb:
Unable to handle kernel paging request at virtual address c3c0
pgd = c3a5c000
[c3c0] *pgd=
Internal error: Oops: f5 [#1]
Modules linked in: dm642 mv_sata ixp400_eth ixp400
dm642 is an out-of-tree module. Contact the author of that module.
CPU: 0
PC is at
On Wed, 21 Nov 2007 12:33:45 +0100
Andre Haupt <[EMAIL PROTECTED]> wrote:
> I think, the status paramter should be unsigned. Is this correct?
> This also fixes a sparse warning about different signedness.
> Only compile tested, because i do not have the hardware.
>
> From: Andre Haupt <[EMAIL
On Wed, Nov 21, 2007 at 10:58:21AM +0100, Sam Ravnborg wrote:
> On Wed, Nov 21, 2007 at 10:44:40AM +0200, Avi Kivity wrote:
> > Kamalesh Babulal wrote:
> > >Andrew Morton wrote:
> > >
> > >>On Wed, 21 Nov 2007 13:54:50 +0530 Kamalesh Babulal
> > >><[EMAIL PROTECTED]> wrote:
> > >>
> > >>
>
1 - 100 of 242 matches
Mail list logo
