Re: only 3 of 4GB memory available on amd64 8.1-RC1
On Sun, Jun 20, 2010 at 12:26 AM, Andriy Gapon a...@icyb.net.ua wrote: on 19/06/2010 20:16 Andreas Tobler said the following: Hi all, I got my hands on a t60 with 4GB of RAM (BIOS displays it) Yes, PAE is for what we call in FreeBSD land i386. x86 we use for both i386 and amd64. Now, to the rest. I recently investigated this topic myself, so I can share what I learned. The first thing you'd want to have is SMAP information. You can get it at the loader prompt with 'smap' command. It is also reported by kernel during a verbose boot, but it is only printed to console; it is not saved to dmesg, because it is printed before msgbuf is created. ... That's about all. I am curious as to what you would discover about your system - please share with us. -- Andriy Gapon Hello My notebook Toshiba U200-10H Install 4Gb(2+2) bios detect 3,... not all SMAP tipe=01 base= len=0009fc00 tipe=02 base=0009fc00 len=0400 tipe=02 base=000e len=ee00 tipe=04 base=000eee00 len=0200 tipe=02 base=000ef000 len=00011000 tipe=01 base=0010 len=cf69 tipe=02 base=cf79 len=0001 tipe=02 base=cf7a len=0006 tipe=02 base=cf80 len=0080 tipe=02 base=fec0 len=00018000 tipe=02 base=fec2 len=8000 tipe=02 base=fed0 len=0400 tipe=02 base=fed14000 len=6000 tipe=02 base=fed1c000 len=00074000 tipe=02 base=feda len=0002 tipe=02 base=fee0 len=1000 tipe=02 base=ffb0 len=0010 tipe=02 base=ffe0 len=0020 FreeBSD 9.0-CURRENT #1 r209362: Sun Jun 20 21:44:27 MSD 2010 and...@my_book:/usr/obj/home/andrey/src_head/sys/MY_BOOK amd64 CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1828.76-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6f2 Family = 6 Model = f Stepping = 2 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) Physical memory chunk(s): 0x1000 - 0x0009bfff, 634880 bytes (155 pages) 0x0126a000 - 0xc95dafff, 3359051776 bytes (820081 pages) avail memory = 3339898880 (3185 MB) full dmesg+debug http://www.suahbsd.org/dmesg.boot.dbg ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Ports doesnt respect fetch environment settings
My company recently enabled proxy authentication for outgoing connections, and this has stopped ports from working. From fetch(5), I understand that I can place my proxy authentication in plain text in the environment*, and this will allow fetch to work correctly, and this does work: # env | grep -i proxy ftp_proxy=http://proxy:3128/ HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password HTTP_PROXY=http://proxy:3128/ # fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps However, the ports makefiles seem to do something funky to my environment which hides these environment variables, and so the ports infrastructure stops working: # make fetch === Vulnerability check disabled, database not found === License check disabled, port has not defined LICENSE = googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. = Attempting to fetch from http://googlecl.googlecode.com/files/. fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz: Proxy Authentication Required = Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/. fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz: Not Found = Couldn't fetch it - please try to retrieve this = port manually into /usr/ports/distfiles/ and try again. *** Error code 1 Stop in /usr/FreeBSD/CURRENT/ports/net/googlecl. This is on i386 7-STABLE, last updated in mid May, with current ports, last updated yesterday. Cheers Tom * Which, incidently, is completely rubbish. Why is there no option for HTTP like ~/.netrc for FTP? Exposing my passwords in plain text in my environment feels stupid. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ports doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote: My company recently enabled proxy authentication for outgoing connections, and this has stopped ports from working. From fetch(5), I understand that I can place my proxy authentication in plain text in the environment*, and this will allow fetch to work correctly, and this does work: # env | grep -i proxy ftp_proxy=http://proxy:3128/ HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password HTTP_PROXY=http://proxy:3128/ # fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps However, the ports makefiles seem to do something funky to my environment which hides these environment variables, and so the ports infrastructure stops working: You should use FETCH_ENV or FETCH_ARGS to pass information to fetch(1) from the ports infrastructure. It is documented in /usr/ports/Mk/bsd.port.mk, search for FETCH_BINARY. Hope that helps. -erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@freebsd.org pgpifgXh0rQzZ.pgp Description: PGP signature
Re: Ports doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 11:10 AM, Erwin Lansing er...@freebsd.org wrote:
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote:
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment*, and this will allow fetch to work
correctly, and this does work:
# env | grep -i proxy
ftp_proxy=http://proxy:3128/
HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password
HTTP_PROXY=http://proxy:3128/
# fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz
googlecl-0.9.5.tar.gz 100% of 36 kB 77 MBps
However, the ports makefiles seem to do something funky to my
environment which hides these environment variables, and so the ports
infrastructure stops working:
You should use FETCH_ENV or FETCH_ARGS to pass information to fetch(1) from
the
ports infrastructure. It is documented in /usr/ports/Mk/bsd.port.mk,
search for FETCH_BINARY. Hope that helps.
-erwin
Er, ok that makes slight sense. In /usr/ports/Mk/bsd.port.mk it says:
# FETCH_ENV - Environment to pass to ${FETCH_CMD}.
# Default: none
So how is it picking up that it needs to go thru a proxy at all, given
that this is also only specified in the environment?
Also, am I supposed to literally repeat my same environment variables
in FETCH_ENV? Meaning I have to place my password in plain text again
in my environment? This is horrific...
Also, even after doing that, it still doesn't look at the environment
variables. I prepended -v to FETCH_ENV to show that it is setting
the right environment variables, but fetch in ports is still not
looking at them:
# export FETCH_ENV=-v HTTP_PROXY=$HTTP_PROXY
HTTP_PROXY_AUTH=$HTTP_PROXY_AUTH ftp_proxy=$ftp_proxy
r...@strangepork '11:26:21' '/usr/ports/net/googlecl'
# make fetch
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
= googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch from http://googlecl.googlecode.com/files/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]= 'http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz'
fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz:
Proxy Authentication Required
= Attempting to fetch from ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]=
'ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz'
fetch: ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz:
Not Found
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ and try again.
*** Error code 1
*.freebsd.org is whitelisted through the proxies, which is why the
second fetch gets a 404 and not a 407
Any thoughts?
Cheers
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ports doesnt respect fetch environment settings
On Mon, 21 Jun 2010 11:34:12 +0100
Tom Evans tevans...@googlemail.com wrote:
On Mon, Jun 21, 2010 at 11:10 AM, Erwin Lansing er...@freebsd.org wrote:
On Mon, Jun 21, 2010 at 11:04:16AM +0100, Tom Evans wrote:
My company recently enabled proxy authentication for outgoing
connections, and this has stopped ports from working.
From fetch(5), I understand that I can place my proxy authentication
in plain text in the environment*, and this will allow fetch to work
correctly, and this does work:
# env | grep -i proxy
ftp_proxy=http://proxy:3128/
HTTP_PROXY_AUTH=basic:*:tev...@domain.com:password
HTTP_PROXY=http://proxy:3128/
# fetch http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz
googlecl-0.9.5.tar.gz __ __ __ __ __ __ __ __ __ __ __ __ 100% of __ 36 kB
__ 77 MBps
However, the ports makefiles seem to do something funky to my
environment which hides these environment variables, and so the ports
infrastructure stops working:
You should use FETCH_ENV or FETCH_ARGS to pass information to fetch(1) from
the
ports infrastructure. __It is documented in /usr/ports/Mk/bsd.port.mk,
search for FETCH_BINARY. __Hope that helps.
-erwin
Er, ok that makes slight sense. In /usr/ports/Mk/bsd.port.mk it says:
# FETCH_ENV - Environment to pass to ${FETCH_CMD}.
# Default: none
So how is it picking up that it needs to go thru a proxy at all, given
that this is also only specified in the environment?
Also, am I supposed to literally repeat my same environment variables
in FETCH_ENV? Meaning I have to place my password in plain text again
in my environment? This is horrific...
Also, even after doing that, it still doesn't look at the environment
variables. I prepended -v to FETCH_ENV to show that it is setting
the right environment variables, but fetch in ports is still not
looking at them:
# export FETCH_ENV=-v HTTP_PROXY=$HTTP_PROXY
HTTP_PROXY_AUTH=$HTTP_PROXY_AUTH ftp_proxy=$ftp_proxy
r...@strangepork '11:26:21' '/usr/ports/net/googlecl'
# make fetch
=== Vulnerability check disabled, database not found
=== License check disabled, port has not defined LICENSE
= googlecl-0.9.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/.
= Attempting to fetch from http://googlecl.googlecode.com/files/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]= 'http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz'
fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz:
Proxy Authentication Required
= Attempting to fetch from
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/.
#env setenv:HTTP_PROXY=http://proxy:3128/
#env setenv:HTTP_PROXY_AUTH=basic:*:tev...@domain:pass
#env setenv:ftp_proxy=http://proxy:3128/
#env executing: /usr/bin/fetch
#envarg[0]= '/usr/bin/fetch'
#envarg[1]= '-ApRr'
#envarg[2]= '-S 37867'
#envarg[3]=
'ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz'
fetch:
ftp://ftp.FreeBSD.org/pub/FreeBSD/ports/distfiles/googlecl-0.9.5.tar.gz:
Not Found
= Couldn't fetch it - please try to retrieve this
= port manually into /usr/ports/distfiles/ and try again.
*** Error code 1
*.freebsd.org is whitelisted through the proxies, which is why the
second fetch gets a 404 and not a 407
Any thoughts?
Yes. When you ran fetch by hand you didn't have the -ApRr on the CL.
Could it be that the 'p' flag is causing problems?
Try running fetch by hand again with those flags and see what happens.
If it fails, try removing the 'p' flag.
--
Gary Jennejohn
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Ports doesnt respect fetch environment settings
On Mon, Jun 21, 2010 at 12:07 PM, Gary Jennejohn gljennj...@googlemail.com wrote: Yes. When you ran fetch by hand you didn't have the -ApRr on the CL. Could it be that the 'p' flag is causing problems? Try running fetch by hand again with those flags and see what happens. If it fails, try removing the 'p' flag. -- Gary Jennejohn Yes, I went through the same logic - its not the 'p' flag, its the 'A' flag, which is supposed to prevent it following 302 redirects. In this case, it refuses to retry the request when it receives a 407. # /usr/bin/fetch -ApRr -v -S 37867 http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz proxy requires authorization fetch: http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz: Proxy Authentication Required r...@strangepork '12:13:28' '/usr/ports/net/googlecl' # /usr/bin/fetch -pRr -v -S 37867 http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz proxy requires authorization looking up proxy connecting to proxy:3128 requesting http://googlecl.googlecode.com/files/googlecl-0.9.5.tar.gz local size / mtime: 37867 / 1276839258 remote size / mtime: 37867 / 1276839258 That doesn't seem right! Looking in lib/libfetch/http.c it tries to fetch the file in a loop. libfetch first tries without proxy authentication, even if you specify it in your environment. If the request fails due to proxy authentication being required, it sets a flag to add proxy auth details next time through the loop, and continues. If the '-A' flag is set however, it will only go through this loop one time, and so does not attempt to use the supplied proxy authentication. Comments in the source code imply that this is a change in behaviour introduced at the start of the year to support digest authentication; prior to that it would have attempted proxy auth on the first request. The flag for '-A' is documented as: -A Do not automatically follow ‘‘temporary’’ (302) redirects. Some broken Web sites will return a redirect instead of a not‐found error when the requested object does not exist. where as the behaviour is: Do not attempt to download this file more than once, for any reason. Having seen this, the bug is that we wish to go thru the loop one more time to retry with proxy authentication added, but the loop may exit on the next iteration. This diff allows it to go through the loop one more time, and now fetches the file correctly. Incidentally, having fixed fetch to work with '-A' thru a proxy that requires proxy auth, I now dont require anything in FETCH_ENV or FETCH_*_ARGS, it works correctly with the PROXY_* environment variables. Patch attached. Cheers Tom Index: /usr/src/lib/libfetch/http.c === RCS file: /home/ncvs/src/lib/libfetch/http.c,v retrieving revision 1.78.2.5 diff -u -r1.78.2.5 http.c --- /usr/src/lib/libfetch/http.c27 Jan 2010 14:54:48 - 1.78.2.5 +++ /usr/src/lib/libfetch/http.c21 Jun 2010 11:30:32 - @@ -1710,6 +1710,7 @@ goto ouch; } /* try again, but send the password this time */ + ++n; if (verbose) fetch_info(proxy requires authorization); break; ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [MFC REQUEST] Filename completion in sh(1)
jhell jh...@dataix.net writes: Because SVN in both our patches for tab completion missed filecomplete.h and filecomplete.c [...] the previous patches from des@ myself will break world builds. Speak for yourself. Both files are present in the patch I posted, and I tested it (make toolchain, which builds both libedit and sh) before I posted it. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: New event timers infrastructure
On Mon, Jun 21, 2010 at 12:33 AM, Alexander Motin m...@freebsd.org wrote: Brandon Gooch wrote: On Sun, Jun 20, 2010 at 3:35 PM, Doug Barton do...@freebsd.org wrote: On 06/20/10 08:47, Alexander Motin wrote: While this can be done in sysctl.conf, it would be better to do it in loader.conf to make it applied from the beginning, without on-the-fly timers change. You're probably right that for something this fundamental it's better to do it in loader.conf, however I wanted to mention that I recently changed the rcorder for the early boot scripts to run sysctl first for very similar reasons. This is good information, so sorry if I'm being dense: does this mean that it should have worked by applying the changes via /etc/sysctl.conf? You are too old. You are already born. (c) Sergey Lukyanenko. stathz set much earlier, just before Starting kernel event timers logged first time. It can only be affected from loader.conf. OK. I understand everything[*] now... No worries though, I've set it in /boot/loader.conf to avoid any possible ambiguity or anomalous behavior, and it's working very well! Nice. Very nice :) BTW, I've successfully tested suspend/resume on my amd64 laptop with all timers. For me, suspend/resume trials will be this evening, U.S. Central Standard Time... Looking forward to it! -Brandon [*] Well, almost everything, except for the Russian Sci-Fi quote ;) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [MFC REQUEST] Filename completion in sh(1)
2010/6/21 Dag-Erling Smørgrav d...@des.no: jhell jh...@dataix.net writes: Because SVN in both our patches for tab completion missed filecomplete.h and filecomplete.c [...] the previous patches from des@ myself will break world builds. Speak for yourself. Both files are present in the patch I posted, and I tested it (make toolchain, which builds both libedit and sh) before I posted it. I thank the both of you! I'll test this further today on my 8-STABLE boxes :) -Brandon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: only 3 of 4GB memory available on amd64 8.1-RC1
on 21/06/2010 11:41 Andrey Fesenko said the following: My notebook Toshiba U200-10H Install 4Gb(2+2) bios detect 3,... not all SMAP tipe=01 base= len=0009fc00 tipe=02 base=0009fc00 len=0400 tipe=02 base=000e len=ee00 tipe=04 base=000eee00 len=0200 tipe=02 base=000ef000 len=00011000 tipe=01 base=0010 len=cf69 tipe=02 base=cf79 len=0001 tipe=02 base=cf7a len=0006 tipe=02 base=cf80 len=0080 tipe=02 base=fec0 len=00018000 tipe=02 base=fec2 len=8000 tipe=02 base=fed0 len=0400 tipe=02 base=fed14000 len=6000 tipe=02 base=fed1c000 len=00074000 tipe=02 base=feda len=0002 tipe=02 base=fee0 len=1000 tipe=02 base=ffb0 len=0010 tipe=02 base=ffe0 len=0020 Looks like your hardware+BIOS can/does not do memory hoisting. 786MB of your RAM can not be used. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [MFC REQUEST] Filename completion in sh(1)
On 06/21/2010 09:12, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Sorry but he only mention of filecomplete in your patch is in this section. That is exactly the same in the patch I had originally generated using SVN. Umm, the copy I have on my disk has those files. Just to be sure, I just generated a new diff from the tree I tested it in. DES I can forward the original message If you would like but I think its just a waste of time, it does not have them files in there, verify your sent folder. I do see that your new patch does this is a good thing ;) Since those files do not exist in stable/8 I believe the error was running ( cd /usr/src svn diff %%ARGS_HERE%% ) which I repeated more then once and the files disapear from the diff. The diff you sent in the original attachment had matched mine all except the order in which the files appeared. ANYWAY... two new correct patches now exist on the list so no worries. -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes DES -- Dag-Erling Smørgrav - d...@des.no Sorry, just to take one step back, why has this become necessary for this particular box? If /usr/obj is empty, and svn up, followed by svn diff, doesn't show any local changes, why can't I go straight to make buildworld? In other words, why do my headers need updating on this particular box, and not on other ia64 boxes? I must've screwed something up, haven't I? Anyway, I tried what jhell suggested, and got the same error again. I'll now try to follow DES's advice. many thanks for your help anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On 06/21/2010 10:45, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes DES Sure, the only difference here is you just seem to have added cleandepend for extra added surety but is unneeded if the obj directory is assumed empty. buildincludes covered by a simple make, I don't even know why I decided to mention the all target since thats what it makes by default. I sure hope the make system was designed to cover that target under all because that would be a shame if it didn't ;). installincludes mm really ? Before install, after install and in the obj directories during the build process there is no difference. Can you point them out ? And yes Ive checked them. Anyhoo this subject is three days old and did not hear anything back, I would say that it probably solved his problem unless you would say he probably crashed and could not reply. ;) Regards, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: strange scsi/CAM related dmesg output
On Friday 18 June 2010 10:18:54 pm Scott Long wrote: On Jun 18, 2010, at 9:11 AM, Alexander Best alexbes...@uni- muenster.de wrote: On Mon, Jun 7, 2010 at 3:57 PM, John Baldwin j...@freebsd.org wrote: On Saturday 05 June 2010 2:54:15 pm Jille Timmermans wrote: Scott Long schreef: On Jun 4, 2010, at 4:35 PM, Alexander Best wrote: hi there. running HEAD, amd64 and r208806 i get this dmesg output which doesn't look right: ada0 at ahcich2 bus 0 scbus3 target 0 lun 0 ada0: SAMSUNG SP2504C VT100-50 ATA-7 SATA 2.x device ada0: 300.000MB/s transferscd0 at ata2 bus 0 scbus2 target 0 lun 0 cd0: HL-DT-ST DVDRAM GSA-H10N JL12 Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: cd present [1944656 x 2048 byte records] (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 238474MB (488395055 512 byte sectors: 16H 63S/T 16383C) my kernel contains: options SC_HISTORY_SIZE=1000 options MSGBUF_SIZE=65536 options PRINTF_BUFR_SIZE=128 might this be caused by one of these lines? cheers. Can you be more specific about what you think is not right? Scott I assume he means that 'cd0 at ata2 ...' is on the same line as the third ada0 line. After all the cd0-lines, the ada0 line continues. That shouldn't happen with PRINTF_BUFR_SIZE set, should it? It can happen because the print buffer size thing is not line- buffered, it is printf-invocation buffered. hmmm...can this somehow be fixed? i'm not sure this is specific to scsi/cam. the other day i bootd my system and almost all of the dmesg output was displayed incorrectly. would increasing PRINTF_BUFR_SIZE from 128 to lets say 512 or 1024 solve the issue Johns response is off base. I explained the issue prior to him, please review that. Huh? My point is that the buffer size is not line buffered, but the entire buffer is always output before printf() returns. Thus, if you do: printf(foo); printf( bar\n); Then another CPU or thread can send output in between the foo and bar\n. What people want, aesthetically, is to have per-thread line-buffered output, so each thread would accumulate chars up to a limit or '\n' across multiple calls to printf() and output all of that at once. On the other hand, if something else should be serializing these printfs then they shouldn't interleave even w/o PRINTF_BUFR_SIZE, so I don't see how PRINTF_BUFR_SIZE would fix it. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Mon, Jun 21, 2010 at 11:24:52AM -0400, jhell wrote: On 06/21/2010 10:45, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes DES Sure, the only difference here is you just seem to have added cleandepend for extra added surety but is unneeded if the obj directory is assumed empty. buildincludes covered by a simple make, I don't even know why I decided to mention the all target since thats what it makes by default. I sure hope the make system was designed to cover that target under all because that would be a shame if it didn't ;). installincludes mm really ? Before install, after install and in the obj directories during the build process there is no difference. Can you point them out ? And yes Ive checked them. Anyhoo this subject is three days old and did not hear anything back, I would say that it probably solved his problem unless you would say he probably crashed and could not reply. ;) well.. I was busy with other things over the week-end. No, I haven't solved this problem yet. I've 3 ia64 boxes, this problem only occured on one of those. I did # cd /usr/src # rm -rf /usr/obj/* # svn up # svn diff The last command did not show any differences. I can't understand how I can have problems with unupdated headers.. many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes this failed in make depend step with *skip* rm -f .depend mkdep -f .depend -a /usr/src/lib/libalias/modules/smedia/../../../../sys/netinet/libalias/alias_smedia.c === lib/libarchive (depend) rm -f .depend mkdep -f .depend -a-DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 -DPLATFORM_CONFIG_H=\config_freebs .h\ -I/usr/obj/usr/src/lib/libarchive -DWITH_OPENSSL /usr/src/lib/libarchive/archive_check_magic.c /usr/src lib/libarchive/archive_entry.c /usr/src/lib/libarchive/archive_entry_copy_stat.c /usr/src/lib/libarchive/arc ive_entry_stat.c /usr/src/lib/libarchive/archive_entry_strmode.c /usr/src/lib/libarchive/archive_entry_link_resolver.c /usr/src/lib/libarchive/archive_entry_xattr.c /usr/src/lib/libarchive/archive_read.c /usr/src/lib/libarchive/archive_read_data_into_fd.c /usr/src/lib/libarchive/archive_read_disk.c /usr/src/lib/libarchive/archive_read_disk_entry_from_file.c /usr/src/lib/libarchive/archive_read_disk_set_standard_lookup.c /usr/src/lib/libarchive/archive_read_extract.c /usr/src/lib/libarchive/archive_read_open_fd.c /usr/src/lib/libarchive/archive_read_open_file.c /usr/src/lib/libarchive/archive_read_open_filename.c /usr/src/lib/libarchive/archive_read_open_memory.c /usr/src/lib/libarchive/archive_read_support_compression_all.c /usr/src/lib/libarchive/archive_read_support_compression_bzip2.c /usr/src/lib/libarchive/archive_read_support_compression_compress.c /usr/src/lib/libarchive/archive_read_support_compression_gzip.c /usr/src/lib/libarchive/archive_read_support_compression_none.c /usr/src/lib/libarchive/archive_read_support_compression_program.c /usr/src/lib/libarchive/archive_read_support_compression_uu.c /usr/src/lib/libarchive/archive_read_support_compression_xz.c /usr/src/lib/libarchive/archive_read_support_format_all.c /usr/src/lib/libarchive/archive_read_support_format_ar.c /usr/src/lib/libarchive/archive_read_support_format_cpio.c /usr/src/lib/libarchive/archive_read_support_format_empty.c /usr/src/lib/libarchive/archive_read_support_format_iso9660.c /usr/src/lib/libarchive/archive_read_support_format_mtree.c /usr/src/lib/libarchive/archive_read_support_format_raw.c /usr/src/lib/libarchive/archive_read_support_format_tar.c /usr/src/lib/libarchive/archive_read_support_format_zip.c /usr/src/lib/libarchive/archive_string.c /usr/src/lib/libarchive/archive_string_sprintf.c /usr/src/lib/libarchive/archive_util.c /usr/src/lib/libarchive/archive_virtual.c /usr/src/lib/libarchive/archive_write.c /usr/src/lib/libarchive/archive_write_disk.c /usr/src/lib/libarchive/archive_write_disk_set_standard_lookup.c /usr/src/lib/libarchive/archive_write_open_fd.c /usr/src/lib/libarchive/archive_write_open_file.c /usr/src/lib/libarchive/archive_write_open_filename.c /usr/src/lib/libarchive/archive_write_open_memory.c /usr/src/lib/libarchive/archive_write_set_compression_bzip2.c /usr/src/lib/libarchive/archive_write_set_compression_compress.c /usr/src/lib/libarchive/archive_write_set_compression_gzip.c /usr/src/lib/libarchive/archive_write_set_compression_none.c /usr/src/lib/libarchive/archive_write_set_compression_program.c /usr/src/lib/libarchive/archive_write_set_compression_xz.c /usr/src/lib/libarchive/archive_write_set_format.c /usr/src/lib/libarchive/archive_write_set_format_ar.c /usr/src/lib/libarchive/archive_write_set_format_by_name.c /usr/src/lib/libarchive/archive_write_set_format_cpio.c /usr/src/lib/libarchive/archive_write_set_format_cpio_newc.c /usr/src/lib/libarchive/archive_write_set_format_mtree.c /usr/src/lib/libarchive/archive_write_set_format_pax.c /usr/src/lib/libarchive/archive_write_set_format_shar.c /usr/src/lib/libarchive/archive_write_set_format_ustar.c /usr/src/lib/libarchive/archive_write_set_format_zip.c /usr/src/lib/libarchive/filter_fork.c /usr/src/lib/libarchive/archive_read_support_compression_xz.c:45:18: error: lzma.h: No such file or directory /usr/src/lib/libarchive/archive_write_set_compression_xz.c:42:18: error: lzma.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libarchive. *** Error code 1 I'm now at r209398 many thanks anton -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: Sorry, just to take one step back, why has this become necessary for this particular box? I have no idea or opinion - I just responded to jhell's incorrect instructions for updating your headers. If /usr/obj is empty, and svn up, followed by svn diff, doesn't show any local changes, why can't I go straight to make buildworld? If you're going to make buildworld, there is no reason whatsoever to update your headers. That is only necessary if you want to shortcut the build process after applying patches which you know affect some headers. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
jhell jh...@dataix.net writes: Sure, the only difference here is you just seem to have added cleandepend for extra added surety but is unneeded if the obj directory is assumed empty. Assumption is the mother of all f***ups. The mother of your particular f***up is the assumption that all headers are in /usr/src/include. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
2010/6/21 Anton Shterenlikht me...@bristol.ac.uk: On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes this failed in make depend step with *skip* rm -f .depend mkdep -f .depend -a /usr/src/lib/libalias/modules/smedia/../../../../sys/netinet/libalias/alias_smedia.c === lib/libarchive (depend) rm -f .depend mkdep -f .depend -a -DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 -DPLATFORM_CONFIG_H=\config_freebs .h\ -I/usr/obj/usr/src/lib/libarchive -DWITH_OPENSSL /usr/src/lib/libarchive/archive_check_magic.c /usr/src lib/libarchive/archive_entry.c /usr/src/lib/libarchive/archive_entry_copy_stat.c /usr/src/lib/libarchive/arc ive_entry_stat.c /usr/src/lib/libarchive/archive_entry_strmode.c /usr/src/lib/libarchive/archive_entry_link_resolver.c /usr/src/lib/libarchive/archive_entry_xattr.c /usr/src/lib/libarchive/archive_read.c /usr/src/lib/libarchive/archive_read_data_into_fd.c /usr/src/lib/libarchive/archive_read_disk.c /usr/src/lib/libarchive/archive_read_disk_entry_from_file.c /usr/src/lib/libarchive/archive_read_disk_set_standard_lookup.c /usr/src/lib/libarchive/archive_read_extract.c /usr/src/lib/libarchive/archive_read_open_fd.c /usr/src/lib/libarchive/archive_read_open_file.c /usr/src/lib/libarchive/archive_read_open_filename.c /usr/src/lib/libarchive/archive_read_open_memory.c /usr/src/lib/libarchive/archive_read_support_compression_all.c /usr/src/lib/libarchive/archive_read_support_compression_bzip2.c /usr/src/lib/libarchive/archive_read_support_compression_compress.c /usr/src/lib/libarchive/archive_read_support_compression_gzip.c /usr/src/lib/libarchive/archive_read_support_compression_none.c /usr/src/lib/libarchive/archive_read_support_compression_program.c /usr/src/lib/libarchive/archive_read_support_compression_uu.c /usr/src/lib/libarchive/archive_read_support_compression_xz.c /usr/src/lib/libarchive/archive_read_support_format_all.c /usr/src/lib/libarchive/archive_read_support_format_ar.c /usr/src/lib/libarchive/archive_read_support_format_cpio.c /usr/src/lib/libarchive/archive_read_support_format_empty.c /usr/src/lib/libarchive/archive_read_support_format_iso9660.c /usr/src/lib/libarchive/archive_read_support_format_mtree.c /usr/src/lib/libarchive/archive_read_support_format_raw.c /usr/src/lib/libarchive/archive_read_support_format_tar.c /usr/src/lib/libarchive/archive_read_support_format_zip.c /usr/src/lib/libarchive/archive_string.c /usr/src/lib/libarchive/archive_string_sprintf.c /usr/src/lib/libarchive/archive_util.c /usr/src/lib/libarchive/archive_virtual.c /usr/src/lib/libarchive/archive_write.c /usr/src/lib/libarchive/archive_write_disk.c /usr/src/lib/libarchive/archive_write_disk_set_standard_lookup.c /usr/src/lib/libarchive/archive_write_open_fd.c /usr/src/lib/libarchive/archive_write_open_file.c /usr/src/lib/libarchive/archive_write_open_filename.c /usr/src/lib/libarchive/archive_write_open_memory.c /usr/src/lib/libarchive/archive_write_set_compression_bzip2.c /usr/src/lib/libarchive/archive_write_set_compression_compress.c /usr/src/lib/libarchive/archive_write_set_compression_gzip.c /usr/src/lib/libarchive/archive_write_set_compression_none.c /usr/src/lib/libarchive/archive_write_set_compression_program.c /usr/src/lib/libarchive/archive_write_set_compression_xz.c /usr/src/lib/libarchive/archive_write_set_format.c /usr/src/lib/libarchive/archive_write_set_format_ar.c /usr/src/lib/libarchive/archive_write_set_format_by_name.c /usr/src/lib/libarchive/archive_write_set_format_cpio.c /usr/src/lib/libarchive/archive_write_set_format_cpio_newc.c /usr/src/lib/libarchive/archive_write_set_format_mtree.c /usr/src/lib/libarchive/archive_write_set_format_pax.c /usr/src/lib/libarchive/archive_write_set_format_shar.c /usr/src/lib/libarchive/archive_write_set_format_ustar.c /usr/src/lib/libarchive/archive_write_set_format_zip.c /usr/src/lib/libarchive/filter_fork.c /usr/src/lib/libarchive/archive_read_support_compression_xz.c:45:18: error: lzma.h: No such file or directory /usr/src/lib/libarchive/archive_write_set_compression_xz.c:42:18: error: lzma.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libarchive. *** Error code 1 I'm now at r209398 Although I know it isn't the proper method of doing things, why not just do... pushd lib/lzma make obj make depend make buildincludes make installincludes popd # Resume regularly scheduled program ? Obviously something is screwed up with the environment on the machine as half-measures don't appear to be working :/... -Garrett
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: this failed in make depend step with you can skip that step... in fact, you can skip the whole thing, since it is completely irrelevant to your case. I'll go check the archives for your OP and see if I can provide some more useful advice than jhell. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On 06/21/2010 11:59, Anton Shterenlikht wrote: On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes this failed in make depend step with *skip* rm -f .depend mkdep -f .depend -a /usr/src/lib/libalias/modules/smedia/../../../../sys/netinet/libalias/alias_smedia.c === lib/libarchive (depend) rm -f .depend mkdep -f .depend -a-DHAVE_BZLIB_H=1 -DHAVE_LIBLZMA=1 -DHAVE_LZMA_H=1 -DPLATFORM_CONFIG_H=\config_freebs .h\ -I/usr/obj/usr/src/lib/libarchive -DWITH_OPENSSL /usr/src/lib/libarchive/archive_check_magic.c /usr/src lib/libarchive/archive_entry.c /usr/src/lib/libarchive/archive_entry_copy_stat.c /usr/src/lib/libarchive/arc ive_entry_stat.c /usr/src/lib/libarchive/archive_entry_strmode.c /usr/src/lib/libarchive/archive_entry_link_resolver.c /usr/src/lib/libarchive/archive_entry_xattr.c /usr/src/lib/libarchive/archive_read.c /usr/src/lib/libarchive/archive_read_data_into_fd.c /usr/src/lib/libarchive/archive_read_disk.c /usr/src/lib/libarchive/archive_read_disk_entry_from_file.c /usr/src/lib/libarchive/archive_read_disk_set_standard_lookup.c /usr/src/lib/libarchive/archive_read_extract.c /usr/src/lib/libarchive/archive_read_open_fd.c /usr/src/lib/libarchive/archive_read_open_file.c /usr/src/lib/libarchive/archive_read_open_filename.c /usr/src/lib/libarchive/archive_read_open _memory.c /usr/src/lib/libarchive/archive_read_support_compression_all.c /usr/src/lib/libarchive/archive_read_support_compression_bzip2.c /usr/src/lib/libarchive/archive_read_support_compression_compress.c /usr/src/lib/libarchive/archive_read_support_compression_gzip.c /usr/src/lib/libarchive/archive_read_support_compression_none.c /usr/src/lib/libarchive/archive_read_support_compression_program.c /usr/src/lib/libarchive/archive_read_support_compression_uu.c /usr/src/lib/libarchive/archive_read_support_compression_xz.c /usr/src/lib/libarchive/archive_read_support_format_all.c /usr/src/lib/libarchive/archive_read_support_format_ar.c /usr/src/lib/libarchive/archive_read_support_format_cpio.c /usr/src/lib/libarchive/archive_read_support_format_empty.c /usr/src/lib/libarchive/archive_read_support_format_iso9660.c /usr/src/lib/libarchive/archive_read_support_format_mtree.c /usr/src/lib/libarchive/archive_read_support_format_raw.c /usr/src/lib/libarchive/archive_read_support_format _tar.c /usr/src/lib/libarchive/archive_read_support_format_zip.c /usr/src/lib/libarchive/archive_string.c /usr/src/lib/libarchive/archive_string_sprintf.c /usr/src/lib/libarchive/archive_util.c /usr/src/lib/libarchive/archive_virtual.c /usr/src/lib/libarchive/archive_write.c /usr/src/lib/libarchive/archive_write_disk.c /usr/src/lib/libarchive/archive_write_disk_set_standard_lookup.c /usr/src/lib/libarchive/archive_write_open_fd.c /usr/src/lib/libarchive/archive_write_open_file.c /usr/src/lib/libarchive/archive_write_open_filename.c /usr/src/lib/libarchive/archive_write_open_memory.c /usr/src/lib/libarchive/archive_write_set_compression_bzip2.c /usr/src/lib/libarchive/archive_write_set_compression_compress.c /usr/src/lib/libarchive/archive_write_set_compression_gzip.c /usr/src/lib/libarchive/archive_write_set_compression_none.c /usr/src/lib/libarchive/archive_write_set_compression_program.c /usr/src/lib/libarchive/archive_write_set_compression_xz.c /usr/src/lib/libarchive/arch ive_write_set_format.c /usr/src/lib/libarchive/archive_write_set_format_ar.c /usr/src/lib/libarchive/archive_write_set_format_by_name.c /usr/src/lib/libarchive/archive_write_set_format_cpio.c /usr/src/lib/libarchive/archive_write_set_format_cpio_newc.c /usr/src/lib/libarchive/archive_write_set_format_mtree.c /usr/src/lib/libarchive/archive_write_set_format_pax.c /usr/src/lib/libarchive/archive_write_set_format_shar.c /usr/src/lib/libarchive/archive_write_set_format_ustar.c /usr/src/lib/libarchive/archive_write_set_format_zip.c /usr/src/lib/libarchive/filter_fork.c /usr/src/lib/libarchive/archive_read_support_compression_xz.c:45:18: error: lzma.h: No such file or directory /usr/src/lib/libarchive/archive_write_set_compression_xz.c:42:18: error: lzma.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/lib/libarchive. *** Error code 1 I'm now at r209398 many thanks anton I do not remember what the exact fix was nor am I looking it up but give this a shot. # I think I missed this step when I did this. # Copy and paste for pleasure. cd /usr/src/lib make obj make depend make includes make installincludes Retry your build from here and report back. Of course all these re-install of includes really is not needed now but this is
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
Anton Shterenlikht me...@bristol.ac.uk writes: I've r209203 kernel on ia64 box. Now I'm trying to rebuild world to r209240. I get these errors. There is absolutely nothing between those two revisions that would explain the errors you're getting. Are you absolutely sure those are the correct revision numbers? Have you tried checking out a clean copy of r209203 and building + installing that before trying to build r209240 again? DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On 06/21/2010 12:25, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Sure, the only difference here is you just seem to have added cleandepend for extra added surety but is unneeded if the obj directory is assumed empty. Assumption is the mother of all f***ups. The mother of your particular f***up is the assumption that all headers are in /usr/src/include. His return post confirmed it was a clean obj. Where did the rest of the answers go ? I have not had to deal with this since: r208258 | mm | 2010-05-18 05:59:09 -0400 (Tue, 18 May 2010) | 16 lines And have no way to test it out if it solves the problem but sure it could be worked through without the attitude flames that you bring to this thread. DES Wow really! your getting that upset you have to start cussing. I just hope that because of your incorrect addition to what you say building the includes improperly is a f***up and being called out on, just like the other patch we've discussed that you so claim had two files in it that you can't own up to does not have anything to do with this. As to the point before you start pointing fingers as you are so gracious to do lately - The steps laid out are the steps I had once took to correct the similar problem. And I seem to be running on these systems fairly well mind you. If you would like to take your aggressions off-list Ill be more than willing to oblige. Praying for you, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
jhell jh...@dataix.net writes: As to the point before you start pointing fingers as you are so gracious to do lately - The steps laid out are the steps I had once took to correct the similar problem. And I seem to be running on these systems fairly well mind you. They are still wrong, and they will not solve his problem. All they will do is muddle the tracks and reduce our chances of ever finding out what the problem really is. Praying for you, I'd rather you didn't. DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2010-06-21 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-21 16:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-06-21 16:15:00 - cleaning the object tree TB --- 2010-06-21 16:15:40 - cvsupping the source tree TB --- 2010-06-21 16:15:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-06-21 16:21:07 - building world TB --- 2010-06-21 16:21:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 16:21:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 16:21:07 - TARGET=i386 TB --- 2010-06-21 16:21:07 - TARGET_ARCH=i386 TB --- 2010-06-21 16:21:07 - TZ=UTC TB --- 2010-06-21 16:21:07 - __MAKE_CONF=/dev/null TB --- 2010-06-21 16:21:07 - cd /src TB --- 2010-06-21 16:21:07 - /usr/bin/make -B buildworld World build started on Mon Jun 21 16:21:07 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jun 21 18:01:08 UTC 2010 TB --- 2010-06-21 18:01:08 - generating LINT kernel config TB --- 2010-06-21 18:01:08 - cd /src/sys/i386/conf TB --- 2010-06-21 18:01:08 - /usr/bin/make -B LINT TB --- 2010-06-21 18:01:08 - building LINT kernel TB --- 2010-06-21 18:01:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 18:01:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 18:01:08 - TARGET=i386 TB --- 2010-06-21 18:01:08 - TARGET_ARCH=i386 TB --- 2010-06-21 18:01:08 - TZ=UTC TB --- 2010-06-21 18:01:08 - __MAKE_CONF=/dev/null TB --- 2010-06-21 18:01:08 - cd /src TB --- 2010-06-21 18:01:08 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 21 18:01:09 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x100a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-21 18:16:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-21 18:16:05 - ERROR: failed to build lint kernel TB --- 2010-06-21 18:16:05 - 5515.73 user 922.46 system 7264.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on i386/i386
mav, could this be related to r209371? Doug On 06/21/10 11:16, FreeBSD Tinderbox wrote: TB --- 2010-06-21 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-21 16:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-06-21 16:15:00 - cleaning the object tree TB --- 2010-06-21 16:15:40 - cvsupping the source tree TB --- 2010-06-21 16:15:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-06-21 16:21:07 - building world TB --- 2010-06-21 16:21:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 16:21:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 16:21:07 - TARGET=i386 TB --- 2010-06-21 16:21:07 - TARGET_ARCH=i386 TB --- 2010-06-21 16:21:07 - TZ=UTC TB --- 2010-06-21 16:21:07 - __MAKE_CONF=/dev/null TB --- 2010-06-21 16:21:07 - cd /src TB --- 2010-06-21 16:21:07 - /usr/bin/make -B buildworld World build started on Mon Jun 21 16:21:07 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jun 21 18:01:08 UTC 2010 TB --- 2010-06-21 18:01:08 - generating LINT kernel config TB --- 2010-06-21 18:01:08 - cd /src/sys/i386/conf TB --- 2010-06-21 18:01:08 - /usr/bin/make -B LINT TB --- 2010-06-21 18:01:08 - building LINT kernel TB --- 2010-06-21 18:01:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 18:01:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 18:01:08 - TARGET=i386 TB --- 2010-06-21 18:01:08 - TARGET_ARCH=i386 TB --- 2010-06-21 18:01:08 - TZ=UTC TB --- 2010-06-21 18:01:08 - __MAKE_CONF=/dev/null TB --- 2010-06-21 18:01:08 - cd /src TB --- 2010-06-21 18:01:08 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 21 18:01:09 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x100a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-21 18:16:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-21 18:16:05 - ERROR: failed to build lint kernel TB --- 2010-06-21 18:16:05 - 5515.73 user 922.46 system 7264.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on ia64/ia64
TB --- 2010-06-21 17:07:18 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-21 17:07:18 - starting HEAD tinderbox run for ia64/ia64 TB --- 2010-06-21 17:07:18 - cleaning the object tree TB --- 2010-06-21 17:07:36 - cvsupping the source tree TB --- 2010-06-21 17:07:36 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2010-06-21 17:07:51 - building world TB --- 2010-06-21 17:07:51 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 17:07:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 17:07:51 - TARGET=ia64 TB --- 2010-06-21 17:07:51 - TARGET_ARCH=ia64 TB --- 2010-06-21 17:07:51 - TZ=UTC TB --- 2010-06-21 17:07:51 - __MAKE_CONF=/dev/null TB --- 2010-06-21 17:07:51 - cd /src TB --- 2010-06-21 17:07:51 - /usr/bin/make -B buildworld World build started on Mon Jun 21 17:07:55 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jun 21 18:30:09 UTC 2010 TB --- 2010-06-21 18:30:09 - generating LINT kernel config TB --- 2010-06-21 18:30:09 - cd /src/sys/ia64/conf TB --- 2010-06-21 18:30:09 - /usr/bin/make -B LINT TB --- 2010-06-21 18:30:09 - building LINT kernel TB --- 2010-06-21 18:30:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 18:30:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 18:30:09 - TARGET=ia64 TB --- 2010-06-21 18:30:09 - TARGET_ARCH=ia64 TB --- 2010-06-21 18:30:09 - TZ=UTC TB --- 2010-06-21 18:30:09 - __MAKE_CONF=/dev/null TB --- 2010-06-21 18:30:09 - cd /src TB --- 2010-06-21 18:30:09 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 21 18:30:09 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies [...] awk -f /src/sys/tools/makeobjops.awk /src/sys/kgssapi/kgss_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/libkern/iconv_converter_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/opencrypto/cryptodev_if.m -h awk -f /src/sys/tools/makeobjops.awk /src/sys/dev/acpica/acpi_if.m -h rm -f .newdep /usr/bin/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/ipfilter -I/src/sys/contrib/pf -I/src/sys/dev/ath -I/src/sys/dev/ath/ath_hal -I/src/sys/contrib/ngatm -I/src/sys/dev/twa -I/src/sys/gnu/fs/xfs/FreeBSD -I/src/sys/gnu/fs/xfs/FreeBSD/support -I/src/sys/gnu/fs/xfs -I/src/sys/contrib/opensolaris/compat -I/src/sys/dev/cxgb -I/src/sys/contrib/ia64/libuwx/src -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=15000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-builtin -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -fpic -ffreestanding /src/sys/dev/acpica/acpi_hpet.c:34:22: error: opt_apic.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /obj/ia64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-21 18:31:39 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-21 18:31:39 - ERROR: failed to build lint kernel TB --- 2010-06-21 18:31:39 - 3947.28 user 661.32 system 5060.38 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
Lawrence Stewart lstew...@freebsd.org wrote: On 06/21/10 05:44, Rui Paulo wrote: On 20 Jun 2010, at 20:36, Fabian Keil wrote: Fabian Keilfreebsd-lis...@fabiankeil.de wrote: Fabian Keilfreebsd-lis...@fabiankeil.de wrote: My custom kernel normally doesn't have INVARIANTS and WITNESS enabled, so I'll try to enable them next. The culprit seem to be non-default KTR settings in the kernel while loading alq as a module. Actually whether or not alq is loaded as a module doesn't seem to matter, with: optionsKTR optionsKTR_ENTRIES=262144 optionsKTR_COMPILE=(KTR_SCHED) optionsKTR_MASK=(KTR_SCHED) optionsKTR_CPUMASK=0x3 optionsALQ optionsKTR_ALQ enabling siftr panics the system, too. That's probably because your module was built with different compile time options than the ones used in the kernel. These options may change structure sizes, function parameters, etc. and that easily causes panics. hmm I wonder if my instructions to build SIFTR manually are causing your problems. Fabian, is the siftr.ko module you're loading built as part of a make buildkernel, or did you follow my instructions and cd /path/to/src/sys/modules/siftr ; make ; kldload ./siftr.ko? The latter. If the latter is true, perhaps try and explicitly build SIFTR as part of make buildkernel and see if loading the module built that way still triggers the panic when enabled (the module will be in /usr/obj/path/to/src/sys/KERNCONF/modules/path/to/src/sys/modules/siftr/siftr.ko or if you make installkernel it'll be in /boot/kernel/kernel/siftr.ko). That seems to work. Fabian signature.asc Description: PGP signature
Re: only 3 of 4GB memory available on amd64 8.1-RC1
On 19.06.10 22:26, Andriy Gapon wrote:
on 19/06/2010 20:16 Andreas Tobler said the following:
Hi all,
I got my hands on a t60 with 4GB of RAM (BIOS displays it)
And I installed 8.1-RC1 on it:
FreeBSD 8.1-RC1 #0: Mon Jun 14 13:40:28 UTC 2010
r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64
Timecounter i8254 frequency 1193182 Hz quality 0
CPU: Intel(R) Core(TM)2 CPU T5600 @ 1.83GHz (1828.76-MHz
K8-class CPU)
Origin = GenuineIntel Id = 0x6f6 Family = 6 Model = f Stepping = 6
Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE
Features2=0xe3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM
AMD Features=0x20100800SYSCALL,NX,LM
AMD Features2=0x1LAHF
TSC: P-state invariant
real memory = 4294967296 (4096 MB)
avail memory = 3092344832 (2949 MB)
ACPI APIC Table:LENOVO TP-79
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 2 core(s)
cpu0 (BSP): APIC ID: 0
cpu1 (AP): APIC ID: 1
Do I need to configure something special to get the full 4GB of memory?
I only found the PAE hint, but this is for x86 machines, right?
Yes, PAE is for what we call in FreeBSD land i386.
x86 we use for both i386 and amd64.
Now, to the rest.
I recently investigated this topic myself, so I can share what I learned.
The first thing you'd want to have is SMAP information.
You can get it at the loader prompt with 'smap' command.
It is also reported by kernel during a verbose boot, but it is only printed to
console; it is not saved to dmesg, because it is printed before msgbuf is
created.
Example of how SMAP information looks:
SMAP type=01 base= end=0009f800
SMAP type=02 base=000f end=0010
SMAP type=02 base=fec0 end=0001
SMAP type=02 base=e000 end=f000
SMAP type=02 base=0009f800 end=000a
SMAP type=02 base=bfdf end=bfe0
SMAP type=01 base=0010 end=bfde
SMAP type=03 base=bfde3000 end=bfdf
SMAP type=04 base=bfde end=bfde3000
SMAP type=01 base=0001 end=00013000
Type 1 ('01') is memory ranges free for OS use.
Note that the ranges could be unsorted.
SMAP would give you an idea what is free for OS use and what is taken away for
BIOS and hardware needs. Also note that what's reported as avail memory is
smaller than sum of sizes of all unreserved regions. Some space is taken away
by FreeBSD virtual memory code to store some core page/memory management
information (~3%). Memory used by kernel and preloaded modules is also not
included into avail memory.
If you discover that your system reserves, in your opinion, too much memory,
then consider the following things.
1. Some memory might be allocated as video adapter's aperture and/or video
adapter's memory in case of some integrated graphics solutions.
2. Some memory addresses below 4GB are used for MMIO (memory mapped
input/output) - accessing those addresses is actually communicating with some
hardware rather than accessing DRAM. Some hardware+firmware combinations can
hoist (or remap) DRAM that corresponds to such an address range to a different
address range above 4G. If you examine last line of my sample SMAP output, then
you'll see that there is 756MB of type 01 RAM above 4GB and that machine has
exactly 4GB of DRAM installed - this is MMIO range 0xd000-0x1
hoisted to 0x1-0x13000.
If your hardware doesn't support that option, then too bad - the memory is
overshadowed by MMIO and is effectively lost.
Sometimes hoisting option (under whatever name) has to be explicitly set in BIOS
configuration.
Thanks for the explanation!
That's about all.
I am curious as to what you would discover about your system - please share
with us.
I'd like to, but how do I get this information out of my box? There is
no serial line. The only way I know is getting a screen shot. Do you
know another way?
Unfortunately I do not have a docking station, there I guess I'd have a
serial line.
Also, sorry for the delay, I had to upgrade the bios in hope that the
em0 is recognized properly, but no chance:
em0: Intel(R) PRO/1000 Network Connection 7.0.5 port 0x3000-0x301f mem
0xee00-0xee01 irq 16 at device 0.0 on pci2
em0: attempting to allocate 1 MSI vectors (1 supported)
msi: routing MSI IRQ 256 to local APIC 0 vector 49
em0: using IRQ 256 for MSI
em0: Using MSI interrupt
em0: The EEPROM Checksum Is Not Valid
Thanks again!
Andreas
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On 06/21/2010 13:47, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: As to the point before you start pointing fingers as you are so gracious to do lately - The steps laid out are the steps I had once took to correct the similar problem. And I seem to be running on these systems fairly well mind you. They are still wrong, and they will not solve his problem. All they will do is muddle the tracks and reduce our chances of ever finding out what the problem really is. Actually I apologize as I originally read your fix to what I posted as cd to /usr/src/includes where as you are correct with those build options for a cd /usr/src. I do think that a full depends and includes build for the whole tree is a little expensive in this case but it would work the same either way. Though with what you said above (second paragraph) I would believe that trying to correct this problem first by finding out if the problem was laid out in the includes directory first would have been one step possibly in the right direction to solving the problem as I am just trying to recall what had actually solved that import of lzma issue. This is the thread with the discussion: http://bit.ly/dCuhHK Why on earth this is breaking on some machines and not on others is weird. Maybe a possibility of having the xz- port installed in comparison to the ones that don't... I didn't have that much time to analyze it when it came about. I can say that after he tried the build after the includes directory build that the `lzma_physmem' error he was getting in the subject line disappeared and he was left with just having to update libarchive liblzma. Praying for you, I'd rather you didn't. In reference to: http://bit.ly/dy4VSb ;) Regards, -- jhell ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: only 3 of 4GB memory available on amd64 8.1-RC1
on 21/06/2010 22:19 Andreas Tobler said the following: On 19.06.10 22:26, Andriy Gapon wrote: I'd like to, but how do I get this information out of my box? There is no serial line. The only way I know is getting a screen shot. Do you know another way? Unfortunately I do not have a docking station, there I guess I'd have a serial line. Screenshot is fine by today's standards :-) Especially if you can OCR it by hand. Or large enough (very large!) SC_HISTORY_SIZE in kernel options (start with 1000) and moused. Or a tiny kernel module that I wrote that can reproduce SMAP info upon loading: http://people.freebsd.org/~avg/smap.diff Comes with no guarantee or warranty :) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r209240 ia64 - buildworld - undefined reference to `lzma_physmem'
On Jun 21, 2010, at 8:04 AM, Anton Shterenlikht wrote: On Mon, Jun 21, 2010 at 04:45:03PM +0200, Dag-Erling Smørgrav wrote: jhell jh...@dataix.net writes: Anton Shterenlikht me...@bristol.ac.uk writes: What do you mean by updating your headers? cd /usr/src/include make obj make depend make all make install wrong. % cd /usr/src % make obj % make cleandepend % make depend % make buildincludes % make installincludes DES -- Dag-Erling Smørgrav - d...@des.no Sorry, just to take one step back, why has this become necessary for this particular box? If /usr/obj is empty, and svn up, followed by svn diff, doesn't show any local changes, why can't I go straight to make buildworld? In other words, why do my headers need updating on this particular box, and not on other ia64 boxes? I must've screwed something up, haven't I? Anton, My suggestion would be to destroy the sandbox entirely and simply checkout a new one from scratch, provided you're not sharing sandboxes across NFS. I would also manually destroy your object tree under /usr/obj (or whereever you have it) before doing the buildworld. It's not impossible (double negative to emphasize that the possibility may not be big enough to worry about, but that I don't want to go there), that you have some corruption that is not exposed by svn diff, but that is causing the build-breakages. A clean slate helps... FYI, -- Marcel Moolenaar xcl...@mac.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on i386/i386
Doug Barton wrote: mav, could this be related to r209371? It is. Fixed. Thanks. On 06/21/10 11:16, FreeBSD Tinderbox wrote: TB --- 2010-06-21 16:15:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-06-21 16:15:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-06-21 16:15:00 - cleaning the object tree TB --- 2010-06-21 16:15:40 - cvsupping the source tree TB --- 2010-06-21 16:15:40 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-06-21 16:21:07 - building world TB --- 2010-06-21 16:21:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 16:21:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 16:21:07 - TARGET=i386 TB --- 2010-06-21 16:21:07 - TARGET_ARCH=i386 TB --- 2010-06-21 16:21:07 - TZ=UTC TB --- 2010-06-21 16:21:07 - __MAKE_CONF=/dev/null TB --- 2010-06-21 16:21:07 - cd /src TB --- 2010-06-21 16:21:07 - /usr/bin/make -B buildworld World build started on Mon Jun 21 16:21:07 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jun 21 18:01:08 UTC 2010 TB --- 2010-06-21 18:01:08 - generating LINT kernel config TB --- 2010-06-21 18:01:08 - cd /src/sys/i386/conf TB --- 2010-06-21 18:01:08 - /usr/bin/make -B LINT TB --- 2010-06-21 18:01:08 - building LINT kernel TB --- 2010-06-21 18:01:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-06-21 18:01:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-06-21 18:01:08 - TARGET=i386 TB --- 2010-06-21 18:01:08 - TARGET_ARCH=i386 TB --- 2010-06-21 18:01:08 - TZ=UTC TB --- 2010-06-21 18:01:08 - __MAKE_CONF=/dev/null TB --- 2010-06-21 18:01:08 - cd /src TB --- 2010-06-21 18:01:08 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jun 21 18:01:09 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh LINT cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue vers.c linking kernel apm.o(.text+0x100a): In function `apm_attach': : undefined reference to `atrtcclock_disable' *** Error code 1 Stop in /obj/i386/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-06-21 18:16:05 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-06-21 18:16:05 - ERROR: failed to build lint kernel TB --- 2010-06-21 18:16:05 - 5515.73 user 922.46 system 7264.84 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on i386/i386
On 06/21/10 13:59, Alexander Motin wrote: Doug Barton wrote: mav, could this be related to r209371? It is. Fixed. Thanks. Thank YOU for jumping on it so quickly. :) Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: only 3 of 4GB memory available on amd64 8.1-RC1
On 21.06.10 21:35, Andriy Gapon wrote: on 21/06/2010 22:19 Andreas Tobler said the following: On 19.06.10 22:26, Andriy Gapon wrote: I'd like to, but how do I get this information out of my box? There is no serial line. The only way I know is getting a screen shot. Do you know another way? Unfortunately I do not have a docking station, there I guess I'd have a serial line. Screenshot is fine by today's standards :-) Especially if you can OCR it by hand. It will end up in a png :) Or large enough (very large!) SC_HISTORY_SIZE in kernel options (start with 1000) and moused. I'll try that. Or a tiny kernel module that I wrote that can reproduce SMAP info upon loading: http://people.freebsd.org/~avg/smap.diff Comes with no guarantee or warranty :) This one too, I'll try it. But nevertheless my interest in this piece of HW has dropped. I got this t60 because the display is broken, someone broke the glass. This is no problem so far, but the issue that I can only access it via cardbus netif is boring me. Thanks for your hints! Andreas ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ problem
i experienced the same problem running r209391. this might have to do something with a fs being full. i saw these warnings during buildworld when eventuall / ran out of space: Jun 21 21:32:55 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:32:59 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:00 otaku kernel: pid 76033 (dd), uid 2 inumber 2591139 on /: filesystem full Jun 21 21:33:02 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:07 otaku kernel: pid 75215 (chrome), uid 1001 inumber 18205737 on /: filesystem full Jun 21 21:33:08 otaku kernel: pid 1467 (script), uid 1001 inumber 14226185 on /: filesystem full Jun 21 21:33:08 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:11 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:18 otaku kernel: pid 75215 (chrome), uid 1001 inumber 18205702 on /: filesystem full Jun 21 21:33:28 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full Jun 21 21:33:39 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full Jun 21 21:33:47 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:48 otaku kernel: pid 75215 (chrome), uid 1001 inumber 16086093 on /: filesystem full Jun 21 21:33:50 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full followed by lots of Jun 21 21:35:25 otaku kernel: bad block 7020785329444114652, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -315669439672768816, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -3220207053503867546, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -6419917778393221405, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 3919397040058727880, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -6888424595660707789, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: g_vfs_done():ufs/rootfs[READ(offset=100240429127958528, length=16384)]error = 5 Jun 21 21:35:25 otaku kernel: bad block -1173790944229704887, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 5537349803492323867, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 882554538064816358, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -2565060229441336925, ino 7468267 ~ 2 minutes later (see timestamp). i then did a `find / -inum 7468267` but couldn't find the file. i then did a clean reboot using `shutdown -r now`. the buffers got synched down to 0 however it said something like / cannot be unmounted filesystem busy. i then was thrown into single user mode due to the same problem alex kada reported. at some point i did a `mount -f /` and did `dmesg -a /FEHLER`. strange thing is that everything seems to have been piped to that file twice. after that i did `fastboot` and freebsd came up with / being clean (although the last fsck report said / was marked dirty). i've attached the file. cheers. -- Alexander Best Copyright (c) 1992-2010 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 is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #0 r209391: Mon Jun 21 17:53:14 CEST 2010 r...@otaku:/usr/obj/usr/src/sys/ARUNDEL amd64 CPU: Intel(R) Pentium(R) Dual CPU E2160 @ 1.80GHz (1800.04-MHz K8-class CPU) Origin = GenuineIntel Id = 0x6fd Family = 6 Model = f Stepping = 13 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0xe39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 2147483648 (2048 MB) avail memory = 2045149184 (1950 MB) Event timer LAPIC frequency 0 Hz quality 500 ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC
Re: [CFT] SIFTR - Statistical Information For TCP Research: Uncle Lawrence needs YOU!
On 06/22/10 04:52, Fabian Keil wrote: Lawrence Stewartlstew...@freebsd.org wrote: On 06/21/10 05:44, Rui Paulo wrote: On 20 Jun 2010, at 20:36, Fabian Keil wrote: Fabian Keilfreebsd-lis...@fabiankeil.de wrote: Fabian Keilfreebsd-lis...@fabiankeil.de wrote: My custom kernel normally doesn't have INVARIANTS and WITNESS enabled, so I'll try to enable them next. The culprit seem to be non-default KTR settings in the kernel while loading alq as a module. Actually whether or not alq is loaded as a module doesn't seem to matter, with: options KTR options KTR_ENTRIES=262144 options KTR_COMPILE=(KTR_SCHED) options KTR_MASK=(KTR_SCHED) options KTR_CPUMASK=0x3 options ALQ options KTR_ALQ enabling siftr panics the system, too. That's probably because your module was built with different compile time options than the ones used in the kernel. These options may change structure sizes, function parameters, etc. and that easily causes panics. hmm I wonder if my instructions to build SIFTR manually are causing your problems. Fabian, is the siftr.ko module you're loading built as part of a make buildkernel, or did you follow my instructions and cd /path/to/src/sys/modules/siftr ; make ; kldload ./siftr.ko? The latter. If the latter is true, perhaps try and explicitly build SIFTR as part of make buildkernel and see if loading the module built that way still triggers the panic when enabled (the module will be in /usr/obj/path/to/src/sys/KERNCONF/modules/path/to/src/sys/modules/siftr/siftr.ko or if you make installkernel it'll be in /boot/kernel/kernel/siftr.ko). That seems to work. Damn, well this is the first time I've encountered a problem like this whilst using SIFTR compiled standalone and I've been using it like that for almost 3 years. I guess the lack of KTR in the module build subtly influences the module in a way that allows it load but in a precarious way. How irritating. Rui you were right on the money! I will revise my testing instructions to build the module as part of a buildkernel to avoid potential problems like this. Thanks for helping get to the bottom of this and for the test feedback. Cheers, Lawrence ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ problem
On 22.06.2010 03:26, Alexander Best wrote: i experienced the same problem running r209391. this might have to do something with a fs being full. i saw these warnings during buildworld when eventuall / ran out of space: Jun 21 21:32:55 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full I have 160Gb disk used as one pat for / Only 16% space used... Jun 21 21:32:59 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:00 otaku kernel: pid 76033 (dd), uid 2 inumber 2591139 on /: filesystem full Jun 21 21:33:02 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:07 otaku kernel: pid 75215 (chrome), uid 1001 inumber 18205737 on /: filesystem full Jun 21 21:33:08 otaku kernel: pid 1467 (script), uid 1001 inumber 14226185 on /: filesystem full Jun 21 21:33:08 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:11 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:18 otaku kernel: pid 75215 (chrome), uid 1001 inumber 18205702 on /: filesystem full Jun 21 21:33:28 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full Jun 21 21:33:39 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full Jun 21 21:33:47 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661904 on /: filesystem full Jun 21 21:33:48 otaku kernel: pid 75215 (chrome), uid 1001 inumber 16086093 on /: filesystem full Jun 21 21:33:50 otaku kernel: pid 1398 (sakura), uid 1001 inumber 2661461 on /: filesystem full followed by lots of Jun 21 21:35:25 otaku kernel: bad block 7020785329444114652, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -315669439672768816, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -3220207053503867546, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -6419917778393221405, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 3919397040058727880, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -6888424595660707789, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: g_vfs_done():ufs/rootfs[READ(offset=100240429127958528, length=16384)]error = 5 Jun 21 21:35:25 otaku kernel: bad block -1173790944229704887, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 5537349803492323867, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block 882554538064816358, ino 7468267 Jun 21 21:35:25 otaku kernel: pid 16 (softdepflush), uid 0 inumber 7468267 on /: bad block Jun 21 21:35:25 otaku kernel: bad block -2565060229441336925, ino 7468267 ~ 2 minutes later (see timestamp). i then did a `find / -inum 7468267` but couldn't find the file. i then did a clean reboot using `shutdown -r now`. the buffers got synched down to 0 however it said something like / cannot be unmounted filesystem busy. i then was thrown into single user mode due to the same problem alex kada reported. at some point i did a `mount -f /` and did `dmesg -a /FEHLER`. strange thing is that everything seems to have been piped to that file twice. after that i did `fastboot` and freebsd came up with / being clean (although the last fsck report said / was marked dirty). i've attached the file. cheers. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
