Re: FreeBSD 6.5-prerelease and if_re - patches needed?
On Mon, 03 Nov 2008 09:47:14 +0900 Pyun YongHyeon [EMAIL PROTECTED] wrote: I've changed to have re(4) wait the completion of DMAable memory allocation during bus_dma cleanups. The delay you've seen may be related with that change. Previously it just failed to load the driver if there is no available memory at the time of driver loading. However I guess that delay wouldn't happen if the driver is statically linked into kernel. Did you use kernel module? No, the driver is compiled into the kernel: [EMAIL PROTECTED] ifconfig re0 re0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=1bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING inet 10.1.150.15 netmask 0x broadcast 10.1.255.255 ether 00:1d:60:2c:80:f0 media: Ethernet autoselect (100baseTX full-duplex) status: active [EMAIL PROTECTED] kldstat Id Refs AddressSize Name 13 0x8010 aa37d8 kernel 21 0x80ba4000 1a850snd_hda.ko 32 0x80bbf000 35c80sound.ko [EMAIL PROTECTED] HTH -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installworld chflags failures
On Mon, 03 Nov 2008 16:18:47 +0900 Randy Bush [EMAIL PROTECTED] wrote: :/ cd /usr/src :/usr/src bash Hmm, what happens if you do _not_ use bash here? bash is non-standard for a FreeBSD install (the procedure), so it might bite you. Or it might not. HTH -- Regards, Torfinn Ingolfsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: installworld chflags failures
On 11/3/08, Randy Bush [EMAIL PROTECTED] wrote: i386, fresh cvsup FreeBSD 7.1-PRERELEASE FreeBSD 7.1-PRERELEASE #14: Sun Nov 2 12:13:46 GMT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PSG i386 single luser mode over serial console :/usr/src# time make installworld 21 installworld.log install: /usr/lib/libkse.so.3: chflags: Operation not supported install: /usr/lib/librt.so.1: chflags: Operation not supported chflags: /usr/bin/chpass: Operation not supported install: /usr/bin/login: chflags: Operation not supported install: /usr/bin/opieinfo: chflags: Operation not supported install: /usr/bin/opiepasswd: chflags: Operation not supported chflags: /usr/bin/passwd: Operation not supported install: /usr/bin/rlogin: chflags: Operation not supported install: /usr/bin/rsh: chflags: Operation not supported install: /usr/bin/su: chflags: Operation not supported install: /usr/bin/crontab: chflags: Operation not supported install: /usr/sbin/sliplogin: chflags: Operation not supported this is new and different, and i am worried. no clue in UPDATING. no clue in head. ZFS currently doesn't support chflags(2): FreeBSD hp010.hetzel.org 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Oct 27 22:02:16 CDT 2008 [EMAIL PROTECTED]:/usr/obj/usr/src/8x-zfs/sys/DV8135NR amd64 hp010# touch t ; chflags arch t chflags: t: Operation not supported hp010# touch t ; chflags opaque t chflags: t: Operation not supported hp010# touch t ; chflags nodump t chflags: t: Operation not supported hp010# touch t ; chflags sappnd t chflags: t: Operation not supported hp010# touch t ; chflags schg t chflags: t: Operation not supported hp010# touch t ; chflags sunlnk t chflags: t: Operation not supported hp010# touch t ; chflags uappnd t chflags: t: Operation not supported hp010# touch t ; chflags uchg t chflags: t: Operation not supported hp010# touch t ; chflags uunlnk t chflags: t: Operation not supported hp010# rm t Even though http://wiki.freebsd.org/ZFS tells says that chflags(2) support is done. (see http://perforce.freebsd.org/changeView.cgi?CH=147105), it hasn't been merged from perforce to -CURRENT. Scot ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fifo log problem
At 10:28 AM 11/3/2008, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mike Tancsa writes: I have been taking a look at the fifolog(1) system in RELENG_7 and I must be missing something obvious. I created a file using default params e.g fifolog_create /var/log/all.fifo and then in /etc/syslog.conf I have *.* /var/log/all.log *.* | /usr/sbin/fifolog_writer /var/log/all.fifo It seems to work for the most part, but there are entries that are missing throughout the log e.g. in the traditional all.log I have # wc all.log 4833 55212 398099 all.log yet the fifo log file I have # fifolog_reader all.fifo | wc From0 Wed Dec 31 19:00:00 1969 To 1225722724 Mon Nov 3 09:32:04 2008 Read from 0 2232783 23271 There does not seem to be any pattern as to what it discards / keeps Try using cat instead of fifolog_writer, so we can tell on which side of the pipe we are looking for the trouble ? Hi, Seems to work fine with cat *.* /var/log/all.log *.* | /usr/sbin/fifolog_writer /var/log/all.fifo *.* | cat /var/log/all.cat ---Mike -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
fifo log problem
I have been taking a look at the fifolog(1) system in RELENG_7 and I must be missing something obvious. I created a file using default params e.g fifolog_create /var/log/all.fifo and then in /etc/syslog.conf I have *.* /var/log/all.log *.* | /usr/sbin/fifolog_writer /var/log/all.fifo It seems to work for the most part, but there are entries that are missing throughout the log e.g. in the traditional all.log I have # wc all.log 4833 55212 398099 all.log yet the fifo log file I have # fifolog_reader all.fifo | wc From0 Wed Dec 31 19:00:00 1969 To 1225722724 Mon Nov 3 09:32:04 2008 Read from 0 2232783 23271 There does not seem to be any pattern as to what it discards / keeps ---Mike Mike Tancsa, tel +1 519 651 3400 Sentex Communications,[EMAIL PROTECTED] Providing Internet since 1994www.sentex.net Cambridge, Ontario Canada www.sentex.net/mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fifo log problem
In message [EMAIL PROTECTED], Mike Tancsa writes: I have been taking a look at the fifolog(1) system in RELENG_7 and I must be missing something obvious. I created a file using default params e.g fifolog_create /var/log/all.fifo and then in /etc/syslog.conf I have *.* /var/log/all.log *.* | /usr/sbin/fifolog_writer /var/log/all.fifo It seems to work for the most part, but there are entries that are missing throughout the log e.g. in the traditional all.log I have # wc all.log 4833 55212 398099 all.log yet the fifo log file I have # fifolog_reader all.fifo | wc From0 Wed Dec 31 19:00:00 1969 To 1225722724 Mon Nov 3 09:32:04 2008 Read from 0 2232783 23271 There does not seem to be any pattern as to what it discards / keeps Try using cat instead of fifolog_writer, so we can tell on which side of the pipe we are looking for the trouble ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fifo log problem
In message [EMAIL PROTECTED], Mike Tancsa writes: Seems to work fine with cat Ok, and the loss is not from one end, it is random records in the middle ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fifo log problem
At 11:34 AM 11/3/2008, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mike Tancsa writes: Seems to work fine with cat Ok, and the loss is not from one end, it is random records in the middle ? Yes, they seem to initially get written and then tail off for some reason. I am not sure why. Actually, if I SIGHUP syslogd, it seems to make a difference, in that I can generally see when newsyslog sig HUPs syslog to do log rotation. Perhaps this is confusing things ? e.g. 1225628270 Nov 2 07:17:50 st32278 ovpn-kit[1047]: Initialization Sequence Completed 1225641602 Nov 2 11:00:02 st32278 syslogd: restart 1225641608 Nov 2 11:00:08 st32278 ppp[927]: tun0: Chat: deflink: Redial timer expired. In this snippet the last entry was 07:17 for some reason and then the SIGHUP from newsyslog seems to wake things up for some reason. ---Mike -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD 6.4-RC2 available...
The second Release Candidate for FreeBSD 6.4 is now available. FreeBSD
6.4-RC2 should be the last of the public test builds for the FreeBSD 6.4
release cycle. Unless a big show-stopper is found from this round of
testing we should begin the 6.4-RELEASE builds in about a week and a
half. We encourage you to test out 6.4-RC2 and report any problems by
submitting PRs or via email to the freebsd-stable list.
One of the things that could use some testing is the late-arriving
patches to sysinstall that should eliminate the excessive disc swapping
that previous releases had if things like gnome or kde were installed as
part of the initial CDROM install. Things selected before you reach the
Package Selection Menu are handled as separate passes from the things
that get selected at that menu. So depending on what you install before
you reach that menu (e.g. Xorg selected as part of the distributions)
and what you select at that menu there may still be some disc swapping
involved. But worst case given the current layout it should ask for
any given disc no more than twice.
For amd64 and i386 DVD images are also available. The DVD images
include the install bits, livefs, docs, and the same set of packages
that are available on the CDROMs all in one image. So, you can choose
to download/burn the DVD image to a DVD, or you can choose to
download/burn the three CDROM-sized discs and use those.
The ISO images and FTP install trees are available on the FreeBSD Mirror
sites. Using the primary site as an example:
ftp://ftp.freebsd.org/pub/FreeBSD/releases/${arch}/ISO-IMAGES/6.4/
where ${arch} is one of alpha, amd64, i386, pc98, or sparc64. Checksums
for the ISO images are at the bottom of this message. The amd64 and
i386 sets include what should be the final selection of packages that
will be included with the release.
If you would like to do a source-based update to 6.4-RC2 from an already
installed machine you can update your tree to RELENG_6_4 using normal
cvsup/csup methods. Note that as a somewhat inconvenient side-effect of
the primary FreeBSD source repository now being in SVN the creation of
the RELENG_6_4 branch in the CVS repository wound up checking in a new
version of every file, in some cases only changing the FBSDID. That
will probably make mergemaster a bit tedious. Sorry for the
inconvenience.
The freebsd-update(8) utility supports binary upgrades of i386 and amd64
systems running earlier FreeBSD releases. Systems running 6.3-RELEASE,
6.4-BETA, or 6.4-RC1 can upgrade as follows:
# freebsd-update upgrade -r 6.4-RC2
During this process, FreeBSD Update may ask the user to help by merging
some configuration files or by confirming that the automatically performed
merging was done correctly.
# freebsd-update install
The system must be rebooted with the newly installed kernel before continuing.
# shutdown -r now
After rebooting, freebsd-update neews to be run again to install the new
userland components, and the system needs to be rebooted again:
# freebsd-update install
# shutdown -r now
Note that FreeBSD Update stores downloaded upgrades in /var/db/freebsd-update,
so at least 400MB should be free in /var before running freebsd-update; if
the /var partition is too small, the -d option to freebsd-update can be used
to indicate that the upgrades should be stored in a different directory.
Checksums:
MD5 (6.4-RC2-alpha-bootonly.iso) = 0c1a10fcb84e4bcc7efbd7c843726f34
MD5 (6.4-RC2-alpha-disc1.iso) = af9ec02034b7d9833f1af9d2fafbfa38
MD5 (6.4-RC2-alpha-disc2.iso) = 80d7e1cf89be3f88af1b99fbbc48e27f
MD5 (6.4-RC2-alpha-disc3.iso) = 693e09dafa19e995303c02970e13acb3
MD5 (6.4-RC2-alpha-docs.iso) = 671a1f48159b63df0decc011d91f9772
MD5 (6.4-RC2-amd64-bootonly.iso) = 67da9f580f8b33762c07c2a85a621534
MD5 (6.4-RC2-amd64-disc1.iso) = ffab4610c8fb807496b289237000aa93
MD5 (6.4-RC2-amd64-disc2.iso) = d1496e78dbb60d4e9210191fd3d57e76
MD5 (6.4-RC2-amd64-disc3.iso) = 708a0d328be5bfd3deb2ac35986aadee
MD5 (6.4-RC2-amd64-docs.iso) = 08588036702646adbe81f78c3bcafdaa
MD5 (6.4-RC2-amd64-dvd1.iso) = 2c2dcc94097aaeec1c7a50101236e2bf
MD5 (6.4-RC2-i386-bootonly.iso) = 7ed7b049d14eb170c2d4c044312bccef
MD5 (6.4-RC2-i386-disc1.iso) = d114cdad5502bff3e8182ddd42d81ab3
MD5 (6.4-RC2-i386-disc2.iso) = c0cbbfcb2a2f2d81974a33c85e242155
MD5 (6.4-RC2-i386-disc3.iso) = cbff7482228883da14f1f85070a89422
MD5 (6.4-RC2-i386-docs.iso) = 4663810144153a21aad6c81768af7358
MD5 (6.4-RC2-i386-dvd1.iso) = 1d3608538d8476c8df64d8e91a03aa22
MD5 (6.4-RC2-pc98-bootonly.iso) = a059b9178c0d985ed729a2d33a1d1577
MD5 (6.4-RC2-pc98-disc1.iso) = b1508c34d2f595ea44c446be1e989c57
MD5 (6.4-RC2-sparc64-bootonly.iso) = 1311e40fb9ccc786994098444d1e18f0
MD5 (6.4-RC2-sparc64-disc1.iso) = 45b629d802f16a73f13e77e70c2f0bfc
MD5 (6.4-RC2-sparc64-disc2.iso) = ddd1d1ad89cf51eac2e5fc2acdfadadc
MD5 (6.4-RC2-sparc64-disc3.iso) = a348d7a193d5f07c8ff11ac8f0d5e478
MD5 (6.4-RC2-sparc64-docs.iso) = 4a3f9d15c149d98096fb9224a1b338c6
SHA256 (6.4-RC2-alpha-bootonly.iso) =
Re: installworld chflags failures
Is /usr a ZFS filesystem or part of a zpool? If so, possibly you have some ZFS settings on your pool or filesystem which are inhibiting the ability to use chflags in some way? zfs get all will help. aha! i suspect you care correct. but i can not decipher from man zfs which property it is. http://wiki.freebsd.org/ZFS tells me that chflags(2) support is done. still googling, but nothing exciting. xattr is extended attributes, and should default to on but is temp off for unknown reasons. is that it? randy -- # zfs get all tank/usr NAME PROPERTY VALUE SOURCE tank/usr type filesystem - tank/usr creation Wed Oct 8 1:02 2008 - tank/usr used 63.0G - tank/usr available 164G - tank/usr referenced 14.6G - tank/usr compressratio 1.00x - tank/usr mountedyes- tank/usr quota none default tank/usr reservationnone default tank/usr recordsize 128K default tank/usr mountpoint /usr local tank/usr sharenfs offdefault tank/usr checksum on default tank/usr compressionoffdefault tank/usr atime on default tank/usr deviceson default tank/usr exec on default tank/usr setuid on default tank/usr readonly offdefault tank/usr jailed offdefault tank/usr snapdirhidden default tank/usr aclmodegroupmask default tank/usr aclinherit secure default tank/usr canmount on default tank/usr shareiscsi offdefault tank/usr xattr offtemporary tank/usr copies 1 default ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
[Call for testers] bce(4) update
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dear 7-STABLE users, I would like to call for test for a patchset that is intended for MFC to 7-STABLE before 7.1-RELEASE. The patchset can be viewed/downloaded here: http://www.delphij.net/bce.diff (~1.2MB) For those with slow network, you can download the compressed version: http://www.delphij.net/bce.diff.bz2 (~210KB) In order to apply the patch, you will need to update your source tree to latest RELENG_7, then, cd into /usr/src/sys and use patch ~/bce.diff (assume that you have downloaded it to your home directory), then recompile your kernel (or module). This patchset would add some new hardware support, plus a bunch of bugfixes done by davidch@ in the past months. Since this is a relatively big change, I would appreciate tests from bce(4) hardware owners, your help will aid us to make FreeBSD 7.1 a better release. For your convenience, here is a summary for the change: r176448,178132,178853,179436,179695,179771,182293 r176448 (davidch) - Added loose RX MTU functionality to allow frames larger than 1500 bytes to be accepted even though the interface MTU is set to 1500. - Implemented new TCP header splitting/jumbo frame support which uses two chains for receive traffic rather than the original single receive chain. - Added additional debug support code. r178132 (davidch) - Fixed a problem with the send chain consumer index which would cause TX traffic to sit in the send chain until a received packet kick started the interrupt handler. This would cause extremely slow performance when used with NFS over UDP. - Removed untested polling code. - Updated copyright year in the file header. - Removed inadvertent ^M's created by DOS text editor. r178853 (scottl) The BCE chips appear to have an undocumented requirement that RX frames be aligned on an 8 byte boundary. Prior to rev 1.36 (now r176448) this wasn't a problem because mbuf clusters tend be naturally aligned. The switch to using split buffers with the first buffer being the embedded data area of the mbuf has broken this assumption, at least on i386, causing a complete failure of RX functionality. Fix this for now by using a full cluster for the first RX buffer. A more sophisticated approach could be done with the old buffer scheme to realign the m_data pointer with m_adj(), but I'm also not clear on performance benefits of this old scheme or the performance implications of adding an m_adj() call to every allocation. r179436 (jhb) Trim an extra semi-colon. r179695 (davidch) - Fixed kern/123696 by increasing firmware timeout value from 100 to 1000. - Fixed a problem on i386 architecture when using split header/jumbo frame firmware caused by hardware alignment requirements. - Added #define BCE_USE_SPLIT_HEADER to allow the feature to be enabled/disabled. Enabled by default. PR: kern/123696 r179771 (davidch) - Added support for BCM5709 and BCM5716 controllers. r182293 (davidch) - Updated support for 5716. - Added some additional code for debug builds. - Fixed a problem printing physical memory on 64bit system during debugging. - Modified some of the context memory and mailbox register names to more clearly distinguish their use. - Added memory barriers for Intel CPUs when accessing host memory data structures which are written by hardware. - -- Xin LI [EMAIL PROTECTED] http://www.delphij.net/ FreeBSD - The Power to Serve! -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (FreeBSD) iEYEARECAAYFAkkOzV4ACgkQi+vbBBjt66C3IgCgi5OVuzAIlzJ/cgSpZuWPdqvZ FAEAn0xUK/gp5VNwisDgcbGzfPh7jig4 =1CGv -END PGP SIGNATURE- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Install issues with 7.x
Thanks for your interest Robert, unfortunately it was a no-go. I went ahead and tested 6.4RC1 and 6.3. Now all I am getting are ACPI errors which I would think I could get the installer going by disabling ACPI. And yes, I'm running on the latest - and only - bios revision for the laptop. The following were done under default boot option. No ACPI did not generate any error messages and hung, single user mode acted the same as default, and safe mode created an interrupt storm like 7.x did. 6.4-RC1 ... acpi_timer0: 24-bit timer at 3.579545 MHz port 0x408-0x40b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62, 0x66 on acpi0 cpu0: ACPI CPU on acpi0 ACPI-0328: *** Error: No pointer back to NS node in buffer obj 0xc85c87c0 ACPI-1304: *** Error: Method execution failed [\_PR_.CPU0._OSC] (Node 0xc84e2580), AE_AML_INTERNAL acpi_throttle0: ACPI CPU Throttling on cpu0 ... then this gets spammed 6 times at the end ACPI-0438: *** Error: Looking up [\_PR_.CPU0._PPC] in name space, AE_NOT_FOUND SearchNode 0xc84cdcc0 StartNode 0xc84cdcc0 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\_SB_.AC__.ADJP] (Node 0xc84cdcc0), AE_NOT_FOUND ACPI-1304: *** Error: Method execution failed [\_SB.AC__._PSR] (Node 0xc84cdd00), AE_NOT_FOUND 6.3-REL 6.3 gives the same errors but with different node addresses. ... acpi_timer0: 24-bit timer at 3.579545 MHz port 0x408-0x40b on acpi0 acpi_ec0: Embedded Controller: GPE 0x18 port 0x62, 0x66 on acpi0 cpu0: ACPI CPU on acpi0 ACPI-0328: *** Error: No pointer back to NS node in buffer obj 0xc85c94c0 ACPI-1304: *** Error: Method execution failed [\_PR_.CPU0._OSC] (Node 0xc84e3780), AE_AML_INTERNAL acpi_throttle0: ACPI CPU Throttling on cpu0 ... spammed again 6 times at the end ACPI-0438: *** Error: Looking up [\_PR_.CPU0._PPC] in name space, AE_NOT_FOUND SearchNode 0xc84cdd20 StartNode 0xc84cdd20 ReturnNode 0 ACPI-1304: *** Error: Method execution failed [\_SB_.AC__.ADJP] (Node 0xc84cdd20), AE_NOT_FOUND ACPI-1304: *** Error: Method execution failed [\_SB.AC__._PSR] (Node 0xc84e3780), AE_NOT_FOUND Help at all? On Sun, Nov 2, 2008 at 9:50 AM, Robert Watson [EMAIL PROTECTED] wrote: On Wed, 29 Oct 2008, Ryan wrote: Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. xpt_config is the CAM configuration wait, so basically the system is waiting for a storage device to report back on whether it could be used as a root file system. I recently saw a similar report of problems involving a firewire controller on an nvidia motherboard following an upgrade to 7.x, and I wonder if you might try the following: see if 6.4 will install, and if so, install it. Then cvsup 7.x, and do a buildworld but not an installworld. This will let you build and experiment with 7.x kernels from a known-working environment. Make sure to keep a working 6.x kernel around -- I suggest something like cp -r /boot/kernel /boot/kernel.good before starting so you can always fall back to a good kernel. Now try building a 7.x kernel without USB or firewire support, and booting that? Also, it's worth checking there are no BIOS upgrades available for the motherboard... Robert N M Watson Computer Laboratory University of Cambridge Hardware: Intel P9500 4gb DDR3-1066 Nvidia 9800M GT Atheros AR5006e FreeBSD 7.1-BETA2 These snippets of dmesg happen around the end where it hangs. 1. Default ... cpu0: ACPI CPU on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a02d40 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc68556e0), AE_AML_INTERNAL est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a0e300 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc685560), AE_AML_INTERNAL est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR Optiarc DVD RW AD-7560S/SX01 at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install
Re: Install issues with 7.x
Ryan skrev: Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. Hardware: Intel P9500 4gb DDR3-1066 Nvidia 9800M GT Atheros AR5006e FreeBSD 7.1-BETA2 These snippets of dmesg happen around the end where it hangs. 1. Default ... cpu0: ACPI CPU on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a02d40 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc68556e0), AE_AML_INTERNAL est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a0e300 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc685560), AE_AML_INTERNAL est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR Optiarc DVD RW AD-7560S/SX01 at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Disabling firewire completely in BIOS might at least get the machine booting. You should try that if you haven't already. I've seen this problem on at least two different systems... -- Joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can not wake on lan after halt -p (or shutdown -p now) on releng_7 and releng_7_0
://people.freebsd.org/~yongari/re/re.phy.patch.20081103 I tried your patch. Just to be sure that I did it correct - here are my steps: cd / patch /path/re.phy.patch.20081103 cd /sys/modules/re make all install reboot After reboot I shutdown the machine and try to wake it from another computer. Still WOL does not work. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Replication system
Hi all, I have to build a clustered website with FreeBSD 7.x as SO and Apache 2.x as httpd. As load-balancing solution I'll use HAProxy (or maybe a OpenBSD relayd, I'm not sure). Because of several technical (and especially non-technical) reasons, I haven't the possibility to mount a shared storage layer (NFS, SAN...) so I have to share the local data among the different httpd servers. At first approach I've thought in rsync+cron, but ¿anyone knows another replication-data solution in the described scenario? PD. Please, don't advice to me to using a pure shared-data layer... I know it will be the optimal structure, but as I've said above, I can't use it because various reasons. -- Thanks, Jordi Espasa Clofent ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Install issues with 7.x
Sadly with the quality of BIOS recently, that is not an option. Not much to offer. Attached is a picture of what I have to change. Other and XP are the same, Vista unlocks AHCI. Another way of accomplishing disabling firewire is to remake the install CD with a different kernel and not quite sure how to do that. On Mon, Nov 3, 2008 at 6:19 PM, Joel Dahl [EMAIL PROTECTED] wrote: Ryan skrev: Hello, I purchased a new Clevo M860TU on the account that it ran linux very well and was hoping it would fair the same on FreeBSD. Not so much, little help? I posted this in mobile originally but though stable would be a better choice. Don't know if it is more appropriate here or ACPI. I'm giving you as much information as I know how to get. as I cannot get sysinstall to load I am having to type all these dmesg. The boot process is hanging. This is all with 7.x, I can give 6.x if needed. Hardware: Intel P9500 4gb DDR3-1066 Nvidia 9800M GT Atheros AR5006e FreeBSD 7.1-BETA2 These snippets of dmesg happen around the end where it hangs. 1. Default ... cpu0: ACPI CPU on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a02d40 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU0._OSC] (Node 0xc68556e0), AE_AML_INTERNAL est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 cpu1: ACPI CPU on acpi0 ACPI Error (dsopcode-0350): No pointer back to NS node in buffer obj 0xc6a0e300 [20070320] ACPI Exception (dswexec-0556): AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] [20070320] ACPI Error (psparse-0626): Method parse/execution failed [\_PR_.CPU1._OSC] (Node 0xc685560), AE_AML_INTERNAL est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 ... cpu0: Cx states changed cpu1: Cx states changed unknown: timeout waiting for read DRQ unknown: timeout waiting for read DRQ acd0: DVDR Optiarc DVD RW AD-7560S/SX01 at ata3-master UDMA33 GEOM_LABEL: Label for provider acd0 is iso9660/FreeBSD_Install run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 120 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 180 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 240 seconds for xpt_config run_interrupt_driven_hooks: still waiting after 300 seconds for xpt_config Disabling firewire completely in BIOS might at least get the machine booting. You should try that if you haven't already. I've seen this problem on at least two different systems... -- Joel ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Replication system
On Mon, Nov 03, 2008 at 10:35:59PM +0100, Jordi Espasa Clofent wrote: I have to build a clustered website with FreeBSD 7.x as SO and Apache 2.x as httpd. As load-balancing solution I'll use HAProxy (or maybe a OpenBSD relayd, I'm not sure). Because of several technical (and especially non-technical) reasons, I haven't the possibility to mount a shared storage layer (NFS, SAN...) so I have to share the local data among the different httpd servers. At first approach I've thought in rsync+cron, but ¿anyone knows another replication-data solution in the described scenario? PD. Please, don't advice to me to using a pure shared-data layer... I know it will be the optimal structure, but as I've said above, I can't use it because various reasons. Try ggatec(8) and ggated(8). They perform replication at the filesystem level, over the network. I do not have experience using them. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Replication system
On Mon, Nov 3, 2008 at 10:35 PM, Jordi Espasa Clofent [EMAIL PROTECTED] wrote: Hi all, I have to build a clustered website with FreeBSD 7.x as SO and Apache 2.x as httpd. As load-balancing solution I'll use HAProxy (or maybe a OpenBSD relayd, I'm not sure). Because of several technical (and especially non-technical) reasons, I haven't the possibility to mount a shared storage layer (NFS, SAN...) so I have to share the local data among the different httpd servers. At first approach I've thought in rsync+cron, but ¿anyone knows another replication-data solution in the described scenario? PD. Please, don't advice to me to using a pure shared-data layer... I know it will be the optimal structure, but as I've said above, I can't use it because various reasons. -- Thanks, Jordi Espasa Clofent GlusterFS http://www.gluster.org seems promising. It is a replication layer that sits on top of FUSE (Filesystem in Userspace http://fuse.sf.net). You can replicate pretty much any type of file system, ufs, zfs, dos...etc. In other words, you don't need to reformat your disk or create some special underlying file system. GlusterFS is in userspace. However I have yet to get it working on freebsd. Anyone had any luck with GlusterFS on Freebsd 6.x? Michael Grant ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Replication system
On 04/11/2008, at 8:35 AM, Jordi Espasa Clofent wrote: At first approach I've thought in rsync+cron, but unison [1] works really well for us. In some ways it is better than some sort of shared SAN type solution since there is no single point of failure at the SAN or link to the SAN. Unison is just two way rsync so that changes can propagate in both directions between servers. Ari [1] http://www.cis.upenn.edu/~bcpierce/unison/ -- ish http://www.ish.com.au Level 1, 30 Wilson Street Newtown 2042 Australia phone +61 2 9550 5001 fax +61 2 9550 4001 GPG fingerprint CBFB 84B4 738D 4E87 5E5C 5EFA EF6A 7D2E 3E49 102A ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fifo log problem
At 11:48 AM 11/3/2008, Mike Tancsa wrote: At 11:34 AM 11/3/2008, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Mike Tancsa writes: Seems to work fine with cat Ok, and the loss is not from one end, it is random records in the middle ? Yes, they seem to initially get written and then tail off for some reason. I am not sure why. Actually, if I SIGHUP syslogd, it seems to make a difference, in that I can generally see when newsyslog sig HUPs syslog to do log rotation. Perhaps this is confusing things ? I tried changing the config so that there is only the fifo log being written to and disabled newsyslog so that syslogd is not getting a HUP signal. The strange thing is that reading from it gives different results?!? Sometimes doing [ps0278]# fifolog_reader all.fifo | wc From0 Wed Dec 31 19:00:00 1969 To 1225760679 Mon Nov 3 20:04:39 2008 Read from 1d800 59 4133068 0[ps0278]# and a exactly for 1min it will show the correct results 0[ps0278]# fifolog_reader all.fifo | wc From0 Wed Dec 31 19:00:00 1969 To 1225760538 Mon Nov 3 20:02:18 2008 Read from 0 10765 75995 556816 0[ps0278]# and then go back to showing just a subset for 4 min. I am guessing this coincides with when the flush runs This is a nanobsd image, so /var on /dev/md1 and RELENG_7 from a few days ago I have been running #!/bin/sh i=0 while true do i=`expr $i + 1` logger $i echo $i sleep 1 done and they seem to be there when it shows all the results, but for the most part it just shows a subset ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
DL360 G3 w/ AMD64 Cant boot from CD
Hello, I am trying to install FreeBSD on my HP DL360 G3 server with 8GB of ram. I need to use the AMD64 distribution, as I understand, to utilize over 4GB of ram. Unfortunately I cannot boot from any of the FreeBSD CDs : 7.0-RELEASE-AMD64 6.3-RELEASE-AMD64 I will try 8.0-CURRENT-AMD64, however I don't think it will matter. Since I'm not using unusual hardware, but rather hardware that has been established at least since 2003, I was hoping that someone else may have encountered this problem. If anyone can assist me , it would be greatly appreciated. The specific error message is as follows : int=000d err= efl=00010006 eip=000219b2 eax=000219ac ebx= ecx=c080 edx=0006d948 esi=0003e007 edi= ebp=000940bc esp=0009e088 cs=0008 ds=0010fs=0010 gs=0010 ss=0010 cs:eip=0f 32 0d 00 01 00 00 0f-30 0f 20 e0 83 c8 30 0f 22 e0 b8 00 c0 03 00 0f-22 d8 0f 20 c0 0d 00 00 Ss:eso=90 95 00 00 00 80 fc 00-00 90 fc 00 07 e0 03 00 00 00 00 00 07 d0 03 00-00 00 00 00 3c d9 06 00 BTX halted The above happens /JUST/ after pressing enter at the boot screen when booting from the FreeBSD cd. Thanks, Kevin K. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: DL360 G3 w/ AMD64 Cant boot from CD
On Mon, Nov 03, 2008 at 11:27:13PM -0500, Kevin wrote: Hello, I am trying to install FreeBSD on my HP DL360 G3 server with 8GB of ram. I need to use the AMD64 distribution, as I understand, to utilize over 4GB of ram. Unfortunately I cannot boot from any of the FreeBSD CDs : 7.0-RELEASE-AMD64 6.3-RELEASE-AMD64 I will try 8.0-CURRENT-AMD64, however I don't think it will matter. Since I'm not using unusual hardware, but rather hardware that has been established at least since 2003, I was hoping that someone else may have encountered this problem. If anyone can assist me , it would be greatly appreciated. Can you please try 7.1-PRERELEASE or 6.4-RC2 (just announced today)? There have been bootstrap-related changes since 7.0-RELEASE which may fix your problem. The specific error message is as follows : int=000d err= efl=00010006 eip=000219b2 eax=000219ac ebx= ecx=c080 edx=0006d948 esi=0003e007 edi= ebp=000940bc esp=0009e088 cs=0008 ds=0010fs=0010 gs=0010 ss=0010 cs:eip=0f 32 0d 00 01 00 00 0f-30 0f 20 e0 83 c8 30 0f 22 e0 b8 00 c0 03 00 0f-22 d8 0f 20 c0 0d 00 00 Ss:eso=90 95 00 00 00 80 fc 00-00 90 fc 00 07 e0 03 00 00 00 00 00 07 d0 03 00-00 00 00 00 3c d9 06 00 BTX halted The above happens /JUST/ after pressing enter at the boot screen when booting from the FreeBSD cd. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Replication system
On Mon, 03 Nov 2008 22:35:59 +0100
Jordi Espasa Clofent [EMAIL PROTECTED] wrote:
Hi all,
Hola Jordi,
I have to build a clustered website with FreeBSD 7.x as SO and Apache
2.x as httpd. As load-balancing solution I'll use HAProxy (or maybe a
OpenBSD relayd, I'm not sure).
you may want to look into carp as well if you don't want to have a separate
layer of load balancers.
Because of several technical (and especially non-technical) reasons, I
haven't the possibility to mount a shared storage layer (NFS, SAN...) so
I have to share the local data among the different httpd servers.
At first approach I've thought in rsync+cron, but
__anyone knows another replication-data solution in the described scenario?
rsync / rsyncd is simple and works. But it really depends on how often you'll
be publishing to your site, how big are the change sets
( consider publishing to a separate directory via rsync and then doing an
atomic rename/move if the change set is too big.)
we used to publish from AU to NL to dir1 in server1 , then ssh to server1 and
rsync to server2-n in parallel - all from a script of course. That way, the
slow link ( AU - NL) never got in the way of the publish.
B
_
{Beto|Norberto|Numard} Meijome
He could be a poster child for retroactive birth control.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
