On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote:
> On Aug 25 2005, at 16:04, Erik Mouw was caught saying:
> > On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> > > I really wanted to release a 2.6.13, but there's been enough changes
> > > while we've been waiting
On Fri, Aug 26, 2005 at 09:33:29PM -0700, Deepak Saxena wrote:
On Aug 25 2005, at 16:04, Erik Mouw was caught saying:
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other
I hate responding to myself but it's necessary:
>RC7-GIT7 barfed on me after some 20 hours:
complete serial console message before it reset is on:
http://newsgate.newsserver.nl/kernel/
as is config-file.
Hardware: AMD64 running pure-64 debian ony tyan motherboard with opteron
250
>I Wrote:
>After 53 hours and 31 minutes it crashed.
>dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31)
>reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41)
>
>Prior to this kernel it had been running 2.6.12-mm1 without problems:
>reboot system boot
I Wrote:
After 53 hours and 31 minutes it crashed.
dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash (2+05:31)
reboot system boot 2.6.13-rc7 Wed Aug 24 09:51 (2+05:41)
Prior to this kernel it had been running 2.6.12-mm1 without problems:
reboot system boot
I hate responding to myself but it's necessary:
RC7-GIT7 barfed on me after some 20 hours:
complete serial console message before it reset is on:
http://newsgate.newsserver.nl/kernel/
as is config-file.
Hardware: AMD64 running pure-64 debian ony tyan motherboard with opteron
250
On Aug 25 2005, at 16:04, Erik Mouw was caught saying:
> On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> > I really wanted to release a 2.6.13, but there's been enough changes
> > while we've been waiting for other issues to resolve that I think it's
> > best to do a -rc7
Richard Henderson wrote:
> Because I use "extern inline" in the proper way. That is, I have both
> inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int
Hello,
It crashes for me right off the bat:
Here is the kernel output:
---
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-2.6.13-rc7-git1 root=/dev/hda3 ro console=ttyS0,115200n8
CONSOLE=/dev/ttyS0
[Linux-bzImage, setup=0x1200, size=0x1fe4fa]
savedefault
boot
Linux
Danny ter Haar <[EMAIL PROTECTED]> wrote:
>Of course it will probably reboot just after sending this message.
Me and my big mouth...
If there is a god he is making fun of me right now ;-)
After 53 hours and 31 minutes it crashed.
dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash
tgoing network traffic and
sufficient storage to the scsi system.
Of course it will probably reboot just after sending this message.
If it stays up after 5 days of pounding it will get _my_ stamp of
aproval ;-)
--
Linux 2.6.13-rc7 ([EMAIL PROTECTED]) (gcc [can't parse]) #??? 1CPU
to the scsi system.
Of course it will probably reboot just after sending this message.
If it stays up after 5 days of pounding it will get _my_ stamp of
aproval ;-)
--
Linux 2.6.13-rc7 ([EMAIL PROTECTED]) (gcc [can't parse]) #??? 1CPU
[newsgate.(none)]
Memory: TotalUsed
Danny ter Haar [EMAIL PROTECTED] wrote:
Of course it will probably reboot just after sending this message.
Me and my big mouth...
If there is a god he is making fun of me right now ;-)
After 53 hours and 31 minutes it crashed.
dth pts/1zaphod.dth.net Wed Aug 24 09:54 - crash
Hello,
It crashes for me right off the bat:
Here is the kernel output:
---
Filesystem type is ext2fs, partition type 0x83
kernel /boot/vmlinuz-2.6.13-rc7-git1 root=/dev/hda3 ro console=ttyS0,115200n8
CONSOLE=/dev/ttyS0
[Linux-bzImage, setup=0x1200, size=0x1fe4fa]
savedefault
boot
Linux
Richard Henderson wrote:
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines.
Is there any reason not to just make the out-of-line version explicit?
i.e.:
/* in some .h file: */
static /*(always!)*/inline int
On Aug 25 2005, at 16:04, Erik Mouw was caught saying:
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
Sorry. Here's the start of the thread.
Tony
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Antonino A. Daplas:
> intelfb/fbdev: Save info->flags in a local variable
> Sylvain Meyer:
> intelfb: Do not ioremap entire graphics aperture
One of these
On Thu, Aug 25, 2005 at 03:16:49PM -0700, Richard Henderson wrote:
> On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
> > IMO that's a question to rth: why do we really need to block always_inline
> > on alpha?
>
> Because I use "extern inline" in the proper way. That is, I have both
>
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
> IMO that's a question to rth: why do we really need to block always_inline
> on alpha?
Because I use "extern inline" in the proper way. That is, I have both
inline and out-of-line versions of some routines. These routines have
their
On Thu, Aug 25, 2005 at 11:27:32AM +0400, Alexey Dobriyan wrote:
> Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
>
> > Which place triggers it in your build?
>
> net/ipv4/route.c:3152, call to rt_hash_lock_init().
>
> >From preprocessed source (reformatted):
>
Sorry but could you re-explain me the problem. Tony, you've only
CC'ed me the end of the story.
Just a correction the options are video=intelfb:accel=0,hwcursor=0
with = and not :
Regards
Sylvain
Sebastian Kaergel a écrit:
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas"
Sebastian Kaergel wrote:
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably
On Fri, 26 Aug 2005 00:23:40 +0800
"Antonino A. Daplas" <[EMAIL PROTECTED]> wrote:
> Sebastian Kaergel wrote:
> > On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
> > Linus Torvalds <[EMAIL PROTECTED]> wrote:
> >
> >> Sylvain Meyer:
> >> intelfb: Do not ioremap entire graphics aperture
>
> Probably
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info->flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds <[EMAIL PROTECTED]> wrote:
> Antonino A. Daplas:
> intelfb/fbdev: Save info->flags in a local variable
> Sylvain Meyer:
> intelfb: Do not ioremap entire graphics aperture
One of these changes broke intelfb. The same .config from
On Thu, 25 Aug 2005, Al Viro wrote:
> On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
> > I have been a little out of it for a while on the sun3 stuffs, I'll admit
> > (cursed day job), but I really, really intend to get recent 2.6 running
> > again. Knowing that the rest of m68k is
On Thu, 25 Aug 2005, Al Viro wrote:
> On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
>
> > I have been a little out of it for a while on the sun3 stuffs, I'll admit
> > (cursed day job), but I really, really intend to get recent 2.6 running
> > again. Knowing that the rest of
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
> I have been a little out of it for a while on the sun3 stuffs, I'll admit
> (cursed day job), but I really, really intend to get recent 2.6 running
> again. Knowing that the rest of m68k is at least compiling is a good
> start
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> I really wanted to release a 2.6.13, but there's been enough changes
> while we've been waiting for other issues to resolve that I think it's
> best to do a -rc7 first.
There's something strange going on with either ACPI or
On Thu, 25 Aug 2005, Geert Uytterhoeven wrote:
> Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
> for my uClinux experiments.
>
> > sun3 is seriously broken and I doubt that we'll see any takers for testing
> > 2.6 on those anyway ;-)
Hey, I'm writing this on a
On Wed, 24 Aug 2005, Al Viro wrote:
> It does, no (build) regressions. BTW, tree is not far from allmodconfig
> buildable on a bunch of targets now - yesterday pile of fixes was about
> half of the set needed for that. Most of the remaining stuff is for
> m68k (and applies both to Linus' tree
On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
> On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > > Most of the remaining stuff is for
> > > m68k (and applies both to Linus' tree and m68k CVS); I'll send
On Wed, Aug 24, 2005 at 10:38:59PM +0100, Al Viro wrote:
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
On Wed, 24 Aug 2005, Al Viro wrote:
It does, no (build) regressions. BTW, tree is not far from allmodconfig
buildable on a bunch of targets now - yesterday pile of fixes was about
half of the set needed for that. Most of the remaining stuff is for
m68k (and applies both to Linus' tree and
On Thu, 25 Aug 2005, Geert Uytterhoeven wrote:
Can't you use the plain m68k toolchain? I always used a m68k-linux-gcc 3.3.3
for my uClinux experiments.
sun3 is seriously broken and I doubt that we'll see any takers for testing
2.6 on those anyway ;-)
Hey, I'm writing this on a sun3! :)
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at least compiling is a good
start point.
On Thu, 25 Aug 2005, Al Viro wrote:
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at
On Thu, 25 Aug 2005, Al Viro wrote:
On Thu, Aug 25, 2005 at 09:59:05AM -0400, Sam Creasey wrote:
I have been a little out of it for a while on the sun3 stuffs, I'll admit
(cursed day job), but I really, really intend to get recent 2.6 running
again. Knowing that the rest of m68k is at
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
There's something strange going on with either ACPI or
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info-flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
One of these changes broke intelfb. The same .config from 2.6.13-rc6
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info-flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is less than stolen
On Fri, 26 Aug 2005 00:23:40 +0800
Antonino A. Daplas [EMAIL PROTECTED] wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this one. If vram is
Sebastian Kaergel wrote:
On Fri, 26 Aug 2005 00:23:40 +0800
Antonino A. Daplas [EMAIL PROTECTED] wrote:
Sebastian Kaergel wrote:
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
Probably this
Sorry but could you re-explain me the problem. Tony, you've only
CC'ed me the end of the story.
Just a correction the options are video=intelfb:accel=0,hwcursor=0
with = and not :
Regards
Sylvain
Sebastian Kaergel a écrit:
On Fri, 26 Aug 2005 00:23:40 +0800
Antonino A. Daplas
On Thu, Aug 25, 2005 at 11:27:32AM +0400, Alexey Dobriyan wrote:
Mine is alpha-unknown-linux-gnu-gcc (GCC) 3.4.4 (Gentoo 3.4.4)
Which place triggers it in your build?
net/ipv4/route.c:3152, call to rt_hash_lock_init().
From preprocessed source (reformatted):
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
Because I use extern inline in the proper way. That is, I have both
inline and out-of-line versions of some routines. These routines have
their address
On Thu, Aug 25, 2005 at 03:16:49PM -0700, Richard Henderson wrote:
On Thu, Aug 25, 2005 at 08:07:55PM +0100, Al Viro wrote:
IMO that's a question to rth: why do we really need to block always_inline
on alpha?
Because I use extern inline in the proper way. That is, I have both
inline and
Sorry. Here's the start of the thread.
Tony
On Tue, 23 Aug 2005 22:08:13 -0700 (PDT)
Linus Torvalds [EMAIL PROTECTED] wrote:
Antonino A. Daplas:
intelfb/fbdev: Save info-flags in a local variable
Sylvain Meyer:
intelfb: Do not ioremap entire graphics aperture
One of these changes
root:sleipner:~# modprobe hotkey
FATAL: Error inserting hotkey
(/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device
Not that I care, but it at least loaded in -rc6 and created the
/proc/acpi/hotkey directory with its content.
When the revolution comes, the author of
Hello,
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
>
> Hullo.
>
> I really wanted to release a 2.6.13, but there's been enough changes
> while we've been waiting for other issues to resolve that I think it's
> best to do a -rc7 first.
>
> Most of the -rc7 changes are
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> > Most of the remaining stuff is for
> > m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> > and if Geert ACKs them, we will be _very_ close to
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
> > sh64: need kernel headers that would make glibc happy enough
> > to build libc headers for that puppy;
>
> binutils already compiled. Will drop a line. Or file a bug. :-\
By some miracle gcc is also compiled. As of now
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
> Most of the remaining stuff is for
> m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
> and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
> out of the box on the following set:
> alpha,
Do I
On Wed, Aug 24, 2005 at 11:43:51AM -0700, Paul Jackson wrote:
> Al Viro wrote:
> > ... breaks ppc64 since there we have node_to_cpumask() done as inlined
> > function, not a macro. So we get __first_cpu(_to_cpumask(...),...),
> > with obvious consequences.
>
> I sent a patch for this a few hours
Al Viro wrote:
> ... breaks ppc64 since there we have node_to_cpumask() done as inlined
> function, not a macro. So we get __first_cpu(_to_cpumask(...),...),
> with obvious consequences.
I sent a patch for this a few hours ago, thanks to Paul Mackerras's report:
[PATCH 2.6.13-rc6]
On Wed, Aug 24, 2005 at 07:43:42AM +0100, Al Viro wrote:
> On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
>
> > cpu_exclusive sched domains on partial nodes temp fix
>
> ... breaks ppc64 since there we have node_to_cpumask() done as inlined
> function, not a macro. So we get
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
> cpu_exclusive sched domains on partial nodes temp fix
... breaks ppc64 since there we have node_to_cpumask() done as inlined
function, not a macro. So we get __first_cpu(_to_cpumask(...),...),
with obvious consequences.
On Wed, Aug 24, 2005 at 07:43:42AM +0100, Al Viro wrote:
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
cpu_exclusive sched domains on partial nodes temp fix
... breaks ppc64 since there we have node_to_cpumask() done as inlined
function, not a macro. So we get
Al Viro wrote:
... breaks ppc64 since there we have node_to_cpumask() done as inlined
function, not a macro. So we get __first_cpu(node_to_cpumask(...),...),
with obvious consequences.
I sent a patch for this a few hours ago, thanks to Paul Mackerras's report:
[PATCH 2.6.13-rc6]
On Wed, Aug 24, 2005 at 11:43:51AM -0700, Paul Jackson wrote:
Al Viro wrote:
... breaks ppc64 since there we have node_to_cpumask() done as inlined
function, not a macro. So we get __first_cpu(node_to_cpumask(...),...),
with obvious consequences.
I sent a patch for this a few hours ago,
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
and if Geert ACKs them, we will be _very_ close to having 2.6.13 build
out of the box on the following set:
alpha,
Do I
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
sh64: need kernel headers that would make glibc happy enough
to build libc headers for that puppy;
binutils already compiled. Will drop a line. Or file a bug. :-\
By some miracle gcc is also compiled. As of now (sh64,
On Thu, Aug 25, 2005 at 12:13:02AM +0400, Alexey Dobriyan wrote:
On Wed, Aug 24, 2005 at 08:15:44PM +0100, Al Viro wrote:
Most of the remaining stuff is for
m68k (and applies both to Linus' tree and m68k CVS); I'll send that today
and if Geert ACKs them, we will be _very_ close to having
Hello,
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
Hullo.
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
Most of the -rc7 changes are pretty
root:sleipner:~# modprobe hotkey
FATAL: Error inserting hotkey
(/lib/modules/2.6.13-rc7/kernel/drivers/acpi/hotkey.ko): No such device
Not that I care, but it at least loaded in -rc6 and created the
/proc/acpi/hotkey directory with its content.
When the revolution comes, the author of
On Tue, Aug 23, 2005 at 10:08:13PM -0700, Linus Torvalds wrote:
cpu_exclusive sched domains on partial nodes temp fix
... breaks ppc64 since there we have node_to_cpumask() done as inlined
function, not a macro. So we get __first_cpu(node_to_cpumask(...),...),
with obvious consequences.
Hullo.
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
Most of the -rc7 changes are pretty trivial, either one-liners or
affecting some particular specific driver or unusual
Hullo.
I really wanted to release a 2.6.13, but there's been enough changes
while we've been waiting for other issues to resolve that I think it's
best to do a -rc7 first.
Most of the -rc7 changes are pretty trivial, either one-liners or
affecting some particular specific driver or unusual
68 matches
Mail list logo
