* Re: patch for dmasound bug
@ 1999-06-11 20:07 64% ` Ryan Nielsen
1999-06-11 22:54 64% ` Alvin Brattli
0 siblings, 1 reply; 200+ results
From: Ryan Nielsen @ 1999-06-11 20:07 UTC (permalink / raw)
To: Alvin Brattli; +Cc: linuxppc-dev
Alvin Brattli wrote:
> >This restores the rate/byteswap to normal after playing a beep
> >if you for example stop timidity, make a beep, resume, the sound
> >will be slower than normal (without this patch).
>
> Although this patch might do what it was intended for, it has some
> unwanted consequences on the PowerBook G3 Series, namely that one gets a
> constant, really annoying hiss from the loudspeakers, most notably
> during the boot sequence. Without this patch, the hiss stops after a
> system beep (like when you do an "echo ^G" in a shell), but now even
> this does not help. So, if this patch is included in the standard
> distribution, I suspect we will hear a lot of complaints from PowerBook
> G3 users.
is this better?
--- dmasound.c 1999/02/05 05:45:42 1.41
+++ dmasound.c 1999/06/11 20:04:43
@@ -3255,6 +3255,11 @@
save_flags(flags); cli();
if (beep_playing) {
st_le16(&beep_dbdma_cmd->command, DBDMA_STOP);
+ out_le32(&awacs_txdma->control, (RUN|PAUSE|FLUSH|WAKE) << 16);
+ out_le32(&awacs->control, MASK_IEPC
+ | (awacs_rate_index << 8) | 0x11
+ | (awacs_revision < AWACS_BURGUNDY? MASK_IEE: 0));
+ out_le32(&awacs->byteswap, sound.hard.format != AFMT_S16_BE);
beep_playing = 0;
}
restore_flags(flags);
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: patch for dmasound bug
1999-06-11 20:07 64% ` Ryan Nielsen
@ 1999-06-11 22:54 64% ` Alvin Brattli
0 siblings, 0 replies; 200+ results
From: Alvin Brattli @ 1999-06-11 22:54 UTC (permalink / raw)
To: Ryan Nielsen; +Cc: linuxppc-dev
Ryan Nielsen:
>Alvin Brattli wrote:
>> Although this patch might do what it was intended for, it has some
>> unwanted consequences on the PowerBook G3 Series, namely that one gets a
>> constant, really annoying hiss from the loudspeakers, most notably
>> during the boot sequence. Without this patch, the hiss stops after a
>> system beep (like when you do an "echo ^G" in a shell), but now even
>> this does not help. So, if this patch is included in the standard
>> distribution, I suspect we will hear a lot of complaints from PowerBook
>> G3 users.
>
>is this better?
>--- dmasound.c 1999/02/05 05:45:42 1.41
>+++ dmasound.c 1999/06/11 20:04:43
>@@ -3255,6 +3255,11 @@
> save_flags(flags); cli();
> if (beep_playing) {
> st_le16(&beep_dbdma_cmd->command, DBDMA_STOP);
>+ out_le32(&awacs_txdma->control, (RUN|PAUSE|FLUSH|WAKE) << 16);
>+ out_le32(&awacs->control, MASK_IEPC
>+ | (awacs_rate_index << 8) | 0x11
>+ | (awacs_revision < AWACS_BURGUNDY? MASK_IEE: 0));
>+ out_le32(&awacs->byteswap, sound.hard.format != AFMT_S16_BE);
> beep_playing = 0;
> }
> restore_flags(flags);
Nope. The hiss is still there, and won't go away. If it can be of any
help, the patch below removes the hiss during boot-time when your
patch is not applied. The patch simply makes a very short beep with
zero volume. However, after playing certain sounds, the hiss comes
back, and can then be stopped with a system beep (like with "echo ^G" in
a terminal window).
--- linux-2.2.8-orig/drivers/sound/dmasound.c Fri May 14 22:24:46 1999
+++ linux-2.2.8/drivers/sound/dmasound.c Sat Jun 12 00:49:44 1999
@@ -4840,6 +4840,7 @@
int has_sound = 0;
#ifdef CONFIG_PPC
struct device_node *np;
+ int beep_volume_tmp;
#endif
#if defined(__mc68000__) || defined(CONFIG_APUS)
@@ -4974,6 +4975,14 @@
#ifdef MODULE
irq_installed = 1;
#endif
+
+#ifdef CONFIG_PPC
+ /* Remove hiss from PowerBook speakers (very ad hoc) */
+ beep_volume_tmp = beep_volume;
+ beep_volume = 0;
+ awacs_mksound(750, 1);
+ beep_volume = beep_volume_tmp;
+#endif /* CONFIG_PPC */
printk(KERN_INFO "DMA sound driver installed, using %d buffers of %dk.\n",
numBufs, bufSize);
aLViN
--
:r .signature
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
@ 1999-06-16 16:29 60% Eric Ding
1999-06-16 17:21 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Eric Ding @ 1999-06-16 16:29 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I'm developing on LinuxPPC R5, with egcs-1.1.2-12c and
binutils-2.9.1.0.990418-1c installed. I'm running into a problem with
using the -Bsymbolic flag. Building a shared library which references
global symbols that are not found in it, we usually use the
--noinhibit-exec flag so that shared library builds even without those
symbols being bound.
The build command looks like this:
gcc -shared -Wl,-v -Wl,-Bsymbolic -Wl,--noinhibit-exec -o \
/ax/axexec/axdata/axshlib/libaxel.so -L/ax/axexec/axdata/axshlib \
-L/ax/axobj/axdata/rts elimports.o elexports.o \
/ax/axobj/axdata/rts/axel.o
Without the -Bsymbolic flag, the shared library builds fine. With the
flag, however, it spits out the following errors (which are expected):
GNU ld version 2.9.4 (with BFD 990418)
/ax/axobj/axdata/rts/axel.o: In function `ElfInstallLibModules':
/ax/axobj/axdata/rts/axel.o(.text+0x38): undefined reference to `ElfInstallModule'
/ax/axobj/axdata/rts/axel.o(.text+0x48): undefined reference to `ElfInstallModule'
/ax/axobj/axdata/rts/axel.o(.text+0x58): undefined reference to `ElfInstallModule'
/ax/axobj/axdata/rts/axel.o: In function `ELElfMacroId':
/ax/axobj/axdata/rts/axel.o(.text+0xc0): undefined reference to `ElfGetModuleStartInd'
On other platforms (i.e., Intel, Alpha), we also see these errors, but
because of the --noinhibit-exec flag, the shared library is correctly
built anyway. But on PPC, ld returns with 1 exit status, and the shared
library is not built. Not using -Bsymbolic is not an option.
Ideas?
Thanks,
Eric
--
Senior Software Engineer / ericding@applix.com <><
Applix, Inc. / 112 Turnpike Road / Westboro MA 01581-2842
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 60%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 16:29 60% ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c) Eric Ding
@ 1999-06-16 17:21 64% ` Franz Sirl
1999-06-16 18:09 64% ` Eric Ding
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 1999-06-16 17:21 UTC (permalink / raw)
To: Eric Ding; +Cc: linuxppc-dev
At 18:29 16.06.99 , Eric Ding wrote:
>Hi,
>
>I'm developing on LinuxPPC R5, with egcs-1.1.2-12c and
>binutils-2.9.1.0.990418-1c installed. I'm running into a problem with
>using the -Bsymbolic flag. Building a shared library which references
>global symbols that are not found in it, we usually use the
>--noinhibit-exec flag so that shared library builds even without those
>symbols being bound.
>
>The build command looks like this:
>
> gcc -shared -Wl,-v -Wl,-Bsymbolic -Wl,--noinhibit-exec -o \
> /ax/axexec/axdata/axshlib/libaxel.so -L/ax/axexec/axdata/axshlib \
> -L/ax/axobj/axdata/rts elimports.o elexports.o \
> /ax/axobj/axdata/rts/axel.o
>
>Without the -Bsymbolic flag, the shared library builds fine. With the
>flag, however, it spits out the following errors (which are expected):
>
>GNU ld version 2.9.4 (with BFD 990418)
>/ax/axobj/axdata/rts/axel.o: In function `ElfInstallLibModules':
>/ax/axobj/axdata/rts/axel.o(.text+0x38): undefined reference to
>`ElfInstallModule'
>/ax/axobj/axdata/rts/axel.o(.text+0x48): undefined reference to
>`ElfInstallModule'
>/ax/axobj/axdata/rts/axel.o(.text+0x58): undefined reference to
>`ElfInstallModule'
>/ax/axobj/axdata/rts/axel.o: In function `ELElfMacroId':
>/ax/axobj/axdata/rts/axel.o(.text+0xc0): undefined reference to
>`ElfGetModuleStartInd'
>
>On other platforms (i.e., Intel, Alpha), we also see these errors, but
>because of the --noinhibit-exec flag, the shared library is correctly
>built anyway. But on PPC, ld returns with 1 exit status, and the shared
>library is not built. Not using -Bsymbolic is not an option.
Hmm, what version of binutils are you using on Intel/Alpha? Does it work on
Intel/Alpha with binutils-2.9.4.0.[3-5]?
In any case, you can try the RPM of binutils-2.9.4.0.5 on
<ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc> and see if it helps.
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 17:21 64% ` Franz Sirl
@ 1999-06-16 18:09 64% ` Eric Ding
1999-06-16 18:31 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Eric Ding @ 1999-06-16 18:09 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
Hi Frank,
thanks for your quick reply. I'm using version 2.9.1.0.15 on Intel. On
Alpha, I'm using 2.9.1.0.22.
I just downloaded the binutils-2.9.4.0.5 RPM, and it's no more
successful. :( :(
Eric
>>>>> Franz Sirl <Franz.Sirl@munich.netsurf.de> writes:
> Hmm, what version of binutils are you using on Intel/Alpha? Does it work on
> Intel/Alpha with binutils-2.9.4.0.[3-5]?
> In any case, you can try the RPM of binutils-2.9.4.0.5 on
> <ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc> and see if it helps.
> Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 18:09 64% ` Eric Ding
@ 1999-06-16 18:31 64% ` Franz Sirl
1999-06-16 19:38 64% ` Eric Ding
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 1999-06-16 18:31 UTC (permalink / raw)
To: Eric Ding; +Cc: linuxppc-dev
Am Mit, 16 Jun 1999 schrieb Eric Ding:
>Hi Frank,
>
>thanks for your quick reply. I'm using version 2.9.1.0.15 on Intel. On
>Alpha, I'm using 2.9.1.0.22.
>
>I just downloaded the binutils-2.9.4.0.5 RPM, and it's no more
>successful. :( :(
Ok, would you mind trying binutils-2.9.4.0.5 on Intel too? It's available on
<ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta> as a RPM.
I'm trying to sort out if this is related to newer binutils or if it's PPC
specific.
Franz.
BTW, I'm "franzo" on #mklinux/EFNet for even faster feedback :-)
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 18:31 64% ` Franz Sirl
@ 1999-06-16 19:38 64% ` Eric Ding
1999-06-16 20:40 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Eric Ding @ 1999-06-16 19:38 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
Hi Franz,
>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> Ok, would you mind trying binutils-2.9.4.0.5 on Intel too? It's
> available on <ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta>
> as a RPM.
> I'm trying to sort out if this is related to newer binutils or if it's
> PPC specific.
just noticed I called you Frank last time. Sorry 'bout that. :)
I had a co-worker test out the Intel 2.9.4.0.5 binutils and it worked
without a problem on that hardware platform.
> BTW, I'm "franzo" on #mklinux/EFNet for even faster feedback :-)
I don't have irc access from work (this is irc, right?)...
Eric
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 19:38 64% ` Eric Ding
@ 1999-06-16 20:40 64% ` Franz Sirl
1999-06-16 21:14 64% ` Eric Ding
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 1999-06-16 20:40 UTC (permalink / raw)
To: Eric Ding; +Cc: linuxppc-dev
Am Mit, 16 Jun 1999 schrieb Eric Ding:
>Hi Franz,
>
>>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>> Ok, would you mind trying binutils-2.9.4.0.5 on Intel too? It's
>> available on <ftp://ftp.varesearch.com/pub/support/hjl/binutils/beta>
>> as a RPM.
>
>> I'm trying to sort out if this is related to newer binutils or if it's
>> PPC specific.
>
>just noticed I called you Frank last time. Sorry 'bout that. :)
no problem :-). I didn't even notice...
>I had a co-worker test out the Intel 2.9.4.0.5 binutils and it worked
>without a problem on that hardware platform.
Hmm, I browsed thru the binutils code and didn't see anything suspicious. Is
there any chance you can strip that down to a small testcase with a few
symbols? That would help debugging a lot.
>> BTW, I'm "franzo" on #mklinux/EFNet for even faster feedback :-)
>
>I don't have irc access from work (this is irc, right?)...
Yes, irc.
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 20:40 64% ` Franz Sirl
@ 1999-06-16 21:14 64% ` Eric Ding
1999-06-17 21:24 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Eric Ding @ 1999-06-16 21:14 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> Hmm, I browsed thru the binutils code and didn't see anything suspicious. Is
> there any chance you can strip that down to a small testcase with a few
> symbols? That would help debugging a lot.
Sure can. Create a file (let's call it foo.c)... it just contains:
int foo_tester()
{
return(twenty());
}
Then run the following:
gcc -fPIC -c foo.c
After the compilation, run:
gcc -shared -o libfoo.so foo.o
gcc -shared -Wl,-Bsymbolic -o libfoo.so foo.o
gcc -shared -Wl,--noinhibit-exec -Wl,-Bsymbolic -o libfoo.so foo.o
On Intel, the first succeeds, the second fails (as expected), and the
third succeeds in building a .so file, even with the "undefined
reference" error.
On PPC, the first succeeds, but the second and third both fail.
Eric
--
Senior Software Engineer / ericding@applix.com <><
Applix, Inc. / 112 Turnpike Road / Westboro MA 01581-2842
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-16 21:14 64% ` Eric Ding
@ 1999-06-17 21:24 64% ` Franz Sirl
1999-06-17 22:49 64% ` Eric Ding
1999-06-18 19:54 64% ` Eric Ding
0 siblings, 2 replies; 200+ results
From: Franz Sirl @ 1999-06-17 21:24 UTC (permalink / raw)
To: Eric Ding; +Cc: linuxppc-dev
Am Mit, 16 Jun 1999 schrieb Eric Ding:
>>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
>
>> Hmm, I browsed thru the binutils code and didn't see anything suspicious. Is
>> there any chance you can strip that down to a small testcase with a few
>> symbols? That would help debugging a lot.
>
>Sure can. Create a file (let's call it foo.c)... it just contains:
>
> int foo_tester()
> {
> return(twenty());
> }
>
>Then run the following:
>
> gcc -fPIC -c foo.c
>
>After the compilation, run:
>
> gcc -shared -o libfoo.so foo.o
> gcc -shared -Wl,-Bsymbolic -o libfoo.so foo.o
> gcc -shared -Wl,--noinhibit-exec -Wl,-Bsymbolic -o libfoo.so foo.o
>
>On Intel, the first succeeds, the second fails (as expected), and the
>third succeeds in building a .so file, even with the "undefined
>reference" error.
>
>On PPC, the first succeeds, but the second and third both fail.
Ok, I've put up a 1b RPM for testing. Let me know if it works as expected. Note
the dev.linuxppc.org has changed IP address, so you might have to use the direct
169.207.161.2.
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-17 21:24 64% ` Franz Sirl
@ 1999-06-17 22:49 64% ` Eric Ding
1999-06-18 19:54 64% ` Eric Ding
1 sibling, 0 replies; 200+ results
From: Eric Ding @ 1999-06-17 22:49 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
Hi Franz,
Yes, it works! At least, it links... :) There is a strange matter of
it needing LD_RUN_PATH where it seems I didn't need this variable set on
other platforms (according to the ld info page, it should look in
LD_LIBRARY_PATH if LD_RUN_PATH isn't defined).
So now I can say that it links... but Applixware yet does not run. More
when I discover more...
Eric
>>>>> Franz Sirl <Franz.Sirl-kernel@lauterbach.com> writes:
> Ok, I've put up a 1b RPM for testing. Let me know if it works as
> expected. Note the dev.linuxppc.org has changed IP address, so you
> might have to use the direct 169.207.161.2.
> Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-17 21:24 64% ` Franz Sirl
1999-06-17 22:49 64% ` Eric Ding
@ 1999-06-18 19:54 64% ` Eric Ding
1999-06-21 9:31 64% ` Franz Sirl
1 sibling, 1 reply; 200+ results
From: Eric Ding @ 1999-06-18 19:54 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
Hi Franz,
thanks for your help so far. After upgrading to 1b, linking works, but
actually running against those shared libraries doesn't seem to
necessarily work. But it's hard for me to tell where the bug is.
The fact that LD_RUN_PATH needed to be set is still a red flag in my
mind... is that "correct" behavior? I know that Applixware linked and
ran OK with binutils from R4; would backtracking be an adequate
solution?
Eric
--
Senior Software Engineer / ericding@applix.com <><
Applix Linux Division / 112 Turnpike Road / Westboro MA 01581-2842
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* weird glibc bug?? (#0 0x153b94c in strlen () at soinit.c:59)
@ 1999-06-19 4:27 58% Troy Benjegerdes
1999-06-19 6:15 64% ` Martin Costabel
0 siblings, 1 reply; 200+ results
From: Troy Benjegerdes @ 1999-06-19 4:27 UTC (permalink / raw)
To: linuxppc-dev
I am completely and totally stumped.
I have been seeing various programs (everthing from the installer to scp
to apache) that have seemingly inexplicable segfaults since at least the
first glibc-2.1 was out (6 months ago?)
At first I thought this had been caused by a bug in 'strip', since a new
binutils fixed the problem.
this problem seems to have resurfaced again in recent glibc's.
in it's current incarnation, scp is segfaulting, and when I use gdb, I get
the following backtrace:
Program received signal SIGSEGV, Segmentation fault.
0x153b94c in strlen () at soinit.c:59
soinit.c:59: No such file or directory.
(gdb) bt
#0 0x153b94c in strlen () at soinit.c:59
#1 0x151fda4 in _IO_vfprintf () at vfprintf.c:1554
#2 0x1523304 in buffered_vfprintf (s=0x15fd118, format=0x18047e0 "%s:
%s",
args=0x7ffff1f0) at vfprintf.c:1747
#3 0x151e2f4 in _IO_vfprintf () at vfprintf.c:1554
#4 0x1803d4c in _SDA2_BASE_ ()
#5 0x18039dc in _SDA2_BASE_ ()
#6 0x18022ac in _SDA2_BASE_ ()
#7 0x1801ac4 in _SDA2_BASE_ ()
#8 0x14fd7d4 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-sta
So, my first thought was that strip was buggy again, so I built scp and
didn't strip it.
It still segfaults when run from the command line. But it gets more
interesting: When run from gdb, the unstripped binary *doesn't* segfault!!
It seems as though depending on where things are aligned in memory either
triggers or masks the problem. I have heard a report that apache works
fine when built with '-g', and segfaults with a screwed up stack when not.
(this normally isn't noticeable with apache, since it occurs when
returning a 'page not found' error)
Someone please tell me I haven't gone of the deep end on this :-/
--------------------------------------------------------------------------
| Troy Benjegerdes | troy@microux.com | hozer@drgw.net |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 58%]
* Re: weird glibc bug?? (#0 0x153b94c in strlen () at soinit.c:59)
1999-06-19 4:27 58% weird glibc bug?? (#0 0x153b94c in strlen () at soinit.c:59) Troy Benjegerdes
@ 1999-06-19 6:15 64% ` Martin Costabel
1999-06-19 6:40 64% ` Troy Benjegerdes
0 siblings, 1 reply; 200+ results
From: Martin Costabel @ 1999-06-19 6:15 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: linuxppc-dev
Could this be an egcs bug? When i reported a similar bug (lines #0 and
#1 in the gdb output were the same) where gnuplot was segfaulting, Franz
Sirl and the others found out that it was related to the varargs bug in
egcs. Have a look at the linuxppc-dev archives from around April 15.
There should be a fix for this in egcs-1.1.2-1c.
According to the sources at http://gate.crashing.org/, the "official"
varargs fix is included in egcs-1.1.2-1e which I managed to compile from
the spec and patch files found at that site. And of course, gcc-2.95 is
probably fixed, too.
Hope this helps
--
Martin
Troy Benjegerdes wrote:
>
> I am completely and totally stumped.
>
> I have been seeing various programs (everthing from the installer to scp
> to apache) that have seemingly inexplicable segfaults since at least the
> first glibc-2.1 was out (6 months ago?)
>
> At first I thought this had been caused by a bug in 'strip', since a new
> binutils fixed the problem.
>
> this problem seems to have resurfaced again in recent glibc's.
>
> in it's current incarnation, scp is segfaulting, and when I use gdb, I get
> the following backtrace:
>
> Program received signal SIGSEGV, Segmentation fault.
> 0x153b94c in strlen () at soinit.c:59
> soinit.c:59: No such file or directory.
> (gdb) bt
> #0 0x153b94c in strlen () at soinit.c:59
> #1 0x151fda4 in _IO_vfprintf () at vfprintf.c:1554
> #2 0x1523304 in buffered_vfprintf (s=0x15fd118, format=0x18047e0 "%s:
> %s",
> args=0x7ffff1f0) at vfprintf.c:1747
> #3 0x151e2f4 in _IO_vfprintf () at vfprintf.c:1554
> #4 0x1803d4c in _SDA2_BASE_ ()
> #5 0x18039dc in _SDA2_BASE_ ()
> #6 0x18022ac in _SDA2_BASE_ ()
> #7 0x1801ac4 in _SDA2_BASE_ ()
> #8 0x14fd7d4 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-sta
>
> So, my first thought was that strip was buggy again, so I built scp and
> didn't strip it.
>
> It still segfaults when run from the command line. But it gets more
> interesting: When run from gdb, the unstripped binary *doesn't* segfault!!
>
> It seems as though depending on where things are aligned in memory either
> triggers or masks the problem. I have heard a report that apache works
> fine when built with '-g', and segfaults with a screwed up stack when not.
> (this normally isn't noticeable with apache, since it occurs when
> returning a 'page not found' error)
>
> Someone please tell me I haven't gone of the deep end on this :-/
>
> --------------------------------------------------------------------------
> | Troy Benjegerdes | troy@microux.com | hozer@drgw.net |
> | Unix is user friendly... You just have to be friendly to it first. |
> | This message composed with 100% free software. http://www.gnu.org |
> --------------------------------------------------------------------------
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: weird glibc bug?? (#0 0x153b94c in strlen () at soinit.c:59)
1999-06-19 6:15 64% ` Martin Costabel
@ 1999-06-19 6:40 64% ` Troy Benjegerdes
0 siblings, 0 replies; 200+ results
From: Troy Benjegerdes @ 1999-06-19 6:40 UTC (permalink / raw)
To: Martin Costabel; +Cc: linuxppc-dev
On Sat, 19 Jun 1999, Martin Costabel wrote:
> Could this be an egcs bug? When i reported a similar bug (lines #0 and
> #1 in the gdb output were the same) where gnuplot was segfaulting, Franz
> Sirl and the others found out that it was related to the varargs bug in
> egcs. Have a look at the linuxppc-dev archives from around April 15.
> There should be a fix for this in egcs-1.1.2-1c.
I doubt it, as I compiled with egcs-1.1.2-12e. It might be possible that a
shared lib the program is linked with was compiled with a bad egcs, but I
doubt it.
>
> According to the sources at http://gate.crashing.org/, the "official"
> varargs fix is included in egcs-1.1.2-1e which I managed to compile from
> the spec and patch files found at that site. And of course, gcc-2.95 is
> probably fixed, too.
>
> Hope this helps
>
> --
> Martin
>
> Troy Benjegerdes wrote:
> >
> > I am completely and totally stumped.
> >
> > I have been seeing various programs (everthing from the installer to scp
> > to apache) that have seemingly inexplicable segfaults since at least the
> > first glibc-2.1 was out (6 months ago?)
> >
> > At first I thought this had been caused by a bug in 'strip', since a new
> > binutils fixed the problem.
> >
> > this problem seems to have resurfaced again in recent glibc's.
> >
> > in it's current incarnation, scp is segfaulting, and when I use gdb, I get
> > the following backtrace:
> >
> > Program received signal SIGSEGV, Segmentation fault.
> > 0x153b94c in strlen () at soinit.c:59
> > soinit.c:59: No such file or directory.
> > (gdb) bt
> > #0 0x153b94c in strlen () at soinit.c:59
> > #1 0x151fda4 in _IO_vfprintf () at vfprintf.c:1554
> > #2 0x1523304 in buffered_vfprintf (s=0x15fd118, format=0x18047e0 "%s:
> > %s",
> > args=0x7ffff1f0) at vfprintf.c:1747
> > #3 0x151e2f4 in _IO_vfprintf () at vfprintf.c:1554
> > #4 0x1803d4c in _SDA2_BASE_ ()
> > #5 0x18039dc in _SDA2_BASE_ ()
> > #6 0x18022ac in _SDA2_BASE_ ()
> > #7 0x1801ac4 in _SDA2_BASE_ ()
> > #8 0x14fd7d4 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-sta
> >
> > So, my first thought was that strip was buggy again, so I built scp and
> > didn't strip it.
> >
> > It still segfaults when run from the command line. But it gets more
> > interesting: When run from gdb, the unstripped binary *doesn't* segfault!!
> >
> > It seems as though depending on where things are aligned in memory either
> > triggers or masks the problem. I have heard a report that apache works
> > fine when built with '-g', and segfaults with a screwed up stack when not.
> > (this normally isn't noticeable with apache, since it occurs when
> > returning a 'page not found' error)
> >
> > Someone please tell me I haven't gone of the deep end on this :-/
> >
> > --------------------------------------------------------------------------
> > | Troy Benjegerdes | troy@microux.com | hozer@drgw.net |
> > | Unix is user friendly... You just have to be friendly to it first. |
> > | This message composed with 100% free software. http://www.gnu.org |
> > --------------------------------------------------------------------------
>
>
--------------------------------------------------------------------------
| Troy Benjegerdes | troy@microux.com | hozer@drgw.net |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-18 19:54 64% ` Eric Ding
@ 1999-06-21 9:31 64% ` Franz Sirl
1999-06-21 13:05 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 1999-06-21 9:31 UTC (permalink / raw)
To: Eric Ding; +Cc: linuxppc-dev
At 21:54 18.06.99 , Eric Ding wrote:
>Hi Franz,
>
>thanks for your help so far. After upgrading to 1b, linking works, but
>actually running against those shared libraries doesn't seem to
>necessarily work. But it's hard for me to tell where the bug is.
If you still have problems after upgrading to 2.9.4.0.6 below, I'm willing
to look further into it, but I assume it will be difficult, as you don't
know the exact cause yourself. Can we rule out bugs in your source here?
Did the executables created with 2.9.4.0.5 on x86 work fine? I'll also post
my patch for the noinhibit-exec problem on the binutils-list for review
later today.
>The fact that LD_RUN_PATH needed to be set is still a red flag in my
>mind... is that "correct" behavior? I know that Applixware linked and
>ran OK with binutils from R4; would backtracking be an adequate
>solution?
Ok, the LD_RUN_PATH should be fixed now with:
ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc/binutils-2.9.4.0.6-1a.ppc.rpm
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-21 9:31 64% ` Franz Sirl
@ 1999-06-21 13:05 64% ` Franz Sirl
1999-06-21 19:44 64% ` Eric Ding
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 1999-06-21 13:05 UTC (permalink / raw)
To: Eric Ding; +Cc: linuxppc-dev
>Ok, the LD_RUN_PATH should be fixed now with:
>
>ftp://dev.linuxppc.org/users/fsirl/R5/RPMS/ppc/binutils-2.9.4.0.6-1a.ppc.rpm
Damned, I forgot a patch, please use the 1b version.
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c)
1999-06-21 13:05 64% ` Franz Sirl
@ 1999-06-21 19:44 64% ` Eric Ding
0 siblings, 0 replies; 200+ results
From: Eric Ding @ 1999-06-21 19:44 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
Hi Franz,
Another one of our developers has installed 2.9.4.0.5 on his x86 box and
it has worked for him. I'm still having problems with 2.9.4.0.6 (though
no longer with LD_RUN_PATH). Again, everything links, but the
executables themselves don't run correctly.
While I can't give you a very small test case, do you think you could
work with a somewhat weightier one? The SHELF open source package is
the core of Applixware, and exhibits the same problems as Applixware as
a whole. If you'd be willing to download the source, and do a build (I
could give you step by step instructions), then you would be able to
duplicate our issues, hopefully. The source download is anything but
small -- it's a weighty 6.8 MB. But the build process is relatively
simple.
What do you think?
Thanks,
Eric
--
Senior Software Engineer / ericding@applix.com <><
Applix Linux Division / 112 Turnpike Road / Westboro MA 01581-2842
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* dl-load.c (ld.so) bug??
@ 1999-06-21 22:52 64% Troy Benjegerdes
1999-06-22 0:04 64% ` Hollis R Blanchard
0 siblings, 1 reply; 200+ results
From: Troy Benjegerdes @ 1999-06-21 22:52 UTC (permalink / raw)
To: linuxppc-dev
testcase:
#include <stdio.h>
int main(void){
char * ptr;
printf("hello world\n");
fflush(stdout);
ptr = (char *)malloc(100);
free(ptr);
}
compile this with:
gcc test.c -lefence -g -static
On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
On a x86 Red Hat 6.0 system, it works fine (
[troybenj@mos6 troybenj]$ ./a.out
Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
hello world
[troybenj@mos6 troybenj]$
Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
I suspect it's the former, and if so, this would explain the weird
segfaults I've been seeing.
Can someone that knows glibc better please confirm or deny this for me?
--------------------------------------------------------------------------
| Troy Benjegerdes | troy@microux.com | hozer@drgw.net |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
1999-06-21 22:52 64% dl-load.c (ld.so) bug?? Troy Benjegerdes
@ 1999-06-22 0:04 64% ` Hollis R Blanchard
1999-06-22 1:57 64% ` Troy Benjegerdes
0 siblings, 1 reply; 200+ results
From: Hollis R Blanchard @ 1999-06-22 0:04 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: linuxppc-dev
On Mon, 21 Jun 1999, Troy Benjegerdes wrote:
>
> testcase:
>
> #include <stdio.h>
> int main(void){
> char * ptr;
> printf("hello world\n");
> fflush(stdout);
> ptr = (char *)malloc(100);
> free(ptr);
> }
>
>
> compile this with:
> gcc test.c -lefence -g -static
>
> On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
>
> On a x86 Red Hat 6.0 system, it works fine (
> [troybenj@mos6 troybenj]$ ./a.out
>
> Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
> hello world
> [troybenj@mos6 troybenj]$
>
>
> Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
> I suspect it's the former, and if so, this would explain the weird
> segfaults I've been seeing.
>
> Can someone that knows glibc better please confirm or deny this for me?
Ok, I don't know squat about glibc, but doesn't the fact that it runs fine
*without* Electric Fence indicate it's a problem with that?
-Hollis
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
1999-06-22 0:04 64% ` Hollis R Blanchard
@ 1999-06-22 1:57 64% ` Troy Benjegerdes
1999-06-22 2:48 64% ` Hollis R Blanchard
0 siblings, 1 reply; 200+ results
From: Troy Benjegerdes @ 1999-06-22 1:57 UTC (permalink / raw)
To: Hollis R Blanchard; +Cc: linuxppc-dev
On Mon, 21 Jun 1999, Hollis R Blanchard wrote:
> On Mon, 21 Jun 1999, Troy Benjegerdes wrote:
> >
> > testcase:
> >
> > #include <stdio.h>
> > int main(void){
> > char * ptr;
> > printf("hello world\n");
> > fflush(stdout);
> > ptr = (char *)malloc(100);
> > free(ptr);
> > }
> >
> >
> > compile this with:
> > gcc test.c -lefence -g -static
> >
> > On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
> >
> > On a x86 Red Hat 6.0 system, it works fine (
> > [troybenj@mos6 troybenj]$ ./a.out
> >
> > Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
> > hello world
> > [troybenj@mos6 troybenj]$
> >
> >
> > Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
> > I suspect it's the former, and if so, this would explain the weird
> > segfaults I've been seeing.
> >
> > Can someone that knows glibc better please confirm or deny this for me?
>
> Ok, I don't know squat about glibc, but doesn't the fact that it runs fine
> *without* Electric Fence indicate it's a problem with that?
>
> -Hollis
>
No. Electric Fence is designed to catch programming errors, such as
attempting to access memory which was not 'malloc'ed. I have traced this
down extensively a couple of months ago, and found that it does indeed
appear to overrun what it malloced.
In normal operation, if I am correct, the ld.so code is just silently
overwriting some other data.
--------------------------------------------------------------------------
| Troy Benjegerdes | troy@microux.com | hozer@drgw.net |
| Unix is user friendly... You just have to be friendly to it first. |
| This message composed with 100% free software. http://www.gnu.org |
--------------------------------------------------------------------------
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
1999-06-22 1:57 64% ` Troy Benjegerdes
@ 1999-06-22 2:48 64% ` Hollis R Blanchard
1999-06-22 3:09 64% ` Daniel Jacobowitz
0 siblings, 1 reply; 200+ results
From: Hollis R Blanchard @ 1999-06-22 2:48 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: linuxppc-dev
> No. Electric Fence is designed to catch programming errors, such as
> attempting to access memory which was not 'malloc'ed. I have traced this
> down extensively a couple of months ago, and found that it does indeed
> appear to overrun what it malloced.
I have two even simpler test cases for you:
int main(void){
char *ptr=NULL;
free(ptr);
}
and
int main(void){
char *ptr = (char *)malloc(100);
}
Both of these work fine (or at least *appear* to work fine) without Electric
Fence.
> In normal operation, if I am correct, the ld.so code is just silently
> overwriting some other data.
If this were the case, wouldn't you expect ridiculous levels of instability?
-Hollis
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
1999-06-22 2:48 64% ` Hollis R Blanchard
@ 1999-06-22 3:09 64% ` Daniel Jacobowitz
1999-06-22 4:36 63% ` Peter Chang
0 siblings, 1 reply; 200+ results
From: Daniel Jacobowitz @ 1999-06-22 3:09 UTC (permalink / raw)
To: linuxppc-dev
On Mon, Jun 21, 1999 at 10:48:12PM -0400, Hollis R Blanchard wrote:
>
> > No. Electric Fence is designed to catch programming errors, such as
> > attempting to access memory which was not 'malloc'ed. I have traced this
> > down extensively a couple of months ago, and found that it does indeed
> > appear to overrun what it malloced.
>
> I have two even simpler test cases for you:
>
> int main(void){
> char *ptr=NULL;
> free(ptr);
> }
Well, that one would probably segfault anyway (or at least, is not
guaranteed not to).
> int main(void){
> char *ptr = (char *)malloc(100);
> }
That one's a problem, though :)
> If this were the case, wouldn't you expect ridiculous levels of instability?
Depends entirely on what it overwrote.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
1999-06-22 3:09 64% ` Daniel Jacobowitz
@ 1999-06-22 4:36 63% ` Peter Chang
1999-06-22 13:52 64% ` Hollis R Blanchard
0 siblings, 1 reply; 200+ results
From: Peter Chang @ 1999-06-22 4:36 UTC (permalink / raw)
To: linuxppc-dev
At 23:09 -0400 06.21.1999, Daniel Jacobowitz wrote:
>On Mon, Jun 21, 1999 at 10:48:12PM -0400, Hollis R Blanchard wrote:
> >
> > > No. Electric Fence is designed to catch programming errors, such as
> > > attempting to access memory which was not 'malloc'ed. I have traced this
> > > down extensively a couple of months ago, and found that it does indeed
> > > appear to overrun what it malloced.
> >
> > I have two even simpler test cases for you:
> >
> > int main(void){
> > char *ptr=NULL;
> > free(ptr);
> > }
>
>Well, that one would probably segfault anyway (or at least, is not
>guaranteed not to).
Hmm... the docs taht I have say this:
2 The free function causes the space pointed to by ptr to be
deallocated, that is, made
available for further allocation. If ptr is a null pointer, no action
occurs. Otherwise, if
the argument does not match a pointer earlier returned by the calloc, malloc,or
realloc function, or if the space has been deallocated by a call to
free or realloc,
the behavior is undefined.
> > int main(void){
> > char *ptr = (char *)malloc(100);
> > }
>
>That one's a problem, though :)
Why? Its allocating memory, but never freeing it. Its a leak, but not
accessing things out of bounds. I haven't used ElectricFence, but its
not going to catch a bounds error on this.
> > If this were the case, wouldn't you expect ridiculous levels of
>instability?
>
>Depends entirely on what it overwrote.
Especially, if the malloc (like most) was sub-allocating from an os
allocated block. In this case it might be possible that the block
after the overwritten block was not holding any valid data or at
least wasn't ever given out by malloc/calloc/realloc.
\p
---
sed quis custodiet ipsos custodes
--Juvenal *Satire* VI, 165
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 63%]
* Re: dl-load.c (ld.so) bug??
[not found] <Pine.LNX.3.96L.990622003119.5237E-100000@unix47.andrew.cmu.edu>
@ 1999-06-22 4:39 64% ` Peter Chang
0 siblings, 0 replies; 200+ results
From: Peter Chang @ 1999-06-22 4:39 UTC (permalink / raw)
To: Hollis R Blanchard; +Cc: linuxppc-dev
> > Uhhh... both of these are legal.
>
>Yes, exactly. There is no reason they should do anything bad. Now compile them
>with 'gcc -o bug main.c -lefence -g -static'. They both segfault.
Ooops. I thought that you meant that the were illegal and were not
getting caught. Sorry.
\p
---
sed quis custodiet ipsos custodes
--Juvenal *Satire* VI, 165
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
1999-06-22 4:36 63% ` Peter Chang
@ 1999-06-22 13:52 64% ` Hollis R Blanchard
0 siblings, 0 replies; 200+ results
From: Hollis R Blanchard @ 1999-06-22 13:52 UTC (permalink / raw)
To: Peter Chang; +Cc: linuxppc-dev
On Mon, 21 Jun 1999, Peter Chang wrote:
>
> At 23:09 -0400 06.21.1999, Daniel Jacobowitz wrote:
> >On Mon, Jun 21, 1999 at 10:48:12PM -0400, Hollis R Blanchard wrote:
> > >
> > > I have two even simpler test cases for you:
> > >
> > > int main(void){
> > > char *ptr=NULL;
> > > free(ptr);
> > > }
> >
> >Well, that one would probably segfault anyway (or at least, is not
> >guaranteed not to).
>
> Hmm... the docs taht I have say this:
>
[snip]
> If ptr is a null pointer, no action occurs.
[snip]
Right. In other words, that's legal and should not segfault.
> > > int main(void){
> > > char *ptr = (char *)malloc(100);
> > > }
> >
> >That one's a problem, though :)
>
> Why? Its allocating memory, but never freeing it. Its a leak, but not
> accessing things out of bounds. I haven't used ElectricFence, but its
> not going to catch a bounds error on this.
Try it. It segfaults. Add a free afterwords if you like. It still segfaults.
Add a printf in front of it, and that printf will never happen. The segfault
starts in __libc_start_main. It makes no sense, but anytime you put a malloc
or a free in a program, EFence makes it segfault (*before* running that malloc
or free).
-Hollis
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* bug in head.S
@ 1999-06-22 16:21 62% Nathan Sheeley
1999-06-23 0:45 64% ` Paul Mackerras
0 siblings, 1 reply; 200+ results
From: Nathan Sheeley @ 1999-06-22 16:21 UTC (permalink / raw)
To: linuxppc-dev
This is more or less the same message that I posted earlier, but no one
replied. Please at least tell me to go away ;^)
I was poking around in arch/ppc/kernel/head.S and I noticed this:
oris r18,r8,0x20000000@h
oris r21,r11,(KERNELBASE+0x20000000)@h
mtspr DBAT2L,r18 /* N.B. 6xx (not 601) have valid */
mtspr DBAT2U,r21 /* bit in upper BAT register */
mtspr IBAT2L,r28
^^^^^^^^^^^^^^^^Wouldn't r18 make more sense here?
mtspr IBAT2U,r21
Has anyone tried to build/run a pmac SMP kernel with a recent (2.2.9)
version of Linux?
o I've got a 9500 with 2 604e/200MHz.
o A UP kernel works fine.
o Compliling the same kernel with the SMP support box checked results in
a kernel that doesn't boot on UP(a G3) or SMP(the 9500) machines.
o I also replaced the dual card with a single 133 MHz CPU, which also fails
to boot the SMP kernel.
Can I expect a SMP kernel to boot on a UP? I thought so, although it might
be slower than a UP kernel on a UP.
The symptoms are that it gets to the point of "opening the display", which
activates the display (all white, I assume painted that way by OF), prints
"copying OF device tree...done" and stops.
Nathan Sheeley
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 62%]
* Re: bug in head.S
1999-06-22 16:21 62% bug in head.S Nathan Sheeley
@ 1999-06-23 0:45 64% ` Paul Mackerras
1999-06-23 14:08 64% ` Nathan Sheeley
0 siblings, 1 reply; 200+ results
From: Paul Mackerras @ 1999-06-23 0:45 UTC (permalink / raw)
To: nsheeley; +Cc: linuxppc-dev
Nathan Sheeley <nsheeley@ibmoto.com> wrote:
> I was poking around in arch/ppc/kernel/head.S and I noticed this:
>
> oris r18,r8,0x20000000@h
> oris r21,r11,(KERNELBASE+0x20000000)@h
> mtspr DBAT2L,r18 /* N.B. 6xx (not 601) have valid */
> mtspr DBAT2U,r21 /* bit in upper BAT register */
> mtspr IBAT2L,r28
> ^^^^^^^^^^^^^^^^Wouldn't r18 make more sense here?
Yep, sure, thanks for pointing that out.
> Has anyone tried to build/run a pmac SMP kernel with a recent (2.2.9)
> version of Linux?
I have 2.2.10 running on my 2-cpu powermac at home (it's a 7500 with a
2 x 604e 200MHz cpu card in it). It mostly runs fine but has frozen
up on me a couple of times - I haven't tracked down why/where yet.
> Can I expect a SMP kernel to boot on a UP? I thought so, although it might
I would have thought so, as long as it's not a 601. The SMP kernel
uses the tlbsync instruction which isn't implemented on the 601.
Paul.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* The file system corruption bug (Summary)
@ 1999-06-23 12:20 64% Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1999-06-23 12:20 UTC (permalink / raw)
To: linux-kernel
Ok this is the distilled info so far
2.2.7 -> 2.2.9 broke a small number of systems. I can't tell if 2.2.8 was
a problem or not. 2.2.8 had enough other problems nobody ran it.
The reports of 2.2.7 worked 2.2.9/10 blow up all fall into the following
categories
o Block numbers off the end of the disk
o Reports of incorrect bitmaps
o Bizarre C compiler error reports
With the cases I followed up on, hitting the reset button after such odd
reports generally made them vanish. That is the corruption was in memory
not on media. Unlike the other noise reports there is a consistent "2.2.7 OK
2.2.9 fails" message.
It doesn't matter what platform - PMac (actually this is the worst hit)
Mips x86 all have reports. IDE and SCSI seem affected.
The most bizarre part of the whole matter is that a given machine will almost
always be affected by the same variant of the problem not a mix.
Lower memory machines seem most likely to trip it.
Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
[not found] <199906231258.HAA25989@www.cedarnet.org>
@ 1999-06-23 13:17 64% ` Geert Uytterhoeven
1999-06-23 14:19 64% ` Hollis R Blanchard
1 sibling, 0 replies; 200+ results
From: Geert Uytterhoeven @ 1999-06-23 13:17 UTC (permalink / raw)
To: Kevin Puetz; +Cc: Justin Vallon, Hollis R Blanchard, LinuxPPC-Dev List
On Wed, 23 Jun 1999, Kevin Puetz wrote:
> Umm... just thought of this - a segfault in __libc_start_main is the symptom
> of an old R4 binary on a glibc2.1 system... did ElectricFence not get
> updated (just a thought)? Then - if both libraries load - it segfaults when
> electricfence initializes _it's_ glibc dynamic link. One could try
> rebuilding the SRPM and see...
>
> Possible? Or am I on crack (don't know much about efence or glibc internals,
> so... probably the latter.)
I don't think so:
| callisto$ dpkg -s electric-fence
| Package: electric-fence
| Status: install ok installed
| Priority: standard
| Section: devel
| Installed-Size: 48
| Maintainer: Debian QA Group <debian-qa@lists.debian.org>
| Version: 2.1-1
| Depends: libc6 (>= 2.1)
^^^^^^^^^^^^^^
| Description: A malloc(3) debugger
| Use virtual memory hardware to detect illegal memory accesses.
Greetings,
Geert
--
Geert Uytterhoeven Geert.Uytterhoeven@cs.kuleuven.ac.be
Wavelets, Linux/{m68k~Amiga,PPC~CHRP} http://www.cs.kuleuven.ac.be/~geert/
Department of Computer Science -- Katholieke Universiteit Leuven -- Belgium
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: bug in head.S
1999-06-23 0:45 64% ` Paul Mackerras
@ 1999-06-23 14:08 64% ` Nathan Sheeley
0 siblings, 0 replies; 200+ results
From: Nathan Sheeley @ 1999-06-23 14:08 UTC (permalink / raw)
To: Paul.Mackerras; +Cc: nsheeley, linuxppc-dev
> > Has anyone tried to build/run a pmac SMP kernel with a recent (2.2.9)
> > version of Linux?
>
> I have 2.2.10 running on my 2-cpu powermac at home (it's a 7500 with a
> 2 x 604e 200MHz cpu card in it). It mostly runs fine but has frozen
> up on me a couple of times - I haven't tracked down why/where yet.
I pulled the MP card from the 9500, and installed it in an 8500;
where it works fine w/2.2.0. The 9500 (even with a single CPU)
still appears to hang just after opening the display. Perhaps
a problem w/ the mach64 driver that only affects older versions
of the card?
Nate
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
[not found] <199906231258.HAA25989@www.cedarnet.org>
1999-06-23 13:17 64% ` dl-load.c (ld.so) bug?? Geert Uytterhoeven
@ 1999-06-23 14:19 64% ` Hollis R Blanchard
1999-06-23 14:32 64% ` Kevin Puetz
1 sibling, 1 reply; 200+ results
From: Hollis R Blanchard @ 1999-06-23 14:19 UTC (permalink / raw)
To: Kevin Puetz; +Cc: Justin Vallon, LinuxPPC-Dev List
On Wed, 23 Jun 1999, Kevin Puetz wrote:
> Umm... just thought of this - a segfault in __libc_start_main is the symptom
> of an old R4 binary on a glibc2.1 system... did ElectricFence not get
> updated (just a thought)? Then - if both libraries load - it segfaults when
> electricfence initializes _it's_ glibc dynamic link. One could try
> rebuilding the SRPM and see...
>
> Possible? Or am I on crack (don't know much about efence or glibc internals,
> so... probably the latter.)
Doesn't look like it's an R4 problem... I just rebuilt it and it does the same
thing. A different __libc_start_main thing, I guess.
-Hollis
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* File Corruption Bug.. continued
@ 1999-06-23 14:21 62% Alan Cox
0 siblings, 0 replies; 200+ results
From: Alan Cox @ 1999-06-23 14:21 UTC (permalink / raw)
To: linux-kernel
I've now been through most of the 2.2.7->2.2.9 diff set discarding stuff
that seems not to be a viable candiate.
The remaining suspects are:
o Quota - which has big 2.2.7->2.2.9 changes.
o The small scsi changes (dubious)
o A small mm change
There are other candiates - notably
TCP changes
interrupt changes
IRDA
NFS
The tcp changes ought to have shown up more than this does. The interrupt
changes dont really seem to explain cross platform stuff. And I doubt most
people running these tests were running irda. NFS is a possibility.
So - are most people seeing the problems running quotas ? And would someone
with their brain firmly wrapped around the page cache/vfs verify this change
that was made is absolutely safe
diff -u --new-file --recursive --exclude-from ../../exclude linux.2.2.7/mm/page_alloc.c linux.2.2.9/mm/page_alloc.c
--- linux.2.2.7/mm/page_alloc.c Wed Jun 23 17:48:03 1999
+++ linux.2.2.9/mm/page_alloc.c Wed Jun 23 17:43:53 1999
@@ -419,12 +419,12 @@
return;
}
- /* The page is unshared, and we want write access. In this
- case, it is safe to tear down the swap cache and give the
- page over entirely to this process. */
-
- if (PageSwapCache(page_map))
- delete_from_swap_cache(page_map);
+ /*
+ * The page is unshared and we're going to dirty it - so tear
+ * down the swap cache and give exclusive access to the page to
+ * this process.
+ */
+ delete_from_swap_cache(page_map);
set_pte(page_table, pte_mkwrite(pte_mkdirty(mk_pte(page, vma->vm_page_prot))));
return;
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [relevance 62%]
* Re: dl-load.c (ld.so) bug??
1999-06-23 14:19 64% ` Hollis R Blanchard
@ 1999-06-23 14:32 64% ` Kevin Puetz
0 siblings, 0 replies; 200+ results
From: Kevin Puetz @ 1999-06-23 14:32 UTC (permalink / raw)
To: Hollis R Blanchard; +Cc: Kevin Puetz, Justin Vallon, LinuxPPC-Dev List
OK, it was just a random thought... before people beat head on wall, it
was something simple to look at. I don't claim enough knowledge to really
make such a statement, anyhow...
> Doesn't look like it's an R4 problem... I just rebuilt it and it does the same
> thing. A different __libc_start_main thing, I guess.
>
> -Hollis
Kevin Puetz <kp11901@www.cedarnet.org>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: dl-load.c (ld.so) bug??
[not found] <Pine.LNX.4.04.9906211749280.27642-100000@narn.local.drgw.n et>
@ 1999-06-23 14:37 64% ` Franz Sirl
0 siblings, 0 replies; 200+ results
From: Franz Sirl @ 1999-06-23 14:37 UTC (permalink / raw)
To: Troy Benjegerdes; +Cc: linuxppc-dev
At 00:52 22.06.99 , Troy Benjegerdes wrote:
>testcase:
>
>#include <stdio.h>
>int main(void){
> char * ptr;
> printf("hello world\n");
> fflush(stdout);
> ptr = (char *)malloc(100);
> free(ptr);
>}
>
>
>compile this with:
>gcc test.c -lefence -g -static
>
>On a PPC glibc-2.1 box, this segfaults in dl-load.c:564
>
>On a x86 Red Hat 6.0 system, it works fine (
>[troybenj@mos6 troybenj]$ ./a.out
>
> Electric Fence 2.0.5 Copyright (C) 1987-1998 Bruce Perens.
>hello world
>[troybenj@mos6 troybenj]$
>
>
>Either dl-load.c has a serious bug, or ElectricFence is broken on PPC.
>I suspect it's the former, and if so, this would explain the weird
>segfaults I've been seeing.
>
>Can someone that knows glibc better please confirm or deny this for me?
This bug is fixed already in cvs-glibc. I've put up mostly untested RPMS
for a newer glibc under <ftp://dev.linuxppc.org/users/fsirl/R5>.
It might be that the new IP of dev is still not fully propagated, so use
169.207.1.122 directly in that case.
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Possible ne2k-pci bug on ppc
@ 1999-06-25 10:30 47% Andrew Chadwick
1999-06-25 12:10 64% ` Christian Bauer
0 siblings, 1 reply; 200+ results
From: Andrew Chadwick @ 1999-06-25 10:30 UTC (permalink / raw)
To: linuxppc-dev
First up, apologies for posting to linuxppc-dev. I'm by no means a kernel
hacker, but this is developer-level stuff. If any ethernet gurus could
help me I'd be eternally grateful *g*.
Does anyone know the status of the ne2k-pci drivers on linux/ppc? I ask
because my ne2000 card seems to be sending very oddly-shaped etherpackets
over the network.
Thanks in advance,
Andrew.
*The actors:
duodecimo: a Fujitsu 110 Lifebook, Processor: Pentium II @233MHz,
ethercard is a PCMCIA Xircom CreditCard IIps (known working and
configured OK via pcmcia-cs). Linux kernel 2.2.7 (unpatched).
piffle: an Apple PowerMac 4400/160, Processor: PowerPC 603e @160MHz,
ethercard is a cheapo 'software-configurable' 8390-based PCI NE2000 clone
made by Genius (drivers are right, card config is OK, but it just doesn't
seem to work). Kernel 2.2.7 (unpatched).
the string: properly teed and terminated 10base2.
*Symptoms
piffle does not send any TCP packets that are even recognised by the other
machine, although they're seen at ethernet level by the ethercard and the
kernel at the other end. Packets sent by duodecimo are at least seen at
the TCP level by piffle, but they're all errors.
These ifconfigs are after a few "ping -v"s either way, and are by no
means synchronized:
**duodecimo ifconfig:
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:14447 errors:0 dropped:0 overruns:0 frame:0
TX packets:14447 errors:0 dropped:0 overruns:0 carrier:0
Collisions:0
eth0 Link encap:Ethernet HWaddr 00:80:C7:26:FD:91
inet addr:192.168.101.2 Bcast:192.168.101.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:343 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
Collisions:0
Interrupt:3 Base address:0x300
**piffle ifconfig:
eth0 Link encap:Ethernet HWaddr 00:C0:DF:EE:15:4F
inet addr:192.168.101.1 Bcast:192.168.101.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:395 dropped:0 overruns:0 frame:0
TX packets:2979 errors:8 dropped:0 overruns:0 carrier:8
collisions:136 txqueuelen:100
Interrupt:25 Base address:0x400
^^^^^
*** Possible problem #1: this clashes on the PCI bus with the on-board ATI
*** mach64 graphics chips. But the gfx chips' IO ports are disabled.
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:3924 Metric:1
RX packets:3019 errors:0 dropped:0 overruns:0 frame:0
TX packets:3019 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
Just to see what was happening and why the lifebook wasn't recognising
the powerpc's ethernet packets, I did a couple of TCPdumps:
**duodecimo tcpdump (piffle pinging duodecimo):
22:15:52.131492 ff:ff:4f:15:ee:df sap 08 > ff:ff:ff:ff:c0:0 ip-sap I
(s=2,r=3,C) len=46
0008 c000 0100 4f15 eedf 0165 a8c0 0000
0000 a8c0 0000 0265 6d6b 3fe7 ebee ef3e
6ffd a9fe 7fef dfd6 f9be ca71 2ab0
22:15:53.131437 ff:ff:4f:15:ee:df sap 08 > ff:ff:ff:ff:c0:0 ip-sap I
(s=2,r=3,C) len=46
0008 c000 0100 4f15 eedf 0165 a8c0 0000
0000 a8c0 0000 0265 6d6b 3fe7 ebee ef3e
6ffd a9fe 7fef dfd6 f9be ca71 2ab0
22:15:54.131883 ff:ff:4f:15:ee:df sap 08 > ff:ff:ff:ff:c0:0 ip-sap I
(s=2,r=3,C) len=46 ^^^^^^^^^^^ ^^^^
^^^^^^^^^^^ ^^^^
*** Almost certainly the real problem: an endianness probblem here?
*** Besides, that should be "card-addr > ff:ff:ff:ff:ff", no?
0008 c000 0100 4f15 eedf 0165 a8c0 0000
0000 a8c0 0000 0265 6d6b 3fe7 ebee ef3e
6ffd a9fe 7fef dfd6 f9be ca71 2ab0
22:15:55.131364 ff:ff:4f:15:ee:df sap 08 > ff:ff:ff:ff:c0:0 ip-sap I
(s=2,r=3,C) len=46
0008 c000 0100 4f15 eedf 0165 a8c0 0000
0000 a8c0 0000 0265 6d6b 3fe7 ebee ef3e
6ffd a9fe 7fef dfd6 f9be ca71 2ab0
**piffle tcpdump -x (piffle pinging duodecimo):
21:26:39.170000 arp who-has duodecimo tell piffle
0001 0800 0604 0001 00c0 dfee 154f c0a8
6501 0000 0000 0000 c0a8 6502
21:26:40.170000 arp who-has duodecimo tell piffle
0001 0800 0604 0001 00c0 dfee 154f c0a8
6501 0000 0000 0000 c0a8 6502
21:26:41.170000 arp who-has duodecimo tell piffle
0001 0800 0604 0001 00c0 dfee 154f c0a8
6501 0000 0000 0000 c0a8 6502
21:26:42.170000 arp who-has duodecimo tell piffle
0001 0800 0604 0001 00c0 dfee 154f c0a8
6501 0000 0000 0000 c0a8 6502
--
sub p{s/^\s*((\"(\\.|.)*?\")|\w+)//&&return$1;s/^\s*\(//||die$_;my @r;until
(s/^\s*\)//){push(@r,&p)}\@r}sub r{ref($c=$_[0])?shift(@{$c}).'('.join(',',
map{r($_)}@{$c}).')':$c}$_= #Andrew Chadwick <http://www.durge.org/~andyc/>
'(print (join " " (reverse "hacker.\n""Perl""another""Just")))';eval &r(&p)
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 47%]
* Re: Possible ne2k-pci bug on ppc
1999-06-25 10:30 47% Possible ne2k-pci bug on ppc Andrew Chadwick
@ 1999-06-25 12:10 64% ` Christian Bauer
0 siblings, 0 replies; 200+ results
From: Christian Bauer @ 1999-06-25 12:10 UTC (permalink / raw)
To: Andrew Chadwick; +Cc: linuxppc-dev
Hi!
On Fri, 25 Jun 1999, Andrew Chadwick wrote:
> Does anyone know the status of the ne2k-pci drivers on linux/ppc?
It has some endianess problems. I posted a patch to this list a while
ago. It can be found on
http://lists.linuxppc.org/listarcs/linuxppc-dev/199904/msg00248.html
Bye,
Christian
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Bug Report : Kernel Panic w/ PPP & Netscape
@ 1999-07-22 12:28 52% Lucas Vergnettes
1999-07-22 14:35 51% ` Jerry Quinn
0 siblings, 1 reply; 200+ results
From: Lucas Vergnettes @ 1999-07-22 12:28 UTC (permalink / raw)
To: LinuxPPC Developpers
Hi everyone.
Iwolud like to submit a bug report. This problem happens on my box something
like 2 times a day, and is ~quite~ annoying ;)
I hope this is the good place for this kind of messages.
The situation :
A powermac 7300/166, YellowDog 1.0, an ATI video card (the one from the 9500s
ATY,MACH64) and an Olitec 56k modem.
When I startup ny internet connexion (ala redhat : ifup ppp0), everything is
ok, but when i start browsing with netscape, the problems begin... This is a
typical log :
Jul 22 14:01:14 wip ifup-ppp: pppd started for ppp0 on /dev/ttyS1 at 115200
Jul 22 14:01:15 wip kernel: registered device ppp0
Jul 22 14:01:15 wip pppd[614]: pppd 2.3.5 started by root, uid 0
Jul 22 14:01:16 wip chat[617]: send (AT&F1M0^M)
Jul 22 14:01:16 wip chat[617]: expect (OK)
Jul 22 14:01:16 wip chat[617]: ^M
Jul 22 14:01:16 wip chat[617]: OK
Jul 22 14:01:16 wip chat[617]: -- got it
Jul 22 14:01:16 wip chat[617]: send (ATDT0836019301^M)
Jul 22 14:01:16 wip chat[617]: expect (CONNECT)
Jul 22 14:01:16 wip chat[617]: ^M
Jul 22 14:01:47 wip chat[617]: ATDT0836019301^M^M
Jul 22 14:01:47 wip chat[617]: CONNECT
Jul 22 14:01:47 wip chat[617]: -- got it
Jul 22 14:01:47 wip chat[617]: send (^M)
Jul 22 14:01:47 wip chat[617]: send (AT&F1^M)
Jul 22 14:01:47 wip pppd[614]: Serial connection established.
Jul 22 14:01:48 wip pppd[614]: Using interface ppp0
Jul 22 14:01:48 wip pppd[614]: Connect: ppp0 <--> /dev/ttyS1
Jul 22 14:01:48 wip pppd[614]: Remote message:
Jul 22 14:01:48 wip modprobe: can't locate module ppp-compress-21
Jul 22 14:01:48 wip modprobe: can't locate module ppp-compress-26
Jul 22 14:01:48 wip modprobe: can't locate module ppp-compress-24
Jul 22 14:01:49 wip pppd[614]: local IP address 193.250.81.28
Jul 22 14:01:49 wip pppd[614]: remote IP address 193.251.116.157
Jul 22 14:02:00 wip kernel: FB. overflow: 1
Jul 22 14:02:00 wip kernel: FB. overflow: 2
Jul 22 14:02:00 wip kernel: FB. overflow: 3
And the FB.overflow message count up to 1000 sometimes, but in general, I get
a superb Kernel panic before, which forces me to reboot ans fsck my disks...
The funny thing is that when the FB messages flood the console, i can stop
them by shutting down my modem. WHen I power it again, the messages restart to
flow!
In fact, this hasn't happened only w/ Netscape, but it is a favorising factor
;)
I have even got this kind of panic while being on the console (No X!)...
I suppose it might be an atyfb problem.
My card makes raindow lines on the screen when there are too much colors.
This problem has occured with :
The 2.2.1 precompiled from paul, a home compiled one from me.
The Linus' 2.2.10 home made w/ turbomouse & mol patches, but they aren't in
cause.
Hope this will help to track something.
Staying at your disposition for testings and further info..
Lucas
--
Lucas Vergnettes -- Osteopathy Student -- mailto:lucas@promac.org
LinuxPPC, Ostéopathie et astuces telnet sur http://lucas.promac.org
EMACS : Escape-Meta-Alt-Control-Shift
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 52%]
* Bug Report : Kernel Panic w/ PPP & Netscape
1999-07-22 12:28 52% Bug Report : Kernel Panic w/ PPP & Netscape Lucas Vergnettes
@ 1999-07-22 14:35 51% ` Jerry Quinn
0 siblings, 0 replies; 200+ results
From: Jerry Quinn @ 1999-07-22 14:35 UTC (permalink / raw)
To: Lucas Vergnettes; +Cc: LinuxPPC Developpers
lv> Hi everyone.
lv>
lv> Iwolud like to submit a bug report. This problem happens on my box something
lv> like 2 times a day, and is ~quite~ annoying ;)
lv>
lv> I hope this is the good place for this kind of messages.
lv>
lv> The situation :
lv> A powermac 7300/166, YellowDog 1.0, an ATI video card (the one from the 9500s
lv> ATY,MACH64) and an Olitec 56k modem.
lv>
lv> When I startup ny internet connexion (ala redhat : ifup ppp0), everything is
lv> ok, but when i start browsing with netscape, the problems begin... This is a
lv> typical log :
lv>
lv> Jul 22 14:01:14 wip ifup-ppp: pppd started for ppp0 on /dev/ttyS1 at 115200
lv> Jul 22 14:01:15 wip kernel: registered device ppp0
lv> Jul 22 14:01:15 wip pppd[614]: pppd 2.3.5 started by root, uid 0
lv> Jul 22 14:01:16 wip chat[617]: send (AT&F1M0^M)
lv> Jul 22 14:01:16 wip chat[617]: expect (OK)
lv> Jul 22 14:01:16 wip chat[617]: ^M
lv> Jul 22 14:01:16 wip chat[617]: OK
lv> Jul 22 14:01:16 wip chat[617]: -- got it
lv> Jul 22 14:01:16 wip chat[617]: send (ATDT0836019301^M)
lv> Jul 22 14:01:16 wip chat[617]: expect (CONNECT)
lv> Jul 22 14:01:16 wip chat[617]: ^M
lv> Jul 22 14:01:47 wip chat[617]: ATDT0836019301^M^M
lv> Jul 22 14:01:47 wip chat[617]: CONNECT
lv> Jul 22 14:01:47 wip chat[617]: -- got it
lv> Jul 22 14:01:47 wip chat[617]: send (^M)
lv> Jul 22 14:01:47 wip chat[617]: send (AT&F1^M)
lv> Jul 22 14:01:47 wip pppd[614]: Serial connection established.
lv> Jul 22 14:01:48 wip pppd[614]: Using interface ppp0
lv> Jul 22 14:01:48 wip pppd[614]: Connect: ppp0 <--> /dev/ttyS1
lv> Jul 22 14:01:48 wip pppd[614]: Remote message:
lv> Jul 22 14:01:48 wip modprobe: can't locate module ppp-compress-21
lv> Jul 22 14:01:48 wip modprobe: can't locate module ppp-compress-26
lv> Jul 22 14:01:48 wip modprobe: can't locate module ppp-compress-24
lv> Jul 22 14:01:49 wip pppd[614]: local IP address 193.250.81.28
lv> Jul 22 14:01:49 wip pppd[614]: remote IP address 193.251.116.157
lv> Jul 22 14:02:00 wip kernel: FB. overflow: 1
lv> Jul 22 14:02:00 wip kernel: FB. overflow: 2
lv> Jul 22 14:02:00 wip kernel: FB. overflow: 3
I can't say that I know what your overflow problem is. However, you are
missing compression. I ran into problems when I didn't tell pppd to turn off
compression when modprobe wasn't able to find the compress modules.
If you have the modules (bsd-compress.o and ppp-deflate.o) for your kernel
version in the right place (/lib/modules/<version>/ppp I think), then you need
to add the following to /etc/conf.modules:
ppp-compress-21 = bsd-compress
ppp-compress-24 = ppp-deflate
ppp-compress-26 = ppp-deflate
Paul Mackerras has added the definitions to the latest modutils package, so
installing that will solve the problem.
In the meantime, try telling pppd to use no compression and see if your
problems go away. If not, it will at least remove a confounding variable.
lv> Lucas Vergnettes -- Osteopathy Student -- mailto:lucas@promac.org
Hope this is helpful
--
Jerry Quinn Tel: (514) 761-8737
jquinn@nortelnetworks.com Fax: (514) 761-8505
Speech Recognition Research
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 51%]
* Linker bug
@ 1999-07-26 21:53 64% Ralf Baechle
0 siblings, 0 replies; 200+ results
From: Ralf Baechle @ 1999-07-26 21:53 UTC (permalink / raw)
To: linux, linux-mips, linux-mips
ld crashes when doing the following:
echo "main(){}" > c.c
gcc -o c c.c -lm -ieee
Strange enough this only hits native linkers, not crosslinkers built from
the same sources. This prevents us from building several RH 6.0 packages.
I don't have the time to track this one down, so I'd _really_ appreciate
if somebody else would do so.
Ralf
^ permalink raw reply [relevance 64%]
* Netatalk bug?, too many routes/iface
@ 1999-07-27 19:02 64% jhart
1999-07-27 19:32 64% ` a sun
0 siblings, 1 reply; 200+ results
From: jhart @ 1999-07-27 19:02 UTC (permalink / raw)
To: Markus Boie; +Cc: a sun, Rob Spellman, linuxppc-dev, Netatalk List
Markus Boie, MBoie@Adobe.COM writes:
>Konstantin wrote:
>>I just tried to play your game. Both interfaces on the same segment only
>>eth1 configured in the atalkd.conf. Everything seems to work fine - no
>>error messages. All the services show up.
>>RH-6.0 (kernel 2.2.5) netatalk-1.4b2+assun2.1.3.
>>I have only one network configured not a range.
>>You may want to try to run it on a separate segment without other
>>machines, have one mac to test it. The problem may really be that you
>>have a too wide network range.
>Jim Hart writes:
>>Here is the actual log entry:
>>
>>Jul 26 14:25:45 m1814 kernel: NET4: AppleTalk 0.18 for Linux NET4.0
>>Jul 26 14:25:56 m1814 atalkd[447]: restart (1.4b2+asun2.0a18.2)
>>Jul 26 14:25:57 m1814 atalkd[447]: zip_getnetinfo for eth0
>>Jul 26 14:25:57 m1814 atalkd[447]: rtmp_packet interface mismatch
>>Jul 26 14:25:57 m1814 atalkd[447]: zip gnireply from 1000.162 (eth0 12)
>>Jul 26 14:25:58 m1814 kernel: Too many routes/iface.
>>Jul 26 14:25:58 m1814 atalkd[447]: setifaddr: eth0: Invalid argument
>>Jul 26 14:25:59 m1814 papd[458]: restart (1.4b2+asun2.0a18.2)
>>Jul 26 14:25:59 m1814 afpd[467]: main: atp_open: Cannot assign requested
>>address
>>Jul 26 14:25:59 m1814 afpd[467]: ASIP started on 134.181.128.227:548(1)
>>(1.4b2+a
>>sun2.0a18.2)
>>
>>
>>Again, this is running LinuxPPC v4.1.
>>
>>The atalkd.conf contains just the one line "eth0", per Adrian's advice.
>>There is only one Ethernet interface in the machine. This is happening
>>on all machines on which I've installed LinuxPPC v4.1, including an iMac,
>>a PowerMac 7250 and a PowerMac 7350.
>Thanks Konstantin - that was indeed the problem. On our AppleTalk router
>(Helios on a Sun) we had defined a network range of 1-60000. Setting this
>to 1-200 was all I needed to do to make atalkd on the Linux box start.
I presume, then, that this is a bug in the Appletalk code in LinuxPPC,
even though it's numbered 0.18, as compared to 0.17 in the Redhat 5.2
we're running on our Intel machines. The Intel machines have no problem
with our network numbering ranges, which, according to our network
administrator, can legally go from 1 to 65535.
--
Jim Hart
"He who gives up liberty for security ends up with neither." - Benjamin
Franklin
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: Netatalk bug?, too many routes/iface
1999-07-27 19:02 64% Netatalk bug?, too many routes/iface jhart
@ 1999-07-27 19:32 64% ` a sun
0 siblings, 0 replies; 200+ results
From: a sun @ 1999-07-27 19:32 UTC (permalink / raw)
To: jhart; +Cc: MBoie, rspell, linuxppc-dev, netatalk-admins
I presume, then, that this is a bug in the Appletalk code in LinuxPPC,
even though it's numbered 0.18, as compared to 0.17 in the Redhat 5.2
we're running on our Intel machines. The Intel machines have no problem
with our network numbering ranges, which, according to our network
administrator, can legally go from 1 to 65535.
i think that it might have been an endianness bug, but i'm not
sure. if it still happens with linux-2.2.10, let me know, and i'll
look into it. oh yeah, your administrator is wrong about the range of
possible network numbers. numbers from 65280 to 65534 are reserved for
routerless networks.
-a
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* active_mm & SMP & TLB flush: possible bug
@ 1999-07-28 12:30 64% Manfred Spraul
1999-07-28 15:46 64% ` Benjamin C.R. LaHaise
1999-07-28 18:07 64% ` Kanoj Sarcar
0 siblings, 2 replies; 200+ results
From: Manfred Spraul @ 1999-07-28 12:30 UTC (permalink / raw)
To: linux-mm
I think that active_mm breaks CLEVER_SMP_INVALIDATE
(linux/asm-i386/pgtable.h)
(version 2.3.11)
e.g. flush_tlb():
CPU 1 executes thread A, CPU2 waits in
the idle thread with a lazy TLB context of thread A.
CPU1: flush_tlb() causes no IPI because
current->mm->mm_users is still 1.
if these 2 CPU switch their roles, then we use an outdates
TLB cache.
-------------
BTW, where can I find more details about the active_mm implementation?
specifically, I'd like to know why active_mm was added to
"struct task_struct".
>From my first impression, it's a CPU specific information
(every CPU has exactly one active_mm, threads which are not running have
no
active_mm), so I'd have used a global array[NR_CPUS].
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: active_mm & SMP & TLB flush: possible bug
1999-07-28 12:30 64% active_mm & SMP & TLB flush: possible bug Manfred Spraul
@ 1999-07-28 15:46 64% ` Benjamin C.R. LaHaise
1999-07-28 18:07 64% ` Kanoj Sarcar
1 sibling, 0 replies; 200+ results
From: Benjamin C.R. LaHaise @ 1999-07-28 15:46 UTC (permalink / raw)
To: masp0008; +Cc: linux-mm
On Wed, 28 Jul 1999, Manfred Spraul wrote:
> if these 2 CPU switch their roles, then we use an outdates
> TLB cache.
You're right, thankfully it's fixed in 2.3.12-8 (meaning that my dual
finally stops SIGSEGVing random processes).
> BTW, where can I find more details about the active_mm implementation?
> specifically, I'd like to know why active_mm was added to
> "struct task_struct".
> >From my first impression, it's a CPU specific information
> (every CPU has exactly one active_mm, threads which are not running have
> no
> active_mm), so I'd have used a global array[NR_CPUS].
That soulds like a good idea -- care to offer a patch? =)
-ben
--
Hi! I'm Signature Virus 99! Copy me into your .signature and join the fun!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: active_mm & SMP & TLB flush: possible bug
@ 1999-07-28 16:58 64% Manfred Spraul
0 siblings, 0 replies; 200+ results
From: Manfred Spraul @ 1999-07-28 16:58 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: Linux MM
>> BTW, where can I find more details about the active_mm implementation?
>> specifically, I'd like to know why active_mm was added to
>> "struct task_struct".
>> >From my first impression, it's a CPU specific information
>> (every CPU has exactly one active_mm, threads which are not running have
>> no
>> active_mm), so I'd have used a global array[NR_CPUS].
>
>That soulds like a good idea -- care to offer a patch? =)
I still try to understand the current implementation, and I can't propose a
patch before I understand the current code...
I'll try to write a patch over the weekend.
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: active_mm & SMP & TLB flush: possible bug
1999-07-28 12:30 64% active_mm & SMP & TLB flush: possible bug Manfred Spraul
1999-07-28 15:46 64% ` Benjamin C.R. LaHaise
@ 1999-07-28 18:07 64% ` Kanoj Sarcar
1 sibling, 0 replies; 200+ results
From: Kanoj Sarcar @ 1999-07-28 18:07 UTC (permalink / raw)
To: masp0008; +Cc: linux-mm
> BTW, where can I find more details about the active_mm implementation?
> specifically, I'd like to know why active_mm was added to
> "struct task_struct".
That goes for a lot of other changes in 2.3 - unfortunately, there
seems to be no concept of release notes etc, that provide one liner
descriptions of the changes being put into a release.
In this case at least, the concept of "active_mm" reduces tlb flushes
when switching *to* a kernel thread, since a kernel thread has no
user level translations, and can use the kernel-level translations
of the previous thread. set_mmu_context updates the task.cr3, which
is checked in __switch_to, and since the cr3 update is skipped, the
tlb's are not flushed.
> >From my first impression, it's a CPU specific information
> (every CPU has exactly one active_mm, threads which are not running have
> no
> active_mm), so I'd have used a global array[NR_CPUS].
Umm, really? My reading of the code was that all kernel threads and
exitted user threads had no "mm", and had an "active_mm" only while
executing on the cpu. Other user threads with user level translations
always have an "mm" and "active_mm".
Kanoj
>
>
> Manfred
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majordomo@kvack.org. For more info on Linux MM,
> see: http://humbolt.geo.uu.nl/Linux-MM/
>
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: active_mm & SMP & TLB flush: possible bug
@ 1999-07-28 18:35 64% Manfred Spraul, Benjamin C.R. LaHaise
0 siblings, 0 replies; 200+ results
From: Manfred Spraul, Benjamin C.R. LaHaise @ 1999-07-28 18:35 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: linux-mm
>> BTW, where can I find more details about the active_mm implementation?
>> specifically, I'd like to know why active_mm was added to
>> "struct task_struct".
>> >From my first impression, it's a CPU specific information
>> (every CPU has exactly one active_mm, threads which are not running have
>> no
>> active_mm), so I'd have used a global array[NR_CPUS].
>
>That soulds like a good idea -- care to offer a patch? =)
I know you should not reply twice to one mail, but I noticed that my initial
assumption was wrong:
It seems that the MMU caches can contain data from multiple
"struct mm_struct"'s on the PPC cpu, perhaps this also applies to
other CPU's.
It's Intel specific that the TLB contains data from just one mm_struct.
--
Manfred
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Bug or hidden feature ?
@ 1999-07-30 13:03 60% Alain Birtz
0 siblings, 0 replies; 200+ results
From: Alain Birtz @ 1999-07-30 13:03 UTC (permalink / raw)
To: linuxppc-dev
/*
In the code below, the second loop print char exactly is the same place
as the first loop. The only change is the char printed. Hit 3 time a key
A strange thing happen when the last half end of the line hold only
blanck space character.
Normally the blank must erase the underscore. This not happen.
Instead the remaining of the line (after the underscore) is erased.
This seem happen only in the X term window
Tested in Gnome terminal (linucPPC R5)
Is it an hidden feature ? Or is there something wrong with the code ?
*/
// gcc -I/usr/include/ncurses tst_addch.c -g -o tst -lncurses
#include <curses.h>
int main()
{
int r, c;
initscr();
for (r = 0; r < LINES; r++) /* fill screen of letter, so we can see
what happen */
{
for (c = 0; c < COLS; c++)
mvaddch(r, c, 'A'+ r);
}
refresh();
getchar();
// FIRST LOOP
for (r = 2; r < LINES - 2; r++) /* write in middle of the screen */
{
for (c = 3; c < COLS / 2; c++)
if (c < COLS / 5)
mvaddch(r, c, '*');
else
mvaddch(r, c, '_'); /* first loop -> use underscore */
}
refresh();
getchar();
// SECOND LOOP
for (r = 2; r < LINES - 2; r++) /* write in same place */
{
for (c = 3; c < COLS / 2; c++)
if (c < COLS / 5)
mvaddch(r, c, '/');
else
mvaddch(r, c, ' '); /* second loop -> use blanck space char */
}
refresh();
getchar();
endwin();
exit(0);
}
// the second loop is same as the first loop, except for the char
printed
// the underscore is not replaced by the blank char
// but the remainning of the line (after the unserscore) is erased
// if the terminal window is small, this not happen
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 60%]
* [linux-lvm] bug in liblvm 0.7 [added on 11/15/1998]
@ 1999-07-31 20:58 60% Ryan Murray
1999-08-02 9:57 64% ` Heinz Mauelshagen
0 siblings, 1 reply; 200+ results
From: Ryan Murray @ 1999-07-31 20:58 UTC (permalink / raw)
To: linux-lvm
The following bit of code tries to "skip" partitions if the main drive
doesn't exist:
pv_read_all_pv.c:102
for ( n = 0; n < cache_size; n++) {
dev_name = dir_cache[n].dev_name;
#ifdef DEBUG
debug ( "pv_read_all_pv -- calling pv_read with \"%s\"\n",
dev_name);
if ( ( tst = open ( dev_name, O_RDONLY)) == -1) {
if ( MAJOR ( dir_cache[n].st_rdev) != MD_MAJOR &&
MINOR ( dir_cache[n].st_rdev) % 16 == 0) {
n += 15;
continue;
}
} else close ( tst);
this will work for SCSI disks (assuming all partition devices exist),
but fails for IDE disks. IDE disks can have up to 63 partitions, and a
quick survey shows debian potato creating devices for the first 20, and
slackware 4.0 creating devices for the first 16.
The only way I can see around it is to build a second directory cache as
you move through the dir_cache, listing strings that should be skipped.
ie (semi-pseudo code):
for ( i = 0 ; i < skip_cache_size ; i++ ) {
if ( !strcmp( dir_cache_skip[i].dev_name, dev_name ) ) {
skip = YES;
break;
}
}
if ( skip )
continue;
if ( ( tst = open ( dev_name, O_RDONLY)) == -1) {
if ( MAJOR ( dir_cache[n].st_rdev) != MD_MAJOR &&
(MAJOR_IS_SCSI && MINOR ( dir_cache[n].st_rdev) % 16 == 0)
|| (MAJOR_IS_IDE && MINOR ( dir_cache[n].st_rdev) % 64 == 0)) {
// realloc memory for "dir_skip_cache"
// allocate memory in dir_skip_cache[skip_cache_size]
// for strlen(dev_name)+1
strcpy( dir_cache_skip[skip_cache_size].dev_name, dev_name );
skip_cache_size++;
continue;
}
} else close ( tst);
This gets rather ugly -- I wonder if the building of the dir_cache and
the check for the partition existing shouldn't be combined instead,
leaving the dir_cache with entries that exist on this system only?
I put it up here for discussion on what the "best" way to do this is.
The reason I bring this up is that pvscan isn't finding /dev/sda,
because of the skipping. The % 16 check also isn't valid for IDE, it
needs to be % 64.
--
Ryan Murray (rmurray@cyberhqz.com, rmurray@glenayre.com)
Software Designer, Glenayre Technologies Inc.
The opinions expressed here are my own.
^ permalink raw reply [relevance 60%]
* Re: [linux-lvm] bug in liblvm 0.7 [added on 11/15/1998]
1999-07-31 20:58 60% [linux-lvm] bug in liblvm 0.7 [added on 11/15/1998] Ryan Murray
@ 1999-08-02 9:57 64% ` Heinz Mauelshagen
1999-08-11 5:59 64% ` Ryan Murray
0 siblings, 1 reply; 200+ results
From: Heinz Mauelshagen @ 1999-08-02 9:57 UTC (permalink / raw)
To: rmurray; +Cc: mge, linux-lvm
Hello Ryan,
the simple idea behind this was to avoid not neccessary accesses in case of
a regular /dev layout (no trouble in case of devfs anyway).
If we put to much effort into holding up this concept i'ld rather say
"let's throw it away and open all existing device special nodes in turn".
Any opinions?
>
> The following bit of code tries to "skip" partitions if the main drive
> doesn't exist:
>
> pv_read_all_pv.c:102
>
> for ( n = 0; n < cache_size; n++) {
> dev_name = dir_cache[n].dev_name;
> #ifdef DEBUG
> debug ( "pv_read_all_pv -- calling pv_read with \"%s\"\n",
> dev_name);
>
> if ( ( tst = open ( dev_name, O_RDONLY)) == -1) {
> if ( MAJOR ( dir_cache[n].st_rdev) != MD_MAJOR &&
> MINOR ( dir_cache[n].st_rdev) % 16 == 0) {
> n += 15;
> continue;
> }
> } else close ( tst);
>
> this will work for SCSI disks (assuming all partition devices exist),
> but fails for IDE disks. IDE disks can have up to 63 partitions, and a
> quick survey shows debian potato creating devices for the first 20, and
> slackware 4.0 creating devices for the first 16.
>
<SNIP>
Regards,
Heinz
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Systemmanagement CS-TS T-Nova
Entwicklungszentrum Darmstadt
Heinz Mauelshagen Otto-Roehm-Strasse 71c
Senior Systems Engineer Postfach 10 05 41
64205 Darmstadt
mge@ez-darmstadt.telekom.de Germany
+49 6151 886-425
FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [relevance 64%]
* MIPS gas bug & fix
@ 1999-08-02 17:59 64% Ralf Baechle
0 siblings, 0 replies; 200+ results
From: Ralf Baechle @ 1999-08-02 17:59 UTC (permalink / raw)
To: binutils; +Cc: linux, linux-mips, linux-mips
Hi,
the cvs version of gas has a tiny typo which prevents it from swapping
an instruction preceeding a jump or branch in most cases. The fix is
trivial and appended below.
Ralf
--- tc-mips.c.orig Mon Aug 2 10:47:15 1999
+++ tc-mips.c Mon Aug 2 10:47:04 1999
@@ -2099,7 +2099,7 @@
|| (mips_opts.mips16 && prev_insn_fixp)
/* If the previous instruction is a sync, sync.l, or
sync.p, we can not swap. */
- || (prev_pinfo && INSN_SYNC))
+ || (prev_pinfo & INSN_SYNC))
{
/* We could do even better for unconditional branches to
portions of this object file; we could pick up the
^ permalink raw reply [relevance 64%]
* Re: yet another bug in atyfb.c
@ 1999-08-03 15:26 62% ` David Edelsohn
1999-08-03 16:57 64% ` Daniel Jacobowitz
0 siblings, 1 reply; 200+ results
From: David Edelsohn @ 1999-08-03 15:26 UTC (permalink / raw)
To: Wulf Hofbauer; +Cc: linuxppc-dev
>>>>> Wulf Hofbauer writes:
Wulf> EXPLANATION: atyfb.c - as of Kernel 2.2.10 - uses the following constructs
Wulf> for accessing little-endian words in Mach32 controller space:
Wulf> asm("lwbrx %0,%1,%2" : "=r"(val) : "r" (regindex), "r" (temp));
Wulf> and
Wulf> asm("stwbrx %0,%1,%2" : : "r" (val), "r" (regindex), "r" (temp) :
Wulf> "memory");
Wulf> This is meant to access a word at address regindex+temp. If regindex
Wulf> happens to be held in register r0, the address calculation is off as
Wulf> r0 is defined as a null operand. This problem shows up with gcc-2.95 which
Wulf> seems to use better register allocation code and _does_ keep regindex in
Wulf> r0 at times.
The problem is that you are using the wrong register constraints.
The inlined assembly should look like:
asm("lwbrx %0,%1,%2" : "=r"(val) : "b" (regindex), "r" (temp));
because %1 must be a BASE register (any GPR other than r0) for this use.
If you use the correct register constraints, GCC register allocation will
arrange to place the values in the correct class of register. If you use
the right register constraints, you do not need to make any other
modifications.
David
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 62%]
* Re: yet another bug in atyfb.c
1999-08-03 15:26 62% ` David Edelsohn
@ 1999-08-03 16:57 64% ` Daniel Jacobowitz
0 siblings, 0 replies; 200+ results
From: Daniel Jacobowitz @ 1999-08-03 16:57 UTC (permalink / raw)
To: David Edelsohn; +Cc: Wulf Hofbauer, linuxppc-dev
On Tue, Aug 03, 1999 at 11:26:39AM -0400, David Edelsohn wrote:
>
> >>>>> Wulf Hofbauer writes:
>
> Wulf> EXPLANATION: atyfb.c - as of Kernel 2.2.10 - uses the following constructs
> Wulf> for accessing little-endian words in Mach32 controller space:
>
> Wulf> asm("lwbrx %0,%1,%2" : "=r"(val) : "r" (regindex), "r" (temp));
>
> Wulf> and
>
> Wulf> asm("stwbrx %0,%1,%2" : : "r" (val), "r" (regindex), "r" (temp) :
> Wulf> "memory");
>
> Wulf> This is meant to access a word at address regindex+temp. If regindex
> Wulf> happens to be held in register r0, the address calculation is off as
> Wulf> r0 is defined as a null operand. This problem shows up with gcc-2.95 which
> Wulf> seems to use better register allocation code and _does_ keep regindex in
> Wulf> r0 at times.
>
> The problem is that you are using the wrong register constraints.
> The inlined assembly should look like:
>
> asm("lwbrx %0,%1,%2" : "=r"(val) : "b" (regindex), "r" (temp));
>
> because %1 must be a BASE register (any GPR other than r0) for this use.
> If you use the correct register constraints, GCC register allocation will
> arrange to place the values in the correct class of register. If you use
> the right register constraints, you do not need to make any other
> modifications.
And congratulations to the both of you, you analyzed that one much more
easily than I did :) It's been fixed in vger for a while:
revision 1.106.2.1
date: 1999/06/22 06:28:23; author: paulus; state: Exp; lines: +42 -23
Geert's crystal frequency estimation stuff from the 2.3 branch;
fix the constraints on the inline assembly.
However, could someone please move this fix onto the mainline also?
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* 2.2.x kernels: Sound Bug report
@ 1999-08-06 10:17 64% Albrecht Dre_
0 siblings, 0 replies; 200+ results
From: Albrecht Dre_ @ 1999-08-06 10:17 UTC (permalink / raw)
To: LinuxPPC-Dev Liste; +Cc: Paul.Mackerras
In kernels 2.2.6 and 2.2.10 I noticed a small flaw in sound support on a
PowerBook G3 (Wallstreet). CD to sound (AWACS) playthrough is not enabled
regardless of the setting in the MacOS control panel. This problem emerges when
booting with the BootX extension, but NOT if booting with the BootX application
(both ver. 1.1.1). As Ben explained, MacOS seems to do some initialisation
which is not present in the Linux sound driver.
Thanks, Albrecht.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* [linux-lvm] bug/questions
@ 1999-08-08 10:13 64% Ryan Murray
0 siblings, 0 replies; 200+ results
From: Ryan Murray @ 1999-08-08 10:13 UTC (permalink / raw)
To: linux-lvm
I've found a bug in e2fsadm. It assumes that the e2fs was created with
a block size of 1024, which is not always the case. The number it then
passes to resize2fs is totally wrong, and resize2fs then exits with an
error.
Also, how does lvm handle (or does it) the effect of removing a SCSI
drive in the middle of the SCSI drives? ie, I have:
sda : scsi id 1
sdb : scsi id 3
sdc : scsi id 5
and I add a drive as scsi id 2, so now we have:
sda : scsi id 1
sdb : scsi id 2
sdc : scsi id 3 (OLD sdb)
sdd : scsi id 5 (OLD sdc)
Will lvm put the drives together in the right order?
--
Ryan Murray (rmurray@cyberhqz.com, rmurray@glenayre.com)
Software Designer, Glenayre Technologies Inc.
The opinions expressed here are my own.
^ permalink raw reply [relevance 64%]
* Re: [linux-lvm] bug in liblvm 0.7 [added on 11/15/1998]
1999-08-02 9:57 64% ` Heinz Mauelshagen
@ 1999-08-11 5:59 64% ` Ryan Murray
0 siblings, 0 replies; 200+ results
From: Ryan Murray @ 1999-08-11 5:59 UTC (permalink / raw)
To: linux-lvm
On Mon, Aug 02, 1999 at 11:57:11AM +0000, Heinz Mauelshagen wrote:
> the simple idea behind this was to avoid not neccessary accesses in case of
> a regular /dev layout (no trouble in case of devfs anyway).
"regular" seems to vary from distribution to distribution,
unfortunately.
> If we put to much effort into holding up this concept i'ld rather say
> "let's throw it away and open all existing device special nodes in turn".
That may be the best bet. Although it would be nice if it was smart
enough to throw away what it's already done. If /dev/hda doesn't exist,
don't do any /dev/hda's. And if /dev/hda is a full LVM drive, you may
as well not check partitions. At this point, it's caused more problems
than majorly noted speed improvements, for me.
For now, I've created fifteen md and loop devices, even though I use 0. I
suppose I could just remove them all...
>
> Any opinions?
It's either got to be ripped out, or made *really* smart. At this
point, I think it's why vgscan is failing. Which brings me to my next
point, it would be nice if vgscan would say something on partial volume
groups, ie: "only 9/20 drives found for volume group "vg00", leaving
offline"
I think this code is what caused vgscan to fail for me. Going to try it
now that I've added all the device files...
--
Ryan Murray (rmurray@cyberhqz.com, rmurray@glenayre.com)
Software Designer, Glenayre Technologies Inc.
The opinions expressed here are my own.
^ permalink raw reply [relevance 64%]
* Bug in modules es1370.o or soundcore.o
@ 1999-08-20 19:44 35% Maarten Wisse
0 siblings, 0 replies; 200+ results
From: Maarten Wisse @ 1999-08-20 19:44 UTC (permalink / raw)
To: linux-sound
[-- Attachment #1: Type: text/plain, Size: 4433 bytes --]
[1.] One line summary of the problem: cd's do not play on the es1370.o
in 2.2.11
[2.] Full description of the problem/report: Yesterday, I updated my
kernel from 2.2.1 to 2.2.11. After compiling with exactly the same
settings as in my 2.2.1 settings, playing cd's using my Soundblaster
PCI128 did not work. Wav files do play properly. As you will see from
the other files everything necessary is present on the system, so it
must be a bug. I've configured my 2.2.1 kernel as vmlinuz.old and that
one still works properly. So the problem is: no sound appears. No
warnings appear in my kmix 1.0. The card is recognised, as evident from
/proc/pci. The modules are loaded,as evident from /proc/modules. I hope
you will be able to solve the problem.
[3.] Keywords (i.e., modules, networking, kernel): soundmodules for
es1370.
[4.] Kernel version (from /proc/version): Linux version 2.2.11
(root@wst) (gcc version egcs-2.91.60 19981201 (egcs-1.1.1 release)) #1
Thu Aug 19 20:26:12 CEST 1999
[7.] Environment
[7.1.] Software (add the output of the ver_linux script here) --
Versions installed: (if some fields are empty or looks
-- unusual then possibly you have very old versions)
Linux wst 2.2.11 #1 Thu Aug 19 20:26:12 CEST 1999 i686 unknown
Kernel modules 2.1.85
Gnu C egcs-2.91.60
Binutils 2.9.1.0.15
Linux C Library x 1 root root 2478585 Jan 14 1999
/lib/libc.so.6
Dynamic linker ldd (GNU libc) 2.0.7
Procps 1.2.7
Mount 2.9
Net-tools 1.46
Kbd 0.96
Sh-utils 1.12
Modules Loaded es1370 soundcore serial
[7.2.] Processor information (from /proc/cpuinfo):processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 5
model name : Pentium II (Deschutes)
stepping : 1
cpu MHz : 350.802645
cache size : 512 KB
fdiv_bug : no
hlt_bug : no
sep_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 2
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 sep mtrr pge mca cmov pat
pse36 mmx osfxsr
bogomips : 349.80
[7.3.] Module information (from /proc/modules):es1370
21340 0 (autoclean) (unused)
soundcore 2148 4 (autoclean) [es1370]
serial 18356 0 (autoclean)
[7.4.] SCSI information (from /proc/scsi/scsi) no scsi devices present
on the system
[7.5.] Other information that might be relevant to the problem
(please look in /proc and include all information that you
think to be relevant):PCI devices found:
Bus 0, device 0, function 0:
Host bridge: Intel 440BX - 82443BX Host (rev 2).
Medium devsel. Master Capable. Latency=64.
Prefetchable 32 bit memory at 0xe0000000 [0xe0000008].
Bus 0, device 1, function 0:
PCI bridge: Intel 440BX - 82443BX AGP (rev 2).
Medium devsel. Master Capable. Latency=64. Min Gnt=136.
Bus 0, device 7, function 0:
ISA bridge: Intel 82371AB PIIX4 ISA (rev 2).
Medium devsel. Fast back-to-back capable. Master Capable. No
bursts.
Bus 0, device 7, function 1:
IDE interface: Intel 82371AB PIIX4 IDE (rev 1).
Medium devsel. Fast back-to-back capable. Master Capable.
Latency=64.
I/O at 0xf000 [0xf001].
Bus 0, device 7, function 2:
USB Controller: Intel 82371AB PIIX4 USB (rev 1).
Medium devsel. Fast back-to-back capable. IRQ 10. Master
Capable. Latency=64.
I/O at 0xe000 [0xe001].
Bus 0, device 7, function 3:
Bridge: Intel 82371AB PIIX4 ACPI (rev 2).
Medium devsel. Fast back-to-back capable.
Bus 0, device 9, function 0:
Multimedia audio controller: Ensoniq AudioPCI (rev 1).
Slow devsel. IRQ 10. Master Capable. Latency=64. Min
Gnt=12.Max Lat=128.
I/O at 0xe400 [0xe401].
Bus 1, device 0, function 0:
VGA compatible controller: Intel Unknown device (rev 33).
Vendor id=8086. Device id=7800.
Medium devsel. Fast back-to-back capable. IRQ 11. Master
Capable. No bursts.
Prefetchable 32 bit memory at 0xe6000000 [0xe6000008].
Non-prefetchable 32 bit memory at 0xe5000000 [0xe5000000].
I attach the kernel configuration file to this message, so that you can
see whether something isn't ok in the configuration of the kernel.
I really hope this information will be helpfull to you. I thank you for
all work you do on Linux. It's a fine system.
Yours sincerely,
Maarten Wisse
[-- Attachment #2: kernelconf --]
[-- Type: text/plain, Size: 6686 bytes --]
#
# Automatically generated make config: don't edit
#
#
# Code maturity level options
#
# CONFIG_EXPERIMENTAL is not set
#
# Processor type and features
#
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
CONFIG_M686=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_TSC=y
CONFIG_X86_GOOD_APIC=y
CONFIG_1GB=y
# CONFIG_2GB is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_SMP is not set
#
# Loadable module support
#
CONFIG_MODULES=y
# CONFIG_MODVERSIONS is not set
CONFIG_KMOD=y
#
# General setup
#
CONFIG_NET=y
CONFIG_PCI=y
CONFIG_PCI_GOBIOS=y
# CONFIG_PCI_GODIRECT is not set
# CONFIG_PCI_GOANY is not set
CONFIG_PCI_BIOS=y
CONFIG_PCI_QUIRKS=y
CONFIG_PCI_OLD_PROC=y
# CONFIG_MCA is not set
# CONFIG_VISWS is not set
CONFIG_SYSVIPC=y
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_SYSCTL=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_MISC=y
CONFIG_PARPORT=m
CONFIG_PARPORT_PC=m
# CONFIG_PARPORT_OTHER is not set
# CONFIG_APM is not set
#
# Plug and Play support
#
# CONFIG_PNP is not set
#
# Block devices
#
CONFIG_BLK_DEV_FD=y
CONFIG_BLK_DEV_IDE=y
#
# Please see Documentation/ide.txt for help/info on IDE drives
#
# CONFIG_BLK_DEV_HD_IDE is not set
CONFIG_BLK_DEV_IDEDISK=y
CONFIG_BLK_DEV_IDECD=y
# CONFIG_BLK_DEV_IDETAPE is not set
# CONFIG_BLK_DEV_IDEFLOPPY is not set
# CONFIG_BLK_DEV_IDESCSI is not set
CONFIG_BLK_DEV_CMD640=y
# CONFIG_BLK_DEV_CMD640_ENHANCED is not set
CONFIG_BLK_DEV_RZ1000=y
CONFIG_BLK_DEV_IDEPCI=y
CONFIG_BLK_DEV_IDEDMA=y
# CONFIG_BLK_DEV_OFFBOARD is not set
CONFIG_IDEDMA_AUTO=y
# CONFIG_IDE_CHIPSETS is not set
#
# Additional Block Devices
#
# CONFIG_BLK_DEV_LOOP is not set
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_MD is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_BLK_DEV_DAC960 is not set
CONFIG_PARIDE_PARPORT=m
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_DEV_HD is not set
#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_NETLINK is not set
# CONFIG_FIREWALL is not set
# CONFIG_FILTER is not set
CONFIG_UNIX=y
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
# CONFIG_IP_PNP is not set
# CONFIG_IP_ROUTER is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_ALIAS is not set
# CONFIG_SYN_COOKIES is not set
#
# (it is safe to leave these untouched)
#
# CONFIG_INET_RARP is not set
# CONFIG_SKB_LARGE is not set
#
#
#
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
#
# SCSI support
#
# CONFIG_SCSI is not set
# CONFIG_SCSI_G_NCR5380_PORT is not set
# CONFIG_SCSI_G_NCR5380_MEM is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
CONFIG_DUMMY=y
# CONFIG_EQUALIZER is not set
# CONFIG_NET_SB1000 is not set
#
# Ethernet (10 or 100Mbit)
#
# CONFIG_NET_ETHERNET is not set
# CONFIG_FDDI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=m
#
# CCP compressors for PPP are only built as modules.
#
# CONFIG_SLIP is not set
# CONFIG_NET_RADIO is not set
#
# Token ring devices
#
# CONFIG_TR is not set
#
# Wan interfaces
#
# CONFIG_HOSTESS_SV11 is not set
# CONFIG_COSA is not set
# CONFIG_SEALEVEL_4021 is not set
# CONFIG_DLCI is not set
# CONFIG_WAN_DRIVERS is not set
#
# Amateur Radio support
#
# CONFIG_HAMRADIO is not set
#
# IrDA subsystem support
#
# CONFIG_IRDA is not set
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_SERIAL=m
# CONFIG_SERIAL_EXTENDED is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_UNIX98_PTYS is not set
CONFIG_PRINTER=m
CONFIG_PRINTER_READBACK=y
CONFIG_MOUSE=y
#
# Mice
#
# CONFIG_ATIXL_BUSMOUSE is not set
# CONFIG_BUSMOUSE is not set
# CONFIG_MS_BUSMOUSE is not set
CONFIG_PSMOUSE=y
# CONFIG_82C710_MOUSE is not set
# CONFIG_PC110_PAD is not set
# CONFIG_QIC02_TAPE is not set
# CONFIG_WATCHDOG is not set
# CONFIG_NVRAM is not set
# CONFIG_RTC is not set
#
# Video For Linux
#
# CONFIG_VIDEO_DEV is not set
#
# Joystick support
#
# CONFIG_JOYSTICK is not set
# CONFIG_DTLK is not set
#
# Ftape, the floppy tape device driver
#
# CONFIG_FTAPE is not set
# CONFIG_FT_NORMAL_DEBUG is not set
# CONFIG_FT_FULL_DEBUG is not set
# CONFIG_FT_NO_TRACE is not set
# CONFIG_FT_NO_TRACE_AT_ALL is not set
# CONFIG_FT_STD_FDC is not set
# CONFIG_FT_MACH2 is not set
# CONFIG_FT_PROBE_FC10 is not set
# CONFIG_FT_ALT_FDC is not set
#
# Filesystems
#
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_UMSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_MINIX_FS is not set
# CONFIG_NTFS_FS is not set
# CONFIG_HPFS_FS is not set
CONFIG_PROC_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_EXT2_FS=y
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
# CONFIG_CODA_FS is not set
# CONFIG_NFS_FS is not set
# CONFIG_SUNRPC is not set
# CONFIG_LOCKD is not set
# CONFIG_SMB_FS is not set
# CONFIG_NCP_FS is not set
#
# Partition Types
#
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MAC_PARTITION is not set
# CONFIG_SMD_DISKLABEL is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
CONFIG_NLS=y
#
# Native Language Support
#
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
CONFIG_NLS_ISO8859_1=m
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_ISO8859_9 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
#
# Console drivers
#
CONFIG_VGA_CONSOLE=y
# CONFIG_VIDEO_SELECT is not set
#
# Sound
#
CONFIG_SOUND=m
CONFIG_SOUND_ES1370=m
# CONFIG_SOUND_ES1371 is not set
# CONFIG_SOUND_SONICVIBES is not set
# CONFIG_SOUND_MSNDCLAS is not set
# CONFIG_SOUND_MSNDPIN is not set
# CONFIG_SOUND_OSS is not set
#
# Kernel hacking
#
# CONFIG_MAGIC_SYSRQ is not set
[-- Attachment #3: Card for Maarten Wisse --]
[-- Type: text/x-vcard, Size: 341 bytes --]
begin:vcard
n:Wisse;Maarten
tel;home:+31 183 631348
tel;work:+31 30 253 9409
x-mozilla-html:TRUE
url:www.homepages.hetnet.nl/~mwisse
org:Utrecht University;Philosophy of Religion
adr:;;Kasteleinstraat 11B;Gorinchem;;4204 AN;The Netherlands
version:2.1
email;internet:pmwisse@hetnet.nl
title:Drs.
x-mozilla-cpt:;0
fn:Maarten Wisse
end:vcard
^ permalink raw reply [relevance 35%]
* bug in glibc 2.1.2 new semaphore functions in libpthread?
@ 1999-08-22 15:09 62% ` Kevin Hendricks
1999-08-24 21:09 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Kevin Hendricks @ 1999-08-22 15:09 UTC (permalink / raw)
To: linuxppc-dev, Franz Sirl
Hi,
Has anyone tested the new semaphore functions in glibc 2.1.2 in libpthreads?
If I link the native threads version of the jdk with sem_wait@@GLIC_2.0,
sem_post@@GLIBC_2.0, etc, they work fine.
If I link the native threads version of the jdk with the new semaphore
functions sem_wait@@GLIBC_2.1, sem_post@@GLIBC_2.1 then nothing works at all.
I found this out because I had two binariies from the same source, one of which
works and the other doesn't and the only difference was that the first (working
one) was built under an earlier glibc 2.1 while the latter was built with
Franz's latest glibc 2.1.2.
Upon further investigation with nm I found that the only difference was in
which semaphore functions got linked in from libpthread.so.
If it matters, this is in a high signal environment (thread interrupts, thread
suspension for garabage collection, etc).
I had to drop back to glibc 2.1.1 and rebuild to get the
native_threads to start working again (so that they would link with the old
sem_* functions and not the new).
Has anyone really tested the new semaphore functions? Are they known to be
broken?
Any ideas here?
Thanks,
Kevin
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 62%]
* Re: bug in glibc 2.1.2 new semaphore functions in libpthread?
1999-08-22 15:09 62% ` bug in glibc 2.1.2 new semaphore functions in libpthread? Kevin Hendricks
@ 1999-08-24 21:09 64% ` Franz Sirl
0 siblings, 0 replies; 200+ results
From: Franz Sirl @ 1999-08-24 21:09 UTC (permalink / raw)
To: Kevin Hendricks, linuxppc-dev
Am Son, 22 Aug 1999 schrieb Kevin Hendricks:
>Hi,
>
>Has anyone tested the new semaphore functions in glibc 2.1.2 in libpthreads?
>
>If I link the native threads version of the jdk with sem_wait@@GLIC_2.0,
>sem_post@@GLIBC_2.0, etc, they work fine.
>
>If I link the native threads version of the jdk with the new semaphore
>functions sem_wait@@GLIBC_2.1, sem_post@@GLIBC_2.1 then nothing works at all.
>
>I found this out because I had two binariies from the same source, one of which
>works and the other doesn't and the only difference was that the first (working
>one) was built under an earlier glibc 2.1 while the latter was built with
>Franz's latest glibc 2.1.2.
>
>Upon further investigation with nm I found that the only difference was in
>which semaphore functions got linked in from libpthread.so.
>
>If it matters, this is in a high signal environment (thread interrupts, thread
>suspension for garabage collection, etc).
>
>I had to drop back to glibc 2.1.1 and rebuild to get the
>native_threads to start working again (so that they would link with the old
>sem_* functions and not the new).
>
>Has anyone really tested the new semaphore functions? Are they known to be
>broken?
>
>Any ideas here?
Kevin, the glibc-2.1.2 RPM's are work-in-progress. They generally work well for
me and others, but it may very well be that things are temporarily broken.
Please test the new 4a build. If your problem persists I'll forward it to the
glibc maintainers.
Franz.
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* bug in l2cr status display?
@ 1999-08-26 21:05 64% Michel Lanners
1999-08-27 8:24 64% ` Adrian Cox
0 siblings, 1 reply; 200+ results
From: Michel Lanners @ 1999-08-26 21:05 UTC (permalink / raw)
To: linuxppc-dev
Hi all,
While playing with the l2cr in order to set it manually after OF
booting, I've come across the following.
It seems that the effect of the L2CR[DO] bit isn't clear. In the 750
user manual, in the table describing l2cr, it says '... setting this
bit enables the caching of instructions'. This doesn't corrsspond to
the name of the register, nor to what I see with my G3 upgrade card: in
normal operation, L2CR[DO] isn't set, but it makes no sense to disable
instruction caching excpet for test purposes.
So, what's happening? Is the user manual wrong? In that case, we should
correct arch/ppc/kernel/ppc_htab.c accordingly.
Any Motorola engineer around? Others with better docs? FWIW, I checked
the 750 errata already... nothing.
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* bug in ioremap/map_page ?
@ 1999-08-27 6:04 56% Ryan Nielsen
0 siblings, 0 replies; 200+ results
From: Ryan Nielsen @ 1999-08-27 6:04 UTC (permalink / raw)
To: linuxppc-dev
Has anyone looked into this ?
this message is almost a year old and I have the same problem
with ioremap in modules.
Date: Sat, 26 Sep 1998 14:15:11 +0200 (MET DST)
From: Carsten Pluntke <su0289@sx2.hrz.uni-dortmund.de>
To: linux-ppc@meetpoint.mcu.motsps.com
Subject: [linux-ppc] Possible bug in arch/ppc/mm/init.c::map_page ?
Message-ID: <Pine.GSO.4.03.9809261404300.28905-100000@sx2.hrz.uni-dortmund.de>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-linux-ppc@meetpoint.mcu.motsps.com
Precedence: bulk
Hi,
I've found a strangeness when using ioremap() on an 8MB block of memory.
When mapping smaller blocks of memory everything works OK, but when a
block crosses a pgd boundary (e.g. from cc3fffff to cc400000) and the new
page has been allocated by map_page(), the kernel usually panics on access
of cc400000.
Tracking down I found out that the page fault (data access) panic only
appears if the new pgd entry is made up by map_page, when vmalloc()ing and
vfree()ing the same amount of memory (8MB) just before the ioremap(),
everything works fine.
-------------------8<---- arch/ppc/mm/init.c::map_page() ----------------
/* Use upper 10 bits of VA to index the first level map */
pd = (pmd_t *) (tsk->mm->pgd + (va >> PGDIR_SHIFT));
if (pmd_none(*pd)) {
#ifndef CONFIG_8xx
/*
* Need to allocate second-level table, but first
* check whether this address is already mapped by
* the BATs; if so, don't bother allocating the page.
*/
for (b = 0; b < 4; ++b) {
if (va >= bat_addrs[b].start
&& va <= bat_addrs[b].limit) {
/* XXX should check the phys address
matches */
return;
}
}
#endif /* CONFIG_8xx */
printk("First-level map for 0x%08lX\n",va);
pg = (pte_t *) MMU_get_page();
pmd_val(*pd) = (unsigned long) pg;
}
--------------------------------8<-------------------------------------
The 'printk' (last but four lines) is added by me to show where a new pgd
entry is created, and whenever it shows up with an address, accessing this
address (and the following) proves fatal. The debug line doesn't show up
when the memory area was used at least once using vmalloc().
I think that if this really is a bug it didn't show up because ioremap()
was normally used for small areas and it never had to put up a new pgd
entry.
Carsten
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 56%]
* Re: bug in l2cr status display?
1999-08-26 21:05 64% bug in l2cr status display? Michel Lanners
@ 1999-08-27 8:24 64% ` Adrian Cox
1999-08-27 18:07 54% ` Michel Lanners
0 siblings, 1 reply; 200+ results
From: Adrian Cox @ 1999-08-27 8:24 UTC (permalink / raw)
To: mlan; +Cc: linuxppc-dev
Michel Lanners wrote:
> It seems that the effect of the L2CR[DO] bit isn't clear. In the 750
> user manual, in the table describing l2cr, it says '... setting this
> bit enables the caching of instructions'. This doesn't corrsspond to
> the name of the register, nor to what I see with my G3 upgrade card: in
> normal operation, L2CR[DO] isn't set, but it makes no sense to disable
> instruction caching excpet for test purposes.
>
> So, what's happening? Is the user manual wrong? In that case, we should
> correct arch/ppc/kernel/ppc_htab.c accordingly.
I think I posted a patch for this a while ago, but I've sort of lost
track. Basically, somebody in Motorola's documentation department
couldn't tell one from zero. In normal use the bit should be clear.
Hopefully somebody with write access will get the correct form into CVS.
They also got the Branch Target Instruction Cache the wrong way round. I
just hope that all firmware developers for G3 machines noticed these
mistakes.
> Any Motorola engineer around? Others with better docs? FWIW, I checked
> the 750 errata already... nothing.
It's in the errata to the manual, not the errata to the chip.
- Adrian Cox, AG Electronics
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: bug in l2cr status display?
@ 1999-08-27 13:09 64% Marc Dietrich
1999-08-27 20:28 64% ` Benjamin Herrenschmidt
0 siblings, 1 reply; 200+ results
From: Marc Dietrich @ 1999-08-27 13:09 UTC (permalink / raw)
To: linuxppc-dev
Hello out there,
I've downloaded the 750 PDF Manuel and to Bit #9 (L2DO) it says:
"L2 Data-only. Setting this bit enables data-only operation in the L2
cache..." ^^^^
So setting this bit disables instruction caching therefore it should'nt be
set on bootup.
It seems to me, that the L2CR programming is implemented but disabled in
current kernel version. The L2CR=xxxxxxx doesn't work for me.
By the way, it seems that Motola (or IBM) uses different cache chips on
the 750 CPU - one with 0.5 and one with 1.0 ns timings. 0.5 ns are the
common used chips while mine has a 1.0ns timing. This causes the
PowerLogix Cache Control to crash my Mac. Has anyone expiriances on this?
How has this been to recocnice in the kernel boot-up?
Marc
On Thu, 26 Aug 1999, Michel Lanners wrote:
>
> Hi all,
>
> While playing with the l2cr in order to set it manually after OF
> booting, I've come across the following.
>
> It seems that the effect of the L2CR[DO] bit isn't clear. In the 750
> user manual, in the table describing l2cr, it says '... setting this
> bit enables the caching of instructions'. This doesn't corrsspond to
> the name of the register, nor to what I see with my G3 upgrade card: in
> normal operation, L2CR[DO] isn't set, but it makes no sense to disable
> instruction caching excpet for test purposes.
>
> So, what's happening? Is the user manual wrong? In that case, we should
> correct arch/ppc/kernel/ppc_htab.c accordingly.
>
> Any Motorola engineer around? Others with better docs? FWIW, I checked
> the 750 errata already... nothing.
>
> Michel
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Re: bug in l2cr status display?
1999-08-27 8:24 64% ` Adrian Cox
@ 1999-08-27 18:07 54% ` Michel Lanners
0 siblings, 0 replies; 200+ results
From: Michel Lanners @ 1999-08-27 18:07 UTC (permalink / raw)
To: linuxppc-dev, Paul.Mackerras
[-- Attachment #1: Type: TEXT/plain, Size: 3092 bytes --]
Hi all,
On 27 Aug, this message from Adrian Cox echoed through cyberspace:
> Michel Lanners wrote:
>> It seems that the effect of the L2CR[DO] bit isn't clear.
>
> I think I posted a patch for this a while ago, but I've sort of lost
> track. Basically, somebody in Motorola's documentation department
> couldn't tell one from zero. In normal use the bit should be clear.
> Hopefully somebody with write access will get the correct form into CVS.
Ok, so I understood it the right way.
Paul, below is a patch that fixes this, adds a few more bit
interpretations, and tries to clean up a bit the code and the display.
I've checked, even if everything is printed, we're staying within the
temp buffer ;-).
On 27 Aug, this message from Marc Dietrich echoed through cyberspace:
> I downloaded the 750 PDF Manuel and to Bit #9 (L2DO) it says:
> "L2 Data-only. Setting this bit enables data-only operation in the L2
> cache..." ^^^^
Ok, found it. The above is in chapter 2; the less-verbose table in
chapter 9 has it wrong.
> So setting this bit disables instruction caching therefore it should'nt be
> set on bootup.
Yep.
> It seems to me, that the L2CR programming is implemented but disabled in
> current kernel version. The L2CR=xxxxxxx doesn't work for me.
The coammnd-line option doesn't work; there is a function for parsing
this option, but it is never called. However, there is
/proc/sys/kernel/l2cr, which is readable _and_ writable. So
echo 0 > /proc/sys/kernel/l2cr disables the L2.
> By the way, it seems that Motola (or IBM) uses different cache chips on
> the 750 CPU - one with 0.5 and one with 1.0 ns timings. 0.5 ns are the
> common used chips while mine has a 1.0ns timing. This causes the
> PowerLogix Cache Control to crash my Mac. Has anyone expiriances on this?
> How has this been to recocnice in the kernel boot-up?
There is no way I know of for autodetecting any attribute of the L2
cache (except the size, maybe). All values have to be set based on some
non-automatic identification, i.e mostly manually.
On 27 Aug, this message from Benjamin Herrenschmidt echoed through cyberspace:
> Don't forget the inverted numbering of bits usually used by Moto.
Yeah; that annoyed me as well; but it is pretty obvious if you cat
/proc/sys/kernel/l2cr.
> Also, you may want to set the invalidate bit when setting l2cr. Note also
> that the _set_l2cr routine in the kernel alrady handles some of the bits.
I learned that the lock-up way ;-) Shouldn't _set_l2cr() check whether
we're switching the cache on, and if so, do the invalidate for us?
> BTW. Paul, did you merge the latest code from PowerLogix I sent you a
> couple of weeks ago ?
2.2.12 contains a patch to this code.
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
[-- Attachment #2: l2cr.patch --]
[-- Type: TEXT/plain, Size: 1768 bytes --]
--- linux-2.2.12/arch/ppc/kernel/ppc_htab.c Thu Aug 26 21:51:03 1999
+++ linux-work/arch/ppc/kernel/ppc_htab.c Fri Aug 27 19:44:57 1999
@@ -595,19 +595,24 @@
if (!first)
*p++ = '\t';
val = _get_L2CR();
- p += sprintf(p, "%08x: ", val);
- p += sprintf(p, " %s",
- (val&0x80000000)?"enabled":"disabled");
- p += sprintf(p,",%sparity",(val&0x40000000)?"":"no ");
- p += sprintf(p, ",%s", sizestrings[(val >> 28) & 3]);
- p += sprintf(p, ",%s", clockstrings[(val >> 25) & 7]);
- p += sprintf(p, ",%s", typestrings[(val >> 23) & 0x2]);
- p += sprintf(p,"%s",(val>>22)&1?"":",data only");
- p += sprintf(p,"%s",(val>>20)&1?",ZZ enabled":"");
- p += sprintf(p,",%s",(val>>19)&1?"write-through":"copy-back");
- p += sprintf(p,",%sns hold", holdstrings[(val>>16)&3]);
+ p += sprintf(p, "0x%08x: ", val);
+ p += sprintf(p, " %s", (val >> 31) & 1 ? "enabled" :
+ "disabled");
+ p += sprintf(p, ", %sparity", (val>>30)&1 ? "" : "no ");
+ p += sprintf(p, ", %s", sizestrings[(val >> 28) & 3]);
+ p += sprintf(p, ", %s", clockstrings[(val >> 25) & 7]);
+ p += sprintf(p, ", %s", typestrings[(val >> 23) & 2]);
+ p += sprintf(p, "%s", (val>>22)&1 ? ", data only" : "");
+ p += sprintf(p, "%s", (val>>20)&1 ? ", ZZ enabled": "");
+ p += sprintf(p, ", %s", (val>>19)&1 ? "write-through" :
+ "copy-back");
+ p += sprintf(p, "%s", (val>>18)&1 ? ", testing" : "");
+ p += sprintf(p, ", %sns hold",holdstrings[(val>>16)&3]);
+ p += sprintf(p, "%s", (val>>15)&1 ? ", DLL slow" : "");
+ p += sprintf(p, "%s", (val>>14)&1 ? ", diff clock" :"");
+ p += sprintf(p, "%s", (val>>13)&1 ? ", DLL bypass" :"");
- p += sprintf(p,"\n");
+ p += sprintf(p, "\n");
len = strlen(buf);
if (len > left)
^ permalink raw reply [relevance 54%]
* Re: bug in l2cr status display?
1999-08-27 13:09 64% bug in l2cr status display? Marc Dietrich
@ 1999-08-27 20:28 64% ` Benjamin Herrenschmidt
0 siblings, 0 replies; 200+ results
From: Benjamin Herrenschmidt @ 1999-08-27 20:28 UTC (permalink / raw)
To: Marc Dietrich, linuxppc-dev
On Fri, Aug 27, 1999, Marc Dietrich <Marc.Dietrich@hrz.uni-giessen.de> wrote:
>It seems to me, that the L2CR programming is implemented but disabled in
>current kernel version. The L2CR=xxxxxxx doesn't work for me.
We didn't add the call to setup_l2cr when merging 2.2 with Linus to avoid
changing non-arch stuffs late during the merge, things were already
complicated enough. In the meantime, I used a different solution via a
property stuck by BootX in the device tree, but this is really broken in
several ways, and we should put back the l2cr=xxxx option once for all now.
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
[[ This message was sent via the linuxppc-dev mailing list. Replies are ]]
[[ not forced back to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting. ]]
^ permalink raw reply [relevance 64%]
* Possible Bug in XFree3.3.5
@ 1999-09-04 0:13 64% jeramy b smith
1999-09-04 6:33 64% ` Tom Rini
0 siblings, 1 reply; 200+ results
From: jeramy b smith @ 1999-09-04 0:13 UTC (permalink / raw)
To: linuxppc-dev
I downloaded the 3.3.5 rpms from Tom's directory and installed them. I have a
2meg ati rage IIc. Before upgrading the rpm, I was using vmode 18 and cmode 16
and the same for my X resolution (1152x864@16bpp). However, trying to startx
with this configuration would crash.
Changing the depth in to 8bpp in XF86config solved this. I tried setting the
the resolution to 800x600 and bumping the colors up to 16bpp. XFB initializes
the accel code, reports the font and pixmap caches are disabled. Then I get
the BBdebug message that it is setting up gnome support. I catch the signal
11. blackbox then tells me:
X Error of failed request: 16 Badlength (poly request too large or internal
Xlib length error
Major/minor opcode of failed request: 72 / 0
Resource id in failed request: 0x8000014
I tried Xconfigurator to rule out window manager/extraneous errors and
Xconfigurator would promptly quit when it would try to test these modes.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: Possible Bug in XFree3.3.5
1999-09-04 0:13 64% Possible Bug in XFree3.3.5 jeramy b smith
@ 1999-09-04 6:33 64% ` Tom Rini
0 siblings, 0 replies; 200+ results
From: Tom Rini @ 1999-09-04 6:33 UTC (permalink / raw)
To: jeramy b smith; +Cc: linuxppc-dev
On 3 Sep 1999, jeramy b smith wrote:
> I downloaded the 3.3.5 rpms from Tom's directory and installed them. I have a
> 2meg ati rage IIc. Before upgrading the rpm, I was using vmode 18 and cmode 16
> and the same for my X resolution (1152x864@16bpp). However, trying to startx
> with this configuration would crash.
Well shoot. I hadn't made an announcement yet for a reason (newer, -1a
locally :))
> Changing the depth in to 8bpp in XF86config solved this. I tried setting the
> the resolution to 800x600 and bumping the colors up to 16bpp. XFB initializes
> the accel code, reports the font and pixmap caches are disabled. Then I get
> the BBdebug message that it is setting up gnome support. I catch the signal
> 11. blackbox then tells me:
>
> X Error of failed request: 16 Badlength (poly request too large or internal
> Xlib length error
> Major/minor opcode of failed request: 72 / 0
> Resource id in failed request: 0x8000014
Odd. I wonder if all of this has to do w/ the 15/16 bit fix... Hmm..
---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Re: Possible Bug in XFree3.3.5]
@ 1999-09-04 6:56 64% jeramy b smith
1999-09-04 7:13 64% ` Tom Rini
0 siblings, 1 reply; 200+ results
From: jeramy b smith @ 1999-09-04 6:56 UTC (permalink / raw)
To: Tom Rini; +Cc: linuxppc-dev
Tom Rini <trini@kernel.crashing.org> wrote:
>Well shoot. I hadn't made an announcement yet for a reason
>(newer, -1a locally :))
Unfortunately the interim linuxppc.org page had a link to your directory for
the 3.3.4 release. Since the interim page is the old page, I went there to see
if you had 3.3.5.
>I wonder if all of this has to do w/ the 15/16 bit fix... Hmm..---Tom >Rini
(TR1265)<br>http://gate.crashing.org/~trini/
The first time I ran the new setup, it gave me a non-reproducible error in the
same place that is now in my buffer history. I think it might take a reboot to
get the original eror, not sure. There was a method or variable mach64?????blt
(not sure) that had an illegal size or number. Vague, yes.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Re: Possible Bug in XFree3.3.5]
1999-09-04 6:56 64% [Re: Possible Bug in XFree3.3.5] jeramy b smith
@ 1999-09-04 7:13 64% ` Tom Rini
0 siblings, 0 replies; 200+ results
From: Tom Rini @ 1999-09-04 7:13 UTC (permalink / raw)
To: jeramy b smith; +Cc: linuxppc-dev
On 4 Sep 1999, jeramy b smith wrote:
> Tom Rini <trini@kernel.crashing.org> wrote:
> >Well shoot. I hadn't made an announcement yet for a reason
> >(newer, -1a locally :))
>
> Unfortunately the interim linuxppc.org page had a link to your directory for
> the 3.3.4 release. Since the interim page is the old page, I went there to see
> if you had 3.3.5.
Yeah, oh well.
> >I wonder if all of this has to do w/ the 15/16 bit fix... Hmm..---Tom >Rini
> (TR1265)<br>http://gate.crashing.org/~trini/
>
> The first time I ran the new setup, it gave me a non-reproducible error in the
> same place that is now in my buffer history. I think it might take a reboot to
> get the original eror, not sure. There was a method or variable mach64?????blt
> (not sure) that had an illegal size or number. Vague, yes.
But is 16 now working fine??
---
Tom Rini (TR1265)
http://gate.crashing.org/~trini/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* bug glibc strlen() or tcl8.2
@ 1999-09-09 14:42 50% Maurice DIAMANTINI
1999-09-09 17:35 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Maurice DIAMANTINI @ 1999-09-09 14:42 UTC (permalink / raw)
To: linuxppc-dev, Maurice DIAMANTINI
Hello
I'm unable to execute tcl8.2 on linuxppc R5. Although it compile and
run very simply on intel box, solaris, ... but not on linuxppc
The programm compils OK, but get a core dump at the first execution
of a tcl command (in fact at the "make test")
I've tried on the following environment :
- PM7500 + update G3
- kernel 2.2.6
and:
- PowerMac Blue G3 - 400MHz - rev 1
- kernel linux 2.2.10 provide by rshaw
then:
- PowerMac Blue G3 - 400MHz - rev 1
- kernel linux 2.2.10 provide by rshaw
- with gcc-2.95.1 (+ the last binutils) built with the magic
"make bootstrap" and installed into a separate directory.
then:
- PowerMac Blue G3 - 400MHz - rev 1
- kernel linux 2.2.10 provide by rshaw
- with gcc-2.95.1 (+ the last binutils) built with the magic
"make bootstrap" and installed into a separate directory.
- upgrade to glibc-2.1.2-4a.ppc.rpm
########################################################################
Here ara my test which gdb and some fprintf added to the file
tclResult.c:
When I run tcltest:
----------------------
./tcltest /home/diam/local/src/tcl/unix/../tests/all.tcl
fprint before strlen
fprint sizeof(tmpArgList)=12
make: *** [test] Error 139
----------------------
gdb tcltest core
GNU gdb 4.17.0.11 with Linux support
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB. Type "show warranty" for details.
This GDB was configured as "ppc-unknown-linux"...
Core was generated by `./tcltest /home/diam/local/src/tcl/unix/../tests/all.tcl'.
Program terminated with signal 11, Erreur de segmentation.
Reading symbols from /home/diam/tmp/compil/tcl_linuxppc_build/libtcl8.2.so...done.
Reading symbols from /lib/libdl.so.2...done.
Reading symbols from /lib/libm.so.6...done.
Reading symbols from /lib/libc.so.6...done.
Reading symbols from /lib/ld.so.1...done.
#0 0x161ac14 in Letext () at soinit.c:59
soinit.c:59: Aucun fichier ou répertoire de ce type.
(gdb)
----------------------
(gdb) backtrace
#0 0x161ac14 in Letext () at soinit.c:59
#1 0x17b2688 in Tcl_AppendResultVA ()
#2 0x17b2824 in Tcl_AppendResult ()
#3 0x17bfef4 in TclpOpenFileChannel ()
#4 0x179f49c in Tcl_OpenFileChannel ()
#5 0x179e088 in Tcl_OpenObjCmd ()
#6 0x1787f7c in TclExecuteByteCode ()
#7 0x176b90c in Tcl_EvalObjEx ()
#8 0x17b06b0 in TclObjInterpProc ()
#9 0x1787f7c in TclExecuteByteCode ()
#10 0x176b90c in Tcl_EvalObjEx ()
#11 0x17b06b0 in TclObjInterpProc ()
#12 0x1787f7c in TclExecuteByteCode ()
#13 0x176b90c in Tcl_EvalObjEx ()
#14 0x17b06b0 in TclObjInterpProc ()
#15 0x17a9528 in EvalObjv ()
#16 0x17a93b0 in EvalObjv ()
#17 0x17a9ce0 in Tcl_EvalEx ()
#18 0x17a9f10 in Tcl_Eval ()
#19 0x176d498 in Tcl_GlobalEval ()
#20 0x17ad80c in Tcl_PkgRequireEx ()
#21 0x17ad5f0 in Tcl_PkgRequire ()
#22 0x17ae0f4 in Tcl_PackageObjCmd ()
#23 0x1787f7c in TclExecuteByteCode ()
#24 0x176b90c in Tcl_EvalObjEx ()
#25 0x17725a0 in Tcl_IfObjCmd ()
#26 0x17a9528 in EvalObjv ()
#27 0x17a9ce0 in Tcl_EvalEx ()
#28 0x179f158 in Tcl_EvalFile ()
#29 0x17a2718 in Tcl_Main ()
#30 0x1802ea0 in main ()
#31 0x15dc3bc in Letext () at ../sysdeps/powerpc/elf/libc-start.c:106
(gdb)
----------------
Note that the previous glibc (firt release od linuxppc-R5) give:
(gdb) backtrace
#0 0x158e94c in strlen () at soinit.c:59
#1 0x17b25d0 in Tcl_AppendResultVA ()
#...
#30 0x1802ea0 in main ()
#31 0x15507d4 in __libc_start_main () at ../sysdeps/powerpc/elf/libc-start.c:106
########################################################################
In file tclResult.c:
void
Tcl_AppendResultVA (interp, argList)
Tcl_Interp *interp; /* Interpreter with which to associate the
* return value. */
va_list argList; /* Variable argument list. */
{
Interp *iPtr = (Interp *) interp;
va_list tmpArgList;
char *string;
int newSpace;
/*
* If the string result is empty, move the object result to the
* string result, then reset the object result.
*/
if (*(iPtr->result) == 0) {
Tcl_SetResult((Tcl_Interp *) iPtr,
TclGetString(Tcl_GetObjResult((Tcl_Interp *) iPtr)),
TCL_VOLATILE);
}
/*
* Scan through all the arguments to see how much space is needed.
*/
memcpy ((VOID *) &tmpArgList, (VOID *) &argList, sizeof (tmpArgList));
newSpace = 0;
while (1) {
string = va_arg(tmpArgList, char *);
if (string == NULL) {
// diam :
fprintf (stderr, "fprint before break\n");
break;
}
////////////////////////////////////////////////////////////////
//
// diam : VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
fprintf (stderr, "fprint before strlen\n");
// diam :
fprintf (stderr, "fprint sizeof(tmpArgList)=%d\n",
sizeof (tmpArgList));
newSpace += strlen(string);
// diam :
fprintf (stderr, "fprint after strlenstrlen\n");
//
////////////////////////////////////////////////////////////////
}
....
}
########################################################################
--
Maurice DIAMANTINI | Ecole Nationale Superieure de Techniques Avancees
mailto:diam@ensta.fr | 32 Boulevard Victor 75739 PARIS Cedex 15 - France
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 50%]
* Re: bug glibc strlen() or tcl8.2
1999-09-09 14:42 50% bug glibc strlen() or tcl8.2 Maurice DIAMANTINI
@ 1999-09-09 17:35 64% ` Franz Sirl
1999-09-10 14:31 59% ` Maurice DIAMANTINI
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 1999-09-09 17:35 UTC (permalink / raw)
To: Maurice DIAMANTINI; +Cc: linuxppc-dev, Maurice DIAMANTINI
At 16:42 09.09.99 , Maurice DIAMANTINI wrote:
>Hello
>
>I'm unable to execute tcl8.2 on linuxppc R5. Although it compile and
>run very simply on intel box, solaris, ... but not on linuxppc
>
>
>The programm compils OK, but get a core dump at the first execution
>of a tcl command (in fact at the "make test")
[...]
> memcpy ((VOID *) &tmpArgList, (VOID *) &argList, sizeof (tmpArgList));
^^^^^^^^
This is unportable in combination with va_list. Try:
__va_copy (tmpArgList, argList);
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: bug glibc strlen() or tcl8.2
1999-09-09 17:35 64% ` Franz Sirl
@ 1999-09-10 14:31 59% ` Maurice DIAMANTINI
1999-09-10 18:19 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Maurice DIAMANTINI @ 1999-09-10 14:31 UTC (permalink / raw)
To: Franz Sirl, linuxppc-dev; +Cc: Maurice DIAMANTINI
Vous disiez:
>
> >I'm unable to execute tcl8.2 on linuxppc R5. Although it compile and
> >and run very simply on intel box, solaris, ... but not on linuxppc
> > ...
> >The programm compils OK, but get a core dump at the first execution
> >of a tcl command (in fact at the "make test")
> ...
> > memcpy ((VOID *) &tmpArgList, (VOID *) &argList, sizeof \
> (tmpArgList));
> ^^^^^^^^
> This is unportable in combination with va_list. Try:
> __va_copy (tmpArgList, argList);
Danke Franz,
But when I modify the code (from the true tcl distrib):
(I do'nt thes function which aren't part of the tcl distrib.
// string = va_arg(tmpArgList, char *);
string = __va_arg(tmpArgList, argList);
then "make clean" then "make test" but I get:
cc -c -O -D__NO_STRING_INLINES -D__NO_MATH_INLINES -fPIC
-I/home/diam/local/src/tcl/unix/../generic
-I/home/diam/local/src/tcl/unix -DHAVE_UNISTD_H=1 -DHAVE_LIMITS_H=1
-DHAVE_GETCWD=1 -DHAVE_OPENDIR=1 -DHAVE_STRSTR=1 -DHAVE_STRTOL=1
-DHAVE_TMPNAM=1 -DHAVE_WAITPID=1 -DHAVE_UNISTD_H=1
-DHAVE_SYS_PARAM_H=1 -DUSE_TERMIOS=1 -DHAVE_SYS_TIME_H=1
-DTIME_WITH_SYS_TIME=1 -DHAVE_TM_ZONE=1 -DHAVE_TM_GMTOFF=1
-DHAVE_TIMEZONE_VAR=1 -DHAVE_ST_BLKSIZE=1 -DSTDC_HEADERS=1
-DNEED_MATHERR=1 -DRETSIGTYPE=void -D__CHAR_UNSIGNED__=1
-DHAVE_SIGNED_CHAR=1 -DHAVE_SYS_IOCTL_H=1
-DTCL_SHLIB_EXT=\".so\"
/home/diam/local/src/tcl/unix/../generic/tclResult.c
/home/diam/local/src/tcl/unix/../generic/tclResult.c: \
In function `Tcl_AppendResultVA':
/home/diam/local/src/tcl/unix/../generic/tclResult.c:488:\
incompatible types in assignment
make: *** [tclResult.o] Error 1
Sorry but I'm not very clever in system! I just need to be able
to compil a standard distrib for tcl...
Anybody there has tried to compil tcl/tk last version?
(available from http://www.scriptics.com/products/tcltk/8.2.html)
When I read this html page :
Supported Platforms
Tcl/Tk 8.2 is compatible with most releases of the
following operating systems:
Windows 95 and 98
Windows NT
Solaris and SunOS
Linux
HP-UX
SGI
IRIX
Digital Unix
AIX
SCO Unix
NetBSD, FreeBSD, BSDi
Most other Unix-like operating systems
Macintosh (68K and Power Mac)
but not linuppc :-((
--
Maurice DIAMANTINI | Ecole Nationale Superieure de Techniques Avancees
mailto:diam@ensta.fr | 32 Boulevard Victor 75739 PARIS Cedex 15 - France
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 59%]
* controlfb.c bug in VRAM bank2 check if bank1
@ 1999-09-10 15:55 61% Lou Langholtz
1999-09-10 17:08 64% ` Lou Langholtz
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Lou Langholtz @ 1999-09-10 15:55 UTC (permalink / raw)
To: linuxppc-dev
I've posted before about this problem but to a different audience. As
I'm hoping to get this resolved (fixed) though in the main source tree
but don't have the chance to test this entirely myself I'm resending
here hoping someone else can test things out...
After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
2MB were still being recognized (despite having just added the 2MB to
total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
2.2.12 and made the following changes to get all 4MB VRAM recognized:
diff controlfb.c.orig controlfb.c
714,719c714,719
< out_8(&p->frame_buffer[0x600000], 0xa5);
< out_8(&p->frame_buffer[0x600001], 0x38);
< asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x600000])
: "memory" );
< bank2 = (in_8(&p->frame_buffer[0x600000]) == 0xa5)
< && (in_8(&p->frame_buffer[0x600001]) == 0x38);
<
---
> out_8(&p->frame_buffer[0x200000], 0xa5);
> out_8(&p->frame_buffer[0x200001], 0x38);
> asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x200000])
: "memory" );
> bank2 = (in_8(&p->frame_buffer[0x200000]) == 0xa5)
> && (in_8(&p->frame_buffer[0x200001]) == 0x38);
>
720a721
> printk(KERN_INFO "Total VRAM = %dMB\n", (int) (p->total_vram / 1024 /
1024));
724,725c725,726
< p->frame_buffer += 0x600000;
< p->frame_buffer_phys += 0x600000;
---
> p->frame_buffer += 0x200000;
> p->frame_buffer_phys += 0x200000;
What I've heard though is that bank2 is indeed found at 0x600000 at
least when bank1 is not there. That seems pretty strange to me but this
info was from a reputable source. If I had the time I'd just add some
code to check in 1MB increments to confirm this and try rebooting with
various VRAM cards in and figure out exactly where things are
recognized. Unfortunately I don't have the time and as the above changes
makes 4MB VRAM work now that's good enough for me. But it'd be a shame
if this didn't get fixed once and for all for everyone with the control
graphics card found on PowerMac 7500's (and perhaps some others too).
So hopefully someone else on this list has a spare 7500 to check this
out on and get the fix into the main tree.
Cheers ;-)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 61%]
* [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
@ 1999-09-10 16:51 73% Lou Langholtz
0 siblings, 0 replies; 200+ results
From: Lou Langholtz @ 1999-09-10 16:51 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 491 bytes --]
I just posted this yesturday to the newsgroup and someone pointed out
that this list has discussed this problem before. After digging through
the archives it seems this issue is still unresolved but that a lot of
changes have been going into the 2.3 kernel that may improve this
situation. In the meantime, I'm hoping then someone can point out what
the difficulties are for fixing this and where I'd have to look.
Alternatively, tell me where a patch already exists for this ;-)
Thanks!!!
[-- Attachment #2: Type: message/rfc822, Size: 3548 bytes --]
From: Lou Langholtz <ldl@chpc.utah.edu>
Cc: paulus@cs.anu.edu.au
Subject: Bug: 2.2.12 still hangs PPC after some PPP activity
Date: Thu, 09 Sep 1999 20:23:18 -0600
Message-ID: <37D86B96.84E580A6@chpc.utah.edu>
Hoping someone can help with this bug...
I just recently compiled the 2.2.12 kernel on my LinuxPPC 1999 OS base
and still find the system hanging sometimes after some PPP activity. It
doesn't seem to happen as easily as earlier kernels but it's still
happening. This last time I was doing some telnet activity so it's
gotten a lot harder for me to believe Netscape does anything more than
tweak the problem (despite what others have reported about Netscape but
perhaps that a similar but seperate bug).
My system is a PowerMac 7500/100 with a 28.8 US Robotics modem. After a
few days my PPP connection drops from what I believe are hardware
problems at my ISP's end. I then restart the PPP connection using netcfg
and get back to work. Ussually after about three reconnects the next
time my PPP connection hoses, the system itself hangs shortly
there-after. As in nothing works, moves, lights up. Can't even switch
virtual console or see any of the keyboard LEDs light up. After I reboot
the system, there's no indication of what caused the hang in the
messages file nor would I suspect anything would have logged a problem
since its getting hung rather than crashing. I've tried with everything
I needed compiled into the kernel and I've tried kernels where most of
what I needed in my kernel that could get built as a module got built as
such. Nothing's helped but 2.2.12 doesn't seem as quick to get into this
hung state.
No one I know using Linux on an Intel box has had this sort of problem
so it would seem something specific to the PowerPC specific code and I'd
guess the bug's in the serial driver or the ppp driver except there
doesn't seem to be any PPC specific code in either of these. I tried
compiling with the SysReq hot key functionality but that didn't seem to
be supported properly for the PowerPC.
If anyone knows of a source patch to fix this, please pass it a long. If
anyone has any better ideas where this bug might be, please point those
kernel files out. If anyone just has some pretty good ideas for how to
debug the kernel code for this problem, even pass that on.
Thanks!
^ permalink raw reply [relevance 73%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-10 15:55 61% controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
@ 1999-09-10 17:08 64% ` Lou Langholtz
1999-09-10 18:33 64% ` Michel Lanners
1999-09-11 10:51 64% ` Brad Boyer
2 siblings, 0 replies; 200+ results
From: Lou Langholtz @ 1999-09-10 17:08 UTC (permalink / raw)
To: linuxppc-dev
Someone requested a re-post of the diff I'm using to get 4MB VRAM suport
using the "-u" option to diff...
diff -u linux/drivers/video/controlfb.c.orig
linux/drivers/video/controlfb.c
--- linux/drivers/video/controlfb.c.orig Mon Aug 9 13:04:57 1999
+++ linux/drivers/video/controlfb.c Wed Sep 1 12:58:19 1999
@@ -711,18 +711,19 @@
asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0]) : "memory"
);
bank1 = (in_8(&p->frame_buffer[0]) == 0x5a) && (in_8(&p->frame_buffer[1])
== 0xc7);
- out_8(&p->frame_buffer[0x600000], 0xa5);
- out_8(&p->frame_buffer[0x600001], 0x38);
- asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x600000]) :
"memory" );
- bank2 = (in_8(&p->frame_buffer[0x600000]) == 0xa5)
- && (in_8(&p->frame_buffer[0x600001]) == 0x38);
-
+ out_8(&p->frame_buffer[0x200000], 0xa5);
+ out_8(&p->frame_buffer[0x200001], 0x38);
+ asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x200000]) :
"memory" );
+ bank2 = (in_8(&p->frame_buffer[0x200000]) == 0xa5)
+ && (in_8(&p->frame_buffer[0x200001]) == 0x38);
p->total_vram = (bank1 + bank2) * 0x200000;
+ printk(KERN_INFO "Total VRAM = %dMB\n", (int) (p->total_vram / 1024 /
1024));
/* If we don't have bank 1 installed, we hope we have bank 2 :-) */
p->control_use_bank2 = !bank1;
if (p->control_use_bank2) {
- p->frame_buffer += 0x600000;
- p->frame_buffer_phys += 0x600000;
+ p->frame_buffer += 0x200000;
+ p->frame_buffer_phys += 0x200000;
}
init_control(p);
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: bug glibc strlen() or tcl8.2
1999-09-10 14:31 59% ` Maurice DIAMANTINI
@ 1999-09-10 18:19 64% ` Franz Sirl
0 siblings, 0 replies; 200+ results
From: Franz Sirl @ 1999-09-10 18:19 UTC (permalink / raw)
To: Maurice DIAMANTINI; +Cc: linuxppc-dev
At 16:31 10.09.99 , Maurice DIAMANTINI wrote:
> Vous disiez:
> >
> > >I'm unable to execute tcl8.2 on linuxppc R5. Although it compile and
> > >and run very simply on intel box, solaris, ... but not on linuxppc
> > > ...
> > >The programm compils OK, but get a core dump at the first execution
> > >of a tcl command (in fact at the "make test")
> > ...
> > > memcpy ((VOID *) &tmpArgList, (VOID *) &argList, sizeof \
> > (tmpArgList));
> > ^^^^^^^^
> > This is unportable in combination with va_list. Try:
> > __va_copy (tmpArgList, argList);
>
> Danke Franz,
>
> But when I modify the code (from the true tcl distrib):
> (I do'nt thes function which aren't part of the tcl distrib.
>
> // string = va_arg(tmpArgList, char *);
> string = __va_arg(tmpArgList, argList);
??? I didn't tell you to do that. I meant: Replace the "memcpy" line in the
source with the "__va_copy" line I sent you.
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-10 15:55 61% controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-09-10 17:08 64% ` Lou Langholtz
@ 1999-09-10 18:33 64% ` Michel Lanners
1999-09-12 16:58 64% ` Lou Langholtz
1999-10-12 6:49 64% ` Lou Langholtz
1999-09-11 10:51 64% ` Brad Boyer
2 siblings, 2 replies; 200+ results
From: Michel Lanners @ 1999-09-10 18:33 UTC (permalink / raw)
To: ldl; +Cc: linuxppc-dev
On 10 Sep, this message from Lou Langholtz echoed through cyberspace:
> After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> 2MB were still being recognized (despite having just added the 2MB to
> total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> 2.2.12 and made the following changes to get all 4MB VRAM recognized:
> < out_8(&p->frame_buffer[0x600000], 0xa5);
> < out_8(&p->frame_buffer[0x600001], 0x38);
> ---
>> out_8(&p->frame_buffer[0x200000], 0xa5);
>> out_8(&p->frame_buffer[0x200001], 0x38);
Hmm, if I remember right, there have been half a dozen patch pairs that
changed 0x600000 to 0x200000 and back over the years ;-)
I guess it's time to clear thgis up once and for all. By the way, I do
have 4 MB of VRAM, and all of it is detected with the current version
of controlfb.....
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-11 10:51 64% ` Brad Boyer
@ 1999-09-10 20:13 64% ` Daniel Jacobowitz
1999-09-11 9:23 64% ` Benjamin Herrenschmidt
0 siblings, 1 reply; 200+ results
From: Daniel Jacobowitz @ 1999-09-10 20:13 UTC (permalink / raw)
To: linuxppc-dev
On Sat, Sep 11, 1999 at 03:51:25AM -0700, Brad Boyer wrote:
>
> Lou Langholtz wrote:
> > I've posted before about this problem but to a different audience. As
> > I'm hoping to get this resolved (fixed) though in the main source tree
> > but don't have the chance to test this entirely myself I'm resending
> > here hoping someone else can test things out...
> >
> > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > 2MB were still being recognized (despite having just added the 2MB to
> > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
>
> Just remember when making changes like this that the old code works fine
> for some people. I've had 4M in my 7600 for a long time, and never once
> had a problem with Linux saying I only had 2M. I don't often have the
> time to do kernel hacking, but I'll try to get a kernel with this patch
> up and running on my computer to see if it breaks things. I suspect it
> will, since it seems that the old way of detecting is removed.
>
> Hopefully I can get back to you on this in a few days.
I have a bunch of information on this lying around, and most of my
other kernel problems seem to be resolved now. I'm in the process of
upgrading to current vger; if it succeeds, I'll try to merge all
pending controlfb stuff tomorrow.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-10 20:13 64% ` Daniel Jacobowitz
@ 1999-09-11 9:23 64% ` Benjamin Herrenschmidt
1999-09-12 18:10 57% ` Daniel Jacobowitz
0 siblings, 1 reply; 200+ results
From: Benjamin Herrenschmidt @ 1999-09-11 9:23 UTC (permalink / raw)
To: Daniel Jacobowitz, linuxppc-dev
>I have a bunch of information on this lying around, and most of my
>other kernel problems seem to be resolved now. I'm in the process of
>upgrading to current vger; if it succeeds, I'll try to merge all
>pending controlfb stuff tomorrow.
I also have a pair of crazy 8500 who have 2Mb of VRAM but in bank2 (they
don't work if the VRAM is moved to bank1, even under MacOS). The current
controlfb appears to work well. Send me your merge results, I'll test on
one of those weird machines Monday.
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-10 15:55 61% controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-09-10 17:08 64% ` Lou Langholtz
1999-09-10 18:33 64% ` Michel Lanners
@ 1999-09-11 10:51 64% ` Brad Boyer
1999-09-10 20:13 64% ` Daniel Jacobowitz
2 siblings, 1 reply; 200+ results
From: Brad Boyer @ 1999-09-11 10:51 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linuxppc-dev
Lou Langholtz wrote:
> I've posted before about this problem but to a different audience. As
> I'm hoping to get this resolved (fixed) though in the main source tree
> but don't have the chance to test this entirely myself I'm resending
> here hoping someone else can test things out...
>
> After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> 2MB were still being recognized (despite having just added the 2MB to
> total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> 2.2.12 and made the following changes to get all 4MB VRAM recognized:
Just remember when making changes like this that the old code works fine
for some people. I've had 4M in my 7600 for a long time, and never once
had a problem with Linux saying I only had 2M. I don't often have the
time to do kernel hacking, but I'll try to get a kernel with this patch
up and running on my computer to see if it breaks things. I suspect it
will, since it seems that the old way of detecting is removed.
Hopefully I can get back to you on this in a few days.
Brad Boyer
flar@pants.nu
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Possible bug in quik
@ 1999-09-12 16:28 64% Benjamin Herrenschmidt
0 siblings, 0 replies; 200+ results
From: Benjamin Herrenschmidt @ 1999-09-12 16:28 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus
In quik 2.0, in main.c (bottom of function main()), I found:
/*
* For the sake of the Open Firmware XCOFF loader, the entry
* point may actually be a procedure descriptor.
*/
start = *(unsigned *)entry;
if (start < load_loc || start >= load_loc + len
|| ((unsigned *)entry)[2] != 0)
/* doesn't look like a procedure descriptor */
start += entry;
printf("Starting at %x\n", start);
(* (void (*)()) start)(params, 0, prom_entry, 0, 0);
prom_exit();
I was wondering why, when we don't find an XCOFF desc, do we _add_ entry to
start. I would have replaced start completely since in this case, we may
want to
enter the kernel at entry directly. Did I miss something ?
--
E-Mail: <mailto:bh40@calva.net>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-10 18:33 64% ` Michel Lanners
@ 1999-09-12 16:58 64% ` Lou Langholtz
1999-09-13 18:13 64% ` Michel Lanners
1999-10-12 6:49 64% ` Lou Langholtz
1 sibling, 1 reply; 200+ results
From: Lou Langholtz @ 1999-09-12 16:58 UTC (permalink / raw)
To: mlan; +Cc: linuxppc-dev
Michel Lanners wrote:
> On 10 Sep, this message from Lou Langholtz echoed through cyberspace:
> > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > 2MB were still being recognized (despite having just added the 2MB to
> > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
>
> > < out_8(&p->frame_buffer[0x600000], 0xa5);
> > < out_8(&p->frame_buffer[0x600001], 0x38);
> > ---
> >> out_8(&p->frame_buffer[0x200000], 0xa5);
> >> out_8(&p->frame_buffer[0x200001], 0x38);
>
> Hmm, if I remember right, there have been half a dozen patch pairs that
> changed 0x600000 to 0x200000 and back over the years ;-)
>
> I guess it's time to clear thgis up once and for all. By the way, I do
> have 4 MB of VRAM, and all of it is detected with the current version
> of controlfb.....
If I had a spare PowerMac 7500 I'd love to test every combo and see what gets
detected where. Unfortunately I don't, but hope someone else can do this
instead and get conclusive info that we need. It concerns me too that people
with 8500's (that seem to have the same graphics card) seem to observe
different behavior in detection.
What version of controlfb are you using? Current from the 2.2 kernel tree,
2.3 kernel tree, or 2.2 or 2.3 from vger, or even somewhere else. 2.2.12
wouldn't detect all 4MB VRAM in my 7500 box. I'm sorry but I haven't kept up
very well with all the different distributions of source. Let me know which
release then you use and I'll eagerely check it out ;-)
> Michel . . .
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-11 9:23 64% ` Benjamin Herrenschmidt
@ 1999-09-12 18:10 57% ` Daniel Jacobowitz
0 siblings, 0 replies; 200+ results
From: Daniel Jacobowitz @ 1999-09-12 18:10 UTC (permalink / raw)
To: Benjamin Herrenschmidt, Geert Uytterhoeven; +Cc: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 1110 bytes --]
OK, this patch should d the trick.
On Sat, Sep 11, 1999 at 11:23:23AM +0200, Benjamin Herrenschmidt wrote:
> >I have a bunch of information on this lying around, and most of my
> >other kernel problems seem to be resolved now. I'm in the process of
> >upgrading to current vger; if it succeeds, I'll try to merge all
> >pending controlfb stuff tomorrow.
>
> I also have a pair of crazy 8500 who have 2Mb of VRAM but in bank2 (they
> don't work if the VRAM is moved to bank1, even under MacOS). The current
> controlfb appears to work well. Send me your merge results, I'll test on
> one of those weird machines Monday.
>
>
> --
> E-Mail: <mailto:bh40@calva.net>
> BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
>
>
>
>
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
[-- Attachment #2: control.diff --]
[-- Type: text/plain, Size: 2778 bytes --]
Index: controlfb.c
===================================================================
RCS file: /cvs/linux/linux/drivers/video/controlfb.c,v
retrieving revision 1.20
diff -u -r1.20 controlfb.c
--- controlfb.c 1999/09/10 07:04:03 1.20
+++ controlfb.c 1999/09/12 18:03:57
@@ -702,26 +702,48 @@
p->cmap_regs = ioremap(p->cmap_regs_phys, 0x1000);
/* Work out which banks of VRAM we have installed. */
- /* danj: I guess the card just ignores writes to nonexistant VRAM... */
+ /* According to Andrew Fyfe <bandr@best.com>, the VRAM behaves like so: */
+ /* afyfe: observations from an 8500:
+ * - with 2M vram in bank 1, it appears at offsets 0, 2M and 4M
+ * - with 2M vram in bank 2, it appears only at offset 6M
+ * - with 4M vram, it appears only as a 4M block at offset 0.
+ */
+
+ /* We know there is something at 2M if there is something at 0M. */
+ out_8(&p->frame_buffer[0x200000], 0xa5);
+ out_8(&p->frame_buffer[0x200001], 0x38);
+ asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x200000]) : "memory" );
+
out_8(&p->frame_buffer[0], 0x5a);
out_8(&p->frame_buffer[1], 0xc7);
asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0]) : "memory" );
- bank1 = (in_8(&p->frame_buffer[0]) == 0x5a) && (in_8(&p->frame_buffer[1]) == 0xc7);
- out_8(&p->frame_buffer[0x600000], 0xa5);
- out_8(&p->frame_buffer[0x600001], 0x38);
- asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x600000]) : "memory" );
- bank2 = (in_8(&p->frame_buffer[0x600000]) == 0xa5)
- && (in_8(&p->frame_buffer[0x600001]) == 0x38);
-
- p->total_vram = (bank1 + bank2) * 0x200000;
- /* If we don't have bank 1 installed, we hope we have bank 2 :-) */
- p->control_use_bank2 = !bank1;
- if (p->control_use_bank2) {
+ bank1 = (in_8(&p->frame_buffer[0x000000]) == 0x5a)
+ && (in_8(&p->frame_buffer[0x000001]) == 0xc7);
+ bank2 = (in_8(&p->frame_buffer[0x200000]) == 0xa5)
+ && (in_8(&p->frame_buffer[0x200001]) == 0x38);
+
+ if(bank2 && !bank1)
+ printk(KERN_INFO "controlfb: Found memory at 2MB but not at 0! Please contact dan@debian.org\n");
+
+ if(!bank1) {
+ out_8(&p->frame_buffer[0x600000], 0xa5);
+ out_8(&p->frame_buffer[0x600001], 0x38);
+ asm volatile("eieio; dcbi 0,%0" : : "r" (&p->frame_buffer[0x600000]) : "memory" );
+ bank2 = (in_8(&p->frame_buffer[0x600000]) == 0xa5)
+ && (in_8(&p->frame_buffer[0x600001]) == 0x38);
+ /* If we don't have bank 1 installed, we hope we have bank 2 :-) */
+ p->control_use_bank2 = 1;
p->frame_buffer += 0x600000;
p->frame_buffer_phys += 0x600000;
}
+ p->total_vram = (bank1 + bank2) * 0x200000;
+
+ printk(KERN_INFO "controlfb: Memory bank 1 %s, bank 2 %s, total VRAM %dMB\n",
+ bank1 ? "present" : "absent", bank2 ? "present" : "absent",
+ 2 * (bank1 + bank2));
+
init_control(p);
}
^ permalink raw reply [relevance 57%]
* Need help from someone with SMP machine to track down bug in native threads jdk
@ 1999-09-12 18:49 64% Kevin Hendricks
0 siblings, 0 replies; 200+ results
From: Kevin Hendricks @ 1999-09-12 18:49 UTC (permalink / raw)
To: linuxppc-dev
Hi,
If anyone has an SMP machine out there and some time to spare, I really need
some help tracking down a bug in the native threads version of the jdk. I have
a short java sample program that seg-faults eventually during heavy thread
creation on SMP x86 linux boxes. I would like to see if the same thing happens
under SMP linux ppc boxes and if so help in tracking it down (I don't have
access to any SMP machines either on x86 or ppc).
If interested in helping and speeding the next release of the jdk, please
e-mail me and let me know:
mailto:khendricks@ivey.uwo.ca
Thanks,
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-12 16:58 64% ` Lou Langholtz
@ 1999-09-13 18:13 64% ` Michel Lanners
1999-09-15 15:14 64% ` Lou Langholtz
1999-10-12 7:07 62% ` Lou Langholtz
0 siblings, 2 replies; 200+ results
From: Michel Lanners @ 1999-09-13 18:13 UTC (permalink / raw)
To: ldl; +Cc: linuxppc-dev
On 12 Sep, this message from Lou Langholtz echoed through cyberspace:
> If I had a spare PowerMac 7500 I'd love to test every combo and see what gets
> detected where. Unfortunately I don't, but hope someone else can do this
> instead and get conclusive info that we need. It concerns me too that people
> with 8500's (that seem to have the same graphics card) seem to observe
> different behavior in detection.
Yeah; might prove interesting to compare the results on a 7500 with
those on a 8500...
> What version of controlfb are you using? Current from the 2.2 kernel tree,
> 2.3 kernel tree, or 2.2 or 2.3 from vger, or even somewhere else. 2.2.12
> wouldn't detect all 4MB VRAM in my 7500 box. I'm sorry but I haven't kept up
> very well with all the different distributions of source. Let me know which
> release then you use and I'll eagerely check it out ;-)
Hmm... official 2.2.12 does detect my 4 MB... and this is a 7600, so
the same motherboard as the 7500...
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* bug in 2.2.13pre7 on Ultras
@ 1999-09-14 18:24 64% pau
1999-09-14 19:51 64% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: pau @ 1999-09-14 18:24 UTC (permalink / raw)
To: ultralinux
[-- Attachment #1: Type: TEXT/PLAIN, Size: 445 bytes --]
I've finally managed to catch the oops on the Ultras :) through the serial
console.
I've been having problems forever with Ultra AXi PCI and Linux, hanging
from time to time: more activity more hangs.
It used to be a SIR Reset, but this one has disappeared -as David said ;)-
in this version. There are still errors to be corrected, so I hope my
ksymoops are useful. If you need more information just tell me.
I attach the log.
Thanks
Pau
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 13948 bytes --]
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre7 on Ultras
1999-09-14 18:24 64% bug in 2.2.13pre7 on Ultras pau
@ 1999-09-14 19:51 64% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1999-09-14 19:51 UTC (permalink / raw)
To: ultralinux
The dumps seem to be corrupted, it is very crucial for the initial
oops generated to be completely visible and decoded. Once the
first oops happens, the only thing that can really be said about
subsequent oopses are that they are due to corrupted state generated
in the first oops, it's difficult then to reason about the true cause.
Also, are you getting correctable ECC memory errors in your kernel
logs before this happens? I am very close to starting to encourage
users to return these AXi boards to Sun and asking for fixed parts
which do not generate these ECC memory errors. They addresses
generating the ECC errors are always at the same exact spot, with the
same ECC syndrome, regardless of how you arrange the simms. This is a
motherboard hardware bug without a doubt, and I'm imagining that a
large set of AXi boards produced in the past half year have this
problem. :-(
I know this issue has never turned up on any other UltraSparc's,
because if they did the machine would lock up at bootup and people
would have told me about it :-)
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre7 on Ultras (more oops)
@ 1999-09-15 7:23 64% pau
1999-09-15 7:34 64% ` David S. Miller
` (3 more replies)
0 siblings, 4 replies; 200+ results
From: pau @ 1999-09-15 7:23 UTC (permalink / raw)
To: ultralinux
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1691 bytes --]
On Tue, 14 Sep 1999, David S. Miller wrote:
> The dumps seem to be corrupted, it is very crucial for the initial
> oops generated to be completely visible and decoded. Once the
> first oops happens, the only thing that can really be said about
> subsequent oopses are that they are due to corrupted state generated
> in the first oops, it's difficult then to reason about the true cause.
Ok, now I'm sure I include the first one, but also the rest, just in case.
> Also, are you getting correctable ECC memory errors in your kernel
> logs before this happens? I am very close to starting to encourage
If it should log anything, I don't get it. No errors in the logs or the
console but the ones I include.
> users to return these AXi boards to Sun and asking for fixed parts
> which do not generate these ECC memory errors. They addresses
> generating the ECC errors are always at the same exact spot, with the
> same ECC syndrome, regardless of how you arrange the simms. This is a
> motherboard hardware bug without a doubt, and I'm imagining that a
> large set of AXi boards produced in the past half year have this
> problem. :-(
In fact these are Sparc compatible, but they have passed Sun the hardware
compatibility tests -twice :)-
And they don't fail with Solaris 2.7 :(((
I got 2 of them replaced, but the problems didn't disappear.
> I know this issue has never turned up on any other UltraSparc's,
> because if they did the machine would lock up at bootup and people
> would have told me about it :-)
Well, maybe with the new logs you can reach other conclusions.
If you need to know the gcc compiler used, the prom settings or something
else, just ask it.
Thanks
Pau
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 4814 bytes --]
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre7 on Ultras (more oops)
1999-09-15 7:23 64% bug in 2.2.13pre7 on Ultras (more oops) pau
@ 1999-09-15 7:34 64% ` David S. Miller
1999-09-15 7:42 64% ` pau
` (2 subsequent siblings)
3 siblings, 0 replies; 200+ results
From: David S. Miller @ 1999-09-15 7:34 UTC (permalink / raw)
To: ultralinux
From: pau@readysoft.es
Date: Wed, 15 Sep 1999 09:23:15 +0200 (CEST)
> Also, are you getting correctable ECC memory errors in your
> kernel logs before this happens? I am very close to starting to
> encourage
If it should log anything, I don't get it. No errors in the logs or
the console but the ones I include.
What kernel are you running? Maybe you are running a kernel which
just ignores the CEE errors and does not log them, current 2.2.x
kernels log all correctable ECC memory errors in the dmesg logs.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre7 on Ultras (more oops)
1999-09-15 7:23 64% bug in 2.2.13pre7 on Ultras (more oops) pau
1999-09-15 7:34 64% ` David S. Miller
@ 1999-09-15 7:42 64% ` pau
1999-09-15 8:10 64% ` David S. Miller
1999-09-15 10:10 64% ` pau
3 siblings, 0 replies; 200+ results
From: pau @ 1999-09-15 7:42 UTC (permalink / raw)
To: ultralinux
On Wed, 15 Sep 1999, David S. Miller wrote:
> From: pau@readysoft.es
> Date: Wed, 15 Sep 1999 09:23:15 +0200 (CEST)
>
> > Also, are you getting correctable ECC memory errors in your
> > kernel logs before this happens? I am very close to starting to
> > encourage
>
> If it should log anything, I don't get it. No errors in the logs or
> the console but the ones I include.
>
> What kernel are you running? Maybe you are running a kernel which
> just ignores the CEE errors and does not log them, current 2.2.x
> kernels log all correctable ECC memory errors in the dmesg logs.
2.2.13pre7 + raid5 patches + ncr patch from Gerard Roudier
Tha machine sill runs ultrapenguin and the kernel is compiled on
ultrapenguin -see at the gcc compiler-.
# uname -a
Linux ultratest 2.2.13pre7 #1 Mon Sep 13 10:24:05 CEST 1999 sparc64
unknown
# dmesg
PROMLIB: Sun IEEE Boot Prom 3.10.6 1998/12/08 13:30
Linux version 2.2.13pre7 (root@ursa) (gcc version egcs-2.92.11 19980921
(gcc2 ss-980609 experimental)) #1 Mon Sep 13 10:24:05 CEST 1999
ARCH: SUN4U
Pau
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre7 on Ultras (more oops)
1999-09-15 7:23 64% bug in 2.2.13pre7 on Ultras (more oops) pau
1999-09-15 7:34 64% ` David S. Miller
1999-09-15 7:42 64% ` pau
@ 1999-09-15 8:10 64% ` David S. Miller
1999-09-15 10:10 64% ` pau
3 siblings, 0 replies; 200+ results
From: David S. Miller @ 1999-09-15 8:10 UTC (permalink / raw)
To: ultralinux
From: pau@readysoft.es
Date: Wed, 15 Sep 1999 09:42:23 +0200 (CEST)
2.2.13pre7 + raid5 patches + ncr patch from Gerard Roudier Tha
machine sill runs ultrapenguin and the kernel is compiled on
ultrapenguin -see at the gcc compiler-.
Please try the following:
1) Grab 2.2.13pre8
2) remove the NCR driver patch
3) make sure the egcs64 package is the most updated one
? rpm -qvf /usr/bin/sparc64-linux-gcc
egcs64-19980921-4
?
Thanks.
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre7 on Ultras (more oops)
1999-09-15 7:23 64% bug in 2.2.13pre7 on Ultras (more oops) pau
` (2 preceding siblings ...)
1999-09-15 8:10 64% ` David S. Miller
@ 1999-09-15 10:10 64% ` pau
3 siblings, 0 replies; 200+ results
From: pau @ 1999-09-15 10:10 UTC (permalink / raw)
To: ultralinux
On Wed, 15 Sep 1999, David S. Miller wrote:
> From: pau@readysoft.es
> Date: Wed, 15 Sep 1999 09:42:23 +0200 (CEST)
>
> 2.2.13pre7 + raid5 patches + ncr patch from Gerard Roudier Tha
> machine sill runs ultrapenguin and the kernel is compiled on
> ultrapenguin -see at the gcc compiler-.
>
> Please try the following:
>
> 1) Grab 2.2.13pre8
> 2) remove the NCR driver patch
> 3) make sure the egcs64 package is the most updated one
>
> ? rpm -qvf /usr/bin/sparc64-linux-gcc
> egcs64-19980921-4
> ?
I have applied the 2.2.13pre8 patch + raid0145-19990824-2.2.11.bz2
as ioctl32.c needed linux/raid/md.h. Otherwise it didn't compile.
The system is working right now. No oops in 10 minutes :)
Pau
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-13 18:13 64% ` Michel Lanners
@ 1999-09-15 15:14 64% ` Lou Langholtz
1999-10-12 7:07 62% ` Lou Langholtz
1 sibling, 0 replies; 200+ results
From: Lou Langholtz @ 1999-09-15 15:14 UTC (permalink / raw)
To: mlan; +Cc: linuxppc-dev
Michel Lanners wrote:
> Hmm... official 2.2.12 does detect my 4 MB... and this is a 7600, so the same
> motherboard as the 7500...
>
> Michel . . .
Odd. I thought I tried stock 2.2.12 and it didn't detect the 4MB VRAM in my
PowerMac 7500. Now I'm not so sure. A quick diff of the kernel controlfb.c sources
between 2.2.6 and 2.2.12 reveal no difference though in the VRAM bank check code
though so it also seems to me that if people had this problem in 2.2.6 then 2.2.12
should also be unable to detect the full 4MB VRAM. If you're saying that the
hardware should be identical then could some other software be responsible such as
the OF software be perhaps different and causing this different behavior? I'd
really like some confirmation now that others with 7500 don't get all
4MB VRAM detected even using stock 2.2.12. I've read postings from others that
they didn't get 4MB VRAM detected but I don't think that was with 2.2.12 at that
time.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
@ 1999-09-15 17:05 64% Kevin_Hendricks
1999-09-15 18:26 64% ` Kevin Puetz
0 siblings, 1 reply; 200+ results
From: Kevin_Hendricks @ 1999-09-15 17:05 UTC (permalink / raw)
To: mlan, ldl; +Cc: linuxppc-dev
Hi,
Just to add fuel to the fire (although I am not sure if this is related or not)
My B+W G3 rev2 with 16MB of vram has never ever detected the correct amount. In
fact, if I run Xconfigurator, it tells me I have less then 1MB of vram and
therefore won't let me use any of the higher resolutions that should work.
The interesting thing is that if I change my bpp via the MacOS, Xconfigurator
reports completely different amounts of vram available and not in any logical
way that I can see.
Any fixes along these lines would be greatly appreciated (this is with Paul's
2.2.10 stable kernel available from his website).
Just thought someone in the know should be told :-)
Kevin
>> Hmm... official 2.2.12 does detect my 4 MB... and this is a 7600, so the same
>> motherboard as the 7500...
>>
>> Michel . . .
>
>Odd. I thought I tried stock 2.2.12 and it didn't detect the 4MB VRAM in my
>PowerMac 7500. Now I'm not so sure. A quick diff of the kernel controlfb.c
sources
>between 2.2.6 and 2.2.12 reveal no difference though in the VRAM bank check
code
>though so it also seems to me that if people had this problem in 2.2.6 then
2.2.12
>should also be unable to detect the full 4MB VRAM. If you're saying that the
>hardware should be identical then could some other software be responsible such
as
>the OF software be perhaps different and causing this different behavior? I'd
>really like some confirmation now that others with 7500 don't get all
>4MB VRAM detected even using stock 2.2.12. I've read postings from others that
>they didn't get 4MB VRAM detected but I don't think that was with 2.2.12 at
that
>time.
>
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-15 17:05 64% controlfb.c bug in VRAM bank2 check if bank1 Kevin_Hendricks
@ 1999-09-15 18:26 64% ` Kevin Puetz
0 siblings, 0 replies; 200+ results
From: Kevin Puetz @ 1999-09-15 18:26 UTC (permalink / raw)
To: Kevin_Hendricks; +Cc: mlan, ldl, linuxppc-dev
khendricks@admin.ivey.uwo.ca said:
> Hi,
> Just to add fuel to the fire (although I am not sure if this is
> related or not)
> My B+W G3 rev2 with 16MB of vram has never ever detected the correct
> amount. In fact, if I run Xconfigurator, it tells me I have less
> then 1MB of vram and therefore won't let me use any of the higher
> resolutions that should work
> The interesting thing is that if I change my bpp via the MacOS,
> Xconfigurator reports completely different amounts of vram available
> and not in any logical way that I can see.
If you use 'no video driver' Linux will see the amount of VRAM that was
actually in use by MacOS when booting. You should probably look into a newer
kernel with aty128fb
> Any fixes along these lines would be greatly appreciated (this is with
> Paul's 2.2.10 stable kernel available from his website).
Which is probably just old enough not to have the correct driver.
> Just thought someone in the know should be told :-)
> Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* bug in 2.2.13pre8 on Ultras (more oops)
@ 1999-09-16 14:37 64% pau
1999-09-17 1:36 64% ` David S. Miller
0 siblings, 1 reply; 200+ results
From: pau @ 1999-09-16 14:37 UTC (permalink / raw)
To: ultralinux
[-- Attachment #1: Type: TEXT/PLAIN, Size: 693 bytes --]
On Wed, 15 Sep 1999 pau@readysoft.es wrote:
> On Wed, 15 Sep 1999, David S. Miller wrote:
>
> > Please try the following:
> >
> > 1) Grab 2.2.13pre8
> > 2) remove the NCR driver patch
> > 3) make sure the egcs64 package is the most updated one
> >
> > ? rpm -qvf /usr/bin/sparc64-linux-gcc
> > egcs64-19980921-4
> > ?
>
> I have applied the 2.2.13pre8 patch + raid0145-19990824-2.2.11.bz2
> as ioctl32.c needed linux/raid/md.h. Otherwise it didn't compile.
>
> The system is working right now. No oops in 10 minutes :)
After 22 hours the system stopped working :(
I attach the ksymoops.
If you need any help in tracing the bugs or testing a patch just drop an
email ;)
Thanks
Pau
[-- Attachment #2: Type: APPLICATION/octet-stream, Size: 1887 bytes --]
^ permalink raw reply [relevance 64%]
* Re: bug in 2.2.13pre8 on Ultras (more oops)
1999-09-16 14:37 64% bug in 2.2.13pre8 on Ultras (more oops) pau
@ 1999-09-17 1:36 64% ` David S. Miller
0 siblings, 0 replies; 200+ results
From: David S. Miller @ 1999-09-17 1:36 UTC (permalink / raw)
To: ultralinux
This is truncated again, from the beginning:
ff80003c88000 l1: 0000000000000000 l2: 0000000000650800 l3: 000000000058c400
l4: 000000000058c400 l5: 0000000000003fff l6: 00000000005e3100 l7: 0000000000000000
i0: fffff80003c7fa50 i1: 0000000004005807 i2: 0000000000100009 i3: 0000000000000169
You aparently grabbed this from /var/spool/log/messages, so why don't
you bzip it up along with the System.map file for the running kernel,
and put it up for FTP so I can inspect this by hand?
Later,
David S. Miller
davem@redhat.com
^ permalink raw reply [relevance 64%]
* Bug in Indy serial driver?
@ 1999-09-17 15:48 64% Kevin D. Kissell
0 siblings, 0 replies; 200+ results
From: Kevin D. Kissell @ 1999-09-17 15:48 UTC (permalink / raw)
To: SGI Linux Alias
In trying to use remote gdb targets, I came across
a problem with the Indy serial driver. I'm running
2.2.12, but the driver and line discipline code are
unchanged from 2.2.10.
If one turns off output postprocessing via ioctl, or simply
with an stty -opost < /dev/ttyS0, writes to the device
succeed, but the data is never sent. A close of the
device will then hang for a 30 second timeout, but
the data isn't flushed then, either. The line discipline
follows a different code path in the O_POST case
than in the no-opost case, and it looked to me as
if perhaps things were working in the O_POST
case simply because there are more explicit
flushes being performed, as the restart of the
transmitter in ns_write is conditional on a status
that may never be satisfied. I removed that
condition, but this has no effect on the behaviour.
Has anyone else seen this, or better still, fixed it?
It's possible that the bug is in n_tty.c itself, but
as that is generic to all Linux serial ports, I would
be rather surprised if it had not been found and
fixed long ago.
Regards,
Kevin K.
__
Kevin D. Kissell
MIPS Technologies European Architecture Lab
kevink@mips.com
Tel. +33.4.78.38.70.67
FAX. +33.4.78.38.70.68
^ permalink raw reply [relevance 64%]
* syslinux-1.43 bug [and possible PATCH]
@ 1999-09-23 21:09 61% Kanoj Sarcar
1999-09-23 21:30 64% ` Matt Wilson
` (2 more replies)
0 siblings, 3 replies; 200+ results
From: Kanoj Sarcar @ 1999-09-23 21:09 UTC (permalink / raw)
To: syslinux, linux-mm, linux-kernel; +Cc: Kanoj Sarcar
I have a possible problem to report with syslinux, and a suggested
fix. Please send me comments and feedback at kanoj@engr.sgi.com,
since I am not subscribed to the syslinux or kernel lists.
While installing linux (RedHat6.0, SuSe, Mandrake etc) on a ia32
Compaq box with 1.5Gb memory, I have observed kernel panics from
mount_root. On further investigation, syslinux decides to put initrd
at a high physical address, which the Linux kernel, compiled with
PAGE_OFFSET=0xc0000000 can not access. The kernel can access at
the most physical address 0x3c000000, whereas syslinux/ldlinux.asm
can put initrd as high as HIGHMEM_MAX=0x3f000000. This leads
setup_arch() to decide it can not use initrd, thus causing the
kernel panic.
The easy fix to me seems to be to change HIGHMEM_MAX in
syslinux/ldlinux.asm to 0x3c000000. In fact, I have verified on
a couple of machines that this will let the installation proceed.
Have other people run into this problem and worked around it some
other way? (One way would be to specify mem= at the boot: prompt
from syslinux. Yet another way seems to be to specify mem= in
the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
although I am not sure whether this will impact the capability of
syslinux to install other os'es).
Thanks.
Kanoj
kanoj@engr.sgi.com
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 61%]
* Re: syslinux-1.43 bug [and possible PATCH]
1999-09-23 21:09 61% syslinux-1.43 bug [and possible PATCH] Kanoj Sarcar
@ 1999-09-23 21:30 64% ` Matt Wilson
1999-09-23 21:55 64% ` H. Peter Anvin
1999-09-24 8:48 64% ` Neil Conway
2 siblings, 0 replies; 200+ results
From: Matt Wilson @ 1999-09-23 21:30 UTC (permalink / raw)
To: Kanoj Sarcar, syslinux, linux-mm, linux-kernel
This was fixed in 1.44, AFAIK. HIGHMEM_MAX is now 38000000h.
We're using 1.45 for our next release.
Matt
msw@redhat.com
On Thu, Sep 23, 1999 at 02:09:58PM -0700, Kanoj Sarcar wrote:
> I have a possible problem to report with syslinux, and a suggested
> fix. Please send me comments and feedback at kanoj@engr.sgi.com,
> since I am not subscribed to the syslinux or kernel lists.
>
> While installing linux (RedHat6.0, SuSe, Mandrake etc) on a ia32
> Compaq box with 1.5Gb memory, I have observed kernel panics from
> mount_root. On further investigation, syslinux decides to put initrd
> at a high physical address, which the Linux kernel, compiled with
> PAGE_OFFSET=0xc0000000 can not access. The kernel can access at
> the most physical address 0x3c000000, whereas syslinux/ldlinux.asm
> can put initrd as high as HIGHMEM_MAX=0x3f000000. This leads
> setup_arch() to decide it can not use initrd, thus causing the
> kernel panic.
>
> The easy fix to me seems to be to change HIGHMEM_MAX in
> syslinux/ldlinux.asm to 0x3c000000. In fact, I have verified on
> a couple of machines that this will let the installation proceed.
>
> Have other people run into this problem and worked around it some
> other way? (One way would be to specify mem= at the boot: prompt
> from syslinux. Yet another way seems to be to specify mem= in
> the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
> although I am not sure whether this will impact the capability of
> syslinux to install other os'es).
>
> Thanks.
>
> Kanoj
> kanoj@engr.sgi.com
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: syslinux-1.43 bug [and possible PATCH]
1999-09-23 21:09 61% syslinux-1.43 bug [and possible PATCH] Kanoj Sarcar
1999-09-23 21:30 64% ` Matt Wilson
@ 1999-09-23 21:55 64% ` H. Peter Anvin
1999-09-24 8:48 64% ` Neil Conway
2 siblings, 0 replies; 200+ results
From: H. Peter Anvin @ 1999-09-23 21:55 UTC (permalink / raw)
To: Kanoj Sarcar; +Cc: syslinux, linux-mm, linux-kernel
This is an old bug; it has been fixed since 1.44 or 1.45. The current
version is 1.47.
-hpa
On Thu, 23 Sep 1999, Kanoj Sarcar wrote:
> I have a possible problem to report with syslinux, and a suggested
> fix. Please send me comments and feedback at kanoj@engr.sgi.com,
> since I am not subscribed to the syslinux or kernel lists.
>
> While installing linux (RedHat6.0, SuSe, Mandrake etc) on a ia32
> Compaq box with 1.5Gb memory, I have observed kernel panics from
> mount_root. On further investigation, syslinux decides to put initrd
> at a high physical address, which the Linux kernel, compiled with
> PAGE_OFFSET=0xc0000000 can not access. The kernel can access at
> the most physical address 0x3c000000, whereas syslinux/ldlinux.asm
> can put initrd as high as HIGHMEM_MAX=0x3f000000. This leads
> setup_arch() to decide it can not use initrd, thus causing the
> kernel panic.
>
> The easy fix to me seems to be to change HIGHMEM_MAX in
> syslinux/ldlinux.asm to 0x3c000000. In fact, I have verified on
> a couple of machines that this will let the installation proceed.
>
> Have other people run into this problem and worked around it some
> other way? (One way would be to specify mem= at the boot: prompt
> from syslinux. Yet another way seems to be to specify mem= in
> the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
> although I am not sure whether this will impact the capability of
> syslinux to install other os'es).
>
> Thanks.
>
> Kanoj
> kanoj@engr.sgi.com
>
<hpa@transmeta.com> at work, <hpa@zytor.com> in private!
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: syslinux-1.43 bug [and possible PATCH]
1999-09-23 21:09 61% syslinux-1.43 bug [and possible PATCH] Kanoj Sarcar
1999-09-23 21:30 64% ` Matt Wilson
1999-09-23 21:55 64% ` H. Peter Anvin
@ 1999-09-24 8:48 64% ` Neil Conway
1999-09-24 8:55 64% ` H. Peter Anvin
2 siblings, 1 reply; 200+ results
From: Neil Conway @ 1999-09-24 8:48 UTC (permalink / raw)
To: Kanoj Sarcar; +Cc: syslinux, linux-mm, linux-kernel
Kanoj Sarcar wrote:
> While installing linux (RedHat6.0, SuSe, Mandrake etc) on a ia32
> Compaq box with 1.5Gb memory, I have observed kernel panics from
> mount_root. On further investigation, syslinux decides to put initrd
> at a high physical address, which the Linux kernel, compiled with
> PAGE_OFFSET=0xc0000000 can not access. The kernel can access at
> the most physical address 0x3c000000, whereas syslinux/ldlinux.asm
> can put initrd as high as HIGHMEM_MAX=0x3f000000. This leads
> setup_arch() to decide it can not use initrd, thus causing the
> kernel panic.
Yup...
> Have other people run into this problem and worked around it some
> other way? (One way would be to specify mem= at the boot: prompt
> from syslinux. Yet another way seems to be to specify mem= in
> the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
> although I am not sure whether this will impact the capability of
> syslinux to install other os'es).
I don't think "mem=" would help at all but I could be wrong.
My "easy" fix was to pull out a DIMM from each of our machines, leaving
3x256 :-) Not elegant, but fast!
Neil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: syslinux-1.43 bug [and possible PATCH]
1999-09-24 8:48 64% ` Neil Conway
@ 1999-09-24 8:55 64% ` H. Peter Anvin
1999-09-24 9:43 64% ` Neil Conway
1999-09-24 16:30 64% ` Stephen C. Tweedie
0 siblings, 2 replies; 200+ results
From: H. Peter Anvin @ 1999-09-24 8:55 UTC (permalink / raw)
To: Neil Conway; +Cc: Kanoj Sarcar, syslinux, linux-mm, linux-kernel
Neil Conway wrote:
>
> > Have other people run into this problem and worked around it some
> > other way? (One way would be to specify mem= at the boot: prompt
> > from syslinux. Yet another way seems to be to specify mem= in
> > the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
> > although I am not sure whether this will impact the capability of
> > syslinux to install other os'es).
>
> I don't think "mem=" would help at all but I could be wrong.
>
It works; both SYSLINUX and the kernel with honour it.
> My "easy" fix was to pull out a DIMM from each of our machines, leaving
> 3x256 :-) Not elegant, but fast!
As already said, get SYSLINUX 1.44 or later...
-hpa
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: syslinux-1.43 bug [and possible PATCH]
@ 1999-09-24 9:04 64% Javan Dempsey
0 siblings, 0 replies; 200+ results
From: Javan Dempsey @ 1999-09-24 9:04 UTC (permalink / raw)
To: kanoj, nconway.list; +Cc: syslinux, linux-mm, linux-kernel
mem=768k is what I've had to use to get linux to install on our Dell PowerEdge boxen with >1GB of mem. I've noticed the same problem with each of those machines.
Javan.D
Senior Systems Admin.
iCelebrate.Com Inc. (raz@icelebrate.com)
---------- Original Message ----------------------------------
From: Neil Conway <nconway.list@UKAEA.ORG.UK>
Date: Fri, 24 Sep 1999 09:48:36 +0100
>Kanoj Sarcar wrote:
> While installing linux (RedHat6.0, SuSe, Mandrake etc) on a ia32
> Compaq box with 1.5Gb memory, I have observed kernel panics from
> mount_root. On further investigation, syslinux decides to put initrd
> at a high physical address, which the Linux kernel, compiled with
> PAGE_OFFSET=0xc0000000 can not access. The kernel can access at
> the most physical address 0x3c000000, whereas syslinux/ldlinux.asm
> can put initrd as high as HIGHMEM_MAX=0x3f000000. This leads
> setup_arch() to decide it can not use initrd, thus causing the
> kernel panic.
Yup...
> Have other people run into this problem and worked around it some
> other way? (One way would be to specify mem= at the boot: prompt
> from syslinux. Yet another way seems to be to specify mem= in
> the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
> although I am not sure whether this will impact the capability of
> syslinux to install other os'es).
I don't think "mem=" would help at all but I could be wrong.
My "easy" fix was to pull out a DIMM from each of our machines, leaving
3x256 :-) Not elegant, but fast!
Neil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: syslinux-1.43 bug [and possible PATCH]
1999-09-24 8:55 64% ` H. Peter Anvin
@ 1999-09-24 9:43 64% ` Neil Conway
1999-09-24 16:30 64% ` Stephen C. Tweedie
1 sibling, 0 replies; 200+ results
From: Neil Conway @ 1999-09-24 9:43 UTC (permalink / raw)
To: H. Peter Anvin; +Cc: syslinux, linux-mm, linux-kernel
H. Peter Anvin wrote:
>
> Neil Conway wrote:
> > I don't think "mem=" would help at all but I could be wrong.
> It works; both SYSLINUX and the kernel with honour it.
Darn - I assumed that SYSLINUX wouldn't parse it :-(
Neil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: syslinux-1.43 bug [and possible PATCH]
@ 1999-09-24 10:05 63% Javan Dempsey
0 siblings, 0 replies; 200+ results
From: Javan Dempsey @ 1999-09-24 10:05 UTC (permalink / raw)
To: kanoj, nconway.list, raz; +Cc: syslinux, linux-mm, linux-kernel
OOOOPSSSS! did I say 768k? I meant mem=768M sorry about that people. I've been awake entirely too long
---------- Original Message ----------------------------------
From: "Javan Dempsey" <raz@mailhost.directlink.net>
Reply-To: <raz@mailhost.directlink.net>
Date: Fri, 24 Sep 1999 04:04:09 -0500
>mem=768k is what I've had to use to get linux to install on our Dell PowerEdge boxen with >1GB of mem. I've noticed the same problem with each of those machines.
Javan.D
Senior Systems Admin.
iCelebrate.Com Inc. (raz@icelebrate.com)
---------- Original Message ----------------------------------
From: Neil Conway <nconway.list@UKAEA.ORG.UK>
Date: Fri, 24 Sep 1999 09:48:36 +0100
>Kanoj Sarcar wrote:
> While installing linux (RedHat6.0, SuSe, Mandrake etc) on a ia32
> Compaq box with 1.5Gb memory, I have observed kernel panics from
> mount_root. On further investigation, syslinux decides to put initrd
> at a high physical address, which the Linux kernel, compiled with
> PAGE_OFFSET=0xc0000000 can not access. The kernel can access at
> the most physical address 0x3c000000, whereas syslinux/ldlinux.asm
> can put initrd as high as HIGHMEM_MAX=0x3f000000. This leads
> setup_arch() to decide it can not use initrd, thus causing the
> kernel panic.
Yup...
> Have other people run into this problem and worked around it some
> other way? (One way would be to specify mem= at the boot: prompt
> from syslinux. Yet another way seems to be to specify mem= in
> the syslinux.cfg file. Changing HIGHMEM_MAX seems to be the cleanest,
> although I am not sure whether this will impact the capability of
> syslinux to install other os'es).
I don't think "mem=" would help at all but I could be wrong.
My "easy" fix was to pull out a DIMM from each of our machines, leaving
3x256 :-) Not elegant, but fast!
Neil
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 63%]
* Re: syslinux-1.43 bug [and possible PATCH]
1999-09-24 8:55 64% ` H. Peter Anvin
1999-09-24 9:43 64% ` Neil Conway
@ 1999-09-24 16:30 64% ` Stephen C. Tweedie
1 sibling, 0 replies; 200+ results
From: Stephen C. Tweedie @ 1999-09-24 16:30 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Neil Conway, Kanoj Sarcar, syslinux, linux-mm, linux-kernel
Hi,
In article <37EB3C86.F17CC25A@transmeta.com>, "H. Peter Anvin"
<hpa@transmeta.com> writes:
> Neil Conway wrote:
>> My "easy" fix was to pull out a DIMM from each of our machines, leaving
>> 3x256 :-) Not elegant, but fast!
> As already said, get SYSLINUX 1.44 or later...
Which works nicely --- thanks Peter. The current Red Hat lorax
snapshots use the later syslinux and for the first time they boot
without messing about with kernel mem= parameters on the large-mem box
here.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://humbolt.geo.uu.nl/Linux-MM/
^ permalink raw reply [relevance 64%]
* [linux-lvm] LVM 0.7: optimization bug
@ 1999-09-24 22:49 64% Andreas Kostyrka
0 siblings, 0 replies; 200+ results
From: Andreas Kostyrka @ 1999-09-24 22:49 UTC (permalink / raw)
To: Linux LVM Mailinglist
Hi!
I've found some buggy assumptions (in my case, like that I do have
16 loop devices. RH6 comes with loop0-loop7).
The following patch fixes this:
diff -uNr LVM.org/0.7/tools/lib/pv_read_all_pv.c
LVM/0.7/tools/lib/pv_read_all_pv.c
--- LVM.org/0.7/tools/lib/pv_read_all_pv.c Mon Jul 12 23:21:26 1999
+++ LVM/0.7/tools/lib/pv_read_all_pv.c Sat Sep 25 03:19:51 1999
@@ -99,13 +99,6 @@
debug ( "pv_read_all_pv -- calling pv_read with \"%s\"\n",
dev_name);
#endif
- if ( ( tst = open ( dev_name, O_RDONLY)) == -1) {
- if ( MAJOR ( dir_cache[n].st_rdev) != MD_MAJOR &&
- MINOR ( dir_cache[n].st_rdev) % 16 == 0) {
- n += 15;
- continue;
- }
- } else close ( tst);
pv_read_errno = 0;
if ( ( ret = pv_read ( dev_name, &pv_tmp, &pv_read_errno)) == 0
||
Andreas
--
Andreas Kostyrka | andreas@mtg.co.at
phone: +43/1/7070750 | phone: +43/676/4091256
MTG Handelsges.m.b.H. | fax: +43/1/7065299
Raiffeisenstr. 16/9 | 2320 Zwoelfaxing AUSTRIA
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
[not found] <37F1AD4B.585E99AB@chpc.utah.edu>
@ 1999-09-29 7:11 64% ` Geert Uytterhoeven
1999-09-29 7:16 64% ` Takashi Oe
1 sibling, 0 replies; 200+ results
From: Geert Uytterhoeven @ 1999-09-29 7:11 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linuxppc-dev
On Wed, 29 Sep 1999, Lou Langholtz wrote:
> What might happen if a driver does:
point A
> save_flags(old_flags);
> cli();
> restore_flags(old_flags);
> save_flags(new_flags);
> cli();
> restore_flags(new_flags);
point B
> /* can't we be interupted here? Assume yes, if so */
> restore_flags(old_flags);
point C
> seems like this might introduce a bug if we could get interrupted after the
> restore of the new_flags but before the second restore of old flags in such a
> way such that the proper state of old_flags could change. I'm not comfortable
> enough though with my understanding of interrupts and driver routines to be
> certain one way or another. To be more specific, consider the case on just a
> single processor system. If this strikes anyone else as a possible race
> condition that could introduce a bug, then this is what we need to fix in
> macserial.c's rs_write routine since this code can potentially happen.
>
> Opinions??? Please clue me in anyway... this stuff's a kick! :-)
The interrupt mask register has the same contents at points A, B and C. Hence,
if we could be interrupt a point A, we can be interrupt at points B and C.
Greetings,
Geert
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
[not found] <37F1AD4B.585E99AB@chpc.utah.edu>
1999-09-29 7:11 64% ` [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] Geert Uytterhoeven
@ 1999-09-29 7:16 64% ` Takashi Oe
1999-09-29 7:40 64% ` Geert Uytterhoeven
` (4 more replies)
1 sibling, 5 replies; 200+ results
From: Takashi Oe @ 1999-09-29 7:16 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linuxppc-dev
On Wed, 29 Sep 1999, Lou Langholtz wrote:
> What might happen if a driver does:
>
> save_flags(old_flags);
> cli();
> restore_flags(old_flags);
> save_flags(new_flags);
> cli();
> restore_flags(new_flags);
> /* can't we be interupted here? Assume yes, if so */
> restore_flags(old_flags);
>
> seems like this might introduce a bug if we could get interrupted after the
> restore of the new_flags but before the second restore of old flags in such a
> way such that the proper state of old_flags could change. I'm not comfortable
> enough though with my understanding of interrupts and driver routines to be
> certain one way or another. To be more specific, consider the case on just a
> single processor system. If this strikes anyone else as a possible race
> condition that could introduce a bug, then this is what we need to fix in
> macserial.c's rs_write routine since this code can potentially happen.
I'm fairly certain it's a bug. Good spotting. The last restore_flags()
shouldn't be there.
--- macserial.c.ORIG Wed Sep 29 02:05:14 1999
+++ macserial.c Wed Sep 29 02:05:31 1999
@@ -1381,7 +1381,6 @@
if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
&& !info->tx_active)
transmit_chars(info);
- restore_flags(flags);
return ret;
}
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
[not found] <37F1C0A3.B9F25580@chpc.utah.edu>
@ 1999-09-29 7:39 64% ` Geert Uytterhoeven
0 siblings, 0 replies; 200+ results
From: Geert Uytterhoeven @ 1999-09-29 7:39 UTC (permalink / raw)
To: Lou Langholtz; +Cc: Linux/PPC Development
Hi Lou,
> > > What might happen if a driver does:
> >
> > point A
> >
> > > save_flags(old_flags);
> > > cli();
> > > restore_flags(old_flags);
>
> point A2?
>
> > > save_flags(new_flags);
> > > cli();
> > > restore_flags(new_flags);
> >
> > point B
> >
> > > /* can't we be interupted here? Assume yes, if so */
> > > restore_flags(old_flags);
> >
> > point C
point A == point A2 == point B == point C
> > > . . .Opinions??? Please clue me in anyway... this stuff's a kick! :-)
> >
> > The interrupt mask register has the same contents at points A, B and C. Hence,
> > if we could be interrupt a point A, we can be interrupt at points B and C. . . .
>
> Looking in macserial.c's rs_write() function it can call transmit_chars(info) at
> point B which would seem to me to be able to be a point at which the interupt mask
> register could change. No? I have to admit I'm only now reading the various docs
> on kernel locks. So I just email'd you hoping you'd give me another hint ;-)
I don't know how the serial port hardware has to be programmed. But if
transmit_chars() must be called with interrupts disabled, it's indeed a bug.
Greetings,
Geert
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 7:16 64% ` Takashi Oe
@ 1999-09-29 7:40 64% ` Geert Uytterhoeven
1999-09-29 9:13 60% ` Benjamin Herrenschmidt
` (3 subsequent siblings)
4 siblings, 0 replies; 200+ results
From: Geert Uytterhoeven @ 1999-09-29 7:40 UTC (permalink / raw)
To: Takashi Oe; +Cc: Lou Langholtz, linuxppc-dev
On Wed, 29 Sep 1999, Takashi Oe wrote:
> On Wed, 29 Sep 1999, Lou Langholtz wrote:
> > What might happen if a driver does:
> >
> > save_flags(old_flags);
> > cli();
> > restore_flags(old_flags);
> > save_flags(new_flags);
> > cli();
> > restore_flags(new_flags);
> > /* can't we be interupted here? Assume yes, if so */
> > restore_flags(old_flags);
> >
> > seems like this might introduce a bug if we could get interrupted after the
> > restore of the new_flags but before the second restore of old flags in such a
> > way such that the proper state of old_flags could change. I'm not comfortable
> > enough though with my understanding of interrupts and driver routines to be
> > certain one way or another. To be more specific, consider the case on just a
> > single processor system. If this strikes anyone else as a possible race
> > condition that could introduce a bug, then this is what we need to fix in
> > macserial.c's rs_write routine since this code can potentially happen.
>
> I'm fairly certain it's a bug. Good spotting. The last restore_flags()
> shouldn't be there.
Or one of the others. The last restore_flags() may make me think there's
something wrong, but it cannot cause harm. If there's a real bug, it should be
related to the other flag manipulation calls.
Greetings,
Geert
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 7:16 64% ` Takashi Oe
1999-09-29 7:40 64% ` Geert Uytterhoeven
@ 1999-09-29 9:13 60% ` Benjamin Herrenschmidt
1999-09-30 0:46 64% ` Takashi Oe
1999-09-29 16:44 64% ` Lou Langholtz
` (2 subsequent siblings)
4 siblings, 1 reply; 200+ results
From: Benjamin Herrenschmidt @ 1999-09-29 9:13 UTC (permalink / raw)
To: Takashi Oe, linuxppc-dev
On Wed, Sep 29, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:
>I'm fairly certain it's a bug. Good spotting. The last restore_flags()
>shouldn't be there.
>
>--- macserial.c.ORIG Wed Sep 29 02:05:14 1999
>+++ macserial.c Wed Sep 29 02:05:31 1999
>@@ -1381,7 +1381,6 @@
> if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
> && !info->tx_active)
> transmit_chars(info);
>- restore_flags(flags);
> return ret;
> }
This doesn't look like the only problem. For example, in rs_close, we
call tty_wait_until_sent with interrupt disabled. Can't this cause a
deadlock ? There may be other cases like this.
I'll look into adding some fixes and include them in the next kernel I
post on my page (along with a few other stuffs I'd want to get tested,
including your page_alloc() fix which _apparently_ increased the overall
perfs on my machine but I didn't do real benchmarks). But I'm wondering
if we shouldn't include your DMA driver right now and make sure it works
fine instead of doing yet another bunch of patches to the current
macserial. I didn't try the DMA driver yet, are there known problems with it ?
I'll try to make 2.3.x versions of my various patches if I find some time
this week (may have to wait next week end).
On another issue: Is there someone with a 3400 and this famous
interrupt-less ethernet combo out there who knows how to hack into
pmac_pic.c ? I have managed to get the interrupt working with an horrible
hack in de4x5.c, and I'm trying to implement a clean version with a
cascaded controller the way I did if for gatwick on the wallstreet.
Unfortuntately, the clean version doesn't work yet, I don't have one of
those machine to test, and my remote-tester was not able (or didn't have
time) to find out what's going on with the clean version. Any volunteer ?
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 60%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 7:16 64% ` Takashi Oe
1999-09-29 7:40 64% ` Geert Uytterhoeven
1999-09-29 9:13 60% ` Benjamin Herrenschmidt
@ 1999-09-29 16:44 64% ` Lou Langholtz
1999-09-29 17:02 64% ` Benjamin Herrenschmidt
1999-09-29 18:46 64% ` Lou Langholtz
1999-09-29 20:00 64% ` Lou Langholtz
4 siblings, 1 reply; 200+ results
From: Lou Langholtz @ 1999-09-29 16:44 UTC (permalink / raw)
To: Takashi Oe; +Cc: linuxppc-dev
Takashi Oe wrote:
> > . . . .seems like this might introduce a bug if we could get interrupted after
> the
> > restore of the new_flags but before the second restore of old flags in such a
> > way such that the proper state of old_flags could change. I'm not comfortable
> > enough though with my understanding of interrupts and driver routines to be
> > certain one way or another. To be more specific, consider the case on just a
> > single processor system. If this strikes anyone else as a possible race
> > condition that could introduce a bug, then this is what we need to fix in
> > macserial.c's rs_write routine since this code can potentially happen.
>
> I'm fairly certain it's a bug. Good spotting. The last restore_flags()
> shouldn't be there.
>
> --- macserial.c.ORIG Wed Sep 29 02:05:14 1999
> +++ macserial.c Wed Sep 29 02:05:31 1999
> @@ -1381,7 +1381,6 @@
> if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
> && !info->tx_active)
> transmit_chars(info);
> - restore_flags(flags);
> return ret;
> }
>
> Takashi Oe
This is pretty much the kernel I'm running now. I haven't had the "FB. overflow"
message yet nor system-freeze but I've experienced the TCP slowdown already.
Evidence that we've got other problems as well (IMO). It's only been 20 hours or
so with new kernel so not enough time for me to feel confident though about these
results.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 16:44 64% ` Lou Langholtz
@ 1999-09-29 17:02 64% ` Benjamin Herrenschmidt
1999-09-29 18:08 63% ` Lou Langholtz
0 siblings, 1 reply; 200+ results
From: Benjamin Herrenschmidt @ 1999-09-29 17:02 UTC (permalink / raw)
To: Lou Langholtz, linuxppc-dev
On Wed, Sep 29, 1999, Lou Langholtz <ldl@chpc.utah.edu> wrote:
>This is pretty much the kernel I'm running now. I haven't had the "FB.
>overflow"
>message yet nor system-freeze but I've experienced the TCP slowdown already.
>Evidence that we've got other problems as well (IMO). It's only been 20 hours
>or
>so with new kernel so not enough time for me to feel confident though about
>these
>results.
I've added another fix to the kernel on my test page
(http://calvaweb.calvacom.fr/bh40/test.html). It may fix the hang on
close. I don't think it will fix anything related to a slowdown however.
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 17:02 64% ` Benjamin Herrenschmidt
@ 1999-09-29 18:08 63% ` Lou Langholtz
0 siblings, 0 replies; 200+ results
From: Lou Langholtz @ 1999-09-29 18:08 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
Benjamin Herrenschmidt wrote:
> On Wed, Sep 29, 1999, Lou Langholtz <ldl@chpc.utah.edu> wrote:
>
> >This is pretty much the kernel I'm running now. I haven't had the "FB.
> >overflow" message yet nor system-freeze but I've experienced the TCP slowdown
> already.
> >Evidence that we've got other problems as well (IMO). It's only been 20 hours
> >or so with new kernel so not enough time for me to feel confident though about
>
> >these results.
>
> I've added another fix to the kernel on my test page
> (http://calvaweb.calvacom.fr/bh40/test.html). It may fix the hang on
> close. I don't think it will fix anything related to a slowdown however.
It's interesting to note that you chose to move save_flags(flags) in
rs_write() to just before the cli()'s. What was your reasoning? I'm asking so
I can get a better understanding of all the implications of this. Most code that
I've perused so far now does what you've basically done --- keeps the
save_flags() right before the cli()'s. When I chose to just to remove that last
restore_flags() I was basing my descision not to move the originall
save_flags() on the rs_write() code in drivers/char/serial.c. In the serial.c
file they call save_flags() outside of the while loop like the original
rs_write() in macserial.c. This would save time by not being constantly
re-invoked within the loop of course but then this only works if the flags saved
stay valid. That's the part I'm having the most trouble with --- what kind of
calls could invalidate the flags that have been saved.
As to the hang-on-close problem, I've never experienced that before nor heard of
it. Is it something that you've seen or heard of? Your change makes sense anyway.
I'm just being curious in case this might be effecting me in ways I didn't even
realize.
Cheers! :-)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 63%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 7:16 64% ` Takashi Oe
` (2 preceding siblings ...)
1999-09-29 16:44 64% ` Lou Langholtz
@ 1999-09-29 18:46 64% ` Lou Langholtz
1999-09-29 20:00 64% ` Lou Langholtz
4 siblings, 0 replies; 200+ results
From: Lou Langholtz @ 1999-09-29 18:46 UTC (permalink / raw)
To: Takashi Oe; +Cc: linuxppc-dev
Takashi Oe wrote:
> On Wed, 29 Sep 1999, Lou Langholtz wrote:
>
> > What might happen if a driver does:
> >
> > save_flags(old_flags);
> > cli();
> > restore_flags(old_flags);
> > save_flags(new_flags);
> > cli();
> > restore_flags(new_flags);
> > /* can't we be interupted here? Assume yes, if so */
> > restore_flags(old_flags);
> >. . .
> I'm fairly certain it's a bug. Good spotting. The last restore_flags()
> shouldn't be there.
>
> --- macserial.c.ORIG Wed Sep 29 02:05:14 1999
> +++ macserial.c Wed Sep 29 02:05:31 1999
> @@ -1381,7 +1381,6 @@
> if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
> && !info->tx_active)
> transmit_chars(info);
> - restore_flags(flags);
> return ret;
> }
>
> Takashi Oe
If this is true, then what about wherever else transmit_chars() is called. There's
numerous instances where because transmit_chars() itself goes into a save_flags();
cli(); ...; restore_flags() where we have these nested cli()... restore_flags().
For instance in rs_throttle() transmit_chars() is called while cli()'s already in
effect. If the real problem is the nesting of the locks introduced by
transmit_chars() then this would also seem to explain the TCP die-off phenomena.
Opinions?
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 7:16 64% ` Takashi Oe
` (3 preceding siblings ...)
1999-09-29 18:46 64% ` Lou Langholtz
@ 1999-09-29 20:00 64% ` Lou Langholtz
1999-09-30 1:14 64% ` Takashi Oe
` (2 more replies)
4 siblings, 3 replies; 200+ results
From: Lou Langholtz @ 1999-09-29 20:00 UTC (permalink / raw)
To: Takashi Oe; +Cc: linuxppc-dev
Takashi Oe wrote:
> . . .I'm fairly certain it's a bug. Good spotting. The last restore_flags()
> shouldn't be there.
>
> --- macserial.c.ORIG Wed Sep 29 02:05:14 1999
> +++ macserial.c Wed Sep 29 02:05:31 1999
> @@ -1381,7 +1381,6 @@
> if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
> && !info->tx_active)
> transmit_chars(info);
> - restore_flags(flags);
> return ret;
> }
>
> Takashi Oe
Bummer...
I just locked up my system and had to reboot. The above change then doesn't seem
to fix the system hangs. On the other hand I never did see the "FB. overflow"
message at least.
I've been trying to search around HOWTOs and FAQs and mailing lists to get a
better idea of wether nesting save_flags(flags); cli(); stuff...;
save_flags(new_flags); cli(); restore_flags(new_flags); restore_flags(flags); is
ever even ok. Haven't found anything conclusive yet though. Whatever the case, it
doesn't seem like it'd be good practice anyhow. All the other serial support C
files I've found so far seem to avoid this except for macserial.c.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 9:13 60% ` Benjamin Herrenschmidt
@ 1999-09-30 0:46 64% ` Takashi Oe
1999-09-30 8:50 64% ` Benjamin Herrenschmidt
1999-10-12 7:20 64% ` Lou Langholtz
0 siblings, 2 replies; 200+ results
From: Takashi Oe @ 1999-09-30 0:46 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Wed, 29 Sep 1999, Benjamin Herrenschmidt wrote:
> This doesn't look like the only problem. For example, in rs_close, we
> call tty_wait_until_sent with interrupt disabled. Can't this cause a
> deadlock ? There may be other cases like this.
>
> I'll look into adding some fixes and include them in the next kernel I
> post on my page (along with a few other stuffs I'd want to get tested,
> including your page_alloc() fix which _apparently_ increased the overall
> perfs on my machine but I didn't do real benchmarks). But I'm wondering
The __get_free_pages() fix is probably not needed for 2.2.13pre, although
something similar might save a few hundred cycles. Anyway, much to my
amazement, there is significant differences in a number of errors ppp link
report between the kernels with and without the __get_free_pages() patch.
With a stock 2.2.12 kernel, ppp link used to report 1 to 10% frame errors.
But, now, it hardly ever reports any error. Besides, my machine hasn't
crashed for two days. I can't remember the last time that my machine
stayed up so long.
> if we shouldn't include your DMA driver right now and make sure it works
> fine instead of doing yet another bunch of patches to the current
> macserial. I didn't try the DMA driver yet, are there known problems with it ?
I don't know of any major flaw, but the DMA code can use some testings.
I've only tested it on Power Mac 7600 with baud rate of upto 115200 bps.
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 20:00 64% ` Lou Langholtz
@ 1999-09-30 1:14 64% ` Takashi Oe
1999-09-30 5:33 63% ` Geert Uytterhoeven
1999-10-01 13:26 64% ` Franz Sirl
2 siblings, 0 replies; 200+ results
From: Takashi Oe @ 1999-09-30 1:14 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linuxppc-dev
On Wed, 29 Sep 1999, Lou Langholtz wrote:
> Bummer...
>
> I just locked up my system and had to reboot. The above change then doesn't seem
> to fix the system hangs. On the other hand I never did see the "FB. overflow"
> message at least.
>
> I've been trying to search around HOWTOs and FAQs and mailing lists to get a
> better idea of wether nesting save_flags(flags); cli(); stuff...;
> save_flags(new_flags); cli(); restore_flags(new_flags); restore_flags(flags); is
Basically, cli() disables interrupts. If the interrupts are disabled to
begin with, it amounts to nothing. So, I think the nesting should cause
no harm.
> ever even ok. Haven't found anything conclusive yet though. Whatever the case, it
> doesn't seem like it'd be good practice anyhow. All the other serial support C
> files I've found so far seem to avoid this except for macserial.c.
>
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 20:00 64% ` Lou Langholtz
1999-09-30 1:14 64% ` Takashi Oe
@ 1999-09-30 5:33 63% ` Geert Uytterhoeven
1999-10-01 13:26 64% ` Franz Sirl
2 siblings, 0 replies; 200+ results
From: Geert Uytterhoeven @ 1999-09-30 5:33 UTC (permalink / raw)
To: Lou Langholtz; +Cc: Takashi Oe, linuxppc-dev
On Wed, 29 Sep 1999, Lou Langholtz wrote:
> Takashi Oe wrote:
>
> > . . .I'm fairly certain it's a bug. Good spotting. The last restore_flags()
> > shouldn't be there.
> >
> > --- macserial.c.ORIG Wed Sep 29 02:05:14 1999
> > +++ macserial.c Wed Sep 29 02:05:31 1999
> > @@ -1381,7 +1381,6 @@
> > if (info->xmit_cnt && !tty->stopped && !info->tx_stopped
> > && !info->tx_active)
> > transmit_chars(info);
> > - restore_flags(flags);
> > return ret;
> > }
> >
> > Takashi Oe
>
> Bummer...
>
> I just locked up my system and had to reboot. The above change then doesn't seem
> to fix the system hangs. On the other hand I never did see the "FB. overflow"
> message at least.
>
> I've been trying to search around HOWTOs and FAQs and mailing lists to get a
> better idea of wether nesting save_flags(flags); cli(); stuff...;
> save_flags(new_flags); cli(); restore_flags(new_flags); restore_flags(flags); is
> ever even ok. Haven't found anything conclusive yet though. Whatever the case, it
> doesn't seem like it'd be good practice anyhow. All the other serial support C
> files I've found so far seem to avoid this except for macserial.c.
Nesting `save_flags(); cli(); ... restore_flags();' is perfectly legal. That's
exactly the reason why `save_flags()' and `restore_flags()' were invented!
Normally, to disable interrupts to make sure a critical code section is not
interrupted, you do:
cli();
...
sti();
The problem with this construct is that the `sti()' will always re-enable the
interrupts, even when they were disabled when the `cli()' was called, like in
void func(void)
{
...
cli();
...
sti();
... // interrupts accidentally re-enabled here!
}
cli();
...
func();
...
sti();
So `save_flags()' saves the current interrupt mask, and `restore_flags()'
restores it. Problem solved by writing:
void func(void)
{
...
save_flags(flags);
cli();
...
restore_flags(flags);
... // interrupts accidentally re-enabled here!
}
For former AmigaOS programmers: it's a bit like the Disable()/Enable() Exec
functions, which allowed nestings:
int interrupt_disable_cnt = 0;
void Disable(void)
{
cli();
interrupt_disable_cnt++;
}
void Enable(void)
{
if (--interrupt_disable_cnt == 0)
sti();
}
Conclusion: use `cli()/sti()' when you're 100% sure interrupts were enabled
before the cli() was called, and `save_flags()/cli()/restore_flags()' when
interrupts may be disabled when entering your code.
Greetings,
Geert
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248648 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 63%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-30 0:46 64% ` Takashi Oe
@ 1999-09-30 8:50 64% ` Benjamin Herrenschmidt
1999-09-30 16:21 64% ` Takashi Oe
1999-10-12 7:20 64% ` Lou Langholtz
1 sibling, 1 reply; 200+ results
From: Benjamin Herrenschmidt @ 1999-09-30 8:50 UTC (permalink / raw)
To: Takashi Oe, linuxppc-dev
On Wed, Sep 29, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:
>I don't know of any major flaw, but the DMA code can use some testings.
>I've only tested it on Power Mac 7600 with baud rate of upto 115200 bps.
I've heard of various possible issues with DMA hardware on the serial
ports and G3 macs. There seem to be a problem with the Heathrow
generation of Apple ASICs. (This was reported to me by people who made a
special device that was plugged into those ports, with a custom driver
under MacOS). They told me some characters end up beeing garbled when
reaching the SCC. I'll do some testings with your driver and my
powerbook's internal modem this week end to see if this problem actually
occurs or not.
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-30 8:50 64% ` Benjamin Herrenschmidt
@ 1999-09-30 16:21 64% ` Takashi Oe
1999-09-30 16:35 64% ` Benjamin Herrenschmidt
0 siblings, 1 reply; 200+ results
From: Takashi Oe @ 1999-09-30 16:21 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
On Thu, 30 Sep 1999, Benjamin Herrenschmidt wrote:
> I've heard of various possible issues with DMA hardware on the serial
> ports and G3 macs. There seem to be a problem with the Heathrow
> generation of Apple ASICs. (This was reported to me by people who made a
> special device that was plugged into those ports, with a custom driver
> under MacOS). They told me some characters end up beeing garbled when
> reaching the SCC. I'll do some testings with your driver and my
> powerbook's internal modem this week end to see if this problem actually
> occurs or not.
I suppose that can happen if DBDMA's FIFO wasn't flushed properly for
some reason. Do you know if the problem occurs on receiving side (from
SCC to DMA) or transmitting side (from DMA to SCC)? How many chars were
garbled? If the FIFO were the cause of the problem, the number should be
between 1 and 7.
Takashi Oe
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-30 16:21 64% ` Takashi Oe
@ 1999-09-30 16:35 64% ` Benjamin Herrenschmidt
0 siblings, 0 replies; 200+ results
From: Benjamin Herrenschmidt @ 1999-09-30 16:35 UTC (permalink / raw)
To: Takashi Oe, linuxppc-dev
On Thu, Sep 30, 1999, Takashi Oe <toe@unlserve.unl.edu> wrote:
>I suppose that can happen if DBDMA's FIFO wasn't flushed properly for
>some reason. Do you know if the problem occurs on receiving side (from
>SCC to DMA) or transmitting side (from DMA to SCC)? How many chars were
>garbled? If the FIFO were the cause of the problem, the number should be
>between 1 and 7.
I don't know the details, it was quite a long time ago... I'll ask him again.
--
Perso. e-mail: <mailto:bh40@calva.net>
Work e-mail: <mailto:benh@mipsys.com>
BenH. Web : <http://calvaweb.calvacom.fr/bh40/>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-29 20:00 64% ` Lou Langholtz
1999-09-30 1:14 64% ` Takashi Oe
1999-09-30 5:33 63% ` Geert Uytterhoeven
@ 1999-10-01 13:26 64% ` Franz Sirl
1999-10-01 13:46 64% ` Alvin Brattli
` (2 more replies)
2 siblings, 3 replies; 200+ results
From: Franz Sirl @ 1999-10-01 13:26 UTC (permalink / raw)
To: Lou Langholtz; +Cc: Takashi Oe, linuxppc-dev
At 22:00 29.09.99 , Lou Langholtz wrote:
>I just locked up my system and had to reboot. The above change then
>doesn't seem
>to fix the system hangs. On the other hand I never did see the "FB. overflow"
>message at least.
Hmm, in the recent kernels Paul changed the code to only print the FB
message once! For me these lockups (I'm using vger nearly unmodified) are
gone since quite a while, but I don't really know a reason why. The major
specialties on my 7200/75 are:
- disabled syslog's fsync'ing of /var/log/messages (this prevents the
amplifying effect of the FB messages)
- all major stuff is compiled with gcc-2.95.2pre
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-10-01 13:26 64% ` Franz Sirl
@ 1999-10-01 13:46 64% ` Alvin Brattli
[not found] ` <Pine.OSF.3.96.991001153658.16772E-100000@mitra.phys.uit.no >
1999-10-01 16:14 64% ` Lou Langholtz
2 siblings, 0 replies; 200+ results
From: Alvin Brattli @ 1999-10-01 13:46 UTC (permalink / raw)
To: linuxppc-dev
On Fri, 1 Oct 1999, Franz Sirl wrote:
>(I'm using vger nearly unmodified)
This is one thing that has been escaping me for quite a while: how do I
get a specific version of the vger kernel, and how do I get a list of
the versions I can checkout? Following the instructions given on
<http://cvs.on.openprojects.net/> only gives me the current vger
development kernel (2.3.X), and not for example the latest 2.2.X kernel
(actually, the "kernel" module does seem to exist on cvs.on.openprojects.net;
after trying different things, "linux" worked, and gave me a 2.3.X kernel).
Reading the CVS man files haven't helped me much either.
Can some kind soul enlighten me on this?
aLViN
--
:r .signature
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
[not found] ` <Pine.OSF.3.96.991001153658.16772E-100000@mitra.phys.uit.no >
@ 1999-10-01 14:08 64% ` Franz Sirl
0 siblings, 0 replies; 200+ results
From: Franz Sirl @ 1999-10-01 14:08 UTC (permalink / raw)
To: Alvin Brattli; +Cc: linuxppc-dev
At 15:46 01.10.99 , Alvin Brattli wrote:
>On Fri, 1 Oct 1999, Franz Sirl wrote:
>
> >(I'm using vger nearly unmodified)
>
>This is one thing that has been escaping me for quite a while: how do I
>get a specific version of the vger kernel, and how do I get a list of
>the versions I can checkout? Following the instructions given on
><http://cvs.on.openprojects.net/> only gives me the current vger
>development kernel (2.3.X), and not for example the latest 2.2.X kernel
>(actually, the "kernel" module does seem to exist on cvs.on.openprojects.net;
>after trying different things, "linux" worked, and gave me a 2.3.X kernel).
>Reading the CVS man files haven't helped me much either.
>Can some kind soul enlighten me on this?
cvs update -dP -rlinux_2_2
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-10-01 13:26 64% ` Franz Sirl
1999-10-01 13:46 64% ` Alvin Brattli
[not found] ` <Pine.OSF.3.96.991001153658.16772E-100000@mitra.phys.uit.no >
@ 1999-10-01 16:14 64% ` Lou Langholtz
2 siblings, 0 replies; 200+ results
From: Lou Langholtz @ 1999-10-01 16:14 UTC (permalink / raw)
To: Franz Sirl; +Cc: Takashi Oe, linuxppc-dev
Franz Sirl wrote:
> At 22:00 29.09.99 , Lou Langholtz wrote:
> >I just locked up my system and had to reboot. The above change then
> >doesn't seem
> >to fix the system hangs. On the other hand I never did see the "FB. overflow"
> >message at least.
>
> Hmm, in the recent kernels Paul changed the code to only print the FB
> message once! For me these lockups (I'm using vger nearly unmodified) are
> gone since quite a while, but I don't really know a reason why. The major
> specialties on my 7200/75 are:
>
> - disabled syslog's fsync'ing of /var/log/messages (this prevents the
> amplifying effect of the FB messages)
> - all major stuff is compiled with gcc-2.95.2pre
>
> Franz.
thats good to hear. you're using a kernel newer than 2.2.12 which has the fixes
i've been experimenting with plus others. like only printing the fb overflow
message the first time it occurs in the sequence rather than all the time. the
overflow may still be occuring but the message wont keep getting printed. this no
doubt makes a few things more usable but by itself shouldn't prevent the tcp slow
down to nothing over ppp nor the complete lock up. there's also a kernel memory
routine that has some ppc specific fixes to it which seems to greatly imprive ppp
performance. 2.2.12 still has some sti() calls in macserial.c which look
suspicious. the newer code has gotten rid of at least some of those and i'm now
running a kernel that has none of those in macserial.c. this seems to be running
much better but i haven't run long enough to have a high confidence that that was
particularly problematic.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-10 18:33 64% ` Michel Lanners
1999-09-12 16:58 64% ` Lou Langholtz
@ 1999-10-12 6:49 64% ` Lou Langholtz
1999-10-12 14:50 64% ` Daniel Jacobowitz
1 sibling, 1 reply; 200+ results
From: Lou Langholtz @ 1999-10-12 6:49 UTC (permalink / raw)
To: linuxppc-dev
Michel Lanners wrote:
> On 10 Sep, this message from Lou Langholtz echoed through cyberspace:
> > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > 2MB were still being recognized (despite having just added the 2MB to
> > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
> . . .
>
> I guess it's time to clear thgis up once and for all. By the way, I do
> have 4 MB of VRAM, and all of it is detected with the current version
> of controlfb.....
Update:
Even with 2.2.13pre15, the stock controlfb.c still doesn't detect the
4MB VRAM in my 7500 (I just tried it). I have to hack controlfb.c to get it
to use all 4MB. This is perhaps a bug specific only to the PowerMac 7500/100
as others have reported that all VRAM was detected on their PowerMac's
without making any changes like I've had to do.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-09-13 18:13 64% ` Michel Lanners
1999-09-15 15:14 64% ` Lou Langholtz
@ 1999-10-12 7:07 62% ` Lou Langholtz
1 sibling, 0 replies; 200+ results
From: Lou Langholtz @ 1999-10-12 7:07 UTC (permalink / raw)
To: mlan; +Cc: linuxppc-dev
Michel Lanners wrote:
> Hmm... official 2.2.12 does detect my 4 MB... and this is a 7600, so the same
> motherboard as the 7500...
> Michel
Something is wrong then. Using AC's 2.2.13pre15 on my 7500 the driver just doesn't
recognize 4MB of VRAM unless I hack the bank2 check. So either you're not really
getting all 4MB VRAM detected or the 7600 uses a different hardware configuration
than my 7500/100. What does "fbset -i" tell you for size of the frame buffer
device? That the 8500 operates as Andrew Fyfe <bandr@best.com> claimed according
to the comments in one of the patches that someone sent out make sense. The
relevant part of that patch reads:
+ /* According to Andrew Fyfe <bandr@best.com>, the VRAM behaves like so: */
+ /* afyfe: observations from an 8500:
+ * - with 2M vram in bank 1, it appears at offsets 0, 2M and 4M
+ * - with 2M vram in bank 2, it appears only at offset 6M
+ * - with 4M vram, it appears only as a 4M block at offset 0.
+ */
What you're seeing with your 7600 then just doesn't make sense unless it's video
hardware is somehow different than the 7500/100 that I have. The 7500/100 that
I have has only four slots where each slot holds a 1MB VRAM memory module. Is that
the same on the 7600? If the 7600 really has the control video card and yours
really has 4MB VRAM then according to sources the memory must be detectable at
both offset 0, and 6M where the second VRAM bank can actually also handle itself
in a contiguous 4MB block from offset 0. That seems very odd indeed.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 62%]
* Re: [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity]
1999-09-30 0:46 64% ` Takashi Oe
1999-09-30 8:50 64% ` Benjamin Herrenschmidt
@ 1999-10-12 7:20 64% ` Lou Langholtz
1 sibling, 0 replies; 200+ results
From: Lou Langholtz @ 1999-10-12 7:20 UTC (permalink / raw)
To: Takashi Oe; +Cc: linuxppc-dev
Takashi Oe wrote:
> On Wed, 29 Sep 1999, Benjamin Herrenschmidt wrote:
>
> > . . .
> > I'll look into adding some fixes and include them in the next kernel I
> > post on my page (along with a few other stuffs I'd want to get tested,
> > including your page_alloc() fix which _apparently_ increased the overall
> > perfs on my machine but I didn't do real benchmarks). But I'm wondering
>
> The __get_free_pages() fix is probably not needed for 2.2.13pre, although
> something similar might save a few hundred cycles. Anyway, much to my
> amazement, there is significant differences in a number of errors ppp link
> report between the kernels with and without the __get_free_pages() patch.
> With a stock 2.2.12 kernel, ppp link used to report 1 to 10% frame errors.
> But, now, it hardly ever reports any error. Besides, my machine hasn't
> crashed for two days. I can't remember the last time that my machine
> stayed up so long. . .
I'm running AC's 2.2.13pre15 now and still seeing high error rates (17 out of 472
recieved packets). So if it even might just save a few extra cycles it still seems
worthwhile to add this __get_free_pages() fix, especially if it might have the
chance of getting rid of the high error rates again. I'll try it myself but I
suspect you could get it done much faster if this was enough inclination for you
;-)
Also, any idea why this wouldn't be true on for transmit errors? At least on my
machine, ifconfig ppp0 always reports zero errors and zero overruns on TX packets.
This seems like a good clue I'll have to dig more into :-)
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-10-12 6:49 64% ` Lou Langholtz
@ 1999-10-12 14:50 64% ` Daniel Jacobowitz
1999-10-12 15:36 64% ` Lou Langholtz
0 siblings, 1 reply; 200+ results
From: Daniel Jacobowitz @ 1999-10-12 14:50 UTC (permalink / raw)
To: Lou Langholtz; +Cc: linuxppc-dev
Could you check whether that kernel has the patch I posted to this list
last month applied?
The patch was in Message-ID: <19990912141014.A17732@them.org>.
On Tue, Oct 12, 1999 at 12:49:34AM -0600, Lou Langholtz wrote:
>
> Michel Lanners wrote:
>
> > On 10 Sep, this message from Lou Langholtz echoed through cyberspace:
> > > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > > 2MB were still being recognized (despite having just added the 2MB to
> > > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
> > . . .
> >
> > I guess it's time to clear thgis up once and for all. By the way, I do
> > have 4 MB of VRAM, and all of it is detected with the current version
> > of controlfb.....
>
> Update:
>
> Even with 2.2.13pre15, the stock controlfb.c still doesn't detect the
> 4MB VRAM in my 7500 (I just tried it). I have to hack controlfb.c to get it
> to use all 4MB. This is perhaps a bug specific only to the PowerMac 7500/100
> as others have reported that all VRAM was detected on their PowerMac's
> without making any changes like I've had to do.
>
>
>
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-10-12 14:50 64% ` Daniel Jacobowitz
@ 1999-10-12 15:36 64% ` Lou Langholtz
1999-10-13 6:30 64% ` Geert Uytterhoeven
0 siblings, 1 reply; 200+ results
From: Lou Langholtz @ 1999-10-12 15:36 UTC (permalink / raw)
To: Daniel Jacobowitz; +Cc: linuxppc-dev
Daniel Jacobowitz wrote:
> Could you check whether that kernel has the patch I posted to this list
> last month applied?
As you suspect, 2.2.13pre15 does not have your patch. AC's 2.2.13pre15 doesn't
have any changes at all to it's controlfb.c code. It's still the same as even in
the kernel distro of 2.2.6 (which is the earliest kernel I still have a copy of
source for on hand). Given a number of different behavioral characteristics
people have been describing of kernel's from vger I'd say there's been other
changes as well that still haven't made it into the Linus or AC distributed
kernel sources either unfortunately. I'm not in the privvy as far as I know
however to push these changes into the main stream kernel sources but if you or
someone else on this lilst is I say: "please, please get the in!". ;-) I guess in
the meantime I'm going to have to try sucking down the sources from vger but
given that I've been badly afflicted by the PPP/TCP death march that I and others
have been discussing I'm unsure I'll succeed at getting the whole thing from
vger.
> The patch was in Message-ID: <19990912141014.A17732@them.org>.
> On Tue, Oct 12, 1999 at 12:49:34AM -0600, Lou Langholtz wrote:
> > Michel Lanners wrote:
> > > On 10 Sep, this message from Lou Langholtz echoed through cyberspace:
> > > > After getting an extra 2MB VRAM for my PowerMac7500 and seeing that only
> > > > 2MB were still being recognized (despite having just added the 2MB to
> > > > total to 4MB VRAM), I dug into the controlfb.c code from 2.2.11 and
> > > > 2.2.12 and made the following changes to get all 4MB VRAM recognized:
> > > . . .
> > Even with 2.2.13pre15, the stock controlfb.c still doesn't detect the
> > 4MB VRAM in my 7500 (I just tried it). . . .
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: controlfb.c bug in VRAM bank2 check if bank1
1999-10-12 15:36 64% ` Lou Langholtz
@ 1999-10-13 6:30 64% ` Geert Uytterhoeven
0 siblings, 0 replies; 200+ results
From: Geert Uytterhoeven @ 1999-10-13 6:30 UTC (permalink / raw)
To: Lou Langholtz; +Cc: Daniel Jacobowitz, linuxppc-dev
On Tue, 12 Oct 1999, Lou Langholtz wrote:
> Daniel Jacobowitz wrote:
>
> > Could you check whether that kernel has the patch I posted to this list
> > last month applied?
>
> As you suspect, 2.2.13pre15 does not have your patch. AC's 2.2.13pre15 doesn't
> have any changes at all to it's controlfb.c code. It's still the same as even in
> the kernel distro of 2.2.6 (which is the earliest kernel I still have a copy of
> source for on hand). Given a number of different behavioral characteristics
> people have been describing of kernel's from vger I'd say there's been other
> changes as well that still haven't made it into the Linus or AC distributed
> kernel sources either unfortunately. I'm not in the privvy as far as I know
> however to push these changes into the main stream kernel sources but if you or
> someone else on this lilst is I say: "please, please get the in!". ;-) I guess in
> the meantime I'm going to have to try sucking down the sources from vger but
> given that I've been badly afflicted by the PPP/TCP death march that I and others
> have been discussing I'm unsure I'll succeed at getting the whole thing from
> vger.
Linus accepted all video patches I sent him for 2.3.20.
Note that I assume no responsabilities for the video stuff in 2.2.x. I barely
have time to take care of 2.3.x.
That's the problem with anything besides ia32: we hardly have enough manpower
to work on 2.3.x, so who's taking care of 2.2.x?
Greetings,
Geert
--
Geert Uytterhoeven ----------------- Sony Suprastructure Center Europe (SUPC-E)
Geert.Uytterhoeven@sonycom.com ------------------- Sint Stevens Woluwestraat 55
Phone +32-2-7248632 Fax +32-2-7262686 ---------------- B-1130 Brussels, Belgium
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Bug Discovered in Binutils/GCC for PPC403
[not found] <Pine.SGI.4.10.9910281200550.695157-100000@sapphire.lcse.umn.edu>
@ 1999-10-28 17:31 64% ` Grant Erickson
0 siblings, 0 replies; 200+ results
From: Grant Erickson @ 1999-10-28 17:31 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Daniel Nilsson, Adrian Cox, Wolfgang Denk
For those of you working with the TiVo Linux sources, I discovered bug in
binutils-2.9.1.0.25 and binutils-2.9.5.0.14 that results in the following
sorts of error:
foobar.c: Assembler messages:
foobar.c:7868: Error: junk at end of line: `28'
It appears that the assembler has the incorrect definition for the
'dcread' instruction:
In the file binutils-2.9.5.0.14/opcodes/ppc-opc.c, the definition is as
follows:
{ "dcread", X(31,486), XRT_MASK, PPC403, { RA, RB } },
However, according to the IBM PowerPC 403GCX manual the definition is:
dcread RT,RA,RB
The patch to fix this is:
{ "dcread", X(31,486), X_MASK, PPC403, { RT, RA, RB } },
Patch the ppc-opc.c file and rebuild binutils and you're back on your way.
Otherwise, just comment out the offending line of code, such as:
asm("dcread %0,0,%1" : "=r" (tag) : "r" (p));
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* bug in getenv/putenv on linuxppc/G4
@ 1999-11-01 8:02 64% Jon A. Christopher
1999-11-01 12:55 64% ` Marcus Sundberg
0 siblings, 1 reply; 200+ results
From: Jon A. Christopher @ 1999-11-01 8:02 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 877 bytes --]
I've just discovered a bug in either getenv (probably) or putenv (less
likely) on linuxppc on a G4, glibc-2.1.1-6c.
The attached test program demonstrates the bug. Basically, using putenv
to add a variable to the environment whose name is only one letter long
and then using getenv to read it doesn't work.
Variables with two or more letters are processed as normal.
I'm not sure if this is a glibc or a linuxppc problem, but I don't have
teh same problem on my intel RH 5.2 box, or any other unix I've ever heard
of.
-jon
Please CC replies to me, since I'm not on this list.
--
Dr. Jon A. Christopher / jac8792@tamu.edu | Project URLs:
Department of Biochem./Biophys. / spock: http://quorum.tamu.edu/spock
Texas A&M University MS-2128 / lesstif: http://www.lesstif.org/
College Station, TX, 77843 / personal: http://quorum.tamu.edu/jon
[-- Attachment #2: Type: TEXT/PLAIN, Size: 237 bytes --]
#include <stdio.h>
#include <stdlib.h>
main()
{
/* doesn't work on ppc, but should */
putenv("i=1");
printf("got: i=%s\n",getenv("i"));
/* works on ppc */
putenv("ii=1");
printf("got: ii=%s\n",getenv("ii"));
}
^ permalink raw reply [relevance 64%]
* Re: bug in getenv/putenv on linuxppc/G4
1999-11-01 8:02 64% bug in getenv/putenv on linuxppc/G4 Jon A. Christopher
@ 1999-11-01 12:55 64% ` Marcus Sundberg
0 siblings, 0 replies; 200+ results
From: Marcus Sundberg @ 1999-11-01 12:55 UTC (permalink / raw)
To: Jon A. Christopher; +Cc: linuxppc-dev
"Jon A. Christopher" <jon@amanda.tamu.edu> writes:
> I've just discovered a bug in either getenv (probably) or putenv (less
> likely) on linuxppc on a G4, glibc-2.1.1-6c.
>
> The attached test program demonstrates the bug. Basically, using putenv
> to add a variable to the environment whose name is only one letter long
> and then using getenv to read it doesn't work.
>
> Variables with two or more letters are processed as normal.
>
> I'm not sure if this is a glibc or a linuxppc problem, but I don't have
> teh same problem on my intel RH 5.2 box, or any other unix I've ever heard
> of.
It's a libc problem, reported on the libc-alpha list a few months
ago, and I think a patch was posted too.
It's fixed in glibc 2.1.2 in any case.
//Marcus
--
-------------------------------+------------------------------------
Marcus Sundberg | http://www.stacken.kth.se/~mackan/
Royal Institute of Technology | Phone: +46 707 295404
Stockholm, Sweden | E-Mail: mackan@stacken.kth.se
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Bug in ptrace on smp systems
@ 1999-11-15 14:06 64% D.J. Barrow
0 siblings, 0 replies; 200+ results
From: D.J. Barrow @ 1999-11-15 14:06 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I found a bugs which causes gdb to go to sleep
forever on smp systems occaisionally
in ptrace.c in the 2.2.10 kernel
( maybe you've this fixed maybe not )
in the sys_ptrace call you are
setting exit_code in most cases after calling
wake_up_process(child) this is incorrect as the
function sys_wait4 will get very confused on smp
systems as the process will be woken up on another
processor & deliver a new exit_code from do_signal
which this code will subsequently clear.
It also would be wise to move the clear_single_step
statement before wake_up_process in PTRACE_CONT.
For the correct treatment of exit_code look at the
intel code.
D.J.
=====
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* [parisc-linux] Trivial Makefile Bug
@ 1999-11-16 19:08 63% John David Anglin
0 siblings, 0 replies; 200+ results
From: John David Anglin @ 1999-11-16 19:08 UTC (permalink / raw)
To: parisc-linux
This has been around for awhile.
ld -R 0xc0010000 -N -e stext arch/parisc/real/head.o arch/parisc/kernel/init_task.o init/main.o init/version.o \
arch/parisc/boot/ramdisk.o arch/parisc/kernel/kernel.o arch/parisc/real/real.o arch/parisc/mm/mm.o kernel/kernel.o mm/mm.o fs/fs.o ipc/ipc.o \
fs/filesystems.a \
net/network.a \
drivers/block/block.a drivers/gsc/gsc.a drivers/char/char.a drivers/net/net.a drivers/pci/pci.a \
/ehic/a/pa/linux/arch/parisc/lib/lib.a /ehic/a/pa/linux/lib/lib.a /ehic/a/pa/linux/arch/parisc/lib/lib.a \
-o vmlinux
If this fails, you're not using GNU nm!
Make sure you have it in your path before HPUX nm.
nm --version > /dev/null 2>&1
nm -td vmlinux |awk '/init_task_union/ { n = int(); t = int(n/8192); t *= 8192; if (t >= n) printf t-n ; else printf n-(t-8192)}' FS=\| > init_task.alignment
awk: cmd. line:1: fatal: int() cannot have 0 arguments
make[1]: *** [vmlinux-real] Error 2
make[1]: Leaving directory `/ehic/a/pa/linux'
make: *** [vmlinux] Error 2
I believe that the argument of int in the awk script needs to be changed
to "$$1".
Dave
--
J. David Anglin dave.anglin@nrc.ca
National Research Council of Canada (613) 990-0752 (FAX: 952-6605)
^ permalink raw reply [relevance 63%]
* Silly bug in sb_ess.c
@ 1999-11-30 22:47 47% Rolf Fokkens
0 siblings, 0 replies; 200+ results
From: Rolf Fokkens @ 1999-11-30 22:47 UTC (permalink / raw)
To: linux-sound
[-- Attachment #1: Type: text/plain, Size: 463 bytes --]
Kernel maintainers,
Cvetan Ivanov pointed out I made a silly programming error in sb_ess.c. In
2.2 this has been taken care of, it hasn't been taken care of in 2.3. I attached
the patch.
The bug is probably harmfull for machines that don't have a BIOS which
initializes the chip. In these cases non ES1887 chips will have no
initialization for their DMA channel at all.
I've seen previous problem reports that might be related to this bug as well.
Rolf.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sb_ess.c-2.3.29.patch --]
[-- Type: text/english; name="sb_ess.c-2.3.29.patch", Size: 4863 bytes --]
--- ../new/linux-2.3.29/drivers/sound/sb_ess.c Sat Oct 2 16:49:30 1999
+++ linux/drivers/sound/sb_ess.c Wed Oct 27 22:27:01 1999
@@ -10,29 +10,29 @@
*
* History:
*
- * Rolf Fokkens (Dec 20 1998): ES188x recording level support on a per
+ * Rolf Fokkens (Dec 20 1998): ES188x recording level support on a per
* fokkensr@vertis.nl input basis.
- * (Dec 24 1998): Recognition of ES1788, ES1887, ES1888,
+ * (Dec 24 1998): Recognition of ES1788, ES1887, ES1888,
* ES1868, ES1869 and ES1878. Could be used for
* specific handling in the future. All except
* ES1887 and ES1888 and ES688 are handled like
* ES1688.
- * (Dec 27 1998): RECLEV for all (?) ES1688+ chips. ES188x now
+ * (Dec 27 1998): RECLEV for all (?) ES1688+ chips. ES188x now
* have the "Dec 20" support + RECLEV
- * (Jan 2 1999): Preparation for Full Duplex. This means
+ * (Jan 2 1999): Preparation for Full Duplex. This means
* Audio 2 is now used for playback when dma16
* is specified. The next step would be to use
* Audio 1 and Audio 2 at the same time.
- * (Jan 9 1999): Put all ESS stuff into sb_ess.[ch], this
+ * (Jan 9 1999): Put all ESS stuff into sb_ess.[ch], this
* includes both the ESS stuff that has been in
* sb_*[ch] before I touched it and the ESS support
* I added later
- * (Jan 23 1999): Full Duplex seems to work. I wrote a small
+ * (Jan 23 1999): Full Duplex seems to work. I wrote a small
* test proggy which works OK. Haven't found
* any applications to test it though. So why did
* I bother to create it anyway?? :) Just for
* fun.
- * (May 2 1999): I tried to be too smart by "introducing"
+ * (May 2 1999): I tried to be too smart by "introducing"
* ess_calc_best_speed (). The idea was that two
* dividers could be used to setup a samplerate,
* ess_calc_best_speed () would choose the best.
@@ -40,10 +40,12 @@
* recording problems for high samplerates. I
* fixed this by removing ess_calc_best_speed ()
* and just doing what the documentation says.
- * Andy Sloane (June 4 1999): Stole some code from ALSA to fix the playback
+ * Andy Sloane (Jun 4 1999): Stole some code from ALSA to fix the playback
* andy@guildsoftware.com speed on ES1869, ES1879, ES1887, and ES1888.
* 1879's were previously ignored by this driver;
* added (untested) support for those.
+ * Cvetan Ivanov (Oct 27 1999): Fixed ess_dsp_init to call ess_set_dma_hw for
+ * zezo@inet.bg _ALL_ ESS models, not only ES1887
*
* This files contains ESS chip specifics. It's based on the existing ESS
* handling as it resided in sb_common.c, sb_mixer.c and sb_audio.c. This
@@ -52,7 +54,7 @@
* - RECLEV support for ES1688 and later
* - 6 bits playback level support chips later than ES1688
* - Recording level support on a per-device basis for ES1887
- * - Full-Duplex for ES1887 (under development)
+ * - Full-Duplex for ES1887
*
* Full duplex is enabled by specifying dma16. While the normal dma must
* be one of 0, 1 or 3, dma16 can be one of 0, 1, 3 or 5. DMA 5 is a 16 bit
@@ -100,7 +102,7 @@
* of writing 0x00 to 0x7f (which should be done by reset): The ES1887 moves
* into ES1888 mode. This means that it claims IRQ 11, which happens to be my
* ISDN adapter. Needless to say it no longer worked. I now understand why
- * after rebooting 0x7f already was 0x05, the value of my choise: the BIOS
+ * after rebooting 0x7f already was 0x05, the value of my choice: the BIOS
* did it.
*
* Oh, and this is another trap: in ES1887 docs mixer register 0x70 is decribed
@@ -1200,10 +1202,10 @@
/* AAS: info stolen from ALSA: these boards have different clocks */
switch(devc->submodel) {
-/* APPARENTLY NOT 1869
+/* APPARENTLY NOT 1869 AND 1887
case SUBMDL_ES1869:
-*/
case SUBMDL_ES1887:
+*/
case SUBMDL_ES1888:
devc->caps |= SB_CAP_ES18XX_RATE;
break;
@@ -1305,6 +1307,13 @@
int ess_dsp_init (sb_devc *devc, struct address_info *hw_config)
{
/*
+ * Caller also checks this, but anyway
+ */
+ if (devc->model != MDL_ESS) {
+ printk (KERN_INFO "ess_dsp_init for non ESS chip\n");
+ return 1;
+ }
+ /*
* This for ES1887 to run Full Duplex. Actually ES1888
* is allowed to do so too. I have no idea yet if this
* will work for ES1888 however.
@@ -1324,15 +1333,12 @@
if (devc->dma8 != devc->dma16 && devc->dma16 != -1) {
devc->duplex = 1;
}
-
- if (!ess_set_dma_hw (devc)) {
- free_irq(devc->irq, devc);
- return 0;
- }
- return 1;
- } else {
- return -1;
}
+ if (!ess_set_dma_hw (devc)) {
+ free_irq(devc->irq, devc);
+ return 0;
+ }
+ return 1;
}
/****************************************************************************
^ permalink raw reply [relevance 47%]
* PATCH: Silly bug in sb_ess.c in 2.3.29
@ 1999-12-02 16:51 47% Rolf Fokkens
0 siblings, 0 replies; 200+ results
From: Rolf Fokkens @ 1999-12-02 16:51 UTC (permalink / raw)
To: linux-sound
[-- Attachment #1: Type: text/plain, Size: 460 bytes --]
Kernel maintainers,
Cvetan Ivanov pointed out I made a silly programming error in sb_ess.c. In
2.2 this has been taken care of, it hasn't been taken care of in 2.3. I attached
the patch.
The bug is probably harmfull for machines that don't have a BIOS which
initializes the chip. In these cases non ES1887 chips will have no
initialization for their DMA channel at all.
I've seen previous problem reports that might be related to this bug as well.
Rolf.
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: sb_ess.c-2.3.29.patch --]
[-- Type: text/english; name="sb_ess.c-2.3.29.patch", Size: 4863 bytes --]
--- ../new/linux-2.3.29/drivers/sound/sb_ess.c Sat Oct 2 16:49:30 1999
+++ linux/drivers/sound/sb_ess.c Wed Oct 27 22:27:01 1999
@@ -10,29 +10,29 @@
*
* History:
*
- * Rolf Fokkens (Dec 20 1998): ES188x recording level support on a per
+ * Rolf Fokkens (Dec 20 1998): ES188x recording level support on a per
* fokkensr@vertis.nl input basis.
- * (Dec 24 1998): Recognition of ES1788, ES1887, ES1888,
+ * (Dec 24 1998): Recognition of ES1788, ES1887, ES1888,
* ES1868, ES1869 and ES1878. Could be used for
* specific handling in the future. All except
* ES1887 and ES1888 and ES688 are handled like
* ES1688.
- * (Dec 27 1998): RECLEV for all (?) ES1688+ chips. ES188x now
+ * (Dec 27 1998): RECLEV for all (?) ES1688+ chips. ES188x now
* have the "Dec 20" support + RECLEV
- * (Jan 2 1999): Preparation for Full Duplex. This means
+ * (Jan 2 1999): Preparation for Full Duplex. This means
* Audio 2 is now used for playback when dma16
* is specified. The next step would be to use
* Audio 1 and Audio 2 at the same time.
- * (Jan 9 1999): Put all ESS stuff into sb_ess.[ch], this
+ * (Jan 9 1999): Put all ESS stuff into sb_ess.[ch], this
* includes both the ESS stuff that has been in
* sb_*[ch] before I touched it and the ESS support
* I added later
- * (Jan 23 1999): Full Duplex seems to work. I wrote a small
+ * (Jan 23 1999): Full Duplex seems to work. I wrote a small
* test proggy which works OK. Haven't found
* any applications to test it though. So why did
* I bother to create it anyway?? :) Just for
* fun.
- * (May 2 1999): I tried to be too smart by "introducing"
+ * (May 2 1999): I tried to be too smart by "introducing"
* ess_calc_best_speed (). The idea was that two
* dividers could be used to setup a samplerate,
* ess_calc_best_speed () would choose the best.
@@ -40,10 +40,12 @@
* recording problems for high samplerates. I
* fixed this by removing ess_calc_best_speed ()
* and just doing what the documentation says.
- * Andy Sloane (June 4 1999): Stole some code from ALSA to fix the playback
+ * Andy Sloane (Jun 4 1999): Stole some code from ALSA to fix the playback
* andy@guildsoftware.com speed on ES1869, ES1879, ES1887, and ES1888.
* 1879's were previously ignored by this driver;
* added (untested) support for those.
+ * Cvetan Ivanov (Oct 27 1999): Fixed ess_dsp_init to call ess_set_dma_hw for
+ * zezo@inet.bg _ALL_ ESS models, not only ES1887
*
* This files contains ESS chip specifics. It's based on the existing ESS
* handling as it resided in sb_common.c, sb_mixer.c and sb_audio.c. This
@@ -52,7 +54,7 @@
* - RECLEV support for ES1688 and later
* - 6 bits playback level support chips later than ES1688
* - Recording level support on a per-device basis for ES1887
- * - Full-Duplex for ES1887 (under development)
+ * - Full-Duplex for ES1887
*
* Full duplex is enabled by specifying dma16. While the normal dma must
* be one of 0, 1 or 3, dma16 can be one of 0, 1, 3 or 5. DMA 5 is a 16 bit
@@ -100,7 +102,7 @@
* of writing 0x00 to 0x7f (which should be done by reset): The ES1887 moves
* into ES1888 mode. This means that it claims IRQ 11, which happens to be my
* ISDN adapter. Needless to say it no longer worked. I now understand why
- * after rebooting 0x7f already was 0x05, the value of my choise: the BIOS
+ * after rebooting 0x7f already was 0x05, the value of my choice: the BIOS
* did it.
*
* Oh, and this is another trap: in ES1887 docs mixer register 0x70 is decribed
@@ -1200,10 +1202,10 @@
/* AAS: info stolen from ALSA: these boards have different clocks */
switch(devc->submodel) {
-/* APPARENTLY NOT 1869
+/* APPARENTLY NOT 1869 AND 1887
case SUBMDL_ES1869:
-*/
case SUBMDL_ES1887:
+*/
case SUBMDL_ES1888:
devc->caps |= SB_CAP_ES18XX_RATE;
break;
@@ -1305,6 +1307,13 @@
int ess_dsp_init (sb_devc *devc, struct address_info *hw_config)
{
/*
+ * Caller also checks this, but anyway
+ */
+ if (devc->model != MDL_ESS) {
+ printk (KERN_INFO "ess_dsp_init for non ESS chip\n");
+ return 1;
+ }
+ /*
* This for ES1887 to run Full Duplex. Actually ES1888
* is allowed to do so too. I have no idea yet if this
* will work for ES1888 however.
@@ -1324,15 +1333,12 @@
if (devc->dma8 != devc->dma16 && devc->dma16 != -1) {
devc->duplex = 1;
}
-
- if (!ess_set_dma_hw (devc)) {
- free_irq(devc->irq, devc);
- return 0;
- }
- return 1;
- } else {
- return -1;
}
+ if (!ess_set_dma_hw (devc)) {
+ free_irq(devc->irq, devc);
+ return 0;
+ }
+ return 1;
}
/****************************************************************************
^ permalink raw reply [relevance 47%]
* [linux-lvm] [PATCH] Bug in pv_read_all_pv.c
@ 1999-12-05 23:47 64% Michael Lundkvist
0 siblings, 0 replies; 200+ results
From: Michael Lundkvist @ 1999-12-05 23:47 UTC (permalink / raw)
To: linux-lvm
Hi!
I had a bit of problem when I ran a kernel without loopback-support
and a PV on /dev/sda1. I turns out that pv_read_all_pv.c gets a bit
confused when it can't open /dev/loop0. The attached patch against
0.7 fixed it for me.
/Micke
--
Michael Lundkvist
Epact Technology AB
ml@epact.se
--- ../LVM.old/0.7/tools/lib/pv_read_all_pv.c Mon Jul 12 23:21:26 1999
+++ 0.7/tools/lib/pv_read_all_pv.c Mon Dec 6 01:23:15 1999
@@ -101,6 +101,7 @@
#endif
if ( ( tst = open ( dev_name, O_RDONLY)) == -1) {
if ( MAJOR ( dir_cache[n].st_rdev) != MD_MAJOR &&
+ MAJOR ( dir_cache[n].st_rdev) != LOOP_MAJOR &&
MINOR ( dir_cache[n].st_rdev) % 16 == 0) {
n += 15;
continue;
^ permalink raw reply [relevance 64%]
* Loading Linux on an MBX board without EPPC-bug
@ 1999-12-10 22:08 64% jmauro
0 siblings, 0 replies; 200+ results
From: jmauro @ 1999-12-10 22:08 UTC (permalink / raw)
To: linuxppc-embedded
I've been trying to load linux onto a MBX860 board, but the instructions
say to use EPPC-Bug, but all my board starts with is raw-bug and nothing
else. Is this board useable for Linux, or do I/can I restore EPPC-bug
some how? Thanks for any help you can give me.
James
** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: Bug in X 3.3.5
[not found] <19991215202647.A503@HSE-MTL-ppp4549.qc.sympatico.ca>
@ 1999-12-16 6:53 64% ` Michel Lanners
0 siblings, 0 replies; 200+ results
From: Michel Lanners @ 1999-12-16 6:53 UTC (permalink / raw)
To: dorland; +Cc: linuxppc-dev
On 15 Dec, this message from Eric Dorland echoed through cyberspace:
>
> I've noticed a problem for a while in X. When I've got a lot of disk i/o
> going on, and then move the mouse, sometimes false mouse button 3 down
> events are sent to the server. I don't really understand why this is
> happening, but it only happens with a lot of disk i/o.
I guess this has something to do with the ADB driver not getting enough
processor time to do its job. I've never seen it on my setup, though
(7600 with R4 and Xpmac-mga, official kernel 2.2.13)..
Michel
-------------------------------------------------------------------------
Michel Lanners | " Read Philosophy. Study Art.
23, Rue Paul Henkes | Ask Questions. Make Mistakes.
L-1710 Luxembourg |
email mlan@cpu.lu |
http://www.cpu.lu/~mlan | Learn Always. "
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: PowerPC kernel bug. (fwd)
@ 1999-12-20 19:29 64% James Simmons
0 siblings, 0 replies; 200+ results
From: James Simmons @ 1999-12-20 19:29 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linuxppc-dev
Geert I know you work with the PowerPC people. I don't belong to the list
so it might not go threw. So could you post it as well.
Subject: PowerPC kernel bug.
Date: Mon, 13 Dec 1999 22:03:26 -0500 (EST)
From: James Simmons <jsimmons@edgeglobal.com>
To: GLX mailing list <glx-dev@lists.openprojects.net>, FrameBuffer List
<linux-fbdev@vuser.vu.union.edu>, Linux Kernel Mailing List
<linux-kernel@vger.rutgers.edu>
This message is toward the Fbdev/kernel group to fix this bug but I wanted
to let the GLX group what caused the memset problem on PowerPC. On a
PowerPC when you mmap the framebuffer and use memset on the mmapped
image you get a SIGBUS. Thanks Marcus for finding out what was causing the
problem.
>I noticed today that it's actually a bug in the PPC-kernel. The
>specification for the dcbz (data cache block zero) instruction
>states that for uncached memory the exception handler should clear
>the memory, but on Linux it just causes a SIGBUS to be sent to the
>app...
-----------
==============
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range
@ 1999-12-22 5:58 56% Benjamin C.R. LaHaise
1999-12-22 15:08 64% ` Chuck Lever
0 siblings, 1 reply; 200+ results
From: Benjamin C.R. LaHaise @ 1999-12-22 5:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linux-mm
Here's the fix I've got for the mmap/write deadlock. I don't like it, but
the only other fixes I can think of are just as bad, or horrendously
complex. Note that the first patch to fs/buffer.c fixes a serious problem
in block_write_zero_range: a partial write to a page that is not already
cached on a file on a file system with more than two blocks per page could
result in a stack scribble -- eeek!
The patch to filemap.c changes filemap_nopage to use __find_page_nolock
rather than __find_get_page which waits for the page to become unlocked
before returning (maybe __find_get_page was meant to check PageUptodate?),
since filemap_nopage checks PageUptodate before proceeding -- which is
consistent with do_generic_file_read.
-ben
diff -ur clean/2.3.34-2/fs/buffer.c 2.3.34-2/fs/buffer.c
--- clean/2.3.34-2/fs/buffer.c Thu Dec 9 16:10:18 1999
+++ 2.3.34-2/fs/buffer.c Wed Dec 22 00:46:18 1999
@@ -1386,7 +1386,7 @@
unsigned long block;
int err = 0, partial = 0, need_balance_dirty = 0;
unsigned blocksize, bbits;
- struct buffer_head *bh, *head, *wait[2], **wait_bh=wait;
+ struct buffer_head *bh, *head, *wait[PAGE_CACHE_SIZE / 512], **wait_bh=wait;
char *kaddr = (char *)kmap(page);
blocksize = inode->i_sb->s_blocksize;
diff -ur clean/2.3.34-2/include/linux/sched.h 2.3.34-2/include/linux/sched.h
--- clean/2.3.34-2/include/linux/sched.h Mon Dec 20 18:53:12 1999
+++ 2.3.34-2/include/linux/sched.h Wed Dec 22 00:02:06 1999
@@ -349,6 +349,7 @@
/* memory management info */
struct mm_struct *mm, *active_mm;
+ struct page *write_locked_page; /* currently locked page for mmap<->write deadlock test */
/* signal handlers */
spinlock_t sigmask_lock; /* Protects signal and blocked */
@@ -426,7 +427,7 @@
/* thread */ INIT_THREAD, \
/* fs */ &init_fs, \
/* files */ &init_files, \
-/* mm */ NULL, &init_mm, \
+/* mm */ NULL, &init_mm, NULL, \
/* signals */ SPIN_LOCK_UNLOCKED, &init_signals, {{0}}, {{0}}, NULL, &init_task.sigqueue, 0, 0, \
/* exec cts */ 0,0, \
/* exit_sem */ __MUTEX_INITIALIZER(name.exit_sem), \
diff -ur clean/2.3.34-2/mm/filemap.c 2.3.34-2/mm/filemap.c
--- clean/2.3.34-2/mm/filemap.c Mon Dec 20 14:20:06 1999
+++ 2.3.34-2/mm/filemap.c Wed Dec 22 00:21:12 1999
@@ -1325,7 +1325,12 @@
*/
hash = page_hash(&inode->i_data, pgoff);
retry_find:
- page = __find_get_page(&inode->i_data, pgoff, hash);
+ spin_lock(&pagecache_lock);
+ page = __find_page_nolock(&inode->i_data, pgoff, *hash);
+ if (page)
+ get_page(page);
+ spin_unlock(&pagecache_lock);
+
if (!page)
goto no_cached_page;
@@ -1388,6 +1393,9 @@
return NULL;
page_not_uptodate:
+ if (current->write_locked_page == page)
+ return NOPAGE_SIGBUS;
+
lock_page(page);
if (Page_Uptodate(page)) {
UnlockPage(page);
@@ -1917,6 +1925,9 @@
PAGE_BUG(page);
}
+ /* Detect the deadlock */
+ current->write_locked_page = page;
+
status = write_one_page(file, page, offset, bytes, buf);
if (status >= 0) {
@@ -1928,6 +1939,7 @@
inode->i_size = pos;
}
/* Mark it unlocked again and drop the page.. */
+ current->write_locked_page = NULL;
UnlockPage(page);
page_cache_release(page);
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.nl.linux.org/Linux-MM/
^ permalink raw reply [relevance 56%]
* Re: [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range
1999-12-22 5:58 56% [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range Benjamin C.R. LaHaise
@ 1999-12-22 15:08 64% ` Chuck Lever
1999-12-22 15:43 64% ` Benjamin C.R. LaHaise
0 siblings, 1 reply; 200+ results
From: Chuck Lever @ 1999-12-22 15:08 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: Linus Torvalds, linux-mm
On Wed, 22 Dec 1999, Benjamin C.R. LaHaise wrote:
> The patch to filemap.c changes filemap_nopage to use __find_page_nolock
> rather than __find_get_page which waits for the page to become unlocked
> before returning (maybe __find_get_page was meant to check PageUptodate?),
> since filemap_nopage checks PageUptodate before proceeding -- which is
> consistent with do_generic_file_read.
i've tried this before several times. i could never get the system to
perform as well under benchmark load using find_page_nolock as when using
find_get_page. the throughput difference was about 5%, if i recall. i
haven't explained this to myself yet.
perhaps a better fix would be to take out some of the page lock complexity
from filemap_nopage? dunno.
- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.nl.linux.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range
1999-12-22 15:08 64% ` Chuck Lever
@ 1999-12-22 15:43 64% ` Benjamin C.R. LaHaise
1999-12-22 15:58 62% ` Chuck Lever
1999-12-23 4:00 64% ` Chuck Lever
0 siblings, 2 replies; 200+ results
From: Benjamin C.R. LaHaise @ 1999-12-22 15:43 UTC (permalink / raw)
To: Chuck Lever; +Cc: Linus Torvalds, linux-mm
On Wed, 22 Dec 1999, Chuck Lever wrote:
> On Wed, 22 Dec 1999, Benjamin C.R. LaHaise wrote:
> > The patch to filemap.c changes filemap_nopage to use __find_page_nolock
> > rather than __find_get_page which waits for the page to become unlocked
> > before returning (maybe __find_get_page was meant to check PageUptodate?),
> > since filemap_nopage checks PageUptodate before proceeding -- which is
> > consistent with do_generic_file_read.
>
> i've tried this before several times. i could never get the system to
> perform as well under benchmark load using find_page_nolock as when using
> find_get_page. the throughput difference was about 5%, if i recall. i
> haven't explained this to myself yet.
>
> perhaps a better fix would be to take out some of the page lock complexity
> from filemap_nopage? dunno.
Well, there certainly is a lot of code in page_cache_read /
do_generic_file_read / filemap_nopage that is duplicate, and our policies
across them are inconsistent.
Here's my hypothesis about why find_page_nolock vs find_get_page makes a
difference: using find_page_nolock means that we'll never do a
run_task_queue(&tq_disk); to get our async readahead requests run. So, in
theory, doing that in filemap_nopage will restore performance. Isn't
there a way that the choice of when to run tq_disk could be made a bit
less arbitrary?
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.nl.linux.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range
1999-12-22 15:43 64% ` Benjamin C.R. LaHaise
@ 1999-12-22 15:58 62% ` Chuck Lever
1999-12-23 4:00 64% ` Chuck Lever
1 sibling, 0 replies; 200+ results
From: Chuck Lever @ 1999-12-22 15:58 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: Linus Torvalds, linux-mm
On Wed, 22 Dec 1999, Benjamin C.R. LaHaise wrote:
> On Wed, 22 Dec 1999, Chuck Lever wrote:
> > i've tried this before several times. i could never get the system to
> > perform as well under benchmark load using find_page_nolock as when using
> > find_get_page. the throughput difference was about 5%, if i recall. i
> > haven't explained this to myself yet.
> >
> > perhaps a better fix would be to take out some of the page lock complexity
> > from filemap_nopage? dunno.
>
> Well, there certainly is a lot of code in page_cache_read /
> do_generic_file_read / filemap_nopage that is duplicate, and our policies
> across them are inconsistent.
when i started looking at mmap read-ahead and madvise, i noticed that
there was a lot of inconsistent code duplication, and thought it would be
a good thing to fold this stuff together. that's one reason i created the
"read_cluster_nonblocking" and "page_cache_read" functions. for example,
you can remove 20-40 lines of do_generic_file_read by replacing them with
one call to page_cache_read. or you could easily try clustered reads
there.
but notice you want to do something slightly different in
generic_file_write, so that code will probably need to stay.
> Here's my hypothesis about why find_page_nolock vs find_get_page makes a
> difference: using find_page_nolock means that we'll never do a
> run_task_queue(&tq_disk); to get our async readahead requests run. So, in
> theory, doing that in filemap_nopage will restore performance.
sounds like a reasonable explanation to me, and easy enough to test, even.
i'll give that a shot later today.
> Isn't
> there a way that the choice of when to run tq_disk could be made a bit
> less arbitrary?
i suppose there's a more *efficient* way of doing it, but i think running
the queue while waiting for a page is probably a good idea. in other
words, running the queue in find_get_page seems like a good idea to me.
what did you have in mind?
- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.nl.linux.org/Linux-MM/
^ permalink raw reply [relevance 62%]
* Re: [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range
1999-12-22 15:43 64% ` Benjamin C.R. LaHaise
1999-12-22 15:58 62% ` Chuck Lever
@ 1999-12-23 4:00 64% ` Chuck Lever
1 sibling, 0 replies; 200+ results
From: Chuck Lever @ 1999-12-23 4:00 UTC (permalink / raw)
To: Benjamin C.R. LaHaise; +Cc: Linus Torvalds, linux-mm
On Wed, 22 Dec 1999, Benjamin C.R. LaHaise wrote:
> On Wed, 22 Dec 1999, Chuck Lever wrote:
> > On Wed, 22 Dec 1999, Benjamin C.R. LaHaise wrote:
> > i've tried this before several times. i could never get the system to
> > perform as well under benchmark load using find_page_nolock as when using
> > find_get_page. the throughput difference was about 5%, if i recall. i
> > haven't explained this to myself yet.
>
> Here's my hypothesis about why find_page_nolock vs find_get_page makes a
> difference: using find_page_nolock means that we'll never do a
> run_task_queue(&tq_disk); to get our async readahead requests run. So, in
> theory, doing that in filemap_nopage will restore performance. Isn't
> there a way that the choice of when to run tq_disk could be made a bit
> less arbitrary?
this patch appears to have negligible effect on benchmark throughput
measurements, whereas, without the run_task_queue, throughput drops.
btw, i notice that a "read_cache_page" function has appeared that looks
similar to "page_cache_read" -- is there necessity for both?
--- linux-2.3.34-ref/mm/filemap.c Wed Dec 22 21:23:03 1999
+++ linux/mm/filemap.c Wed Dec 22 22:53:19 1999
@@ -1325,9 +1325,13 @@
*/
hash = page_hash(&inode->i_data, pgoff);
retry_find:
- page = __find_get_page(&inode->i_data, pgoff, hash);
+ spin_lock(&pagecache_lock);
+ page = __find_page_nolock(&inode->i_data, pgoff, *hash);
if (!page)
goto no_cached_page;
+ get_page(page);
+ spin_unlock(&pagecache_lock);
+ run_task_queue(&tq_disk);
/*
* Ok, found a page in the page cache, now we need to check
@@ -1358,6 +1362,8 @@
return old_page;
no_cached_page:
+ spin_unlock(&pagecache_lock);
+
/*
* If the requested offset is within our file, try to read a whole
* cluster of pages at once.
- Chuck Lever
--
corporate: <chuckl@netscape.com>
personal: <chucklever@netscape.net> or <cel@monkey.org>
The Linux Scalability project:
http://www.citi.umich.edu/projects/linux-scalability/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.nl.linux.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* [linux-lvm] Bug in 0.8i - lvm_tab_vg_check_exist_all_vg.c
@ 1999-12-29 18:55 64% Terry Hardie
0 siblings, 0 replies; 200+ results
From: Terry Hardie @ 1999-12-29 18:55 UTC (permalink / raw)
To: Linux LVM
After line 95 of the aforementioned file, there is a missing "data =
NULL;", which causes a crash when /etc/lvmtab is small (< 2 bytes)
---
Terry Hardie terry@gxc.com
Founder and Chief Technology officer ICQ#: 977679
Convergence Equipment Co, Manassas, VA, USA V: +1-703-361-5566
"Home of the BOB Class 4 convergence switch"
^ permalink raw reply [relevance 64%]
* [parisc-linux] wq bug forcing oops
@ 2000-01-17 4:34 64% Matthew Wilcox
0 siblings, 0 replies; 200+ results
From: Matthew Wilcox @ 2000-01-17 4:34 UTC (permalink / raw)
To: parisc-linux
if you've had this error message on recent kernels, it actually meant
`null pointer exception'. the current cvs tree should report these
correctly.
^ permalink raw reply [relevance 64%]
* gcc 2.95/PPC bug
@ 2000-01-21 7:03 63% Albrecht Dre_
2000-01-21 15:37 64% ` Franz Sirl
0 siblings, 1 reply; 200+ results
From: Albrecht Dre_ @ 2000-01-21 7:03 UTC (permalink / raw)
To: LinuxPPC Users; +Cc: LinuxPPC-Dev Liste
When trying to find the cause for crashes of LAME, I think I found a
bug in the gcc. The code below (which is actually a simpilified excerpt
from LAME) will NOT pass the parameter `buggy' correctly to the
subroutine. Changing the number/type/sorting of the parameters will,
however, produce a working code in some cases. Some facts about the
system:
Machines: PowerMac 7300 (604e), LinuxPPC 2.2.11
PB "Lombard" (G3), LinuxPPC 2.2.12
gcc: versions 2.95 and 2.95.1
options: gcc -O0 -Wall gcc-2.95-ppc-bug.c -o gcc-2.95-ppc-bug
Is this a known (and hopefully already fixed ;-) bug, or should it go
directly to gcc-bugs@gcc.gnu.org?
Thanks, Albrecht.
---snip here:gcc-2.95-ppc-bug.c-----------------------------------------------
#include <stdio.h>
void vartest (double xr[2][2][576],
int l3_enc[2][2][576],
int var1, int var2, int var3, int var4, int var5, int var6,
int var7, int var8, int var9, double var10, int buggy)
{
printf ("%d %d %d %d %d %d %d %d %d %g %d\n",
var1, var2, var3, var4, var5, var6, var7, var8, var9, var10, buggy);
}
int main ()
{
double xxx [2][2][576];
int eee [2][2][576];
vartest (xxx, eee, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10.1, 11);
return 0;
}
---end of bug demo code-------------------------------------------------------
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 63%]
* Re: gcc 2.95/PPC bug
2000-01-21 7:03 63% gcc 2.95/PPC bug Albrecht Dre_
@ 2000-01-21 15:37 64% ` Franz Sirl
2000-01-24 9:53 64% ` Albrecht Dre_
0 siblings, 1 reply; 200+ results
From: Franz Sirl @ 2000-01-21 15:37 UTC (permalink / raw)
To: Albrecht Dreß; +Cc: LinuxPPC Users, LinuxPPC-Dev Liste
At 08:03 21.01.00 , Albrecht Dreß wrote:
>When trying to find the cause for crashes of LAME, I think I found a
>bug in the gcc. The code below (which is actually a simpilified excerpt
>from LAME) will NOT pass the parameter `buggy' correctly to the
>subroutine. Changing the number/type/sorting of the parameters will,
>however, produce a working code in some cases. Some facts about the
>system:
>
> Machines: PowerMac 7300 (604e), LinuxPPC 2.2.11
> PB "Lombard" (G3), LinuxPPC 2.2.12
> gcc: versions 2.95 and 2.95.1
> options: gcc -O0 -Wall gcc-2.95-ppc-bug.c -o gcc-2.95-ppc-bug
>
>Is this a known (and hopefully already fixed ;-) bug, or should it go
>directly to gcc-bugs@gcc.gnu.org?
I believe this is fixed in my current gcc-2.95.2 RPM-set available on
<ftp://devel.linuxppc.org/users/fsirl/>.
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: gcc 2.95/PPC bug
2000-01-21 15:37 64% ` Franz Sirl
@ 2000-01-24 9:53 64% ` Albrecht Dre_
0 siblings, 0 replies; 200+ results
From: Albrecht Dre_ @ 2000-01-24 9:53 UTC (permalink / raw)
To: Franz Sirl; +Cc: LinuxPPC Users, LinuxPPC-Dev Liste
Franz Sirl wrote:
> >Is this a known (and hopefully already fixed ;-) bug, or should it go
> >directly to gcc-bugs@gcc.gnu.org?
>
> I believe this is fixed in my current gcc-2.95.2 RPM-set available on
> <ftp://devel.linuxppc.org/users/fsirl/>.
It is fixed, thanks a lot!
Yours, Albrecht.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* 2.2.1{3,4,5pre*} VM bug found
@ 2000-01-25 3:27 63% Rik van Riel
2000-01-25 18:15 64% ` Andrea Arcangeli
2000-01-27 19:07 64% ` Stephen C. Tweedie
0 siblings, 2 replies; 200+ results
From: Rik van Riel @ 2000-01-25 3:27 UTC (permalink / raw)
To: Alan Cox; +Cc: Linux MM, Linux Kernel
Hi Alan,
I've found the bug that makes the VM subsystem in the
latest 2.2 kernels go belly-up (or mess up processes).
Sometimes a process with tsk->state != TASK_RUNNABLE
calls __get_free_pages(). When we're (almost) out of
memory, the process will wake up kswapd and try to
free some memory itself.
In 2.2.15pre4 or when the call to try_to_free_pages()
generates disk I/O, the task will call schedule().
Since the task state != TASK_RUNNABLE, schedule() will
immedately remove it from the run queue ...
The task itself will still be somewhere `in the middle
of' __get_free_pages() and has no chance of ever
returning to whatever it was doing. Of course it still
reacts on signals, so you can easily kill it (unless
it happens to be your X server).
I will prepare a fix for this after I've had some
sleep ... you'll hear back from me tomorrow.
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 63%]
* Re: 2.2.1{3,4,5pre*} VM bug found
2000-01-25 3:27 63% 2.2.1{3,4,5pre*} VM bug found Rik van Riel
@ 2000-01-25 18:15 64% ` Andrea Arcangeli
2000-01-26 0:48 64% ` Rik van Riel
2000-01-27 19:07 64% ` Stephen C. Tweedie
1 sibling, 1 reply; 200+ results
From: Andrea Arcangeli @ 2000-01-25 18:15 UTC (permalink / raw)
To: Alan Cox, Linux MM, Linux Kernel
On Tue, 25 Jan 2000, Rik van Riel wrote:
>calls __get_free_pages(). When we're (almost) out of
>memory, the process will wake up kswapd and try to
You'll block also before to go out of memory if the allocation rate is
high enough.
>In 2.2.15pre4 or when the call to try_to_free_pages()
>generates disk I/O, the task will call schedule().
>Since the task state != TASK_RUNNABLE, schedule() will
>immedately remove it from the run queue ...
Before calling schedule() you always gets registered in a waitqueue so
you can't deadlock or wait too much.
If something there is the opposite problem. If you do:
__set_current_state(TASK_UNINTERRUPTIBLE);
get_page(GFP_KERNEL);
XXXXXXXXXXXXXXXXXXXX
schedule();
then at point XXXXXXX you may become a task running and you don't block
anymore.
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: 2.2.1{3,4,5pre*} VM bug found
2000-01-25 18:15 64% ` Andrea Arcangeli
@ 2000-01-26 0:48 64% ` Rik van Riel
2000-01-27 19:09 64% ` Stephen C. Tweedie
0 siblings, 1 reply; 200+ results
From: Rik van Riel @ 2000-01-26 0:48 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Alan Cox, Linux MM, Linux Kernel
On Tue, 25 Jan 2000, Andrea Arcangeli wrote:
> Before calling schedule() you always gets registered in a
> waitqueue so you can't deadlock or wait too much.
>
> If something there is the opposite problem. If you do:
>
> __set_current_state(TASK_UNINTERRUPTIBLE);
> get_page(GFP_KERNEL);
> XXXXXXXXXXXXXXXXXXXX
> schedule();
>
> then at point XXXXXXX you may become a task running and you don't
> block anymore.
The problem in this case is that schedule() may be called
from within get_page(GFP_KERNEL). This already was possible
in 2.2.14 and before (if the task had to wait for I/O on
try_to_free_pages()), but the explicit schedule() in my
stuff in 2.2.15pre4 amplified the problem and made it
visible.
A fix for this problem is in one of my other emails and
at my web page: http://www.surriel.com/patches/
regards,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: 2.2.1{3,4,5pre*} VM bug found
2000-01-25 3:27 63% 2.2.1{3,4,5pre*} VM bug found Rik van Riel
2000-01-25 18:15 64% ` Andrea Arcangeli
@ 2000-01-27 19:07 64% ` Stephen C. Tweedie
1 sibling, 0 replies; 200+ results
From: Stephen C. Tweedie @ 2000-01-27 19:07 UTC (permalink / raw)
To: Rik van Riel; +Cc: Alan Cox, Linux MM, Stephen Tweedie, Linux Kernel
Hi,
On Tue, 25 Jan 2000 04:27:43 +0100 (CET), Rik van Riel
<riel@nl.linux.org> said:
> Sometimes a process with tsk->state != TASK_RUNNABLE
> calls __get_free_pages(). When we're (almost) out of
> memory, the process will wake up kswapd and try to
> free some memory itself.
> In 2.2.15pre4 or when the call to try_to_free_pages()
> generates disk I/O, the task will call schedule().
> Since the task state != TASK_RUNNABLE, schedule() will
> immedately remove it from the run queue ...
Shouldn't be a problem. Anywhere that we stall in try_to_free_pages()
to wait for disk IO, we obviously have to set task->state to
TASK_UNINTERRUPTIBLE, as we're about to block. If we do that as a
result of disk IO, then we have necessarily already scheduled a wakeup
event which will set the task state back to runnable.
So, the only risk is that the call to try_to_free_pages() has the
unexpected side effect of setting the task state to TASK_RUNNABLE. That
isn't a problem: the only effect it will have on the caller is to make a
call schedule() return sooner than expected.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: 2.2.1{3,4,5pre*} VM bug found
2000-01-26 0:48 64% ` Rik van Riel
@ 2000-01-27 19:09 64% ` Stephen C. Tweedie
0 siblings, 0 replies; 200+ results
From: Stephen C. Tweedie @ 2000-01-27 19:09 UTC (permalink / raw)
To: Rik van Riel
Cc: Andrea Arcangeli, Alan Cox, Linux MM, Stephen Tweedie,
Linux Kernel
Hi,
On Wed, 26 Jan 2000 01:48:43 +0100 (CET), Rik van Riel
<riel@nl.linux.org> said:
> The problem in this case is that schedule() may be called
> from within get_page(GFP_KERNEL). This already was possible
> in 2.2.14 and before (if the task had to wait for I/O on
> try_to_free_pages()), but the explicit schedule() in my
> stuff in 2.2.15pre4 amplified the problem and made it
> visible.
It's not only possible, it is explicitly legal. It always has been.
You _must_ call it with GFP_ATOMIC if you can't afford to block (or,
alternatively, call it without __GFP_IO, or with the PF_MEMALLOC flag).
> A fix for this problem is in one of my other emails
It's not a problem. If callers are expecting GFP_KERNEL to be atomic,
then _that_ is a problem, but it is perfectly all right for GFP_KERNEL
allocations to block.
--Stephen
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Bug in glibc 2.1.3 linuxthreads in pthread_cond_timedwait_relative
[not found] ` <vtou2jy3t2q.fsf@astra.cs.uni-dortmund.de>
@ 2000-01-28 22:45 53% ` Kevin Hendricks
2000-01-29 3:10 64% ` scott hutinger
0 siblings, 1 reply; 200+ results
From: Kevin Hendricks @ 2000-01-28 22:45 UTC (permalink / raw)
To: linuxppc-dev, Andreas Jaeger, Jesper Skov
Hi,
Checkout the following code piece. reltime is set by pthread_condtimedwait
before it calls pthread_cond_timedwait_relative_new.
That routine calls nanosleep with reltime and NULL.
If this routine gets an interrupt nanosleep is called again with reltime.
But according to the man page for nanosleep reltime is not changed from before.
If the remaining time is needed the NULL should have been changed in the
nanosleep call.
So if enough interrupts hit this thread within the timeout, it will effectively
always restart itself and hang forever.
I will put together a formal patch but this one was nasty to find since there
have to be enogh signals to keep the thread restarting with the old reltime.
Kevin
static int
pthread_cond_timedwait_relative_new(pthread_cond_t *cond,
pthread_mutex_t *mutex,
const struct timespec * reltime)
{
volatile pthread_descr self = thread_self();
sigset_t unblock, initial_mask;
int retsleep, already_canceled, was_signalled;
sigjmp_buf jmpbuf;
pthread_extricate_if extr;
requeue_and_wait_again:
retsleep = 0;
already_canceled = 0;
was_signalled = 0;
/* Set up extrication interface */
extr.pu_object = cond;
extr.pu_extricate_func = cond_extricate_func;
/* Register extrication interface */
__pthread_set_own_extricate_if(self, &extr);
/* Enqueue to wait on the condition and check for cancellation. */
__pthread_lock(&cond->__c_lock, self);
if (!(THREAD_GETMEM(self, p_canceled)
&& THREAD_GETMEM(self, p_cancelstate) == PTHREAD_CANCEL_ENABLE))
enqueue(&cond->__c_waiting, self);
else
already_canceled = 1;
__pthread_unlock(&cond->__c_lock);
if (already_canceled) {
__pthread_set_own_extricate_if(self, 0);
pthread_exit(PTHREAD_CANCELED);
}
pthread_mutex_unlock(mutex);
/* Set up a longjmp handler for the restart signal, unblock
the signal and sleep. */
if (sigsetjmp(jmpbuf, 1) == 0) {
THREAD_SETMEM(self, p_signal_jmp, &jmpbuf);
THREAD_SETMEM(self, p_signal, 0);
/* Unblock the restart signal */
sigemptyset(&unblock);
sigaddset(&unblock, __pthread_sig_restart);
sigprocmask(SIG_UNBLOCK, &unblock, &initial_mask);
/* Sleep for the required duration */
retsleep = __libc_nanosleep(reltime, NULL);
/* Block the restart signal again */
sigprocmask(SIG_SETMASK, &initial_mask, NULL);
was_signalled = 0;
} else {
retsleep = -1;
was_signalled = 1;
}
THREAD_SETMEM(self, p_signal_jmp, NULL);
/* Now was_signalled is true if we exited the above code
due to the delivery of a restart signal. In that case,
everything is cool. We have been removed from the queue
by the other thread, and consumed its signal.
Otherwise we this thread woke up spontaneously, or due to a signal other
than restart. The next thing to do is to try to remove the thread
from the queue. This may fail due to a race against another thread
trying to do the same. In the failed case, we know we were signalled,
and we may also have to consume a restart signal. */
if (!was_signalled) {
int was_on_queue;
/* __pthread_lock will queue back any spurious restarts that
may happen to it. */
__pthread_lock(&cond->__c_lock, self);
was_on_queue = remove_from_queue(&cond->__c_waiting, self);
__pthread_unlock(&cond->__c_lock);
if (was_on_queue) {
__pthread_set_own_extricate_if(self, 0);
: /* __pthread_lock will queue back any spurious restarts that
may happen to it. */
__pthread_lock(&cond->__c_lock, self);
was_on_queue = remove_from_queue(&cond->__c_waiting, self);
__pthread_unlock(&cond->__c_lock);
if (was_on_queue) {
__pthread_set_own_extricate_if(self, 0);
pthread_mutex_lock(mutex);
if (retsleep == 0)
return ETIMEDOUT;
/* Woken by a signal: resume waiting as
required by Single Unix Specification. */
goto requeue_and_wait_again;
}
/* Eat the outstanding restart() from the signaller */
: suspend(self);
}
__pthread_set_own_extricate_if(self, 0);
/* The remaining logic is the same as in other cancellable waits,
such as pthread_join sem_wait or pthread_cond wait. */
if (THREAD_GETMEM(self, p_woken_by_cancel)
&& THREAD_GETMEM(self, p_cancelstate) == PTHREAD_CANCEL_ENABLE) {
THREAD_SETMEM(self, p_woken_by_cancel, 0);
pthread_mutex_lock(mutex);
pthread_exit(PTHREAD_CANCELED);
}
pthread_mutex_lock(mutex);
return 0;
}
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 53%]
* Re: Bug in glibc 2.1.3 linuxthreads in pthread_cond_timedwait_relative
2000-01-28 22:45 53% ` Bug in glibc 2.1.3 linuxthreads in pthread_cond_timedwait_relative Kevin Hendricks
@ 2000-01-29 3:10 64% ` scott hutinger
0 siblings, 0 replies; 200+ results
From: scott hutinger @ 2000-01-29 3:10 UTC (permalink / raw)
To: Kevin Hendricks; +Cc: linuxppc-dev, scott hutinger
Kevin,
Yes! I would like to keep it in the realm of what people download :-) So
I don't need to do a build that takes all night on a 8100.
Thanks much, as always, you come through with a fix !!!!
scott
On Fri, 28 Jan 2000, Kevin Hendricks wrote:
> Hi,
>
> If you are using Franz Sirl's glibc 2.1.3 0k or 0l rpms and are seeing funny
> hangs with linuxthreads programs, here is a small patch to fix the problem of
> restarting pthread_cond_timedwait_relative_new with the same timeout and not
> remaining time.
> (see my earlier problem report).
>
> The patch file is attached:
>
> Kevin
>
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* bug-glibc,linuxppc-dev: semctl on linux/ppc
@ 2000-01-30 0:26 58% james woodyatt
0 siblings, 0 replies; 200+ results
From: james woodyatt @ 2000-01-30 0:26 UTC (permalink / raw)
To: bug-glibc, linuxppc-dev
gospoda--
I have found what appears to be a minor problem with the System V IPC
code for Linux as implemented in the GNU C Library, version 2.1.2 and
previous versions.
Observe that the 'semctl' function is declared in sysvipc/sys/sem.h as
follows:
/* Semaphore control operation. */
extern int semctl __P ((int __semid, int __semnum, int __cmd, ...));
This is a sorta-kinda reasonable prototype for an interface that was
defined before ANSI C introduced such modern conveniences; the fourth
argument is only needed when the 'cmd' argument has certain values. But
consider the definition of the function in
sysdeps/unix/sysv/linux/semctl.c:
int
semctl (int semid, int semnum, int cmd, ...)
{
union semun *arg;
va_list ap;
va_start (ap, cmd);
/* Get a pointer the argument. */
arg = &va_arg (ap, union semun);
va_end (ap);
return INLINE_SYSCALL (ipc, 5, IPCOP_semctl, semid, semnum, cmd, arg);
}
This function requires the fourth argument no matter what the value of
the 'cmd' argument. For example, consider the following perfectly
reasonable use of 'semctl' taken from a piece of old software I have
that has compiled and run on every version of Solaris 2.x I've ever had
the displeasure to encounter:
if (semctl(semid, 0, IPC_RMID) == -1)) {
/* throw up horribly */
}
This will compile fine on my Powerbook G3 running Linux/PPC 1999, but it
won't work. I have to work around the problem by providing a 'union
semun' type parameter (not a pointer, the actual union passed by value),
even for the IPC_RMID command (which doesn't use it), because otherwise
the GNU C Library will exhibit what the ANSI C standard euphemistically
refers to as 'undefined behavior'-- in my case, a lovely core dump.
Good thing I have the source code to my application and I can work
around problems like this, but I thought someone maintaining the GNU C
Library might want to have a look at this.
(And don't *anyone* hassle me about using System V IPC in the first
place. If it were *my* choice, I'd be using
_POSIX_THREAD_PROCESS_SHARED. Besides, *that* isn't
supported/supportable on Linux anyway <*bitch* *moan* *complain*>.)
--jhw@wetware.com
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 58%]
* [xfree accel bug] Re: 24 bitplanes in X? (openh323 videoconf)
@ 2000-02-06 10:47 64% ` Brad Midgley
0 siblings, 0 replies; 200+ results
From: Brad Midgley @ 2000-02-06 10:47 UTC (permalink / raw)
To: linuxppc-dev
i confirmed this is an accel bug in Xfree86-3.3.6. if i put options
"noaccel" in my xconfig, then the video is well-behaved, just slow.
On Sun, 6 Feb 2000, Brad Midgley wrote:
>
> is anyone having success with specifying 24 bitplanes in their xconfig?
>
> apparently this is the only way one can use openh323's videoconferencing
> but on my bronze powerbook, the screen is messed up (there are 4 mini
> duplicates of the main screen appearing at the top of the screen)
>
> i'm using xfree 3.3.6 (dev-rel-1.1), bootx, and rsync-benh.
>
> Brad
> brad@turbolinux.com | http://www.turbolinux.com/~brad/
>
>
Brad
brad@turbolinux.com | http://www.turbolinux.com/~brad/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* bug in kernel header
@ 2000-02-06 11:31 64% Moritz Thomas
0 siblings, 0 replies; 200+ results
From: Moritz Thomas @ 2000-02-06 11:31 UTC (permalink / raw)
To: linuxppc-dev
Hi there,
when trying to compile some stuff the other day, I found that there is a
bug in "include/asm-ppc/bitops.h" in linux-2.2.13. It's probably fixed
by now (don't have any newer versions), but I thought it doesn't hurt to
report.
The function "ext2_find_next_zero_bit" uses "cpu_to_le32p" which is a
kernel function. However, "ext2_find_next_zero_bit" is not in
"#ifdef __KERNEL__". I guess the obvious solution would be to do just that.
mo
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Kernel Gurus Help! Possible kernel bug in conversion of jiffees in nanosleep.
@ 2000-02-13 4:21 52% Kevin Hendricks
[not found] ` <200002130440.XAA25134@mal-ach.watson.ibm.com>
0 siblings, 1 reply; 200+ results
From: Kevin Hendricks @ 2000-02-13 4:21 UTC (permalink / raw)
To: linuxppc-dev
Hi,
I have been tracking down a bug in pthread cond timed wait that I think is
actually related to a kernel bug in linux/kernel/sched.c
See glibc-2.1.3-cvs from Feb 11,
in linuxthreads/condvar.c in pthread_cond_timedwait_relative_new
you can see the following loop.
while ( __libc_nanosleep(&reltime,&reltime) != 0)
;
But in *high* signal environments (such as lots of garbage collection going
on in the jdk) the damn value of reltime actually gets larger and not smaller.
I edited the while loop that repeatedly calls __libc_nanosleep and had it print
out (via MSG()) the reltime value each time an interrupted syscall happened.
Would you believe reltime (the remaining time) was actually increasing!
Here is a short snippet showing the value of reltime.tv_sec, reltime.tv_nsec,
and the value of errno (in this case 4 is EINTR). There are two threads in
pthread_cond_timedwait in this example, you can look at values for thread 19016
which was originally told to wait for exactly 30 seconds.
19016 : reltime: 30 250000000 4
18987 : reltime: 1 460000000 4
19016 : reltime: 30 250000000 4
18987 : reltime: 1 470000000 4
19016 : reltime: 30 250000000 4
18987 : reltime: 1 480000000 4
19016 : reltime: 30 260000000 4
18987 : reltime: 1 490000000 4
19016 : reltime: 30 270000000 4
18987 : reltime: 1 500000000 4
19016 : reltime: 30 280000000 4
18987 : reltime: 1 510000000 4
19016 : reltime: 30 280000000 4
18987 : reltime: 1 510000000 4
19016 : reltime: 30 280000000 4
18987 : reltime: 1 510000000 4
19016 : reltime: 30 280000000 4
Notice by the end that the tv_nsec field has actually grown.
It seems the kernel routine (see linux/kernel/sched.c) converts the
time to jiffees and when interrupted converts jiffees back to time.
Unfortunately, some bug in this conversion is actually coming back with
a higher time than was passed in if it is interrupted fast enough.
Here is the kernel routine in question:
asmlinkage int sys_nanosleep(struct timespec *rqtp, struct timespec *rmtp)
{ struct timespec t;
unsigned long expire;
if(copy_from_user(&t, rqtp, sizeof(struct timespec)))
return -EFAULT;
if (t.tv_nsec >= 1000000000L || t.tv_nsec < 0 || t.tv_sec < 0)
return -EINVAL;
if (t.tv_sec == 0 && t.tv_nsec <= 2000000L &&
current->policy != SCHED_OTHER)
{
/*
* Short delay requests up to 2 ms will be handled with
* high precision by a busy wait for all real-time processes.
*
* Its important on SMP not to do this holding locks.
*/
udelay((t.tv_nsec + 999) / 1000);
return 0;
}
expire = timespec_to_jiffies(&t) + (t.tv_sec || t.tv_nsec);
current->state = TASK_INTERRUPTIBLE;
expire = schedule_timeout(expire);
if (expire) {
if (rmtp) {
jiffies_to_timespec(expire, &t);
if (copy_to_user(rmtp, &t, sizeof(struct timespec)))
return -EFAULT;
}
return -EINTR;
}
return 0;
}
So I think this is a kernel bug that is scratched by this new tight loop and
the very high signal environment used in the jdk.
The previous version used in condvar timed wait always decreased time since
alot of time actually elapsed outside of __libc_nanosleep and it overwhelmed
any tiny increases due to conversion to and from jiffees.
I have no idea whether this bug exists on Linux x86 or not. The kernel
routine in question is not arch specific so it should be used by
everyone.
This was the first time I have ever seen remaining time actually increase!
I need *help* resolving this issue before glibc 2.1.3 goes final in case this
turns out to be a glibc bug.
Any help here would be greatly appreciated!!!!!
Kevin
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 52%]
* Re: Kernel Gurus Help! Possible kernel bug in conversion of jiffees in nanosleep.
[not found] ` <200002130440.XAA25134@mal-ach.watson.ibm.com>
@ 2000-02-13 16:51 64% ` Kevin B. Hendricks
0 siblings, 0 replies; 200+ results
From: Kevin B. Hendricks @ 2000-02-13 16:51 UTC (permalink / raw)
To: David Edelsohn, linuxppc-dev
Hi,
> Maybe submit the question to the glibc-alpha mailinglist as well?
>
>David
I submitted two bug reports about this via the glibc bug database.
The second report just adds info about the first.
The bug reports are 1597 and 1598.
I have previously fixed pthread_cond_timedwait in glibc 2.1.3 to actually
work recently but a final "cleanup" recently committed patch rewrote things
so that it no longer worked.
The funny thing is that their technique *should* work if the remtime value
from nanosleep would actually decrease and not increase.
So I think the whole thing is actually a kernel bug but I am not sure.
I know nothing about jiffees and their conversion to and from time values
and I am not sure how jiffees could ever grow (lost jiffees added back?).
If anyone who knows something about jiffees and conversions could look at
nanosleep I would greatly appreciate it.
Thanks,
Kevin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Bug in acceled Xpmac?
@ 2000-02-14 16:26 57% Nathan Ingersoll
0 siblings, 0 replies; 200+ results
From: Nathan Ingersoll @ 2000-02-14 16:26 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1001 bytes --]
It looks like the accelerated Xpmac that was released in January may have
a bug in mouse handling.
I was working on a small epplet for one button mouse users to make better
use of enlightenment. When using the version of Xpmac that shipped with
LinuxPPC 1999 Q1 it worked fine. But when using the recent accelerated
version, the mouse functionality wouldn't change.
XGetPointerMapping returns the values that were set, but it doesn't seem
to be updating the way it handles the button.
Has anyone else seen similar behavior or know of a fix? I attached the
source of my program for anyone interested in trying it out.
---------------------------------------------------------------------------
| Nathan Ingersoll | Computer Science/Mathematics |
| mailto: ningerso@d.umn.edu | University of Minnesota-Duluth |
| http://umn.edu/~ningerso | http://www.d.umn.edu |
---------------------------------------------------------------------------
[-- Attachment #2: E-UniButton.c --]
[-- Type: TEXT/PLAIN, Size: 2486 bytes --]
/*
* Copyright (C) 2000-2001, Nathan Ingersoll
*
* This software is licensed under the GNU General Public
* License. If you did not receive a copy with this software,
* it may be obtained from http://www.gnu.org/
*/
#include <stdio.h>
#include <unistd.h>
#include "epplet.h"
#define MAXBUTTON 3
Epplet_gadget close_button, label1, label2, button1;
int cur_button;
unsigned char buttons[MAXBUTTON];
char curb[2];
Display *disp;
static void close_cb(void *data);
static void in_cb(void *data, Window w);
static void out_cb(void *data, Window w);
static int delete_cb(void *data, Window win);
static void ok_cb(void *data);
static void
close_cb(void *data)
{
Epplet_unremember();
Esync();
Epplet_cleanup();
data = NULL;
exit(0);
}
static void
in_cb(void *data, Window w)
{
if (w == Epplet_get_main_window()) {
Epplet_gadget_show(close_button);
}
return;
data = NULL;
}
static void
out_cb(void *data, Window w)
{
if (w == Epplet_get_main_window()) {
Epplet_gadget_hide(close_button);
}
return;
data = NULL;
}
static int
delete_cb(void *data, Window win)
{
win = (Window) 0;
data = NULL;
return 1;
}
void
next_button(void *data)
{
int b;
XGetPointerMapping(disp, buttons, MAXBUTTON);
b = buttons[1];
buttons[1] = buttons[2];
buttons[2] = buttons[0];
buttons[0] = b;
if (XSetPointerMapping(disp, buttons, MAXBUTTON) >= 0) {
cur_button = buttons[0];
Esnprintf(curb, 2, "%d", cur_button);
Epplet_change_label(label2, curb);
}
}
int
main(int argc, char **argv)
{
atexit(Epplet_cleanup);
Epplet_Init("E-UniButton", "0.1", "Mouse Button Changer", 4,3, argc, argv, 0);
Epplet_load_config();
disp = Epplet_get_display();
XGetPointerMapping(disp, buttons, MAXBUTTON);
cur_button = buttons[0];
Esnprintf(curb, 2, "%d", cur_button);
close_button = Epplet_create_std_button("CLOSE", 2, 2, close_cb, (void *)NULL);
Epplet_gadget_show(label1 = Epplet_create_label(5, 10, "Button:", 3));
Epplet_gadget_show(label2 = Epplet_create_label(48, 10, curb, 3));
Epplet_gadget_show(button1 = Epplet_create_text_button("Next", 15, 28, 30, 12,
next_button, (void *)NULL));
Epplet_register_focus_in_handler(in_cb, NULL);
Epplet_register_focus_out_handler(out_cb, NULL);
Epplet_register_delete_event_handler(delete_cb, NULL);
Epplet_show();
Epplet_Loop();
return 0;
}
^ permalink raw reply [relevance 57%]
* Re: Bug in acceled Xpmac?
@ 2000-02-14 17:45 64% Kevin_Hendricks
0 siblings, 0 replies; 200+ results
From: Kevin_Hendricks @ 2000-02-14 17:45 UTC (permalink / raw)
To: linuxppc-dev, ningerso
Hi,
Yes, thjere was a serious mouse bug problem with usb mice fixed in
Xpmac rev8 and later versions. It seems that the accelerated Xpmac
was not properly setting an accurate time for the mouse button
events.
Please try upgrading to Xpmac rev9 and try again (see
http://www.linuxppc.org/BlueG3/ for a link.
If you still have a mouse problem with Xpmac rev9, please let me
know.
Thanks,
Kevin
>It looks like the accelerated Xpmac that was released in January
may have
>a bug in mouse handling.
>
>I was working on a small epplet for one button mouse users to make
better
>use of enlightenment. When using the version of Xpmac that shipped
with
>LinuxPPC 1999 Q1 it worked fine. But when using the recent
accelerated
>version, the mouse functionality wouldn't change.
>
>XGetPointerMapping returns the values that were set, but it doesn't
seem
>to be updating the way it handles the button.
>
>Has anyone else seen similar behavior or know of a fix? I attached
the
>source of my program for anyone interested in trying it out.
>
>-------------------------------------------------------------------
--------
>| Nathan Ingersoll | Computer Science/Mathematics
|
>| mailto: ningerso@d.umn.edu | University of Minnesota-Duluth
|
>| http://umn.edu/~ningerso | http://www.d.umn.edu
|
>-------------------------------------------------------------------
--------
>
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: Bug in acceled Xpmac?
[not found] <200002141749.LAA13446@mail.d.umn.edu>
@ 2000-02-14 21:33 64% ` Nathan Ingersoll
0 siblings, 0 replies; 200+ results
From: Nathan Ingersoll @ 2000-02-14 21:33 UTC (permalink / raw)
To: Kevin_Hendricks; +Cc: linuxppc-dev
The problem still exists in this version. Also, this machine doesn't have
USB. It's a straight 6500/250, no upgrades or add-ons. The program just
tries to remap the first button to a different button.
The server reports making the change, but the mouse button behavior
doesn't change. I know the server is acknowledging the change, because the
program calls XGetPointerMapping to set it's initial values. Exiting the
program and starting it again reports the same values that were set at the
end of the last run.
---------------------------------------------------------------------------
| Nathan Ingersoll | Computer Science/Mathematics |
| mailto: ningerso@d.umn.edu | University of Minnesota-Duluth |
| http://umn.edu/~ningerso | http://www.d.umn.edu |
---------------------------------------------------------------------------
On Mon, 14 Feb 2000, Kevin_Hendricks wrote:
> Hi,
>
> Yes, thjere was a serious mouse bug problem with usb mice fixed in
> Xpmac rev8 and later versions. It seems that the accelerated Xpmac
> was not properly setting an accurate time for the mouse button
> events.
>
> Please try upgrading to Xpmac rev9 and try again (see
> http://www.linuxppc.org/BlueG3/ for a link.
>
> If you still have a mouse problem with Xpmac rev9, please let me
> know.
>
> Thanks,
>
> Kevin
>
> >It looks like the accelerated Xpmac that was released in January
> may have
> >a bug in mouse handling.
> >
> >I was working on a small epplet for one button mouse users to make
> better
> >use of enlightenment. When using the version of Xpmac that shipped
> with
> >LinuxPPC 1999 Q1 it worked fine. But when using the recent
> accelerated
> >version, the mouse functionality wouldn't change.
> >
> >XGetPointerMapping returns the values that were set, but it doesn't
> seem
> >to be updating the way it handles the button.
> >
> >Has anyone else seen similar behavior or know of a fix? I attached
> the
> >source of my program for anyone interested in trying it out.
> >
> >-------------------------------------------------------------------
> --------
> >| Nathan Ingersoll | Computer Science/Mathematics
> |
> >| mailto: ningerso@d.umn.edu | University of Minnesota-Duluth
> |
> >| http://umn.edu/~ningerso | http://www.d.umn.edu
> |
> >-------------------------------------------------------------------
> --------
> >
>
> --
> Kevin B. Hendricks
> Associate Professor of Operations and Information Technology
> Richard Ivey School of Business, University of Western Ontario
> London, Ontario N6A-3K7 CANADA
> khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* New GCC package to fix "internal compiler error in add_pending_init" bug with linux-2.3.47
@ 2000-02-21 0:37 64% Franz Sirl
0 siblings, 0 replies; 200+ results
From: Franz Sirl @ 2000-02-21 0:37 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Paul Mackerras
Hi,
I've made gcc rev. 1i, fixing the ICE in compiling 2.3.47. It contains the
official fix backported to gcc-2.95.2.
You can download from the usual place:
ftp://devel.linuxppc.org/users/fsirl/R5/RPMS/ppc/
Franz.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* [parisc-linux] Tulip Driver Bug
@ 2000-02-23 16:25 59% John Marvin
2000-02-23 18:22 64% ` Grant Grundler
0 siblings, 1 reply; 200+ results
From: John Marvin @ 2000-02-23 16:25 UTC (permalink / raw)
To: parisc-linux
I've been having reliability problems with networking on my J5000.
I tracked the problem down to this piece of code in tulip_interrupt():
if (--work_budget < 0) {
if (tulip_debug > 1)
printk(KERN_WARNING "%s: Too much work during an interrupt, "
"csr5=0x%8.8x.\n", dev->name, csr5);
/* Acknowledge all interrupt sources. */
outl(0x8001ffff, ioaddr + CSR5);
/* Clear all interrupting sources, set timer to re-enable. */
outl(((~csr5) & 0x0001ebef) | AbnormalIntr | TimerInt,
ioaddr + CSR7);
outl(12, ioaddr + CSR11);
break;
}
My understanding is that this code tries to defer work until later because
too many incoming packets have been handled during the current interrupt.
The problem is that there is no later. Once this code is run I stop
seeing iosapic interrupts, and a little later I get some Tx Hung messages,
one or two more interrupts, and then that is it. The bug may not actually
be in the above code, i.e. it may be in the timer re-enable that is
mentioned in the comment above.
If I ifdef the above code out, the driver is fairly reliable. I've run
tests with more than 20 sockets open simultaneously.
I believe the reason I see this problem more than others is probably due
to the fact that I am running on a fairly high traffic network, so the
machine is seeing a lot more packets. You should be able to reproduce
the problem by reducing the value of max_interrupt_work.
I could continue working on this problem to track it to root cause, but at
this point I would have to spend more time learning the driver and the
tulip hardware. Perhaps someone with more experience with this driver
could find the problem with less effort.
I haven't tried this on another machine like an A-180 to determine if
the problem is only on iosapic based machines or if the problem is
general to all tulip based lan interfaces.
John Marvin
jsm@fc.hp.com
^ permalink raw reply [relevance 59%]
* Re: [parisc-linux] Tulip Driver Bug
2000-02-23 16:25 59% [parisc-linux] Tulip Driver Bug John Marvin
@ 2000-02-23 18:22 64% ` Grant Grundler
0 siblings, 0 replies; 200+ results
From: Grant Grundler @ 2000-02-23 18:22 UTC (permalink / raw)
To: John Marvin; +Cc: parisc-linux
John Marvin wrote:
> My understanding is that this code tries to defer work until later because
> too many incoming packets have been handled during the current interrupt.
> The problem is that there is no later.
John,
thanks for bringing it this far.
Can someone verify the IRQ line is remains asserted?
If the IRQ line is asserted, this sounds like a problem in iosapic code.
I've seen this behavior before when iosapic_isr() didn't write the
correct value to the EOI register. I'll review the iosapic code.
But if someone could give me confidence the IRQ is asserted, I'd
appreciate it.
thanks,
grant
Grant Grundler
Unix Development Lab
+1.408.447.7253
^ permalink raw reply [relevance 64%]
* [linux-lvm] Bug in modules (fwd)
@ 2000-02-25 8:59 64% Michael Marxmeier
0 siblings, 0 replies; 200+ results
From: Michael Marxmeier @ 2000-02-25 8:59 UTC (permalink / raw)
To: linux-lvm
Forwarded message ...
-------- Original Message --------
Date: Thu, 24 Feb 2000 20:17:02 -0500
From: Wakko Warner <wakko@animx.eu.org>
Subject: Bug in modules
I have a machine that boots from scsi and I have IDE compiled as
modules.
The use count for the IDE modules are always 0 even when writing to
the
ide drives. I consider this a major bug if someone uses rmmod -a
every so
often.
--
Lab tests show that use of micro$oft causes cancer in lab animals
^ permalink raw reply [relevance 64%]
* [linux-lvm] Re: LVM bug report and questions
[not found] <m12Rayn-0006h9C@grumbeer.inka.de>
@ 2000-03-05 17:07 64% ` Heinz Mauelshagen
0 siblings, 0 replies; 200+ results
From: Heinz Mauelshagen @ 2000-03-05 17:07 UTC (permalink / raw)
To: Hans-Joachim Baader; +Cc: mge, linux-lvm
> Hi,
>
> I have kernel 2.2.15pre13, LVM 0.7 (first question: will 0.8 be ported
> to kernel 2.2.15?
Yes.
) on a dual Pentium-200 MMX with two 20G IBM disks
> (/dev/hdb and /dev/hdc at the moment).
> vgscan was unable to find the volume groups I defined. In the debug
> output I could see that after scanning hda16, the scan continued
> with hdb11 rather than hdb1. I found the relevant code which looked
> suspicous to me. So I changed it:
>
> --- pv_read_all_pv.c.orig Sun Mar 5 14:07:34 2000
> +++ pv_read_all_pv.c Sun Mar 5 14:07:40 2000
> @@ -102,7 +102,7 @@
> if ( ( tst = open ( dev_name, O_RDONLY)) == -1) {
> if ( MAJOR ( dir_cache[n].st_rdev) != MD_MAJOR &&
> MINOR ( dir_cache[n].st_rdev) % 16 == 0) {
> - n += 15;
> + /*n += 15;*/
> continue;
> }
> } else close ( tst);
>
> It's probably still wrong but at least it worked for me ;-)
In some /dev configurations there's overlapping of device nodes which
breaks the above performance oriented search algorithm.
Your workaround helps in these cases as correct setup of all /dev
nodes does.
>
> It is possible to make a LV the root partition if initrd is used.
> However, is this also possible when the root is on a striped LV?
Yes.
> I guess not because LILO would have to know how to handle it.
LILO loads an initrd from a small partition (about 20MB in size)
and at the EOF of /linuxrc after activation of the Volume Group(s)
it switches to the real root-filesystem which can live on a
striped logical volume,
> Are there plans to make this possible?
See above.
>
> What is the performance of striped LVs compared to a md device with
> RAID0?
More or less the same.
> On my system, using Reiserfs, I get about 9 MB/s on each
> individual disk, measured with hdparm. On a striped LV I get
> about 11 MB/s, measured with Bonnie.
Do you have all Physical Volumes you use to allocate Extemts to the striped
Logical Volume on different physical disks and IDE adapters?
> Given that hdparm and Bonnie
> usually agree about the speed, this seems not much of an
> improvement. How much is the CPU overhead for striped LVs?
Minimal.
> Is there more to gain in different configurations, eg. if I
> hooked the disks to a UDMA controller?
>
> Thanks,
> hjb
> --
> http://www.pro-linux.de/ - Germany's largest volunteer Linux support site
> You feel strangely lucky...
>
Heinz
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Systemmanagement CS-TS T-Nova
Entwicklungszentrum Darmstadt
Heinz Mauelshagen Otto-Roehm-Strasse 71c
Senior Systems Engineer Postfach 10 05 41
64205 Darmstadt
mge@EZ-Darmstadt.Telekom.de Germany
+49 6151 886-425
FAX-386
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
^ permalink raw reply [relevance 64%]
* Kernel Bug Report-Jeram
@ 2000-03-07 8:19 64% jeramy b smith
0 siblings, 0 replies; 200+ results
From: jeramy b smith @ 2000-03-07 8:19 UTC (permalink / raw)
To: linuxppc-dev
I wrote to linuxppc user to get some feedback on a kernel error I was running
into. Specifically, when booting 2.2.15pre3 directly (yaboot); my Lombard 333
hangs when it enables multiword dma for hda. It gives the message that it
enables multiword dma , gives the specs of the drive twice, and duly hangs.
1. If I boot from a a linuxppc cdrom this does not occur.
2. If I warm reboot after booting from a Linux cdrom and mounting the drives
or booting from a macos cdrom, then the direct boot succeeds.
3. If I boot from a bootx extension, this does not occur.
4. If I direct boot the newer kernel in cs 1.2 (pre8?), multiword dma is
successfully initialized for hda but then I get two messages that multiword is
enabled for hdc followed by a nice hang.
-Jeramy
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* LinuxPPC-2000: Bug in the RH installer
[not found] <Pine.LNX.4.10.10001211706220.29354-100000@mail.linuxppc.org>
@ 2000-03-23 12:11 64% ` Ingvar Hagelund; UiO
0 siblings, 0 replies; 200+ results
From: Ingvar Hagelund; UiO @ 2000-03-23 12:11 UTC (permalink / raw)
To: Jeff Carr; +Cc: linuxppc-dev
The CD-ROM images spread to the LinuxPPC mirrors over the world are in hfs
format. The Red Hat installer tries to mount the CD-ROM as an 9660 image.
This won't of course work, and causes problems, for example for RS/6000
owners like myself.
A simple solution would be to change the RH installer so that it mounts
with "-t auto" instead of "-t iso9660". Then it will detect the CD-ROM
properly, both for iso9660 and hfs CD-ROMs.
Regards
Ingvar
------------------------------------------------------------------------
Ingvar Hagelund Phone: (+47) 22740512
E-mail: ingvar@unik.no WWW: http://www.ifi.uio.no/~ingvarha
Adress: Ringshusveien 10, N-1176 OSLO, NORWAY
Experience GNU/Linux!
-------------------------------------------------------------------------
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Found bug in mode switching but who is at fault...XFree86 or aty128fb.c?
@ 2000-03-25 3:54 56% ` Kevin Hendricks
2000-03-25 7:57 64% ` Michel Dänzer
2000-03-25 13:46 64% ` Geert Uytterhoeven
0 siblings, 2 replies; 200+ results
From: Kevin Hendricks @ 2000-03-25 3:54 UTC (permalink / raw)
To: Kostas Gewrgiou, Ani Joshi; +Cc: linuxppc-dev
Hi,
I figured since the fbdev driver showed the same problem as the r128 driver,
that the mode switching problem must be in either aty128fb.c or xfree86 but not
in the r128 driver.
Okay so I found the bug. It seems all through the r128 driver, crtc.pitch
values are set to the virtual x resolution (vxres) / 8. But in aty128fb.c in
the var_to_crtc routine the crtc.pitch is set to be just the xres / 8.
This is not a problem if xres == vxres. Which is what happens when the
aty128fb.c starts up. So for any one mode it defaults to being okay.
However, when doing mode switching via the Cntl-Alt-Keypad+- keys, xfree sets
vxres and vyres to be the same as the resolution of the largest mode on that
line (so 1152x870 becomes my vxres, and vyres when 1152x870, 832x624, 1024x768
are all specified on the same line.
This results in a call to aty128fb_set-var which calls decode_var which calls
var_to_crtc. which gets the crtc.pitch wrong.
So my questions is as follows?
Who is wrong? Should xfree shrink the vxres and vyres to match xres and yres
before calling set_var or should aty128fb.c var_to_crtc routine be fixed to use
vxres >> 3 instead of just xres >> 3?
If aty128fb.c needs to be fixed, here is a patch:
--- aty128fb.c.last Sat Mar 18 23:04:24 2000
+++ aty128fb.c Fri Mar 24 22:39:26 2000
@@ -794,8 +794,11 @@
crtc->v_sync_strt_wid = v_sync_strt | (v_sync_wid << 16) |
(v_sync_pol << 23);
+#if 0
crtc->pitch = xres >> 3;
-
+#else
+ crtc->pitch = vxres >> 3;
+#endif
crtc->offset = 0;
crtc->offset_cntl = 0;
But I am not sure if this makes sense alone.
What use is it to get a nice 832x624 hole into a display that is virtually
1152x870?!? I can't get to any of the kde controls, panels, etc since they are
off the screen! And it would be a pain to have to pan around looking for them
(especially since the ioctl for panning is on the "to do" list!).
So my feeling is that both are wrong. We should shrink the virtual resolution
to match the physical resolution in xfree when mode switching and put the patch
in place in aty128fb.c
Comments?
Thanks,
Kevin
--
Kevin B. Hendricks
Associate Professor of Operations and Information Technology
Richard Ivey School of Business, University of Western Ontario
London, Ontario N6A-3K7 CANADA
khendricks@ivey.uwo.ca, (519) 661-3874, fax: 519-661-3959
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 56%]
* Re: Found bug in mode switching but who is at fault...XFree86 or aty128fb.c?
2000-03-25 3:54 56% ` Found bug in mode switching but who is at fault...XFree86 or aty128fb.c? Kevin Hendricks
@ 2000-03-25 7:57 64% ` Michel Dänzer
2000-03-25 8:07 64% ` Michel Dänzer
2000-03-25 13:46 64% ` Geert Uytterhoeven
1 sibling, 1 reply; 200+ results
From: Michel Dänzer @ 2000-03-25 7:57 UTC (permalink / raw)
To: khendricks; +Cc: Kostas Gewrgiou, Ani Joshi, linuxppc-dev
Kevin Hendricks wrote:
> Okay so I found the bug. It seems all through the r128 driver, crtc.pitch
> values are set to the virtual x resolution (vxres) / 8. But in aty128fb.c
> in the var_to_crtc routine the crtc.pitch is set to be just the xres / 8.
>
> This is not a problem if xres == vxres. Which is what happens when the
> aty128fb.c starts up.
Not necessarily. The problem could have shown up if someone had put a mode
with xres < vxres as first in the "Modes" line, but apparently only
configuration tools tend to do that...
> So for any one mode it defaults to being okay.
Okay.
> Who is wrong? Should xfree shrink the vxres and vyres to match xres and
> yres before calling set_var or should aty128fb.c var_to_crtc routine be
> fixed to use vxres >> 3 instead of just xres >> 3?
I vote for the latter, because otherwise invisible parts of the screen may be
damaged, or am I wrong?
A better reason might be that it works perfectly as-is in glint ;)
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: Found bug in mode switching but who is at fault...XFree86 or aty128fb.c?
2000-03-25 7:57 64% ` Michel Dänzer
@ 2000-03-25 8:07 64% ` Michel Dänzer
0 siblings, 0 replies; 200+ results
From: Michel Dänzer @ 2000-03-25 8:07 UTC (permalink / raw)
To: khendricks; +Cc: Kostas Gewrgiou, Ani Joshi, linuxppc-dev
Michel Dänzer wrote:
>
> Kevin Hendricks wrote:
>
> > This is not a problem if xres == vxres. Which is what happens when the
> > aty128fb.c starts up.
>
> Not necessarily. The problem could have shown up if someone had put a mode
> with xres < vxres as first in the "Modes" line, but apparently only
> configuration tools tend to do that...
Oops. I misread you were writing about the r128 driver. My apologies.
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: Found bug in mode switching but who is at fault...XFree86 or aty128fb.c?
2000-03-25 3:54 56% ` Found bug in mode switching but who is at fault...XFree86 or aty128fb.c? Kevin Hendricks
2000-03-25 7:57 64% ` Michel Dänzer
@ 2000-03-25 13:46 64% ` Geert Uytterhoeven
1 sibling, 0 replies; 200+ results
From: Geert Uytterhoeven @ 2000-03-25 13:46 UTC (permalink / raw)
To: Kevin Hendricks; +Cc: Kostas Gewrgiou, Ani Joshi, linuxppc-dev
On Fri, 24 Mar 2000, Kevin Hendricks wrote:
> Okay so I found the bug. It seems all through the r128 driver, crtc.pitch
> values are set to the virtual x resolution (vxres) / 8. But in aty128fb.c in
> the var_to_crtc routine the crtc.pitch is set to be just the xres / 8.
Which is wrong: aty128fb must do `vxres * bpp / 8'.
> Who is wrong? Should xfree shrink the vxres and vyres to match xres and yres
> before calling set_var or should aty128fb.c var_to_crtc routine be fixed to use
> vxres >> 3 instead of just xres >> 3?
XFree86 cannot change the visible resolution on the fly.
> What use is it to get a nice 832x624 hole into a display that is virtually
> 1152x870?!? I can't get to any of the kde controls, panels, etc since they are
> off the screen! And it would be a pain to have to pan around looking for them
> (especially since the ioctl for panning is on the "to do" list!).
Hence panning needs to be fixed :-) In fact panning is very simple, just change
the offset of the first pixel. That's a `one-register' update.
> So my feeling is that both are wrong. We should shrink the virtual resolution
> to match the physical resolution in xfree when mode switching and put the patch
> in place in aty128fb.c
XFree86 cannot change the visible resolution on the fly, so we cannot change
it. Design bug in the whole X system :-)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* [linux-lvm] SMP bug: vmalloc() called without lock_kernel()
@ 2000-03-25 14:38 64% Manfred Spraul
0 siblings, 0 replies; 200+ results
From: Manfred Spraul @ 2000-03-25 14:38 UTC (permalink / raw)
To: linux-LVM, linux-LVM
vmalloc() is protected by the big kernel lock, but AFAICS
lvm_proc_get_info() calls vmallloc() without lock_kernel():
lvm_proc_get_info() is called by
linux/fs/proc/generic.c:proc_file_read(), and file_read runs without the
big kernel lock in 2.3.
Could you add "lock_kernel()" around vmalloc()/vfree() in
lvm_proc_get_info()? The ioctl functions are called with the kernel
locked, thus you don't need lock_kernel() in your ioctl/open functions.
Btw, your sleep_on() usage in lvm_map() seems to be wrong:
* sleep_on() is evil, processes could get stuck if the second cpu in in
lvm_do_pe_unlock() [even on i386].
add_wait_queue();
wait_again:
set_current_state(TASK_UNINTERRUPTIBLE);
if(we_must_wait_and_someone_will_wake_us_up) {
schedule();
goto wait_again;
}
remove_wait_queue();
goto retry;
* lvm_do_pe_lock_unlock() assume that the cpu won't reorder write
instructions,
pe_lock_req.lock = UNLOCK_PE;
+ wmb();
pe_lock_req.data.lv_dev = \
--
Manfred
^ permalink raw reply [relevance 64%]
* Re: Voodoo 3 bug on 2.3.99pre3
@ 2000-03-28 10:29 64% Michel D?nzer
2000-03-28 15:22 47% ` Kostas Gewrgiou
0 siblings, 1 reply; 200+ results
From: Michel D?nzer @ 2000-03-28 10:29 UTC (permalink / raw)
To: sabotage; +Cc: linuxppc-dev
--- sabotage <kcz84@dial.pipex.com> wrote:
> I have a voodoo 3 2000 PCI card on my UMAX s900 SMP and i was trying to
> get the SMP and the Voodoo to work with linux I decided to start with the
> graphics card i got a 2.3.99pre3 kernel via ftp from kernel.org and
> compiled it with voodoo support but NO ati card support (since i dont have
> ati -- well i do but i dont use it and it failed to compile when i had ATI
> checked anyway) thus i it compiled booted but the whoole console display
was
> completely messed up sorta reversed with weird colors etc basically a
> complete mess.
Sounds like the usual endianness problems ...
What depth?
> So i was just wondering if anyone had any ideas on getting it to work or
> am i wasting my time.....
AFAIK Kostas has the 3Dfx fbdev working.
Michel
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: Voodoo 3 bug on 2.3.99pre3
2000-03-28 10:29 64% Voodoo 3 bug on 2.3.99pre3 Michel D?nzer
@ 2000-03-28 15:22 47% ` Kostas Gewrgiou
0 siblings, 0 replies; 200+ results
From: Kostas Gewrgiou @ 2000-03-28 15:22 UTC (permalink / raw)
To: michdaen; +Cc: sabotage, linuxppc-dev
[-- Attachment #1: Type: TEXT/PLAIN, Size: 923 bytes --]
On Tue, 28 Mar 2000, Michel D?nzer wrote:
> Sounds like the usual endianness problems ...
>
> What depth?
Right the accelerated functions aren't big endian friendly,
it also needs to switch the framebuffer to the right byteswapping
for the depth in big endian machines.
> > So i was just wondering if anyone had any ideas on getting it to work or
> > am i wasting my time.....
>
> AFAIK Kostas has the 3Dfx fbdev working.
>
I am attaching the patch that i use (which is far from perfect at the
moment) i did so i could work in fbdev support in the xfree tdfx driver.
Text accel is disabled, i also use a 32mb mapping for the registers
to include the 3D registers (needed by the xserver).
The xserver also needs a fb mapping with twice the ram size (for tiled
memory accesses also needed by the Xserver) unfortunately this has the side
affect that the reported memory from tdfxfb is twice the normal size.
Kostas
[-- Attachment #2: Type: TEXT/PLAIN, Size: 6755 bytes --]
--- cvs/linux-pmac-devel/drivers/video/tdfxfb.c Fri Jan 7 03:52:48 2000
+++ linux_2.3.99-pre3/drivers/video/tdfxfb.c Tue Mar 28 18:02:22 2000
@@ -295,6 +295,7 @@
unsigned long clip1max;
unsigned long srcbase;
unsigned long dstbase;
+ unsigned long miscinit0;
};
struct tdfxfb_par {
@@ -579,12 +580,16 @@
static struct fb_info_tdfx fb_info;
+#if defined(CONFIG_PPC)
+static int noaccel = 1; /* accel is broken in ppc */
+#else
static int noaccel = 0;
+#endif
+static int nohwcursor = 1; /* disable hwcursor for now */
static int nopan = 0;
static int nowrap = 1; // not implemented (yet)
static int inverse = 0;
static int nomtrr = 0;
-static int nohwcursor = 0;
static char __initdata fontname[40] = { 0 };
static const char *mode_option __initdata = NULL;
@@ -721,7 +726,7 @@
static void do_pan_var(struct fb_var_screeninfo* var, struct fb_info_tdfx *i)
{
u32 addr;
- addr = var->yoffset*i->current_par.lpitch;
+ addr = var->yoffset*i->current_par.lpitch + var->xoffset * ((var->bits_per_pixel+7)>>3);
banshee_make_room(1);
tdfx_outl(VIDDESKSTART, addr);
}
@@ -1008,7 +1013,7 @@
tdfx_outl(VIDPROCCFG, reg->vidcfg);
tdfx_outl(VGAINIT1, reg->vgainit1);
- banshee_make_room(8);
+ banshee_make_room(9);
tdfx_outl(SRCBASE, reg->srcbase);
tdfx_outl(DSTBASE, reg->dstbase);
tdfx_outl(COMMANDEXTRA_2D, 0);
@@ -1017,6 +1022,7 @@
tdfx_outl(CLIP1MIN, 0);
tdfx_outl(CLIP1MAX, 0x0fff0fff);
tdfx_outl(SRCXY, 0);
+ tdfx_outl(MISCINIT0, (tdfx_inl(MISCINIT0) & ~0xc0000000) | reg->miscinit0);
banshee_wait_idle();
}
@@ -1353,6 +1359,17 @@
vbs = vd;
vbe = vt;
+#if defined(__BIG_ENDIAN)
+ switch(par->bpp) {
+ case 32: reg.miscinit0 = 0x40000000; break;
+ case 16: reg.miscinit0 = 0xc0000000; break;
+ default: reg.miscinit0 = 0x00000000; break;
+ }
+ /* XXX what can be done for 24bpp ?? */
+#elif
+ reg.miscinit0 = 0x00000000;
+#endif
+
/* this is all pretty standard VGA register stuffing */
reg.misc[0x00] =
0x0f |
@@ -1468,7 +1485,7 @@
fb_info.cursor.enable=reg.vidcfg | VIDCFG_HWCURSOR_ENABLE;
fb_info.cursor.disable=reg.vidcfg;
- reg.stride = par->width*cpp;
+ reg.stride = par->width_virt*cpp;
reg.cursloc = 0;
reg.cursc0 = 0;
@@ -1523,13 +1540,8 @@
return -EINVAL;
}
- if(var->xoffset) {
- DPRINTK("xoffset not supported\n");
- return -EINVAL;
- }
-
- if(var->xres != var->xres_virtual) {
- DPRINTK("virtual x resolution != physical x resolution not supported\n");
+ if(var->xres > var->xres_virtual) {
+ DPRINTK("virtual x resolution < physical x resolution not supported\n");
return -EINVAL;
}
@@ -1550,12 +1562,12 @@
case PCI_DEVICE_ID_3DFX_BANSHEE:
case PCI_DEVICE_ID_3DFX_VOODOO3:
par->width = (var->xres + 15) & ~15; /* could sometimes be 8 */
- par->width_virt = par->width;
+ par->width_virt = var->xres_virtual;
par->height = var->yres;
par->height_virt = var->yres_virtual;
par->bpp = var->bits_per_pixel;
par->ppitch = var->bits_per_pixel;
- par->lpitch = par->width* ((par->ppitch+7)>>3);
+ par->lpitch = par->width_virt* ((par->ppitch+7)>>3);
par->cmap_len = (par->bpp == 8) ? 256 : 16;
par->baseline = 0;
@@ -1645,6 +1657,7 @@
v.green.offset=8;
v.blue.offset=0;
v.red.length = v.green.length = v.blue.length = 8;
+ break;
case 32:
v.red.offset = 16;
v.green.offset = 8;
@@ -1708,7 +1721,7 @@
? FB_VISUAL_PSEUDOCOLOR
: FB_VISUAL_DIRECTCOLOR;
- fix->xpanstep = 0;
+ fix->xpanstep = nopan ? 0 : 8;
fix->ypanstep = nopan ? 0 : 1;
fix->ywrapstep = nowrap ? 0 : 1;
@@ -1882,7 +1895,7 @@
struct fb_info_tdfx* i = (struct fb_info_tdfx*)fb;
if(nopan) return -EINVAL;
- if(var->xoffset) return -EINVAL;
+ if(var->xoffset + var->xres > var->xres_virtual) return -EINVAL;
if(var->yoffset > var->yres_virtual) return -EINVAL;
if(nowrap &&
(var->yoffset + var->yres > var->yres_virtual)) return -EINVAL;
@@ -1962,6 +1975,7 @@
#endif
struct pci_dev *pdev = NULL;
struct fb_var_screeninfo var;
+ unsigned short cmd;
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,1)
if(!pcibios_present()) return;
@@ -1983,18 +1997,23 @@
? BANSHEE_MAX_PIXCLOCK
: VOODOO3_MAX_PIXCLOCK;
+ /* Enable IO and MEM (not enabled in ppc by OF) */
+ pci_read_config_word( pdev, PCI_COMMAND, &cmd );
+ cmd |= (PCI_COMMAND_MEMORY | PCI_COMMAND_IO);
+ pci_write_config_word( pdev, PCI_COMMAND, cmd );
+
#if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,1)
fb_info.regbase_phys = pdev->base_address[0] & PCI_BASE_ADDRESS_MEM_MASK;
- fb_info.regbase_size = 1 << 24;
+ fb_info.regbase_size = 1 << 25;
fb_info.regbase_virt =
- (u32)ioremap_nocache(fb_info.regbase_phys, 1 << 24);
+ (u32)ioremap_nocache(fb_info.regbase_phys, 1 << 25);
if(!fb_info.regbase_virt) {
printk("fb: Can't remap %s register area.\n", name);
return;
}
fb_info.bufbase_phys = pdev->base_address[1] & PCI_BASE_ADDRESS_MEM_MASK;
- if(!(fb_info.bufbase_size = do_lfb_size())) {
+ if(!(fb_info.bufbase_size = 2*do_lfb_size())) {
printk("fb: Can't count %s memory.\n", name);
iounmap((void*)fb_info.regbase_virt);
return;
@@ -2010,16 +2029,16 @@
fb_info.iobase = pdev->base_address[2] & PCI_BASE_ADDRESS_IO_MASK;
#else
fb_info.regbase_phys = pdev->resource[0].start;
- fb_info.regbase_size = 1 << 24;
+ fb_info.regbase_size = 1 << 25;
fb_info.regbase_virt =
- (u32)ioremap_nocache(fb_info.regbase_phys, 1 << 24);
+ (u32)ioremap_nocache(fb_info.regbase_phys, 1 << 25);
if(!fb_info.regbase_virt) {
printk("fb: Can't remap %s register area.\n", name);
return -ENXIO;
}
fb_info.bufbase_phys = pdev->resource[1].start;
- if(!(fb_info.bufbase_size = do_lfb_size())) {
+ if(!(fb_info.bufbase_size = 2*do_lfb_size())) {
iounmap((void*)fb_info.regbase_virt);
printk("fb: Can't count %s memory.\n", name);
return -ENXIO;
@@ -2443,7 +2462,7 @@
fb_info.bufbase_size=start;
fb_info.cursor.cursorimage=fb_info.bufbase_size;
printk("tdfxfb: reserving 1024 bytes for the hwcursor at 0x%08lx\n",
- fb_info.regbase_virt+fb_info.cursor.cursorimage);
+ fb_info.bufbase_virt+fb_info.cursor.cursorimage);
}
^ permalink raw reply [relevance 47%]
* Re: Voodoo 3 bug on 2.3.99pre3
2000-03-29 9:48 64% sabotage
@ 2000-03-28 19:01 64% ` phandel
0 siblings, 0 replies; 200+ results
From: phandel @ 2000-03-28 19:01 UTC (permalink / raw)
To: sabotage; +Cc: linuxppc-dev
On Wed, 29 Mar 2000, sabotage wrote:
> I have a voodoo 3 2000 PCI card on my UMAX s900 SMP and i was trying to get
You can try the _experimental_ kernel & XFree86 3.9.16 rpm from Kostas:
ftp://idd-01.imbc.gr/pub/voodoo3
NOTE: XFree86 4.0 REQUIRES a very different /etc/X11/XF86Config file from
XFree86 3.x. I have some different XF86Config files at:
http://www.cise.ufl.edu/~phandel/linux/sample/
Also, you *may* need to change the BusID number based on what slot your
Voodoo3 is in (BusID "PCI:0:15:0" for me) if commenting it out doesn't
work.
3.9.16 runs well, although not as fast as 4.0. I've put a comparison of
the Rage128-x86, TNT2, and Voodoo3 XF86 3.9.16 & 4.0 on my web page:
http://www.cise.ufl.edu/~phandel/linux/txt/r128_tnt2_v3.txt
I believe these were all done at 1024x768 16bpp.
Thanks,
Peter
[btw- you can also copy the tdfxfb.c from 2.3.x to a 2.2.14 tree and apply
Kostas' tdfxfb patch, which is what I'm running]
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Voodoo 3 bug on 2.3.99pre3
@ 2000-03-29 9:48 64% sabotage
2000-03-28 19:01 64% ` phandel
0 siblings, 1 reply; 200+ results
From: sabotage @ 2000-03-29 9:48 UTC (permalink / raw)
To: linuxppc-dev
hello all...
ok i dont know weather i am writing to the right people but here goes.
I have a voodoo 3 2000 PCI card on my UMAX s900 SMP and i was trying to get
the SMP and the Voodoo to work with linux I decided to start with the
graphics card i got a 2.3.99pre3 kernel via ftp from kernel.org and compiled
it with voodoo support but NO ati card support (since i dont have ati --
well i do but i dont use it and it failed to compile when i had ATI checked
anyway) thus i it compiled booted but the whoole console display was
completely messed up sorta reversed with weird colors etc basically a
complete mess.
So i was just wondering if anyone had any ideas on getting it to work or am
i wasting my time.....
thanks =)
PS talk about a weird/unsupported setup eh....
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* gcc bug
@ 2000-03-31 14:27 64% Josh Huber
2000-03-31 15:18 62% ` Gabriel Paubert
0 siblings, 1 reply; 200+ results
From: Josh Huber @ 2000-03-31 14:27 UTC (permalink / raw)
To: Linux/PowerPC Devel List
Interesting gcc bug here...
in both cases this should print 0xDEADBEEF, but in the second case, garbage
is printed.
main()
{
unsigned long t1 = 32;
unsigned long long t2 = 64;
printf("%x\n", 1 ? 0xDEADBEEF : t1);
printf("%x\n", 1 ? 0xDEADBEEF : t2);
}
as expected, the 1 ? ... operation is optimized away, but the compiler seems
to screw things up ...
working case:
li 4,15
crxor 6,6,6
bl printf
failure case:
li 5,0
li 6,15
crxor 6,6,6
bl printf
in the failure case, r4 is not loaded with anything, so this is were the
garbage probably comes from.
This is a greatly simplified version of an actual piece of code (obviously,
as the code above is silly :)
Josh
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: gcc bug
2000-03-31 14:27 64% gcc bug Josh Huber
@ 2000-03-31 15:18 62% ` Gabriel Paubert
0 siblings, 0 replies; 200+ results
From: Gabriel Paubert @ 2000-03-31 15:18 UTC (permalink / raw)
To: Josh Huber; +Cc: Linux/PowerPC Devel List
On Fri, 31 Mar 2000, Josh Huber wrote:
>
> Interesting gcc bug here...
No.
>
> in both cases this should print 0xDEADBEEF, but in the second case, garbage
> is printed.
>
> main()
> {
> unsigned long t1 = 32;
> unsigned long long t2 = 64;
>
> printf("%x\n", 1 ? 0xDEADBEEF : t1);
> printf("%x\n", 1 ? 0xDEADBEEF : t2);
> }
>
> as expected, the 1 ? ... operation is optimized away, but the compiler seems
> to screw things up ...
>
> working case:
> li 4,15
> crxor 6,6,6
> bl printf
>
> failure case:
> li 5,0
> li 6,15
> crxor 6,6,6
> bl printf
>
> in the failure case, r4 is not loaded with anything, so this is were the
> garbage probably comes from.
The compiler is right, it chooses to pass the parameter as a long long
because of promotion rules among the types of the two expressions of a ? :
operator.
But you have to tell printf that the variable is a long long for varargs
in the library functions to find it, so replace your last statement with
printf("%llx\n", 1 ? 0xDEADBEEF : t2) and it will work properly.
There have been various bugs in this area with GCC on PPC, in some cases
due to varargs problems and the ABI actually took some time to stabilize
and to be properly implemeted IIRC. But in this case the compiler is
right: if it is a long long it can only be passed in r3:r4, r5:r6, r7:r8,
r9:r10, or on the stack.
Think at what happens if you don't tell that the argument is a long long
and you have more arguments after that one, everything will be off. And
it's not an endian issue either, it will just give the impression to work
when this is the last parameter on most little endian machines but the bug
would stil be here. Little endian is great to hide bugs, it's basically
the only "advantage" it has, and I regard this as a fundamental flaw.
Gabriel.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 62%]
* [linux-lvm] BUG: use of lvchange leads to disk corruption
@ 2000-03-31 19:00 64% jorg de jong
0 siblings, 0 replies; 200+ results
From: jorg de jong @ 2000-03-31 19:00 UTC (permalink / raw)
To: linux-lvm@msede.com
Hi,
the use of lvhange can lead to corruption of the lvm data structure on
disk,
and by doing so preventing you to access you data.
Incase you have more than one LV in one VG the use of lvchange will make
your VG inaccessable.
regards,
jorg de jong
^ permalink raw reply [relevance 64%]
* [linux-lvm] SuSE 6.4: Bug in lvmcreate_initrd
@ 2000-03-31 20:05 64% Torsten Neumann
0 siblings, 0 replies; 200+ results
From: Torsten Neumann @ 2000-03-31 20:05 UTC (permalink / raw)
To: linux-lvm
Moin,
in LVM 0.8e (4/1/2000) (shipped with SuSE 6.4) there is a bug in
lvmcreate_intrd. The new vgscan needs(?) /proc, but mount and umount are not
copied to the initrd.
Fix: Add /bin/mount and /bin/umount to INTRDFILES, and rerun
lvmcreate_intrd.
Torsten
^ permalink raw reply [relevance 64%]
* [BUG] macmodes.c in 2.3.99-pre3-pre8
@ 2000-04-01 21:10 64% Martin Costabel
2000-04-02 19:15 64% ` Ani Joshi
0 siblings, 1 reply; 200+ results
From: Martin Costabel @ 2000-04-01 21:10 UTC (permalink / raw)
To: linuxppc-dev@lists.linuxppc.org
Starting from about a week ago, the 2.3.99 bitkeeper kernels screw up
the colors in Xpmac, making it unusable (8-bit color, valkyriefb
driver). XF_FBDev is working fine.
I tracked this down to what I think is a typo in the big code crossover
from offb.c to macmodes.c. In any case, the following patch fixes the
problem for me:
-- drivers/video/macmodes.c.ori Sat Mar 25 08:25:22 2000
+++ drivers/video/macmodes.c Sat Apr 1 22:08:08 2000
@@ -271,7 +271,7 @@
n = n_entries - i;
if (n > 16)
n = 16;
- palette_cmap.start = 1;
+ palette_cmap.start = i;
palette_cmap.len = n;
for (j = 0; j < n; j++) {
--
Martin
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* Re: [BUG] macmodes.c in 2.3.99-pre3-pre8
2000-04-01 21:10 64% [BUG] macmodes.c in 2.3.99-pre3-pre8 Martin Costabel
@ 2000-04-02 19:15 64% ` Ani Joshi
0 siblings, 0 replies; 200+ results
From: Ani Joshi @ 2000-04-02 19:15 UTC (permalink / raw)
To: Martin Costabel; +Cc: linuxppc-dev@lists.linuxppc.org
oops, thanks for spotting that. You're right, i missed that in the code
migration.
thanks,
ani
On Sat, 1 Apr 2000, Martin Costabel wrote:
>
> Starting from about a week ago, the 2.3.99 bitkeeper kernels screw up
> the colors in Xpmac, making it unusable (8-bit color, valkyriefb
> driver). XF_FBDev is working fine.
>
> I tracked this down to what I think is a typo in the big code crossover
> from offb.c to macmodes.c. In any case, the following patch fixes the
> problem for me:
>
> -- drivers/video/macmodes.c.ori Sat Mar 25 08:25:22 2000
> +++ drivers/video/macmodes.c Sat Apr 1 22:08:08 2000
> @@ -271,7 +271,7 @@
> n = n_entries - i;
> if (n > 16)
> n = 16;
> - palette_cmap.start = 1;
> + palette_cmap.start = i;
> palette_cmap.len = n;
>
> for (j = 0; j < n; j++) {
>
> --
> Martin
>
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [relevance 64%]
* PG_swap_entry bug in recent kernels
@ 2000-04-03 22:22 64% Ben LaHaise
2000-04-04 15:06 61% ` Andrea Arcangeli
0 siblings, 1 reply; 200+ results
From: Ben LaHaise @ 2000-04-03 22:22 UTC (permalink / raw)
To: torvalds; +Cc: linux-mm
The following one-liner is a painful bug present in recent kernels: swap
cache pages left in the LRU lists and subsequently reclaimed by
shrink_mmap were resulting in new pages having the PG_swap_entry bit set.
This leads to invalid swap entries being put into users page tables if the
page is eventually swapped out. This was nasty to track down.
-ben
diff -ur 2.3.99-pre4-3/mm/swap_state.c test-pre4-3/mm/swap_state.c
--- 2.3.99-pre4-3/mm/swap_state.c Mon Dec 6 13:19:45 1999
+++ test-pre4-3/mm/swap_state.c Mon Apr 3 17:59:30 2000
@@ -80,6 +80,7 @@
#endif
remove_from_swap_cache(page);
swap_free(entry);
+ clear_bit(PG_swap_entry, &page->flags);
}
/*
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: PG_swap_entry bug in recent kernels
2000-04-03 22:22 64% PG_swap_entry bug in recent kernels Ben LaHaise
@ 2000-04-04 15:06 61% ` Andrea Arcangeli
2000-04-04 15:46 64% ` Rik van Riel
0 siblings, 1 reply; 200+ results
From: Andrea Arcangeli @ 2000-04-04 15:06 UTC (permalink / raw)
To: Ben LaHaise; +Cc: torvalds, linux-mm
On Mon, 3 Apr 2000, Ben LaHaise wrote:
>The following one-liner is a painful bug present in recent kernels: swap
>cache pages left in the LRU lists and subsequently reclaimed by
>shrink_mmap were resulting in new pages having the PG_swap_entry bit set.
The patch is obviously wrong and shouldn't be applied. You missed the
semantics of the PG_swap_entry bitflage enterely.
Such bit is meant _only_ to allow the swapping out the same page in the
same swap place across write-pagein faults (to avoid swap fragmentation
upon write-page-faults). If you clear such bit within
remove_from_swap_cache (that gets recalled upon a write swapin fault) you
can as well drop such bitflag completly.
The PG_swap_entry is meant to give persistence to pages in the swap space.
>This leads to invalid swap entries being put into users page tables if the
>page is eventually swapped out. This was nasty to track down.
That's obviously not the case. If you have that problem you'd better
continue to debug it.
The PG_swap_entry can _only_ deal with performance (not with stability).
You can set modify such bit as you want at any time everywhere and the
system will remains rock solid, only performance can change. You can
trivially verify that. The bitflag is read _only_ in acquire_swap_entry,
and such function will run succesfully an safely despite of the
PG_swap_entry bitflag settings.
Said the above, I obviously agree free pages shouldn't have such bit set,
since they aren't mapped anymore and so it make no sense to provide
persistence on the swap space to not allocated pages :). I seen where we
have a problem in not clearing such bit, but the fix definitely isn't to
clear the bit in the swapin-modify path.
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 61%]
* Re: PG_swap_entry bug in recent kernels
2000-04-04 15:06 61% ` Andrea Arcangeli
@ 2000-04-04 15:46 64% ` Rik van Riel
2000-04-04 16:50 64% ` Andrea Arcangeli
0 siblings, 1 reply; 200+ results
From: Rik van Riel @ 2000-04-04 15:46 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: Ben LaHaise, torvalds, linux-mm
On Tue, 4 Apr 2000, Andrea Arcangeli wrote:
> On Mon, 3 Apr 2000, Ben LaHaise wrote:
>
> >The following one-liner is a painful bug present in recent kernels: swap
> >cache pages left in the LRU lists and subsequently reclaimed by
> >shrink_mmap were resulting in new pages having the PG_swap_entry bit set.
>
> The patch is obviously wrong and shouldn't be applied. You missed the
> semantics of the PG_swap_entry bitflage enterely.
[snip]
> Said the above, I obviously agree free pages shouldn't have such
> bit set, since they aren't mapped anymore and so it make no
> sense to provide persistence on the swap space to not allocated
> pages :). I seen where we have a problem in not clearing such
> bit, but the fix definitely isn't to clear the bit in the
> swapin-modify path.
You might want to have read _where_ Ben's patch applies.
void __delete_from_swap_cache(struct page *page)
{
swp_entry_t entry;
entry.val = page->index;
#ifdef SWAP_CACHE_INFO
swap_cache_del_total++;
#endif
remove_from_swap_cache(page);
swap_free(entry);
+ clear_bit(PG_swap_entry, &page->flags);
}
When we remove a page from the swap cache, it seems fair to me
that we _really_ remove it from the swap cache.
If __delete_from_swap_cache() is called from a wrong code path,
that's something that should be fixed, of course (but that's
orthogonal to this).
To quote from memory.c::do_swap_page() :
if (write_access && !is_page_shared(page)) {
delete_from_swap_cache_nolock(page);
UnlockPage(page);
If you think this is a bug, please fix it here...
cheers,
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
Wanna talk about the kernel? irc.openprojects.net / #kernelnewbies
http://www.conectiva.com/ http://www.surriel.com/
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: PG_swap_entry bug in recent kernels
2000-04-04 15:46 64% ` Rik van Riel
@ 2000-04-04 16:50 64% ` Andrea Arcangeli
2000-04-04 17:06 63% ` Ben LaHaise
0 siblings, 1 reply; 200+ results
From: Andrea Arcangeli @ 2000-04-04 16:50 UTC (permalink / raw)
To: riel; +Cc: Ben LaHaise, Linus Torvalds, linux-mm
On Tue, 4 Apr 2000, Rik van Riel wrote:
>You might want to have read _where_ Ben's patch applies.
>
>void __delete_from_swap_cache(struct page *page)
>{
> swp_entry_t entry;
>
> entry.val = page->index;
>
>#ifdef SWAP_CACHE_INFO
> swap_cache_del_total++;
>#endif
> remove_from_swap_cache(page);
> swap_free(entry);
>+ clear_bit(PG_swap_entry, &page->flags);
>}
>
>When we remove a page from the swap cache, it seems fair to me
>that we _really_ remove it from the swap cache.
Are you sure you didn't mistaken PG_swap_entry for PG_swap_cache?
We're here talking about PG_swap_entry. The only object of that bit is to
remains set on anonymous pages that aren't in the swap cache, so next time
we'll re-add them to the swap cache we'll try to swap out them in the same
swap entry as the page were before.
>If __delete_from_swap_cache() is called from a wrong code path,
>that's something that should be fixed, of course (but that's
>orthogonal to this).
__delete_from_swap_cache is called by delete_from_swap_cache_nolock that
is called by do_swap_page that does the swapin.
>To quote from memory.c::do_swap_page() :
>
> if (write_access && !is_page_shared(page)) {
> delete_from_swap_cache_nolock(page);
> UnlockPage(page);
>
>If you think this is a bug, please fix it here...
The above quoted code is correct.
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 64%]
* Re: PG_swap_entry bug in recent kernels
2000-04-04 16:50 64% ` Andrea Arcangeli
@ 2000-04-04 17:06 63% ` Ben LaHaise
2000-04-04 18:03 47% ` Andrea Arcangeli
0 siblings, 1 reply; 200+ results
From: Ben LaHaise @ 2000-04-04 17:06 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: riel, Linus Torvalds, linux-mm
On Tue, 4 Apr 2000, Andrea Arcangeli wrote:
> On Tue, 4 Apr 2000, Rik van Riel wrote:
> >When we remove a page from the swap cache, it seems fair to me
> >that we _really_ remove it from the swap cache.
>
> Are you sure you didn't mistaken PG_swap_entry for PG_swap_cache?
Yes I'm sure. What's happening is that the presence of PG_swap_entry on
the page means that page->index is being returned as the swap entry. This
is completely bogus after the page has been freed and reallocated. Just
try running a swap test under any recent devel kernel -- eventually you
will see an invalid swap entry show up in someone's pte causing a random
SIGSEGV (it's as if the entry was marked PROT_NONE -- present, but no
user access).
> We're here talking about PG_swap_entry. The only object of that bit is to
> remains set on anonymous pages that aren't in the swap cache, so next time
> we'll re-add them to the swap cache we'll try to swap out them in the same
> swap entry as the page were before.
Which is bogus. If it's an anonymous page that we want to swap out to the
same swap entry, leave it in the swap cache.
> >If __delete_from_swap_cache() is called from a wrong code path,
> >that's something that should be fixed, of course (but that's
> >orthogonal to this).
>
> __delete_from_swap_cache is called by delete_from_swap_cache_nolock that
> is called by do_swap_page that does the swapin.
As well as from shrink_mmap.
> >To quote from memory.c::do_swap_page() :
> >
> > if (write_access && !is_page_shared(page)) {
> > delete_from_swap_cache_nolock(page);
> > UnlockPage(page);
> >
> >If you think this is a bug, please fix it here...
>
> The above quoted code is correct.
The code path that this patch really affects is shrink_mmap ->
__delete_from_swap_cache. Clearing the bit from shrink_mmap is an option,
but it doesn't make that much sense to me; if we're removing a page from
the swap cache, why aren't we clearing the PG_swap_entry bit? I'd rather
leave the page in the swap cache and set PG_dirty on it that have such
obscure sematics.
-ben
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 63%]
* Re: PG_swap_entry bug in recent kernels
2000-04-04 17:06 63% ` Ben LaHaise
@ 2000-04-04 18:03 47% ` Andrea Arcangeli
2000-04-06 22:11 61% ` [patch] take 2 " Ben LaHaise
0 siblings, 1 reply; 200+ results
From: Andrea Arcangeli @ 2000-04-04 18:03 UTC (permalink / raw)
To: Ben LaHaise; +Cc: riel, Linus Torvalds, linux-mm
On Tue, 4 Apr 2000, Ben LaHaise wrote:
>try running a swap test under any recent devel kernel -- eventually you
>will see an invalid swap entry show up in someone's pte causing a random
acquire_swap_entry() should be just doing all the safety checking to make
sure the page->index is caching a _valid_ swap entry. If it's garbage
get_swap_page() will be recalled and a valid entry will be allocated (and
if get_swap_page() returns an invalid-entry that's definitely not related
to the PG_swap_entry logic anymore).
Could you explain me how acquire_swap_entry() can return an invalid swap
entry (starting with a random page->index of course)? I can't exclude
there's a bug, but acquire_swap_entry was meant to return only valid
entries despite of the page->index possible garbage and it seems it's
doing that.
>SIGSEGV (it's as if the entry was marked PROT_NONE -- present, but no
>user access).
I'm not saying you are not seeing that, I'm only trying to understand how
can it be related to the PG_swap_entry logic.
>> We're here talking about PG_swap_entry. The only object of that bit is to
>> remains set on anonymous pages that aren't in the swap cache, so next time
>> we'll re-add them to the swap cache we'll try to swap out them in the same
>> swap entry as the page were before.
>
>Which is bogus. If it's an anonymous page that we want to swap out to the
>same swap entry, leave it in the swap cache.
There's a very basic reason that we can't left it in the swap cache. We
can't left it in the swap cache simply because the swap cache is a read
only entity and if you do a write access you can't left the page in the
swap cache and change it without updating its on-disk counterpart.
So we always remove the anonymous pages from the swap cache upon
swapin-_write_-faults. That's also how 2.2.x works.
Then I noticed it was possible to give persistence on the swap also to the
dirtified pages without making the swap-cache dirty, by adding the
PG_swap_entry bit that tell us if the page->index is currently caching the
last swap entry where the page was allocated on the swap. That does all
the job and we don't need dirty swap cache anymore.
>> >If __delete_from_swap_cache() is called from a wrong code path,
>> >that's something that should be fixed, of course (but that's
>> >orthogonal to this).
>>
>> __delete_from_swap_cache is called by delete_from_swap_cache_nolock that
>> is called by do_swap_page that does the swapin.
>
>As well as from shrink_mmap.
I would not be complaining your patch if you would put the clear_bit
within shrink_mmap :).
BTW, also the SHM unmap points have to be checked to make sure the
PG_swap_entry gets cleared. Also SHM uses swap cache and shares the
do_swap_page code.
>> >To quote from memory.c::do_swap_page() :
>> >
>> > if (write_access && !is_page_shared(page)) {
>> > delete_from_swap_cache_nolock(page);
>> > UnlockPage(page);
>> >
>> >If you think this is a bug, please fix it here...
>>
>> The above quoted code is correct.
>
>The code path that this patch really affects is shrink_mmap ->
>__delete_from_swap_cache. Clearing the bit from shrink_mmap is an option,
>but it doesn't make that much sense to me; if we're removing a page from
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>the swap cache, why aren't we clearing the PG_swap_entry bit? I'd rather
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
As just said the whole point of the PG_swap_entry is to be set for
regular anonymous swappable pages, _not_ for the swap cache at all.
So it really make no sense to clear the PG_swap_entry bit while removing a
page from the swap cache and I don't see your arguemnt.
We have instead to cover the points where a swappable page become not a
swappable page anymore. There's also to cover the shrink_mmap case where
we free the page. I'm thinking about it to see if we can skip to cover the
shrink_mmap case changing the point where we set the PG_swap_entry bit. I
think it would be possible if we would avoid the double page fault in the
write_swapin_access+page-is-shared case. But right now I think it's
cleaner to keep the double page fault and to clear the PG_swap_entry
within shrink_mmap while dropping page cache.
>leave the page in the swap cache and set PG_dirty on it that have such
>obscure sematics.
If the page is shared you can't simply set the PG_dirty bit and change the
contents of the page or you'll screwup all other in-core and on-disk users
of the page. You have at least to do a COW and re-add the COWed page to a
new swap cache entry so by definition failing to give persistence to the
page in the swap space.
In general (also for non-shared pages) setting the PG_dirty is inferior
because it would waste swap space by keeping busy on the swap side a swap
entry that it not uptodate and that's really not cache (there's no way
somebody else can fault in the same swap cache page since the user who did
the write-access is now the only user of the page and it has it just
mapped in its pte so it can't fault on it). The reason we keep the page
mapped in the read-only access is to skip a write to disk if we run low on
memory but we can't skip the write to disk in the write-access case...
In the case of multiple users on the swap side (for example when a process
does a fork with some page in the swap) the PG_swap_entry can allow the
two tasks to share the same swap entry if they gets swapped out and
swapped in at different times. A PG_dirty swap cache wouldn't allow that
because of the is-page-shared issue mentioned two paragraphs above.
Andrea
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 47%]
* [patch] take 2 Re: PG_swap_entry bug in recent kernels
2000-04-04 18:03 47% ` Andrea Arcangeli
@ 2000-04-06 22:11 61% ` Ben LaHaise
0 siblings, 0 replies; 200+ results
From: Ben LaHaise @ 2000-04-06 22:11 UTC (permalink / raw)
To: Andrea Arcangeli; +Cc: riel, Linus Torvalds, linux-mm
On Tue, 4 Apr 2000, Andrea Arcangeli wrote:
> Could you explain me how acquire_swap_entry() can return an invalid swap
> entry (starting with a random page->index of course)? I can't exclude
> there's a bug, but acquire_swap_entry was meant to return only valid
> entries despite of the page->index possible garbage and it seems it's
> doing that.
First off, it doesn't verify that all of the bits which should be clear in
a swap entry actually are -- eg bit 0 (present) can and is getting
set. It would have to rebuild and compare the swap entry produced by
SWP_ENTRY(type,offset) to be 100% sure that it is a valid swap entry.
And yes, I see what you're doing with the PG_swap_entry code now, although
I'm thinking it might be better done by taking a look at what swap entries
are present in the page tables near the page (since otherwise a pair of
fork()ed process could end up splitting contiguous swap entries if the
swapout is timed just right). But that's for later...
> >As well as from shrink_mmap.
>
> I would not be complaining your patch if you would put the clear_bit
> within shrink_mmap :).
Heheh, okay I've moved it there. Just in case I've also added a
BUG() check in free_pages_okay to make sure there aren't any other places
that have been missed.
-ben
diff -ur 2.3.99-pre4-4/mm/filemap.c linux-test/mm/filemap.c
--- 2.3.99-pre4-4/mm/filemap.c Thu Apr 6 15:03:05 2000
+++ linux-test/mm/filemap.c Thu Apr 6 17:50:39 2000
@@ -300,6 +300,7 @@
if (PageSwapCache(page)) {
spin_unlock(&pagecache_lock);
__delete_from_swap_cache(page);
+ ClearPageSwapEntry(page);
goto made_inode_progress;
}
diff -ur 2.3.99-pre4-4/mm/page_alloc.c linux-test/mm/page_alloc.c
--- 2.3.99-pre4-4/mm/page_alloc.c Thu Apr 6 15:03:05 2000
+++ linux-test/mm/page_alloc.c Thu Apr 6 17:38:10 2000
@@ -110,6 +110,8 @@
BUG();
if (PageDecrAfter(page))
BUG();
+ if (PageSwapEntry(page))
+ BUG();
zone = page->zone;
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux.eu.org/Linux-MM/
^ permalink raw reply [relevance 61%]
* [linux-lvm] bug in vgdisplay?
@ 2000-04-06 22:51 64% bert hubert
0 siblings, 0 replies; 200+ results
From: bert hubert @ 2000-04-06 22:51 UTC (permalink / raw)
To: linux-lvm
Hi,
Is this correct:
debian:/home/ahu/programming/lvm-viewer# vgdisplay -D group1
--- Volume group ---
VG Name group1
VG Access read/write
>VG Status NOT available/resizable
VG # 0
MAX LV 256
Cur LV 1
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 2
Act PV 2
VG Size 184 MB
PE Size 4 MB
Total PE 46
Alloc PE / Size 5 / 20 MB
Free PE / Size 41 / 164 MB
debian:/home/ahu/programming/lvm-viewer# vgdisplay group1
--- Volume group ---
VG Name group1
VG Access read/write
>VG Status available/resizable
VG # 0
MAX LV 256
Cur LV 1
Open LV 0
MAX LV Size 255.99 GB
Max PV 256
Cur PV 2
Act PV 2
VG Size 184 MB
PE Size 4 MB
Total PE 46
Alloc PE / Size 5 / 20 MB
Free PE / Size 41 / 164 MB
--
| http://www.rent-a-nerd.nl
| - U N I X -
| Inspice et cautus eris - D11T'95
^ permalink raw reply [relevance 64%]
Results 201-400 of ~385580 next (newer) | prev (older) | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
1999-06-02 20:05 patch for dmasound bug Ryan Nielsen
1999-06-10 22:56 ` Alvin Brattli
1999-06-11 20:07 64% ` Ryan Nielsen
1999-06-11 22:54 64% ` Alvin Brattli
1999-06-16 16:29 60% ld bug with -Bsymbolic --noinhibit-exec (2.9.1.0.990418-1c) Eric Ding
1999-06-16 17:21 64% ` Franz Sirl
1999-06-16 18:09 64% ` Eric Ding
1999-06-16 18:31 64% ` Franz Sirl
1999-06-16 19:38 64% ` Eric Ding
1999-06-16 20:40 64% ` Franz Sirl
1999-06-16 21:14 64% ` Eric Ding
1999-06-17 21:24 64% ` Franz Sirl
1999-06-17 22:49 64% ` Eric Ding
1999-06-18 19:54 64% ` Eric Ding
1999-06-21 9:31 64% ` Franz Sirl
1999-06-21 13:05 64% ` Franz Sirl
1999-06-21 19:44 64% ` Eric Ding
1999-06-19 4:27 58% weird glibc bug?? (#0 0x153b94c in strlen () at soinit.c:59) Troy Benjegerdes
1999-06-19 6:15 64% ` Martin Costabel
1999-06-19 6:40 64% ` Troy Benjegerdes
1999-06-21 22:52 64% dl-load.c (ld.so) bug?? Troy Benjegerdes
1999-06-22 0:04 64% ` Hollis R Blanchard
1999-06-22 1:57 64% ` Troy Benjegerdes
1999-06-22 2:48 64% ` Hollis R Blanchard
1999-06-22 3:09 64% ` Daniel Jacobowitz
1999-06-22 4:36 63% ` Peter Chang
1999-06-22 13:52 64% ` Hollis R Blanchard
[not found] <Pine.LNX.3.96L.990622003119.5237E-100000@unix47.andrew.cmu.edu>
1999-06-22 4:39 64% ` Peter Chang
1999-06-22 16:21 62% bug in head.S Nathan Sheeley
1999-06-23 0:45 64% ` Paul Mackerras
1999-06-23 14:08 64% ` Nathan Sheeley
1999-06-23 12:20 64% The file system corruption bug (Summary) Alan Cox
[not found] <199906231258.HAA25989@www.cedarnet.org>
1999-06-23 13:17 64% ` dl-load.c (ld.so) bug?? Geert Uytterhoeven
1999-06-23 14:19 64% ` Hollis R Blanchard
1999-06-23 14:32 64% ` Kevin Puetz
1999-06-23 14:21 62% File Corruption Bug.. continued Alan Cox
[not found] <Pine.LNX.4.04.9906211749280.27642-100000@narn.local.drgw.n et>
1999-06-23 14:37 64% ` dl-load.c (ld.so) bug?? Franz Sirl
1999-06-25 10:30 47% Possible ne2k-pci bug on ppc Andrew Chadwick
1999-06-25 12:10 64% ` Christian Bauer
1999-07-22 12:28 52% Bug Report : Kernel Panic w/ PPP & Netscape Lucas Vergnettes
1999-07-22 14:35 51% ` Jerry Quinn
1999-07-26 21:53 64% Linker bug Ralf Baechle
1999-07-27 19:02 64% Netatalk bug?, too many routes/iface jhart
1999-07-27 19:32 64% ` a sun
1999-07-28 12:30 64% active_mm & SMP & TLB flush: possible bug Manfred Spraul
1999-07-28 15:46 64% ` Benjamin C.R. LaHaise
1999-07-28 18:07 64% ` Kanoj Sarcar
1999-07-28 16:58 64% Manfred Spraul
1999-07-28 18:35 64% Manfred Spraul, Benjamin C.R. LaHaise
1999-07-30 13:03 60% Bug or hidden feature ? Alain Birtz
1999-07-31 20:58 60% [linux-lvm] bug in liblvm 0.7 [added on 11/15/1998] Ryan Murray
1999-08-02 9:57 64% ` Heinz Mauelshagen
1999-08-11 5:59 64% ` Ryan Murray
1999-08-01 13:58 current recommended versions of glibc/egcs/binutils for R5? Franz Sirl
1999-08-22 15:09 62% ` bug in glibc 2.1.2 new semaphore functions in libpthread? Kevin Hendricks
1999-08-24 21:09 64% ` Franz Sirl
1999-08-02 17:59 64% MIPS gas bug & fix Ralf Baechle
1999-08-06 10:17 64% 2.2.x kernels: Sound Bug report Albrecht Dre_
1999-08-08 10:13 64% [linux-lvm] bug/questions Ryan Murray
1999-08-20 19:44 35% Bug in modules es1370.o or soundcore.o Maarten Wisse
1999-08-26 21:05 64% bug in l2cr status display? Michel Lanners
1999-08-27 8:24 64% ` Adrian Cox
1999-08-27 18:07 54% ` Michel Lanners
1999-08-27 6:04 56% bug in ioremap/map_page ? Ryan Nielsen
1999-08-27 13:09 64% bug in l2cr status display? Marc Dietrich
1999-08-27 20:28 64% ` Benjamin Herrenschmidt
1999-09-04 0:13 64% Possible Bug in XFree3.3.5 jeramy b smith
1999-09-04 6:33 64% ` Tom Rini
1999-09-04 6:56 64% [Re: Possible Bug in XFree3.3.5] jeramy b smith
1999-09-04 7:13 64% ` Tom Rini
1999-09-09 14:42 50% bug glibc strlen() or tcl8.2 Maurice DIAMANTINI
1999-09-09 17:35 64% ` Franz Sirl
1999-09-10 14:31 59% ` Maurice DIAMANTINI
1999-09-10 18:19 64% ` Franz Sirl
1999-09-10 15:55 61% controlfb.c bug in VRAM bank2 check if bank1 Lou Langholtz
1999-09-10 17:08 64% ` Lou Langholtz
1999-09-10 18:33 64% ` Michel Lanners
1999-09-12 16:58 64% ` Lou Langholtz
1999-09-13 18:13 64% ` Michel Lanners
1999-09-15 15:14 64% ` Lou Langholtz
1999-10-12 7:07 62% ` Lou Langholtz
1999-10-12 6:49 64% ` Lou Langholtz
1999-10-12 14:50 64% ` Daniel Jacobowitz
1999-10-12 15:36 64% ` Lou Langholtz
1999-10-13 6:30 64% ` Geert Uytterhoeven
1999-09-11 10:51 64% ` Brad Boyer
1999-09-10 20:13 64% ` Daniel Jacobowitz
1999-09-11 9:23 64% ` Benjamin Herrenschmidt
1999-09-12 18:10 57% ` Daniel Jacobowitz
1999-09-10 16:51 73% [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] Lou Langholtz
1999-09-12 16:28 64% Possible bug in quik Benjamin Herrenschmidt
1999-09-12 18:49 64% Need help from someone with SMP machine to track down bug in native threads jdk Kevin Hendricks
1999-09-14 18:24 64% bug in 2.2.13pre7 on Ultras pau
1999-09-14 19:51 64% ` David S. Miller
1999-09-15 7:23 64% bug in 2.2.13pre7 on Ultras (more oops) pau
1999-09-15 7:34 64% ` David S. Miller
1999-09-15 7:42 64% ` pau
1999-09-15 8:10 64% ` David S. Miller
1999-09-15 10:10 64% ` pau
1999-09-15 17:05 64% controlfb.c bug in VRAM bank2 check if bank1 Kevin_Hendricks
1999-09-15 18:26 64% ` Kevin Puetz
1999-09-16 14:37 64% bug in 2.2.13pre8 on Ultras (more oops) pau
1999-09-17 1:36 64% ` David S. Miller
1999-09-17 15:48 64% Bug in Indy serial driver? Kevin D. Kissell
1999-09-23 21:09 61% syslinux-1.43 bug [and possible PATCH] Kanoj Sarcar
1999-09-23 21:30 64% ` Matt Wilson
1999-09-23 21:55 64% ` H. Peter Anvin
1999-09-24 8:48 64% ` Neil Conway
1999-09-24 8:55 64% ` H. Peter Anvin
1999-09-24 9:43 64% ` Neil Conway
1999-09-24 16:30 64% ` Stephen C. Tweedie
1999-09-24 9:04 64% Javan Dempsey
1999-09-24 10:05 63% Javan Dempsey
1999-09-24 22:49 64% [linux-lvm] LVM 0.7: optimization bug Andreas Kostyrka
[not found] <37F1AD4B.585E99AB@chpc.utah.edu>
1999-09-29 7:11 64% ` [Fwd: Bug: 2.2.12 still hangs PPC after some PPP activity] Geert Uytterhoeven
1999-09-29 7:16 64% ` Takashi Oe
1999-09-29 7:40 64% ` Geert Uytterhoeven
1999-09-29 9:13 60% ` Benjamin Herrenschmidt
1999-09-30 0:46 64% ` Takashi Oe
1999-09-30 8:50 64% ` Benjamin Herrenschmidt
1999-09-30 16:21 64% ` Takashi Oe
1999-09-30 16:35 64% ` Benjamin Herrenschmidt
1999-10-12 7:20 64% ` Lou Langholtz
1999-09-29 16:44 64% ` Lou Langholtz
1999-09-29 17:02 64% ` Benjamin Herrenschmidt
1999-09-29 18:08 63% ` Lou Langholtz
1999-09-29 18:46 64% ` Lou Langholtz
1999-09-29 20:00 64% ` Lou Langholtz
1999-09-30 1:14 64% ` Takashi Oe
1999-09-30 5:33 63% ` Geert Uytterhoeven
1999-10-01 13:26 64% ` Franz Sirl
1999-10-01 13:46 64% ` Alvin Brattli
[not found] ` <Pine.OSF.3.96.991001153658.16772E-100000@mitra.phys.uit.no >
1999-10-01 14:08 64% ` Franz Sirl
1999-10-01 16:14 64% ` Lou Langholtz
[not found] <37F1C0A3.B9F25580@chpc.utah.edu>
1999-09-29 7:39 64% ` Geert Uytterhoeven
[not found] <Pine.SGI.4.10.9910281200550.695157-100000@sapphire.lcse.umn.edu>
1999-10-28 17:31 64% ` Bug Discovered in Binutils/GCC for PPC403 Grant Erickson
1999-11-01 8:02 64% bug in getenv/putenv on linuxppc/G4 Jon A. Christopher
1999-11-01 12:55 64% ` Marcus Sundberg
1999-11-15 14:06 64% Bug in ptrace on smp systems D.J. Barrow
1999-11-16 19:08 63% [parisc-linux] Trivial Makefile Bug John David Anglin
1999-11-30 22:47 47% Silly bug in sb_ess.c Rolf Fokkens
1999-12-02 16:51 47% PATCH: Silly bug in sb_ess.c in 2.3.29 Rolf Fokkens
1999-12-05 23:47 64% [linux-lvm] [PATCH] Bug in pv_read_all_pv.c Michael Lundkvist
1999-12-10 22:08 64% Loading Linux on an MBX board without EPPC-bug jmauro
[not found] <19991215202647.A503@HSE-MTL-ppp4549.qc.sympatico.ca>
1999-12-16 6:53 64% ` Bug in X 3.3.5 Michel Lanners
1999-12-20 19:29 64% PowerPC kernel bug. (fwd) James Simmons
1999-12-22 5:58 56% [patch] mmap<->write deadlock fix, plus bug in block_write_zero_range Benjamin C.R. LaHaise
1999-12-22 15:08 64% ` Chuck Lever
1999-12-22 15:43 64% ` Benjamin C.R. LaHaise
1999-12-22 15:58 62% ` Chuck Lever
1999-12-23 4:00 64% ` Chuck Lever
1999-12-29 18:55 64% [linux-lvm] Bug in 0.8i - lvm_tab_vg_check_exist_all_vg.c Terry Hardie
2000-01-17 4:34 64% [parisc-linux] wq bug forcing oops Matthew Wilcox
2000-01-21 7:03 63% gcc 2.95/PPC bug Albrecht Dre_
2000-01-21 15:37 64% ` Franz Sirl
2000-01-24 9:53 64% ` Albrecht Dre_
2000-01-25 3:27 63% 2.2.1{3,4,5pre*} VM bug found Rik van Riel
2000-01-25 18:15 64% ` Andrea Arcangeli
2000-01-26 0:48 64% ` Rik van Riel
2000-01-27 19:09 64% ` Stephen C. Tweedie
2000-01-27 19:07 64% ` Stephen C. Tweedie
[not found] <Pine.LNX.3.95.1000128103100.276B-100000@www.mprojects>
[not found] ` <00012814071700.05087@localhost.localdomain>
[not found] ` <vtou2jy3t2q.fsf@astra.cs.uni-dortmund.de>
2000-01-28 22:45 53% ` Bug in glibc 2.1.3 linuxthreads in pthread_cond_timedwait_relative Kevin Hendricks
2000-01-29 3:10 64% ` scott hutinger
2000-01-30 0:26 58% bug-glibc,linuxppc-dev: semctl on linux/ppc james woodyatt
2000-02-06 9:17 24 bitplanes in X? (openh323 videoconf) Brad Midgley
2000-02-06 10:47 64% ` [xfree accel bug] " Brad Midgley
2000-02-06 11:31 64% bug in kernel header Moritz Thomas
2000-02-13 4:21 52% Kernel Gurus Help! Possible kernel bug in conversion of jiffees in nanosleep Kevin Hendricks
[not found] ` <200002130440.XAA25134@mal-ach.watson.ibm.com>
2000-02-13 16:51 64% ` Kevin B. Hendricks
2000-02-14 16:26 57% Bug in acceled Xpmac? Nathan Ingersoll
2000-02-14 17:45 64% Kevin_Hendricks
[not found] <200002141749.LAA13446@mail.d.umn.edu>
2000-02-14 21:33 64% ` Nathan Ingersoll
2000-02-21 0:37 64% New GCC package to fix "internal compiler error in add_pending_init" bug with linux-2.3.47 Franz Sirl
2000-02-23 16:25 59% [parisc-linux] Tulip Driver Bug John Marvin
2000-02-23 18:22 64% ` Grant Grundler
2000-02-25 8:59 64% [linux-lvm] Bug in modules (fwd) Michael Marxmeier
[not found] <m12Rayn-0006h9C@grumbeer.inka.de>
2000-03-05 17:07 64% ` [linux-lvm] Re: LVM bug report and questions Heinz Mauelshagen
2000-03-07 8:19 64% Kernel Bug Report-Jeram jeramy b smith
[not found] <Pine.LNX.4.10.10001211706220.29354-100000@mail.linuxppc.org>
2000-03-23 12:11 64% ` LinuxPPC-2000: Bug in the RH installer Ingvar Hagelund; UiO
[not found] <Pine.LNX.4.10.10003230911180.6826-100000@shell.unixbox.com>
2000-03-23 18:16 ` Some issues to resolve with XFree 4.0 yet Kevin Hendricks
2000-03-25 3:54 56% ` Found bug in mode switching but who is at fault...XFree86 or aty128fb.c? Kevin Hendricks
2000-03-25 7:57 64% ` Michel Dänzer
2000-03-25 8:07 64% ` Michel Dänzer
2000-03-25 13:46 64% ` Geert Uytterhoeven
2000-03-25 14:38 64% [linux-lvm] SMP bug: vmalloc() called without lock_kernel() Manfred Spraul
2000-03-28 10:29 64% Voodoo 3 bug on 2.3.99pre3 Michel D?nzer
2000-03-28 15:22 47% ` Kostas Gewrgiou
2000-03-29 9:48 64% sabotage
2000-03-28 19:01 64% ` phandel
2000-03-31 14:27 64% gcc bug Josh Huber
2000-03-31 15:18 62% ` Gabriel Paubert
2000-03-31 19:00 64% [linux-lvm] BUG: use of lvchange leads to disk corruption jorg de jong
2000-03-31 20:05 64% [linux-lvm] SuSE 6.4: Bug in lvmcreate_initrd Torsten Neumann
2000-04-01 21:10 64% [BUG] macmodes.c in 2.3.99-pre3-pre8 Martin Costabel
2000-04-02 19:15 64% ` Ani Joshi
2000-04-03 22:22 64% PG_swap_entry bug in recent kernels Ben LaHaise
2000-04-04 15:06 61% ` Andrea Arcangeli
2000-04-04 15:46 64% ` Rik van Riel
2000-04-04 16:50 64% ` Andrea Arcangeli
2000-04-04 17:06 63% ` Ben LaHaise
2000-04-04 18:03 47% ` Andrea Arcangeli
2000-04-06 22:11 61% ` [patch] take 2 " Ben LaHaise
2000-04-06 22:51 64% [linux-lvm] bug in vgdisplay? bert hubert
2018-09-28 16:27 yet another bug in atyfb.c Wulf Hofbauer
1999-08-03 15:26 62% ` David Edelsohn
1999-08-03 16:57 64% ` Daniel Jacobowitz
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.