On 21 Aug, Don Lewis wrote:
On 21 Aug, Martin Blapp wrote:
Hi,
Try to compile the entire system on another box, install it then
on the CURRENT target box, and try again !
Bye the way, after 6 rounds, I see now SIG4 and SIG11 too :-/
To bad - so it's definitly data corruption in
Hi all,
I used to have a functionaly working X. After I made world
I see now this:
write(0,0x81e6040,11)= 11 (0xb)
write(0,0x81e6040,19)= 19 (0x13)
break(0x8983000) = 0 (0x0)
Anselm Garbe wrote:
On Wed, Aug 21, 2002 at 05:34:36PM -0700, Terry Lambert wrote:
On a hunch, I will guess that the special case code for ISA
sharing for the keyboard and mouse on the same PS/2 controller
is not present in the ACPI.
Try not loading ACPI, and see if it fixes it for you
It seems Martin Blapp wrote:
I used to have a functionaly working X. After I made world
I see now this:
...
I've removed everything and build a new X. Same symptoms.
Mmap problem ?
I saw the same problem here, but after upgrading to sources around
1200GMT aug 21 the problem seems to be
Hi,
I recently started building -current daily on my 4.6-STABLE build machine.
After buildworld and -kernel I install via nfs on my testboxes. So far I
haven't been able to provide any relevant feedback, but it's fun and I'm
learning :-)
Now, I would like to 'make release' for CURRENT, as I'm
On Thu, Aug 22, 2002 at 09:43:45AM +0200, Martin Blapp wrote:
I suspect all the SIG4 and SIG11 problems we see are due
memory corruption in CURRENT.
In the latter case, the affected file looks like:
case HASH('^', 'e'):
case HASH('^', 'i'):
case HASH('^' 'o'):
\xc0 case
It seems Martin Blapp wrote:
Hi all,
I suspect all the SIG4 and SIG11 problems we see are due
memory corruption in CURRENT.
The file is correct after a reboot, so the corruption was limited to the
copy cached in RAM.
Thats memory corruption. I'm also not able anymore
to make
Hi,
I don't know why, but adding this to XF86Config:
Option NoInt10
Solved the problem.
Thank you anyways ;-)
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Hi Soeren,
However, this kind of problem in most cases spells bad HW to me,
ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc...
That's what I thought too. I have now three different systems which show
all this:
1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram,
2)
It seems Martin Blapp wrote:
Hi Soeren,
However, this kind of problem in most cases spells bad HW to me,
ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc...
That's what I thought too. I have now three different systems which show
all this:
1) PIV 1,6Ghz,
On Thu, Aug 22, 2002 at 11:23:46 +0200, Martin Blapp wrote:
That's what I thought too. I have now three different systems which show
all this:
1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram,
2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram
3) PIV 2,26 Ghz Asus P4B533 Board with
On 22 Aug, Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 09:43:45AM +0200, Martin Blapp wrote:
Thats memory corruption. I'm also not able anymore
to make 10 buildworlds (without -j, that triggers
panics in pmap code).
Bye the way, I'm experiencing this since about 4-5 months.
All
Soeren Schmidt wrote:
It seems Martin Blapp wrote:
I suspect all the SIG4 and SIG11 problems we see are due
memory corruption in CURRENT.
The file is correct after a reboot, so the corruption was limited to the
copy cached in RAM.
Thats memory corruption. I'm also not able
On Thu, Aug 22, 2002 at 11:30:50AM +0200, Udo Schweigert wrote:
Only a little addition from me: I had the same problems on -stable and they
only disappeared after compiling the kernel without debugging. I had the
impression that it has to do with the size of the kernel (but this of course
Martin Blapp wrote:
I have now three different systems which show all this:
1) PIV 1,6Ghz, Intel B845DG Board, 1GB Kingston Ram,
2) PIV 2Ghz Intel B845DG Board, 1GB Kingston ECC Ram
3) PIV 2,26 Ghz Asus P4B533 Board with I845 chipset, 1GB noname Ram
All running CURRENT. I also replaced
Hi Martin,
As you know this problem for longer, did you already try to make the
problem a bit more reproducable / narrowed down?
If not, we really should try to, that will be the first step in fixing it.
Mark
--
Mark Santcroos RIPE Network Coordination Centre
On Thu, Aug 22, 2002 at 02:38:25AM -0700, Terry Lambert wrote:
Alternatively, rather than those options, try losing 512M of
the RAM... I note they are all 1G boxes.
No, mine is 256MB.
Mark
--
Mark Santcroos RIPE Network Coordination Centre
On 22 Aug, Soeren Schmidt wrote:
However, this kind of problem in most cases spells bad HW to me,
ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc...
My motherboard chipset supports ECC RAM and I have ECC RAM installed. I
upgraded to an expensive Antec power supply
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 02:38:25AM -0700, Terry Lambert wrote:
Alternatively, rather than those options, try losing 512M of
the RAM... I note they are all 1G boxes.
No, mine is 256MB.
Correction: all of his were 1G, and should be halved. *You*, on
the other hand,
On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote:
options DISABLE_PSE
options DISABLE_PG_G
Coming up next in this theater :-)
btw, how does the report that using the other compiler fixed everything
for KT fit in?
--
Mark Santcroos RIPE
Hi
This is what I did the to system's cc/gcc. I built gcc3.1.1 released version
from the ports (with much pain of coz).
passion:/usr/bin[514]# ls -l cc* gcc*
lrwxr-xr-x 1 root wheel 20 Aug 12 21:54 cc - /usr/local/bin/gcc31
-r-xr-xr-x 2 root wheel 135616 Aug 12 21:52 cc.sav
lrwxr-xr-x
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote:
options DISABLE_PSE
options DISABLE_PG_G
Coming up next in this theater :-)
btw, how does the report that using the other compiler fixed everything
for KT fit in?
Coincidentally. It's
On 22 Aug, Terry Lambert wrote:
Alternatively, rather than those options, try losing 512M of
the RAM... I note they are all 1G boxes.
When I first put this system together several months ago, I only
installed the first 512M of RAM and the problem was much worse. I only
had about a 50% chance
On Thu, Aug 22, 2002 at 03:17:03AM -0700, Terry Lambert wrote:
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote:
options DISABLE_PSE
options DISABLE_PG_G
Coming up next in this theater :-)
btw, how does the report that using the
Hi,
options DISABLE_PSE
options DISABLE_PG_G
Just added them. I'll now build 20 buildworlds with those enabled.
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Don Lewis wrote:
At the moment I'm running a set of buildworlds with an August 6th
kernel, just to verify the problem that I'm seeing isn't something new.
When I'm done with that, I'll reduce the RAM from 1G to 512M and try
again. I'll also try the DISABLE_PSE and DISABLE_PG_G options.
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 03:17:03AM -0700, Terry Lambert wrote:
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote:
options DISABLE_PSE
options DISABLE_PG_G
Coming up next in this theater :-)
btw, how does
Martin Blapp wrote:
options DISABLE_PSE
options DISABLE_PG_G
Just added them. I'll now build 20 buildworlds with those enabled.
Let the list know if it does anything. If Soren could also test,
that would give a sample size.
If it's a 3-for-3 workaround, then I probably need
On Thu, Aug 22, 2002 at 04:23:46AM -0700, Terry Lambert wrote:
Ugh! Wait until it seems to work for a statistically significant
sample size, and for more than one person before calling it happy!
Also, I'm not sure looking at the code whether or not the PG_G is
truly significant, or just
On Thu, Aug 22, 2002 at 04:31:02AM -0700, Terry Lambert wrote:
If it's a 3-for-3 workaround, then I probably need to take the
discussion offline with Peter Wemm, and come up with a permanent
fix.
There was something with non-disclosure, am I right?
--
Mark Santcroos
It seems Terry Lambert wrote:
Martin Blapp wrote:
options DISABLE_PSE
options DISABLE_PG_G
Just added them. I'll now build 20 buildworlds with those enabled.
Let the list know if it does anything. If Soren could also test,
that would give a sample size.
Sure, but I
Hi,
Can you revert back to the system compiler and also compile your kernel
with this options and do some buildworlds again?
Thanks
Mark
On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote:
It seems Terry Lambert wrote:
Martin Blapp wrote:
options DISABLE_PSE
It seems Mark Santcroos wrote:
Hi,
Can you revert back to the system compiler and also compile your kernel
with this options and do some buildworlds again?
I already use the system compiler...
On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote:
Sure, but I dont have the
Hi,
as far as I can tell it is really reather easy to hide the bug.
All these options did hide the bug for some time:
- Use -g to compile the segfaulting binarys
- Remove -g to compile the segfaulting binarys
- Use a kernel compiler on another machine
- New hardware
They just disappeared
On Thu, Aug 22, 2002 at 01:55:42PM +0200, Soeren Schmidt wrote:
Can you revert back to the system compiler and also compile your kernel
with this options and do some buildworlds again?
I already use the system compiler...
That's why the message was addressed to kt ;-)
--
Mark Santcroos
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 04:31:02AM -0700, Terry Lambert wrote:
If it's a 3-for-3 workaround, then I probably need to take the
discussion offline with Peter Wemm, and come up with a permanent
fix.
There was something with non-disclosure, am I right?
No. If it's
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote:
Sure, but I dont have the problem :) I can buildworld for days on my
(heavily overclocked btw) Athlon with no problems at all...
Can you revert back to the system compiler and also compile your kernel
On Thu, Aug 22, 2002 at 05:21:54AM -0700, Terry Lambert wrote:
Mark Santcroos wrote:
On Thu, Aug 22, 2002 at 01:41:13PM +0200, Soeren Schmidt wrote:
Sure, but I dont have the problem :) I can buildworld for days on my
(heavily overclocked btw) Athlon with no problems at all...
Can
I did not create diskcheckd, I just ported it from src/ let me cc
some people that may know something more about it.
Since then it was running fine for a few months. Then I did an Upgrade
of Diskcheckd and FreeBSD on one of the machines. After that, Diskcheckd
refused to check one of the 8
Mark Santcroos wrote:
I was just giving a slight report, not yelling halleluja yet ;-)
It's doing the 2nd buildworld now.
Do you also want me to try to split up the disabling of the two options?
No.
Me saying to use both options was just me being lazy about
spending 2 days re-documenting
In my machine, FreeBSD 5.0-current, NetBSD 1.6-BETA and OpenBSD 3.1
are installed, and they share some partitions, e. g. /home, and
had no problem.
Now, however, after FreeBSD mount those partitions once,
when NetBSD and OpenBSD mount those partitions at boot time,
fsck stops with error
We have seen weird problems regarding the pmap PG_G related stuff (well
sort of, it has to do with PSE and PG_G) on ppro and pII chips
(apparently, this is not the case with at least Xeons) but what
happened, for the record, was this:
We would enable PSE and switch the pde corresponding to the
Hi Terry,
options DISABLE_PSE
options DISABLE_PG_G
I'm now at buildworld IV, since I have these options compiled it
the bug did not show up again.
Another sideeffect: Before that I could not even make -j 10 buildworld,
that ended with a page fault somewhere im pmap... This
Hi everyone,
I find many system call under the control of Giant mutex, I do not know
when we should call mtx_lock(Giant) and mtx_unlock(Giant). I only know it
is a global mutex.
normally, the two functions will occure together. But, in the
/sys/dev/aac/aac.c aac_host_command(struct
I'm going to import Intel acpica-unix-20020815 sometime early next
week. Please test new version of acpica and give feedback before my
importing.
Major fix in this version is Ref/Deref operators bug fix.
Personally I'm very happy with the new version because
now my laptop (FIVA 206VL) reports
On 21-Aug-2002 Doug White wrote:
On Wed, 21 Aug 2002, Andy Sparrow wrote:
At least one person with a 6100 persevered further with this, maybe
someone else can help you with the current status or better advice?
There is an issue with the HP laptop DSDT and our ACPI code. They
initialize
46 matches
Mail list logo