Re: Solved: CURRENT and P-IV problems
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 CURRENT.
Asus Board P4B533-V, P-IV 2,26Ghz, 1GB DDR 2100 Ram.
No sign of any problems here with last night's -current. Gigabyte
GA7-DX+, Athlon XP 1900+, 1GB PC2100 ECC DRAM, SCSI disk, NFS client.
I'm not running any sound hardware or the Xserver, and I'm accessing the
host via ssh instead of the console. The kernel is GENERIC + SMBus.
It's on buildworld #7 at the moment:
I guess I spoke too soon. I encountered errors on buildworld iterations
8 and 10.
cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr\ -I/usr/obj/usr/src/gnu/u
sr.bin/cc/cc_int/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc_int/../cc_tools -I/usr
/src/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc_
int/../../../../contrib/gcc/config -DHAVE_CONFIG_H -DTARGET_NAME=\i386-undermyd
esk-freebsd\ -DIN_GCC -c /usr/src/contrib/gcc/reload1.c -o reload1.o
/usr/src/contrib/gcc/reload1.c: In function `emit_reload_insns':
/usr/src/contrib/gcc/reload1.c:7339: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://www.gnu.org/software/gcc/bugs.html for instructions.
*** Error code 1
Stop in /usr/src/gnu/usr.bin/cc/cc_int.
c++ -O -pipe -DHAVE_STDLIB_H=1 -DHAVE_UNISTD_H=1 -DHAVE_DIRENT_H=1 -DHAVE_LIMI
TS_H=1 -DHAVE_STRING_H=1 -DHAVE_STRINGS_H=1 -DHAVE_MATH_H=1 -DRET_TYPE_SRAND_IS_
VOID=1 -DHAVE_SYS_NERR=1 -DHAVE_SYS_ERRLIST=1 -DHAVE_CC_LIMITS_H=1 -DRETSIGTYPE=
void -DHAVE_STRUCT_EXCEPTION=1 -DHAVE_GETPAGESIZE=1 -DHAVE_MMAP=1 -DHAVE_FMOD=1
-DHAVE_STRTOL=1 -DHAVE_GETCWD=1 -DHAVE_STRERROR=1 -DHAVE_PUTENV=1 -DHAVE_RENAME=
1 -DHAVE_MKSTEMP=1 -DHAVE_STRCASECMP=1 -DHAVE_STRNCASECMP=1 -DHAVE_STRSEP=1 -DHA
VE_STRDUP=1 -DSYS_SIGLIST_DECLARED=1 -I/usr/src/gnu/usr.bin/groff/src/utils/addf
tinfo/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/s
rc/utils/addftinfo/../../../src/include-fno-rtti -fno-exceptions -c /usr/src
/contrib/groff/src/utils/addftinfo/guess.cc
/usr/src/contrib/groff/src/utils/addftinfo/guess.cc:446:20: missing terminating
' character
/usr/src/contrib/groff/src/utils/addftinfo/guess.cc:447:1: warning: null charact
er(s) ignored
*** Error code 1
Stop in /usr/src/gnu/usr.bin/groff/src/utils/addftinfo.
In the latter case, the affected file looks like:
case HASH('^', 'e'):
case HASH('^', 'i'):
case HASH('^' 'o'):
\xc0 case HASH('^', 'u'):
%case HADH('`', \xc0A'):
^@ase HASH('`', 'E'):
case HASH('`', 'I'):
case HASH('`', 'O'):
case HASH('`', 'U'):
The file is correct after a reboot, so the corruption was limited to the
copy cached in RAM.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
XFree86 segfaulting on recent CURRENT
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) ioctl(4,MEMRANGE_GET,0xbfbffa10) ERR#45 'Operation not supported ' mmap(0x0,131072,0x3,0x1,4,0xa) = 673927168 (0x282b5000) mmap(0x0,65536,0x3,0x1,4,0xf)= 674058240 (0x282d5000) mmap(0x0,4096,0x1,0x1,4,0x0) = 673910784 (0x282b1000) munmap(0x282b1000,0x1000)= 0 (0x0) mmap(0x0,65536,0x1,0x1,4,0xc)= 674123776 (0x282e5000) munmap(0x282e5000,0x1) = 0 (0x0) mmap(0x0,65536,0x1,0x1,4,0xd)= 674123776 (0x282e5000) munmap(0x282e5000,0x1) = 0 (0x0) mmap(0x0,65536,0x1,0x1,4,0xe)= 674123776 (0x282e5000) munmap(0x282e5000,0x1) = 0 (0x0) sigaction(SIGSEGV,0xbfbff908,0xbfbff8e8) = 0 (0x0) I've removed everything and build a new X. Same symptoms. Mmap problem ? Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: BAD psmintr: [Re: psm problem]
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 (this seems to be the week for ACPI). Well Terry, without loading ACPI it works fine for me now. It seems, that there's the dog :-) You might want to check if there's a BIOS update available that changes the ACPI information for your system to make it more correct. If you know the last time it was working, and have a local CVS repository, it should only take log2(N)+1, at most, to do a binary date search to see what day the code broke. That's 10 recompiles and reboots to get the date, if it occurred at any time in the last 16 months. If it's when ACPI was enabled by default in the first place, it means it's your BIOS (which is why I suggested going after the BIOS first thing). You've played higher/lower enough to know the optimum strategy, right? Basically, you get a bounding date, and divide it in two, and divide the remaining time in 2, etc., until you have the day, using e.g. cvs co # fails == +0 cvs co -D512 days ago # works == -512 cvs co -D256 days ago # works == +256 cvs co -D128 days ago # fails == +128 cvs co -D192 days ago # works == -96 ... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree86 segfaulting on recent CURRENT
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 fixed... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
make release (CURRENT) on 4.6 build machine?
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 doing for RELENG_4 and RELENG_4_6, so I can automate the installation process on my testboxes So far I have not been successful. Can someone give me a clue about why I'm getting signal 12 (see below) ? I have the -current sources in /usr/build/current/usr/src, local cvs tree in /usr/build/ncvs and use the following command from the release directory: make -DNO_WERROR release CHROOTDIR=/usr/build/chroot-current \ BUILDNAME=CURRENT-`date +%Y%m%d` \ CVSROOT=/usr/build/ncvs \ NODOC=YES NOPORTS=YES The process stops after a while with the following error: -- stage 4: populating /usr/obj/usr/src/i386/usr/include -- cd /usr/src; MAKEOBJDIRPREFIX=/usr/obj MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE=i386 OBJFORMAT_PATH=/usr/obj/usr/src/i386/usr/libexec GROFF_BIN_PATH=/usr/obj/usr/src/i386/usr/bin GROFF_FONT_PATH=/usr/obj/usr/src/i386/usr/share/groff_font GROFF_TMAC_PATH=/usr/obj/usr/src/i386/usr/share/tmac DESTDIR=/usr/obj/usr/src/i386 INSTALL=sh /usr/src/tools/install.sh PATH=/usr/obj/usr/src/i386/usr/sbin:/usr/obj/usr/src/i386/usr/bin:/usr/obj/usr/src/i386/usr/games:/sbin:/bin:/usr/sbin:/usr/bin make -f Makefile.inc1 SHARED=symlinks par-includes === share/info cd /usr/src/share/info; make buildincludes; make installincludes === include cd /usr/src/include; make buildincludes; make installincludes creating osreldate.h from newvers.sh setvar PARAMFILE /usr/src/include/../sys/sys/param.h; . /usr/src/include/../sys/conf/newvers.sh;echo $COPYRIGHT osreldate.h; echo #ifdef _KERNEL osreldate.h;echo '#error /usr/include/osreldate.h cannot be used in the kernel, use sys/param.h' osreldate.h; echo #else osreldate.h;echo \#'undef __FreeBSD_version' osreldate.h;echo \#'define __FreeBSD_version' $RELDATE osreldate.h; echo #endif osreldate.h *** Signal 12 Stop in /usr/src/include. *** Error code 1 Thanks, Ruben de Groot To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 HASH('^', 'u'):
%case HADH('`', \xc0A'):
^@ase HASH('`', 'E'):
case HASH('`', 'I'):
case HASH('`', 'O'):
case HASH('`', 'U'):
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 10 buildworlds (without -j, that triggers
panics in pmap code).
Bye the way, I'm experiencing this since about 4-5 months.
All hackers, please help to track this down.
Is it P4 specific or not?
Mark
--
Mark Santcroos RIPE Network Coordination Centre
http://www.ripe.net/home/mark/ New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 10 buildworlds (without -j, that triggers panics in pmap code). Bye the way, I'm experiencing this since about 4-5 months. All hackers, please help to track this down. Hmm, I haven't seen this at all, but I've just started buildworld loops on two machines here, but I normally do at least a couble buildworlds a day and I havn't notice problems like the above (but plenty of bad commits etc). However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: XFree86 segfaulting on recent CURRENT
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
Re: Memory corruption in CURRENT
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) 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 in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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, 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 in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Hmm, thats probably a P4 problem then, I dont see it on any of my systems (P3 + K7) I dont have a P4 here (and newer will unless left at my doorstep), and I have no immediate ideas other than trying a MB that doesn't have a i845 chipset (the less Intel parts the better :) ) -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 I845 chipset, 1GB noname Ram All running CURRENT. I also replaced in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. 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 maybe wrong). After dropping -g from kernel compiling I hadn't a problem again on -stable. (At the moment I do not have -current on a P-IV, the motherboard is a Fujitsu-Siemens) Best regards -- Udo Schweigert, Siemens AG | Voice : +49 89 636 42170 CT IC CERT, Siemens CERT | Fax: +49 89 636 41166 D-81730 Muenchen / Germany | email : [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 hackers, please help to track this down. Is it P4 specific or not? Nope. I'm seeing it on an AMD Athlon XP 1900+. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 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 hackers, please help to track this down. Hmm, I haven't seen this at all, but I've just started buildworld loops on two machines here, but I normally do at least a couble buildworlds a day and I havn't notice problems like the above (but plenty of bad commits etc). However, this kind of problem in most cases spells bad HW to me, ie subspec RAM, poor powersupply, badly cooled CPU, overclocking etc etc... Try: options DISABLE_PSE options DISABLE_PG_G -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 maybe wrong). After dropping -g from kernel compiling I hadn't a problem again on -stable. (At the moment I do not have -current on a P-IV, the motherboard is a Fujitsu-Siemens) I will try that asap. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 in 1) and 2) the CPU, RAM. It happens both on SCSI and ATA disks. Powersupply has been changed for all 3 systems. Problem is still the same. The problem sometimes appears just after startup. CPU is still cold then. Other times it builds 6 buildworlds sucessfully, and then suddenly I see a SIG4. Alternatively, rather than those options, try losing 512M of the RAM... I note they are all 1G boxes. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 that has better specs than most of the other supplies I looked at. The system is plugged into a surge supressor. I don't currently have an UPS. I added an extra case fan and drive cooler fans, and the two failures happened in the evening after the room cooled off. For some reason xmbmon doesn't seem to be working at the moment, but when I looked at the temperatures previously they seemed to be acceptable. I don't believe in overclocking. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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, should try doubling the RAM size. 8-). Another potential winner is: options maxfiles=5 Note that I believe this one, the RAM size change, and the compile without debug all merely mask, rather than fixing, the problem (i.e. it's not the code that's generated, it's a side effect of a more subtle and amusing problem). I don't believe anyone actually loads kernels with debug symbols anyway if you config -g GENERIC, unless you intentionally copy up kernel.debug, you will get the stripped one). The suggested options, if they work, actually *fix* the problem, but it's a really pessimal way to go about it (they work by making the requisite preconditions impossible to trigger); only an idiot would run with those options, unless they had no other choice in the matter (e.g. they had local kernel hacks that broke all of the other workarounds, with no hope of repair). If it's what I think it is, it's more fixable than that. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 1 root wheel 20 Aug 12 21:54 gcc - /usr/local/bin/gcc31 -r-xr-xr-x 2 root wheel 135616 Aug 12 21:52 gcc.sav The hardware = Asus P4S533 + P4 1.6A (now 2.4Ghz) + Kingston DDR333 value ram. Haven't encountered any random signal or stability issue since I swapped cc/gcc with ports' version. Will try to run 10 buildworlds in a row later tonight. kt On Thu, Aug 22, 2002 at 12:00:14PM +0200, 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? -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 hard to trigger the bug, so it's easy to work around it accidently. Most people who run into these type of bugs only really care about getting things working, so if they accidently work around the thing, they stop there, without digging down to discover the root cause. It's much better to find out the root cause than to submerge the bug again; making it go away for unknown reasons means it will probably come back for unknown reasons at a later point, and bite you on the butt. No one in their right mind could believe that recompining a user space application to avoid kernel-based faults actually fixes the underlying problem. If I had to voice a theory, I would say that the change in memory access patterns resulted in the problem being submerged again. Most likely, a different set of system load characteristics could cause it to resurface, everything else being the same (in fact, that's what I would say is happening with the original compiler; workarounds are commutative). It's not really predictable at what future point that could/would happen, so you basically you end up being left with a live landmine somewhere in your back yard, and you think it's safe because poodles no longer explode 15 minutes after they are tied to the apple tree. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 of getting a successful buildworld. The problem seemed to go away shortly thereafter, and though I wasn't sure whether the problem was caused by hardware or software, I attributed the improvement to an upgrade to a newer version of -current. Since then I've replaced the motherboard (the old one didn't support ECC), the disk and controller (I needed more space, and the new disk consumes a lot less power than the two that it replaced, plus it doesn't sound like a dental drill), and the power supply (because I was concerned that the original might be marginal). I also added an extra intake fan on the front of the case. 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. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 other compiler fixed everything for KT fit in? It looks indeed like it is a 'winner'. The buildworld is still running but getting further already than the previous 10. Coincidentally. It's hard to trigger the bug, so it's easy to work around it accidently. Thats very true indeed. I can take that as a good 'explanation'. I remember you talking about this PSE problems earlier and more often. Is it fixable? I assume we would like to turn these options back on as they improve performance don't they? Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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
Re: Memory corruption in CURRENT
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. Please do these seperately. Changing the amount of RAM is only indicative, not diagnostic, so it's just additional information, if it does anything, instead of nothing. With Matt Dillon's changes to machdep.c to do auto-tuning, changing the amount of RAM is much less likely to work around the problem, unless you hit the stair function at just the right point. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 the report that using the other compiler fixed everything for KT fit in? It looks indeed like it is a 'winner'. The buildworld is still running but getting further already than the previous 10. 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 preterbs the workaround. The problem I've referred to in my hunch here is actually related solely to the PSE, but with the recent code reorganization in locore.s, etc., it could have become more significant. Coincidentally. It's hard to trigger the bug, so it's easy to work around it accidently. Thats very true indeed. I can take that as a good 'explanation'. I remember you talking about this PSE problems earlier and more often. Is it fixable? I assume we would like to turn these options back on as they improve performance don't they? Yes and yes, but it could be pretty ugly. It would be better to get more data from people who are seeing the problem. It may be that it's just similar symptoms and more than one proot cause, etc., so I'm pretty loathe to make any assumptions. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 to take the discussion offline with Peter Wemm, and come up with a permanent fix. If it's not 3-for-3, then more testing and thinking is needed. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 preterbs the workaround. The problem I've referred to in my hunch here is actually related solely to the PSE, but with the recent code reorganization in locore.s, etc., it could have become more significant. 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? Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 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 dont have the problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -S?ren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 problem :) I can buildworld for days on my (heavily overclocked btw) Athlon with no problems at all... -S?ren -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 after such an action, but showed up again later after some buildworlds. Martin Martin Blapp, [EMAIL PROTECTED] [EMAIL PROTECTED] -- ImproWare AG, UNIXSP ISP, Zurlindenstrasse 29, 4133 Pratteln, CH Phone: +41 061 826 93 00: +41 61 826 93 01 PGP: finger -l [EMAIL PROTECTED] PGP Fingerprint: B434 53FC C87C FE7B 0A18 B84C 8686 EF22 D300 551E -- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 even the same problem, I figured out what was going on by myself, not for an employer, by being obsessive about details, and spending well over a week on my need to know why?. I had *seen* the problem at two previous employers, but neither of them were interested in me wasting time on the why?, once there was a workaround available. No reason to give the information away to competitors, if there's nothing in it but that they become more competitive... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 with this options and do some buildworlds again? You are making the same mistake I did. We should be asking Udo Schweigert and KT Sin. Soeren doesn't have any P4's or AMD's with the problem. Hmmm... P4... AMD... have to wonder if someone looked at someone else's paper during the test... ;^). Here's the list of people I have, from a casual look at the archives for this week: Mark Santcroos Martin Blapp (P4) Udo Schweigert (P4, new compiler workaround) KT Sin (P4, new compiler workaround) Don Lewis (AMD Athlon) Alexander Leidinger (P4) David O'Brien (AMD) Alfred Perlstein (?) If we could get most or all of them to try the workaround, it would provide useful information... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 you revert back to the system compiler and also compile your kernel with this options and do some buildworlds again? You are making the same mistake I did. No, you are making the same mistake as Soren ;-) I did ask KT, look at the 'To:' field. Mark -- Mark Santcroos RIPE Network Coordination Centre http://www.ripe.net/home/mark/ New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: DIskcheckd Problems
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 disks in the system. Aug 22 10:13:20 diskcheckd[128]: seek failure on /dev/da1: Bad file descriptor I tried a lot to get it up and running again: - remade all devices in /dev - undo the diskcheckd upgrade (diskcheckd-20010823_3 - diskcheckd-20010823) - checked the disk several times for errors - Google didn't help also The disk is fine. I gave up and forgot about it, until it happened to another machine. We got 2 more machines with exactly the same hardware and software setup. On one of the machines diskcheckd is working fine, on the other one it stopped checking the disk-array. Same Message: Aug 22 10:12:45 diskcheckd[130]: seek failure on /dev/twed0: Bad file descriptor This time i even synced /dev and the binarys of both systems, it didn't help either. Is this a known problem? What can i do about it? Both Systems are running on FreeBSD 4.5-RELEASE. -- David W. Chapman Jr. [EMAIL PROTECTED] Raintree Network Services, Inc. www.inethouston.net [EMAIL PROTECTED] FreeBSD Committer www.FreeBSD.org To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 the code from boot2 through mi_startup(), to be sure nothing had crept in there. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
UFS2 may prevent from sharing partitions with some *BSDs
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 number 8 and *BSDs fall in single-user mode. `fsck -y' doesn't succeed too. If I run `fsck_ffs -b 32' on NetBSD and OpenBSD, fsck finishes completely. But FreeBSD mounts those partition once, NetBSD and OpenBSD fall in single-user mode again. Though this phenomenon doesn't happen with kernel at 21 June 2002 6:15 UTC, that happens with one at 6:20 UTC. Differences between them may be UFS2 codes. So UFS2 may prevent some *BSDs from mounting shared partitions. This phenomenon is, however, not so critical, because NetBSD and OpenBSD can mount those partitions without fsck checking. If I run `mount -a' and `exit' after NetBSD and OpenBSD fall in single-user mode, those *BSDs start with no problem. No file is lost. Can you let your *BSDs share some partitions? If anyone can't do it, I'll write send-pr. Below are messages of FreeBSD dmesg and mount: Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #38: Thu Aug 22 09:27:27 JST 2002 root@kaoru:/usr/src/sys/i386/compile/KAORU.5.0.0D Preloaded elf kernel /boot/kernel/kernel at 0xc0464000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04640a8. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 250568746 Hz CPU: AMD-K6tm w/ multimedia extensions (250.57-MHz 586-class CPU) Origin = AuthenticAMD Id = 0x570 Stepping = 0 Features=0x8001bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,MMX AMD Features=0x400b10 real memory = 268419072 (262128K bytes) avail memory = 255660032 (249668K bytes) Using $PIR table, 8 entries at 0xc00f0d00 npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS P5A on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-safe frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xec08-0xec0b on acpi0 acpi_cpu0: CPU on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 agp0: Ali M1541 host to AGP bridge mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pci0: bridge, PCI-unknown at device 3.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 de0: Digital 21140A Fast Ethernet port 0xd800-0xd87f mem 0xde00-0xde7f irq 9 at device 9.0 on pci0 de0: 21140A [10-100Mb/s] pass 2.0 de0: address 00:80:c8:54:f5:eb pcm0: Avance Logic ALS4000 port 0xd400-0xd47f irq 10 at device 11.0 on pci0 atapci0: AcerLabs Aladdin ATA33 controller port 0xd000-0xd00f at device 15.0 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 fdc0: enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/7 bytes threshold lpt0: Printer on ppbus0 lpt0: Interrupt-driven port sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ad0: DMA limited to UDMA33, non-ATA66 cable or device ad0: 38166MB ST340823A [77545/16/63] at ata0-master UDMA33 acd0: CD-RW 4424 CDRW at ata1-slave PIO3 Mounting root from ufs:/dev/ad0s2a de0: enabling 10baseT port /dev/ad0s2a on / (ufs, local) devfs on /dev (devfs, local) /dev/md0c on /tmp (ufs, local, nodev, nosuid, soft-updates) /dev/ad0s1 on /dos (msdosfs, local) /dev/ad0s2h on /home (ufs, local) /dev/ad0s2f on /usr (ufs, local) /dev/ad0s2g on /usr/src (ufs, asynchronous, local) /dev/ad0s2e on /var (ufs, local) -- Kazuhito HONDA [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 first 4M to the new entry describing a 4M page, instead of the one describing the location of the ptes covering those 4M. Then, what we would do is walk all the ptes, including those old stale and useless ones that previously described those first 4M and set the PG_G bit there (Note: we've already set PG_G on our 4M page). Normally, we don't really need to touch the old ptes but we did it just because it was more convenient (i.e. a few lines less code). Oddly enough, on the ppro and pII what would happen is that we would page fault on that page where we kept the old ptes covering those first 4M, and only on that page! The other ptes - the ones that actually mattered - were all fine. The ptes are mapped above the 4M so I don't see how changing the pde for those first 4M would have done anything. To fix the problem, we (actually Peter) committed code that basically just jumps beyond that first page of stale ptes when setting the PG_G bit for the 4K pages, and since then, the problem seems to have gone away. Although we are not sure, this seems like a silicon bug. Since then, Peter had some work planned to load the kernel above the first 4M to see if that fixed the problems. I'm wondering if this problem on the PIVs could be related. Please let us know if the removal of those two options really makes 5-10 buildworlds in a row work out for you. Regards, Bosko On Thu, Aug 22, 2002 at 01:34:11PM +0200, Mark Santcroos wrote: 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 preterbs the workaround. The problem I've referred to in my hunch here is actually related solely to the PSE, but with the recent code reorganization in locore.s, etc., it could have become more significant. 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? Mark -- Mark SantcroosRIPE Network Coordination Centre http://www.ripe.net/home/mark/New Projects Group/TTM To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Memory corruption in CURRENT
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 has gone away too. But let's see. I'll build 20 worlds at one row. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
how to use the Giant?
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 aac_softc *sc), before kthread_exit, it only calls the mtx_lock(Giant). If I also write one kernel thread program, should I use the Giant? Thank you! Best Regards Ouyang Kai _ ÓëÁª»úµÄÅóÓѽøÐн»Á÷£¬ÇëʹÓà MSN Messenger: http://messenger.microsoft.com/cn/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Call for testers: acpica-unix-20020815
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 correct battery info. :-) The full change log: http://developer.intel.com/technology/iapc/acpi/downloads/CHANGES.txt The patches against CURRENT sys tree are available at: http://people.freebsd.org/~iwasaki/acpi/acpica-20020725-20020815-test20020822.diff Please note that any feedback should be sent to [EMAIL PROTECTED] Enjoy! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: install crash on hp omnibook 6100
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 some child devices before initializing their parents, causing an infinite loop. The acpi-jp list doesn't seem interested in changing the way we do initialization, and theres no docs on the part it's initializing to rewrite the DSDT. Hmm, could you clarify. What child devices is it initializing first? -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
