On Tue, 27 Nov 2007 13:34:57 PST, Michael Chan said:
> Ideally, the BIOS should modify the NVRAM's setting when it is changed.
> We will talk to Dell to get their opinion on this as this is very
> confusing to the user.
That would certainly explain what I'm seeing, and I can certainly wait
if the
On Tue, 2007-11-27 at 01:35 -0800, [EMAIL PROTECTED] wrote:
>
> Issue:
>
> I (for unrelated reasons) run powertop, and it suggests I conserve power
> by doing 'ethtool -s eth0 wol d'. I look at it, and think that it's daft,
> because (a) the Dell factory default is WOL disabled and (b) if it wa
On Tue, 27 Nov 2007 08:04:28 PST, Michael Chan said:
> [EMAIL PROTECTED] wrote:
>
> > (a) the Dell factory default is WOL disabled and (b)
> > if it wasn't
> > the default, I'd have *set* it to disabled, and (c) I even
> > went back and
> > rebooted and checked the BIOS setting - disabled. Nonethe
[EMAIL PROTECTED] wrote:
> (a) the Dell factory default is WOL disabled and (b)
> if it wasn't
> the default, I'd have *set* it to disabled, and (c) I even
> went back and
> rebooted and checked the BIOS setting - disabled. Nonetheless:
>
> # ethtool eth0 | grep Wake
> Supports Wake-on:
Scenario - Dell Latitude D820 laptop, tg3 driver says this at boot:
eth0: Tigon3 [partno(BCM5752KFBG) rev 6002 PHY(5752)] (PCI Express)
10/100/1000Base-T Ethernet 00:15:c5:c8:33:4e
eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] WireSpeed[1] TSOcap[1]
eth0: dma_rwctrl[7618] dma_mask[64-bit]
#
On Fri, Nov 09, 2007 at 03:24:44PM -0500, [EMAIL PROTECTED] wrote:
> On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:
>
> > wing patch fixes up the cpuidle / pm-qos integration.
> >
> > I suspect that this is folded into another mm patch but it should fix
> > C-state issue identified.
>
> Conf
On Thu, 08 Nov 2007 14:30:07 PST, Mark Gross said:
> wing patch fixes up the cpuidle / pm-qos integration.
>
> I suspect that this is folded into another mm patch but it should fix
> C-state issue identified.
Confirming that patch left my CPUs mostly in C3 again. Thanks.
I'll have to let Mark a
l.
>
> As reported by 'powertop' on a basically idle machine:
>
> 2.6.23-mm1:
>
> CnAvg residency P-states (frequencies)
> C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
&g
p://ftp.kernel.org/pub/linux/kernel/people/akpm/mm/broken-out-2007-11-06-02-32.tar.gz
is from two days ago.
> FWIW I think I fixed this when I fixed up Rafael's issue. Would you
> like me to send out a re-fresh patch against 2.6.23-mm1?
sure.
-
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/
> >
> > Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
> >
> > As reported by 'powertop' on a basically idle machine:
> >
> > 2.6.23-mm1:
> >
> > CnAvg residency P-states (frequencies)
> >
l.
>
> As reported by 'powertop' on a basically idle machine:
>
> 2.6.23-mm1:
>
> CnAvg residency P-states (frequencies)
> C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
&g
> As reported by 'powertop' on a basically idle machine:
>
> 2.6.23-mm1:
>
> CnAvg residency P-states (frequencies)
> C0 (cpu running)(100.0%)2.00 Ghz 0.8%
> C10.0ms ( 0.0%) 1.67 Ghz 0.0%
>
(Sorry for not reporting this sooner - I haven't been running off battery
much in the last 3 weeks, so I didn't notice it till now...)
Dell Latitude D820 laptop, T7200 Core2 Duo CPU, x86_64 kernel.
As reported by 'powertop' on a basically idle machine:
2.6.23-mm1:
C
On Wed, 31 Oct 2007 11:06:32 +0100 Pierre Peiffer <[EMAIL PROTECTED]> wrote:
> >
> > Storage classes which need to allcoate memory at insertion time are hard:
> > radix_tree_preload() gets it right in terms of robustness, but it's an
> > awful lot of fuss.
> >
> > IDR gets it all wrong and compo
Andrew Morton wrote:
> On Tue, 30 Oct 2007 17:13:50 +0100
> Pierre Peiffer <[EMAIL PROTECTED]> wrote:
>
>> ida_pre_get() and idr_pre_get() currently return 0 in case of error, and 1
>> in case of success, what is not the conventional way to handle error cases.
>>
>> This patch makes both of them
On Tue, 30 Oct 2007 17:13:50 +0100
Pierre Peiffer <[EMAIL PROTECTED]> wrote:
>
> ida_pre_get() and idr_pre_get() currently return 0 in case of error, and 1
> in case of success, what is not the conventional way to handle error cases.
>
> This patch makes both of them return 0 in case of success,
ida_pre_get() and idr_pre_get() currently return 0 in case of error, and 1
in case of success, what is not the conventional way to handle error cases.
This patch makes both of them return 0 in case of success, and an errcode
otherwise, and then it changes each caller to let them return the error
On Sat, Oct 27, 2007 at 05:19:24PM +0200, Tilman Schmidt wrote:
> /me wrote:
>
> > [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make
> > include/config/kernel.release
> > [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat
> > include/config/k
/me wrote:
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make
> include/config/kernel.release
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> cat
> include/config/kernel.release
> 2.6.23-mm1-testing
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> make
On Sun, 21 Oct 2007 12:12:38 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
> After the bisecting, i found that the patch git-net.patch is the cause for
> the link failure.
The actual cause is my patch to mark some things in head_64.S as
init_refok. I have a test patch which I will tidy up
Elantech
driver seem to try that query too.
- Make an educated guess bases on the Synaptics Capabilities query whether
middle mouse button reporting works and how finger taps are reported.
- Added a debug option.
Signed-off-by: Arjan Opmeer <[EMAIL PROTECTED]>
---
diff -purN -X linux-2.6
On Tue, 23 Oct 2007 09:52:08 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Tue, 23 Oct 2007 12:55:44 +0400
> Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
>
> > I look at the 2.6.23-mm1 and see that there's one hunk lost. This
> > is the one Oleg re-sent
On Tue, 23 Oct 2007 12:55:44 +0400
Pavel Emelyanov <[EMAIL PROTECTED]> wrote:
> I look at the 2.6.23-mm1 and see that there's one hunk lost. This
> is the one Oleg re-sent some days ago (the mail thread subject was
> 2.6.23-mm1 thread exit_group issue). Here it
> >> I guess we can debug it in the old-fashioned ways. The first of which is
> >> to palm the problem off on Pavel ;)
>
> I look at the 2.6.23-mm1 and see that there's one hunk lost. This
> is the one Oleg re-sent some days ago (the mail thread subject was
>
Miklos Szeredi wrote:
>> I guess we can debug it in the old-fashioned ways. The first of which is
>> to palm the problem off on Pavel ;)
I look at the 2.6.23-mm1 and see that there's one hunk lost. This
is the one Oleg re-sent some days ago (the mail thread subject was
quot;1 tests failed". On
2.6.23-mm1, it just hangs after the first test.
I've only tried under UML, but since Rick is seeing it on real HW, I
guess this method may work there as well.
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of
On Mon, Oct 22, 2007 at 09:38:12PM -0400, Rik van Riel wrote:
> Wrt. the UML failures that Miklos is seeing, I imagine UML needs
> to do some similar tricks.
UML is just an architecture - it has no need of such tricks (although
it does need to keep track of host pids, but these are in architecture
On Mon, 2007-10-22 at 21:38 -0400, Rik van Riel wrote:
> On Mon, 22 Oct 2007 21:11:43 -0400
> Rik van Riel <[EMAIL PROTECTED]> wrote:
>
> > I have my systems set up to automount my home directory over
> > NFS when I log in. When trying to log in to the system wit
On Mon, 22 Oct 2007 21:11:43 -0400
Rik van Riel <[EMAIL PROTECTED]> wrote:
> I have my systems set up to automount my home directory over
> NFS when I log in. When trying to log in to the system with
> 2.6.23-mm1, I get the messages from above in my syslog, and
> the NFS
tems set up to automount my home directory over
NFS when I log in. When trying to log in to the system with
2.6.23-mm1, I get the messages from above in my syslog, and
the NFS filesystem is not automounted.
I am thinking something in autofs or the pid-namespace* patches
does not match up and us
> > If not, I'll go searching for the offending patch.
> > > >
> > > > I wonder if that's the same bug that's breaking autofs for me.
> > >
> > > Probably.
> > >
> > > > Oct 22 14:39:01 kenny automount[2299]:
7;s breaking autofs for me.
> >
> > Probably.
> >
> > > Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent
> > > cache rwlock lock failed
> > > Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error:
> > > 11 at 65 in cac
On Sat, 2007-10-20 at 10:56 -0400, Rik van Riel wrote:
> I just tried it. In the latest git tree, autofs still works.
>
> The regression is in -mm only.
Andrew,
Rik tracked it down to an interaction with futexes from the pid
namespace code. I believe r/o bind mounts are innocent for now.
-- D
gt; > rwlock lock failed
> > Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error:
> > 11 at 65 in cache.c
> >
> > I'm bisecting 2.6.23-mm1 today to find the problem patch, with
> > some luck I'll have it this afternoon.
> >
> >
er if that's the same bug that's breaking autofs for me.
Probably.
> Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent cache
> rwlock lock failed
> Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error: 11 at
> 65 in cache.c
>
> I'm bis
searching for the offending patch.
I wonder if that's the same bug that's breaking autofs for me.
Oct 22 14:39:01 kenny automount[2299]: cache_readlock: mapent cache
rwlock lock failed
Oct 22 14:39:01 kenny automount[2299]: unexpected pthreads error: 11 at
65 in cache.c
I'm bis
I'm getting a process stuck in pthread_rwlock_wrlock(), even though it
looks like the lock is not held by anybody.
I think the last -mm was OK. Any ideas?
If not, I'll go searching for the offending patch.
Thanks,
Miklos
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"
ich probably isn't good and I'd
> rather not if we can avoid it.
I do not know if this an autofs issue or the result of something
else in 2.6.23-mm1.
> > I am not sure if this is due to autofs changes or changes in some
> > other code that was merged. If you can think of
On Sat, 2007-10-20 at 01:13 -0400, Rik van Riel wrote:
> On Thu, 11 Oct 2007 21:31:26 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> >
> > - I've been larg
Ben wrote:
Hello.
Whenever I log into xfce with gdm my computer will freeze when i use
reiserfs as my /home on 2.6.23-mm1. Logging into the VT works
perfectly fine. Previously my system would crash when logging into the
VT but the
make-reiserfs-stop-using-struct-file-for-internal.patch patch
On Sunday, 21 October 2007 11:58, Pavel Machek wrote:
> Hi!
>
> > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> >
> > Ok, now that it
Hi!
> On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
>
> Ok, now that it boots let's go for more.
>
> I cannot suspend if mysqld is running. mysql isn&#
t; lpar,
>>> which was seen in 2.6.23-rc8-mm2 (http://lkml.org/lkml/2007/9/30/2) is
>>> still
>>> seen in 2.6.23-mm1, the link failure is
>>>
>>> ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization
>>> to `.text.init.ref
On Sun, Oct 21, 2007 at 02:58:17PM +0900, Mattia Dongili wrote:
> On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
>
> Ok, now that it boots let's go for more.
>
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
Ok, now that it boots let's go for more.
I cannot suspend if mysqld is running. mysql isn't atually doing
anything useful any
on wrote:
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > >
> > > Hey there!!
> > > fails to boot here with this friendly oops:
> > > http://oioio.altervista.org/linux/dsc01702.jpg
>
; > > On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > On Thu, 11 Oct 2007 21:31:26 -0700
> > > > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > > >
> > > > >
>
On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
Hey there!!
fails to boot here with this friendly oops:
http://oioio.altervista.org/linux/dsc01702.jpg
.config: http://oioio.altervista.org
Hello.
Whenever I log into xfce with gdm my computer will freeze when i use
reiserfs as my /home on 2.6.23-mm1. Logging into the VT works perfectly
fine. Previously my system would crash when logging into the VT but the
make-reiserfs-stop-using-struct-file-for-internal.patch patch fixed the
On Fri, 2007-10-19 at 22:34 -0700, Andrew Morton wrote:
> On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
>
> > On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/peopl
gt;
> > > On Thu, 11 Oct 2007 21:31:26 -0700
> > > Andrew Morton <[EMAIL PROTECTED]> wrote:
> > >
> > > >
> > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > >
> > > &g
> >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > >
> > > - I've been largely avoiding applying anything since rc8-mm2 in an
> > > attempt to stabilise things for the 2.6.23 merge.
> >
> > Be
On Sat, 20 Oct 2007 01:13:10 -0400 Rik van Riel <[EMAIL PROTECTED]> wrote:
> On Thu, 11 Oct 2007 21:31:26 -0700
> Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> >
&g
On Sat, 20 Oct 2007 13:57:54 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote:
> On Thu, Oct 11, 2007 at 09:31:26PM -0700, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
>
> Hey there!!
> fails to boo
On Thu, 11 Oct 2007 21:31:26 -0700
Andrew Morton <[EMAIL PROTECTED]> wrote:
>
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
>
> - I've been largely avoiding applying anything since rc8-mm2 in an
> attempt to stabilise things for
e prev (80a3f338), but was
> 00200200. (next=810103dcbe90).
> [ cut here ]
> kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
> invalid opcode: [1] SMP
> last sysfs file: /devices/pci:00/:00:1e.0/:0
On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:
> > hm, I guess this is probably due to pie-randomization patch, right?
> > (could you please try reverting it, to see whether things get back to
> > normal).
> Maybe this can be fix.
Andrew,
below is a fixed version with patch from Kamezawa Hiroyu
> >> illegal operation: 0001 Ý#1¨
> >
> > that's a network issue ;)
> >
> >> 002b3352 gives : include/linux/netdevice.h:819
> >>
> >
> > I have a feeling that we fixed this. But there's no BUG at 2.6.23-mm1's
>> Ý<0029a8d0>¨ sock_ioctl+0x1cc/0x2dc
>> Ý<000cb844>¨ do_ioctl+0xb8/0xcc
>> Ý<000cb8f2>¨ vfs_ioctl+0x9a/0x3ec
>> Ý<000cbc96>¨ sys_ioctl+0x52/0x7c
>> Ý<00022484>¨ sysc_noemu+0x10/0x16
>
n itself not a problem, but it
>>> surfaced a bug: there is no *(.init.initramfs), that needs to be
>>> *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
>>> the older one that still causes the "Cannot open root device". For
>>> 2.6.
Oktober 2007 schrieb Serge E. Hallyn:
> >>>> Sigh, well this turned out less informative than I'd liked.
> >>>> After bisecting 2.6.23 to 2.6.23-mm1, I found that
> >>>> git-s390.patch is the one breaking my s390 boot :(
> >>>> (Frown bc it&
surfaced a bug: there is no *(.init.initramfs), that needs to be
> > *(init.ramfs). I corrected this in the upstream patch but 2.6.23-mm1 has
> > the older one that still causes the "Cannot open root device". For
> > 2.6.23-mm1 use the patch below.
> >
>
>
ked.
>>>> After bisecting 2.6.23 to 2.6.23-mm1, I found that
>>>> git-s390.patch is the one breaking my s390 boot :(
>>>> (Frown bc it's a conglomeration of patches0
>>>>
>>>> Symptom is:
>>>>"Cannot open root device
On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:
> > yes, this looks correct to me. Did you verify that it makes the
> > problem you are seeing go away?
> yes. I confirmed this works well.
Thanks a lot, it works flawlessly. I will rebase the patch after
2.6.24-rc1 is released and will send it to A
On Thu, 2007-10-18 at 15:31 -0500, Serge E. Hallyn wrote:
> Quoting Christian Borntraeger ([EMAIL PROTECTED]):
> > Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
> > > Sigh, well this turned out less informative than I'd liked.
> > > After bisecting 2.
Quoting Christian Borntraeger ([EMAIL PROTECTED]):
> Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
> > Sigh, well this turned out less informative than I'd liked.
> > After bisecting 2.6.23 to 2.6.23-mm1, I found that
> > git-s390.patch is the one breaking my
Am Donnerstag, 18. Oktober 2007 schrieb Serge E. Hallyn:
> Sigh, well this turned out less informative than I'd liked.
> After bisecting 2.6.23 to 2.6.23-mm1, I found that
> git-s390.patch is the one breaking my s390 boot :(
> (Frown bc it's a conglomeration of pa
Sigh, well this turned out less informative than I'd liked.
After bisecting 2.6.23 to 2.6.23-mm1, I found that
git-s390.patch is the one breaking my s390 boot :(
(Frown bc it's a conglomeration of patches0
Symptom is:
"Cannot open root device "dasdd2" or unknown-
ff80a3f338), but was
> 00200200. (next=810103dcbe90).
> [ cut here ]
> kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
> invalid opcode: [1] SMP
> last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
> CPU
ror: errno.h: No such file or directory
>
> This problem is fixed by d4faaecbcc6d9ea4f7c05f6de6af98e2336a4afb in
> Linus' tree.
>
> Paul.
> -
Hi Paul,
Thanks, we tried it out over the 2.6.23-mm1 and the patch fixes the build
failure.
--
Thanks & Regards,
Kamalesh Babulal
Kamalesh Babulal writes:
> The kernel build fails on the power box
>
> INSTALL vdso64.so
>
> INSTALL vdso32.so
>
> BOOTCC arch/powerpc/boot/inflate.o
>
> arch/powerpc/boot/inflate.c:920:19: error: errno.h: No such file or directory
This problem is fixed by d4faaecbcc6d9ea4f7c05f6de6af9
On Thu, Oct 18, 2007 at 10:07:54AM +1000, Paul Mackerras wrote:
> The correct fix is to make advansys depend on CONFIG_VIRT_TO_BUS, or
> alternatively fix advansys.c properly by making it use the interfaces
> described in Documentation/DMA-mapping.txt (or the equivalent scsi
> helpers).
If you loo
Andrew Morton writes:
> On Sat, 13 Oct 2007 10:14:22 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> > The functions virt_to_bus and bus_to_virt are begin defined between ifdef
> > CONFIG_PPC32
> > but when i compile allyesconfig with ppc64 box,i get this error. This patch
> > removes the
>
Am 14.10.2007 00:11 schrieb Tilman Schmidt:
> CONFIG_LOCALVERSION="-testing"
[...]
> has worked fine for all of 2.6.23{-rc?{,-mm?},}. For 2.6.23-mm1
> [there is] "make modules_install" installing the
> modules into /lib/modules/2.6.23-mm1 instead of
> /lib/mo
ocki wrote:
> > > > > > > On Friday, 12 October 2007 06:31, Andrew Morton wrote:
> > > > > > > >
> > > > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > > > > >
ke modules_install install"
> has worked fine for all of 2.6.23{-rc?{,-mm?},}. For 2.6.23-mm1
> it fails with:
>
> [EMAIL PROTECTED]:~/kernel/linux-2.6.23-mm1-work> sudo make modules_install
> install
> root's password:
> INSTALL arch/i386/crypto/aes-i58
On Fri, Oct 12, 2007 at 11:32:40PM +0200, Rafael J. Wysocki wrote:
> On Friday, 12 October 2007 06:31, Andrew Morton wrote:
> >
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> >
> > - I've been largely avoiding applying anyt
but was
00200200. (next=810103dcbe90).
[ cut here ]
kernel BUG at /home/legoater/linux/2.6.23-mm1/lib/list_debug.c:27!
invalid opcode: [1] SMP
last sysfs file: /devices/pci:00/:00:1e.0/:01:01.0/local_cpus
CPU 3
Modules linked in: ipt_REJECT iptable_filte
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Christoph Hellwig wrote:
> On Mon, Oct 15, 2007 at 02:31:03PM -0400, Jeff Mahoney wrote:
>> Here's a patch I worked up the other night that kills off struct file
>> completely from the xattr code. I've tested it locally.
>
> Looks like a merge of Dave
On Wed, 17 Oct 2007 13:42:04 +0200 (CEST)
Jiri Kosina <[EMAIL PROTECTED]> wrote:
> On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:
>
> > > Oh well, this causes more trouble that I have ever imagined ... I will
> > > look into it, thanks a lot for the report. Andrew, please drop this
> > > one aga
On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:
> > Oh well, this causes more trouble that I have ever imagined ... I will
> > look into it, thanks a lot for the report. Andrew, please drop this
> > one again, I will fix it up.
> Maybe this can be fix.
Hi Kame,
yes, this looks correct to me. Did
file changed, 11 insertions(+), 2 deletions(-)
Index: devel-2.6.23-mm1/arch/x86_64/mm/mmap.c
=======
--- devel-2.6.23-mm1.orig/arch/x86_64/mm/mmap.c
+++ devel-2.6.23-mm1/arch/x86_64/mm/mmap.c
@@ -54,13 +54,17 @@ static inline unsigned long mmap
On Wed, 17 Oct 2007, KAMEZAWA Hiroyuki wrote:
> I noticed 32bit binary on x86_64 behavior is changed on 2.6.23-mm1.
> This is a result of pmap after process returns -ENOMEM.(see attached program)
> == on 2.6.23 ==
[...]
> total 4193272K
> ==
> == on 2.6.23-mm
On Wed, 17 Oct 2007 16:01:01 +0900 KAMEZAWA Hiroyuki <[EMAIL PROTECTED]> wrote:
> I noticed 32bit binary on x86_64 behavior is changed on 2.6.23-mm1.
>
> This is a result of pmap after process returns -ENOMEM.(see attached program)
> == on 2.6.23 ==
> errno
On Mon, Oct 15, 2007 at 10:06:04PM +0200, Laurent Riffard wrote:
> > Here's a patch I worked up the other night that kills off struct file
> > completely from the xattr code. I've tested it locally.
>
> Sorry Jeff, your patch does not apply on 2.6.23-mm1. The
On Mon, Oct 15, 2007 at 02:31:03PM -0400, Jeff Mahoney wrote:
> Here's a patch I worked up the other night that kills off struct file
> completely from the xattr code. I've tested it locally.
Looks like a merge of Dave's and my patch :)
ACK from me, I don't care whether it's one or two patches.
-
I noticed 32bit binary on x86_64 behavior is changed on 2.6.23-mm1.
This is a result of pmap after process returns -ENOMEM.(see attached program)
== on 2.6.23 ==
errno 12
3531: ./malloc
1000 6272K -[ anon ]
00621000100K r-x-- /lib/ld-2.5.so
0063a000
ri, Oct 12, 2007 at 11:32:40PM +0200, Rafael J. Wysocki wrote:
> > > > > On Friday, 12 October 2007 06:31, Andrew Morton wrote:
> > > > > >
> > > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> >
Friday, 12 October 2007 06:31, Andrew Morton wrote:
> > > > >
> > > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > > >
> > > > > - I've been largely avoiding applying anyth
t; > > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm1/
> > > >
> > > > - I've been largely avoiding applying anything since rc8-mm2 in an
> > > > attempt
> > > > to stabilise things for the 2.6.
On Mon, Oct 15, 2007 at 10:55:06PM +0200, Rafael J. Wysocki wrote:
> On Sunday, 14 October 2007 22:20, Rafael J. Wysocki wrote:
> > On Sunday, 14 October 2007 21:47, Joseph Fannin wrote:
> > > On Sat, Oct 13, 2007 at 09:13:13PM +0200, Rafael J. Wysocki wrote:
> > >
> > > > Yes. Corrected patch fol
ml/2007/9/30/2) is still
>> seen in 2.6.23-mm1, the link failure is
>>
>> ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization
>> to `.text.init.refok' does not allow automatic multiple TOCs; recompile with
>> -mminimal-toc or -fno-optimize-s
On Tue, 16 Oct 2007 12:48:48 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi Andrew,
>
> The link failure while compiling the kernel with allyesconfig over the lpar,
> which was seen in 2.6.23-rc8-mm2 (http://lkml.org/lkml/2007/9/30/2) is still
> seen in 2.6.23-mm1
Hi Andrew,
The link failure while compiling the kernel with allyesconfig over the lpar,
which was seen in 2.6.23-rc8-mm2 (http://lkml.org/lkml/2007/9/30/2) is still
seen in 2.6.23-mm1, the link failure is
ld: arch/powerpc/kernel/head_64.o(.text+0x80c8): sibling call optimization to
On 10/14/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
> I didn't notice that qemu was involved. Does qemu have an emulator for the
> gdth hardware?
>
I think no, the kernel just probe exist or not hardware, and hangs after that.
-
To unsubscribe from this list: send the line "unsubscribe linux-ke
Nick Piggin <[EMAIL PROTECTED]> wrote:
> I don't think the fault handler is currently in any position to do
> that ATM. It is possible to make it interruptible in some contexts,
> but faults from kernel code may not be able to cope.
Hmmm... Good point. Yuck.
David
-
To unsubscribe from this li
On Tuesday 16 October 2007 00:06, David Howells wrote:
> Peter Zijlstra <[EMAIL PROTECTED]> wrote:
> > I get funny SIGBUS' like so:
> >
> > fault
> > if (->page_mkwrite() < 0)
> > nfs_vm_page_mkwrite()
> > nfs_write_begin()
> > nfs_flush_incompatible()
> > nfs_wb_page(
On Sunday, 14 October 2007 22:20, Rafael J. Wysocki wrote:
> On Sunday, 14 October 2007 21:47, Joseph Fannin wrote:
> > On Sat, Oct 13, 2007 at 09:13:13PM +0200, Rafael J. Wysocki wrote:
> >
> > > Yes. Corrected patch follows.
> >
> > A bit more is needed due to the rename of lite5200_pm_init()
On Monday, 15 October 2007 18:09, Mark Gross wrote:
> On Fri, Oct 12, 2007 at 11:32:40PM +0200, Rafael J. Wysocki wrote:
> > On Friday, 12 October 2007 06:31, Andrew Morton wrote:
> > >
> > > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.23/2.6.23-mm
http://lkml.org/lkml/2007/9/27/235). Dave Hansen sent a patch for it, I
>>>> tested it and it was OK for 2.6.22-rc8-mm2.
>>>>
>>>> I tried this patch on 2.6.23-mm1, and it fixed the BUGs here too.
>>> The delete path is a similar case as the one Dave
1 - 100 of 186 matches
Mail list logo
