Ugly black bars in dialog processor
Will it be likely/possible that the dialog processor in the base will be updated to include the fixes that have already appeared in the cdialog port? This has been an issue since day one or 13.0-CURRENT. Thanks for any assistance that you can provide. David Boyd. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unable to build 12.0-STABLE release
On Fri, 2018-12-28 at 15:42 +, Glen Barber wrote: > On Thu, Dec 27, 2018 at 11:31:55PM -0500, David Boyd wrote: > > While attempting to build 12.0-STABLE release images, the following > > error message sequence occurs: > > > > make[2]: don't know how to make CHECKSUM.SHA512-FreeBSD-12.0- > > STABLE- > > amd64.asc. Stop. > > > > make[2]: stopped in /usr/doc/en_US.ISO8859-1/htdocs/releases/12.0R > > *** Error code 2 > > > > Stop. > > make[1]: stopped in /usr/src/release > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src/release > > > > The build of 12.0-RELEASE release images was successful. > > > > The only change made to release.conf.sample was > > CHROOTDIR="/u/1/scratch". > > > > The host is 12.0-RELEASE-p1. > > > > I don't have a log of the build, but will acquire one if that would > > be > > useful. > > > > I know why it is failing (missing CHECKSUM.*-STABLE*.asc > files). Please > try again after doc revision r52735, which seems to be the correct > fix. > > Thank you for the report. > > Glen > Glen, I was able to try r52735 yesterday. It appears to have fixed my problem. Thanks. David ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Unable to build 12.0-STABLE release
On Fri, 2018-12-28 at 15:42 +, Glen Barber wrote: > On Thu, Dec 27, 2018 at 11:31:55PM -0500, David Boyd wrote: > > While attempting to build 12.0-STABLE release images, the following > > error message sequence occurs: > > > > make[2]: don't know how to make CHECKSUM.SHA512-FreeBSD-12.0- > > STABLE- > > amd64.asc. Stop. > > > > make[2]: stopped in /usr/doc/en_US.ISO8859-1/htdocs/releases/12.0R > > *** Error code 2 > > > > Stop. > > make[1]: stopped in /usr/src/release > > *** Error code 1 > > > > Stop. > > make: stopped in /usr/src/release > > > > The build of 12.0-RELEASE release images was successful. > > > > The only change made to release.conf.sample was > > CHROOTDIR="/u/1/scratch". > > > > The host is 12.0-RELEASE-p1. > > > > I don't have a log of the build, but will acquire one if that would > > be > > useful. > > > > I know why it is failing (missing CHECKSUM.*-STABLE*.asc > files). Please > try again after doc revision r52735, which seems to be the correct > fix. > > Thank you for the report. > > Glen > Glen, Thanks for the quick reply. I won't be able to give this a try until tomorrow. David. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Unable to build 12.0-STABLE release
While attempting to build 12.0-STABLE release images, the following error message sequence occurs: make[2]: don't know how to make CHECKSUM.SHA512-FreeBSD-12.0-STABLE- amd64.asc. Stop. make[2]: stopped in /usr/doc/en_US.ISO8859-1/htdocs/releases/12.0R *** Error code 2 Stop. make[1]: stopped in /usr/src/release *** Error code 1 Stop. make: stopped in /usr/src/release The build of 12.0-RELEASE release images was successful. The only change made to release.conf.sample was CHROOTDIR="/u/1/scratch". The host is 12.0-RELEASE-p1. I don't have a log of the build, but will acquire one if that would be useful. Thanks. David. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
release build fails due to mesa-libs python version mismatch
When attempting to build releng/11.2 (11.2-RELEASE-p6) via the release.sh process, the build fails with the following message: "mesa-libs-18.1.9 needs Python 2.7 at most, but 3.6 was specified" I was attempting to build using PORTBRANCH="ports/branches/2018Q4". Building with PORTBRANCH="ports/branches/2018Q3" works normally. The release process also fails if PORTBRANCH="ports/head@rHEAD" is used. Specifying NOPORTS=yes also allows the build to complete normally, but forces NODOC. Thanks, in advance, for any help that you may be able to provide. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
VM image for 11.1-STABLE exhibiting same problem as 12.0-CURRENT. MFC?
VM image for 11.1-STABLE began exhibiting same dislike for USB 3.0 ports as problem reported in PR 225794 for 12.0-CURRENT. Prior to FreeBSD-11.1-STABLE-amd64-20180215-r329320.vmdk.xz no such problem was observed. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
11.1-STABLE Images
All, There is no link from the web site to the 11.1-STABLE images. 10.4-STABLE and 12.0-CURRENT are present. Thanks. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
[REVISED] Panic with FreeBSD 11.1-RC2 VM-IMAGE when starting vboxservice
With latest VM-IMAGE (vmdk) for 11.1-RC2 system panics. I haven't been able to process the panic completely, but the backtrace looks mysteriously similar to those provided with PR219146. Initially, the VM-IMAGE booted just fine. The VM-IMAGE is then configured as a VirtualBox client. The panic occurs on subsequent reboots when attempting to start vboxservice. Additionally, during the custom configuration process, lsof hangs for more than 2 minutes each time that it is invoked. Please let me know exactly what information is needed to correct this problem. I will be able to provide that information no later than Tuesday morning. Thanks, in advance, for your assistance. David Boyd. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Panic with FreeBSD 11.0-RC2 VM-IMAGE when starting vboxservice
With latest VM-IMAGE (vmdk) for 11.1-RC2 system panics. I haven't been able to process the panic completely, but the backtrace looks mysteriously similar to those provided with PR219146. Initially, the VM-IMAGE booted just fine. The VM-IMAGE is then configured as a VirtualBox client. The panic occurs on subsequent reboots when attempting to start vboxservice. Additionally, during the custom configuration process, lsof hangs for more than 2 minutes each time that it is invoked. Please let me know exactly what information is needed to correct this problem. I will be able to provide that information no later than Tuesday morning. Thanks, in advance, for your assistance. David Boyd. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Regression in pciconf utility in releng/11.0
-Original Message-From: David Boyd <david.boy...@twc.com> To: freebsd-stable@freebsd.org Subject: Regression in pciconf utility in releng/11.0 Date: Wed, 28 Dec 2016 10:14:57 -0500 pciconf -lv em0@pci0:6:0:0: returns the following error: pciconf: cannont parse selector em0:pci0:6:0:0: This is contrary to the man page documentation which specifies that the trailing colon is optional and ignored. I have verified that this worked properly (as documented) in releng/10.3. A diff of pciconf.c between releng/11.0 and releng/10.3 show that the "parsesel" function received a major rewrite. Thanks. If I should submit a PR, just let me know. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Regression in pciconf utility in releng/11.0
pciconf -lv em0@pci0:6:0:0: returns the following error: pciconf: cannont parse selector em0:pci0:6:0:0: This is contrary to the man page documentation which specifies that the trailing colon is optional and ignored. I have verified that this worked properly (as documented) in releng/10.3. A diff of pciconf.c between releng/11.0 and releng/10.3 show that the "parsesel" function received a major rewrite. Thanks. If I should submit a PR, just let me know. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11.0-RC1 regression with regard to mouse integration in VirtualBox 5.1.4
-Original Message-From: Karl Denninger <k...@denninger.net> To: freebsd-stable@freebsd.org Subject: Re: FreeBSD 11.0-RC1 regression with regard to mouse integration in VirtualBox 5.1.4 Date: Tue, 23 Aug 2016 13:05:54 -0500 On 8/23/2016 12:48, David Boyd wrote: > Using FreeBSD 10.3-RELEASE-p6 with virtualbox-guest-additions 5.0.26 on > VirtualBox 5.1.4 (CentOS EL7 host) as a baseline I didn't experience any > difficulties. > > After fresh install of FreeBSD 11.0-RC1 with virtualbox-guest-additions > 5.0.26 on VirtualBox 5.1.4 (CentOS EL7 host) mouse integration is > missing. > > I have time and resources to test any changes you have to suggest. > > Thanks. > Does the mouse normally attach as what appears to be a USB port? If so the problem is likely here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211884 The mouse is attached to the host via usb (wireless). Unlike PR211884 there is not any problem with mouse operation once the mouse is captured by the guest. It is only mouse integration which appears to be affected. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 11.0-RC1 regression with regard to mouse integration in VirtualBox 5.1.4
Using FreeBSD 10.3-RELEASE-p6 with virtualbox-guest-additions 5.0.26 on VirtualBox 5.1.4 (CentOS EL7 host) as a baseline I didn't experience any difficulties. After fresh install of FreeBSD 11.0-RC1 with virtualbox-guest-additions 5.0.26 on VirtualBox 5.1.4 (CentOS EL7 host) mouse integration is missing. I have time and resources to test any changes you have to suggest. Thanks. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
unbound-control-setup missing from 10.3-RC1 media
/usr/sbin/unbound-control-setup is missing from the 10.3-RC1 release media (at least disc1.iso and memstick.img). I have filed PR 207748 reporting this. ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
AUTOFS (automount) and NFS server not playing together nicely
At the risk of being dubbed insane, here goes: On five FreeBSD 10.1-RELEASE-p9 production servers autofs(5) is enabled and working as advertised. On the same servers nfs v3 clients are also fat, dumb and happy. On a test server where autofs(5) is also enabled and working well, I am testing nfs v3 (later v4) server. Strange things are happening. When nfs mountd(8) is running, the autofs(5) auto-mount (via automountd) function seems to work, but the autofs(5) auto-unmount (via autounmountd) never occurs. Without nfs mountd(8), when the filesystem /disc is auto-mounted (via autoumountd), the mount(8) command shows status of (ufs, local, journaled soft-updates, auto-mounted) for the auto-mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted (via autounmountd). No problem. With nfs mountd(8) the mount(8) command shows (ufs, local, journaled soft-updates). The auto-mounted filesystem is never (a long, long time) unmounted. Big problem. Without nfs mountd(8) running, the mount(8) command mount -o automounted /dev/ada0p8 /disc mounts the filesystem and the mount(8) command shows (ufs, local, journaled soft-updates, automounted) for the manually mounted filesystem and after the autofs(5) timeout period (600 seconds) the filesystem is auto-unmounted even though it was not mounted automatically. No problem. With nfs mountd(8), the mount(8) command mount -o automounted /dev/ada0p8 /disc mounts the filesystem but the mount(8) command shows (ufs, local, journaled soft-updates) and after the timeout period (600 seconds) the filesystem is remains mounted. Big problem. It appears that nfs mountd(8) is interferring with the mount(8) command's -o option processing but admittedly that is just a very weak SWAG. I have adequate hardware (real and virtual) to do any testing that may be suggested. Most days there is no time constraint either. The /etc/auto_master file is two lines: 1:/net -hosts -nobrowse,nosuid(original) 2:/-/etc/autofs/auto_disc The /etc/autofs/auto_disc file is one line: 1:/disc -fstype=ufs :/dev/ada0p8 Once again, everything works well when nfs mountd(8) is not present in the system. Thanks for any assistance that you may be able to supply. David Boyd. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
AAC regression in 9.2-BETA
I have an Adaptec 2820SA (SATA) controller that hangs the system during booting on 9.2-BETA[12]. The only message I see on the console refers to controller aac0 and indicates TIMEOUT 138 SECONDS. This same controller/motherboard works flawlessly with 9.1-RELEASE-p5. I have moved this hardware to testing mode and can rebuild often. I am asking for direction and suggestions as to which commits might be at fault. I am sorry that I didn't detect this problem earlier in the release cycle. Hope we can resolve this before 9.2-RELEASE. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
r239739 needs committing for 9.1
r239739 (share/doc/smm/Makefile) fixes a regression in 9.x. John Baldwin submitted this fix in August. Please commit this fix before 9.1-RELEASE. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
systutils/arcconf errors on 9.x versions
Back in July, this error was discussed briefly on the mailing list(s). It appears that a fix (r238182) was submitted for inclusion in 9.1 (early). This problem still appears in 9.1-RC1. Will the fix be included in 9.1-RELEASE (or better yet 9.1-RC2)? Thanks. David Boyd. -- 1st e-mail from pluknet responding to Sergey Kandaurov -- On 6 July 2012 14:49, Serg R serg...@mail.ru wrote: Hi! There is a problem with running the Adaptec Storage Manager in freebsd 9. # uname -a FreeBSD sorgo 9.0-STABLE FreeBSD 9.0-STABLE #4: Thu May 31 13:39:39 SAMT 2012 root@sorgo:/usr/obj/usr/src/sys/SORGO amd64 # portversion -v | grep arc arcconf-v7.30.18837 = up-to-date with port # arcconf Undefined symbol __collate_load_error referenced from COPY relocation in /usr/local/sbin/arcconf This is probably because the private symbol __collate_load_error changed to macro (i.e. removed) in r235785 after 9.0. If so, it might brake those older binaries which rely on that symbol, though it's still defined in Symbol.map. Probably David Chisnall could further comment on this. -- wbr, pluknet -- 2nd e-mail from David Chisnall responding to Sergey Kandaurov -- On 6 Jul 2012, at 20:32, Sergey Kandaurov wrote: This is probably because the private symbol __collate_load_error = changed to macro (i.e. removed) in r235785 after 9.0. If so, it might brake = those older binaries which rely on that symbol, though it's still defined in Symbol.map. Probably David Chisnall could further comment on this. This was accidentally removed in the xlocale refactoring. I've restored = it in r238182 and CC'd re@ for permission to merge to the 9.1 release = branch. David= ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.1-RC1 make buildworld with WITHOUT_LPR NO_LPR not cleaning up properly
/etc/make.conf contains NO_LPR=YES /etc/src.conf contains WITHOUT_LPR=YES make buildworld consistently (9.0 through 9.1-RC1) leaves /usr/share/doc/smm/07.lpd/paper.ascii.gz which is then deleted by make delete-old. This behaviour was not apparent in 8.x. I have systems available to test a fix. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
9.x with NO_LPR
When building 9.1-BETA1 (for instance) despite having NO_LPR in /etc/make.conf, build process asks to remove /usr/share/doc/smm/07.lpd/paper.acsii.gz every time. I think this happens during make delete-old. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
current status of digi driver
While attempting to upgrade our comm servers from 7.4-RELEASE to 8.2-RELEASE, I discovered that the digi driver didn't make the grade. I searched the archives and found discussions in August 2008 concerning drivers that were disconnected for lack of MPSAFEness. The threads continued right up to the point where it was agreed that the drivers shouldn't be allowed to halt/delay the MPSAFE switch in 8.0-RELEASE. It appears that there was also agreement that (at least) some of the drivers, digi included, would be converted soon after 8.0-RELEASE. The pre-MPSAFE code appears to be included in the most recent -STABLE and -CURRENT, but doesn't get built. The HARDWARE.TXT still includes digi among supported multiport serial device drivers. Is there any plan to bring digi forward? We have about 55 modem ports over ten 8-port Xr cards (PCI) that connect remote sites via dial-up. These work perfectly with 7.4-RELEASE. We would like to see them work perfectly with 8.x-RELEASE or 9.x-RELEASE. I have time and hardware to test with and can help as needed. Thoughts? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
sysinstall.8 update to reflect improved use of netDev for scripted installs
Would it be possible to update the man page for sysinstall to reflect the new and improved usage for the netDev variable. This functionality is important (to me and my users) and seems to bear documenting. I realize that there may not be many users of scripted installs who care about this, so even a reference to the source code in sysinstall/tcpip.c would be acceptable. /* * netDev can be set to several types of values. * If netDev is set to ANY, scan all network devices * looking for a valid link, and go with the first * device found. netDev can also be specified as a * comma delimited list, with each network device * tried in order. netDev can also be set to a single * network device. */ There are two places in sysinstall.8 where the usage of netDev is described. Thanks, in advance, for considering this request. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
6.4-RELEASE missing from mirrors
The link (actually file) called 6.4 moved to ftp-archive is missing from most/all mirrors. We have been using these files to follow the releases when they move. It works as long as the 6.4 moved to ftp-archive file is present. Please help. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.3-RELEASE make release requires wrong version of perl
Attempting make release results in error complaining that perl-5.8.9 installs into the same locations as perl-5.10.1. This seems similar to the problem I encountered with make release when NODOC was not set. The complaint then was that ghostscript8-nox11 installs into the same locations as ghostscrip8. Any help would be appreciated. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
7.3-RELEASE sysinstall netDev feature
The 7.3-RELEASE release notes indicate that sysinstall now supports a list of network interfaces in the netDev (install.cfg) parameter. After upgrading to 7.3-RELEASE (via csup) sysinstall does not seem to support that feature. Also, the man page doesn't contain any mention of the new feature. Is this the code committed by Rink Springer last October? This feature would sure be great for our many scripted installs (avoiding the hassles associated with plugging the cable into the wrong interface or having the interface type change unexpectedly due to hardware swaps). Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
6.4-RELEASE distribution missing link(s)
The 6.4-RELEASE distribution has apparently been move to ftp-archive but no indication of this is present on the mirrors. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
make release fails if ghostscript8-8.70 is installed
When attempting make release (7.3-PRERELEASE or 7.2-RELEASE or 8.0-RELEASE-p2) and ghostscript8-8.70 is installed on the build machine the following error occurs: === ghostscript8-nox11-8.70 conflicts with installed package(s): ghostscript8-8.70 They install files into the same place. Please remote them first with pkg_delete(1). *** Error code 1 Stop in /u/release/usr/ports/print/ghostscript8-nox11. *** Error code 1 Stop in /u/release/usr/ports/textproc/docproj. *** Error code 1 Stop in /var/cvsup/usr/src/release. *** Error code 1 Stop in /var/cvsup/usr/src/release. I can work around this by defining NODOC in /etc/make.conf or by deleting the ghostscipt8 package before running make release. I never had this problem in previous builds (6.4-RELEASE and 7.1-RELEASE). Is this expected/normal? Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
FW: 8.0-BETA2 sysinstall ignoring setting of nonInteractive
Can someone PLEASE commit this fix. Daniel was kind enough to write it up, but it has not been committed as of 8/3/2009. Thanks. -Original Message- From: Daniel O'Connor [mailto:docon...@gsoft.com.au] Sent: Tuesday, July 21, 2009 8:28 PM To: freebsd-curr...@freebsd.org Cc: David Boyd Subject: Re: 8.0-BETA2 sysinstall ignoring setting of nonInteractive On Wed, 22 Jul 2009, David Boyd wrote: With 8.0-BETA(1/2) sysinstall ignores setting of nonInteractive variable when using USB-based install. With or without nonInteractive sysinstall issues message Using USB device: da0a and waits for confirmation. This breaks unattended installations using USB device. I think this would fix it, can you test it? Index: media.c === --- media.c (revision 195813) +++ media.c (working copy) @@ -262,7 +262,8 @@ mediaDevice = devs[0]; if (mediaDevice) mediaDevice-private = NULL; - msgConfirm(Using USB device: %s, mediaDevice-name); + if (!variable_get(VAR_NONINTERACTIVE)) + msgConfirm(Using USB device: %s, mediaDevice-name); return (mediaDevice ? DITEM_LEAVE_MENU : DITEM_FAILURE); } -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C signature.asc Description: PGP signature ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
RE: Promise SX4060 on 7.1-BETA2
-Original Message- From: Andrey V. Elsukov [mailto:[EMAIL PROTECTED] Sent: Friday, October 24, 2008 00:23 To: David Boyd Cc: freebsd-stable@freebsd.org Subject: Re: Promise SX4060 on 7.1-BETA2 David Boyd wrote: I am attempting to install 7.1-BETA2 (from CD) onto a PC with a Promise SX4060 RAID controller and two Seagate 120GB ATA disk drives. Did you try to select Safe mode in boot menu or boot with ACPI disabled? Can you boot your system in verbose mode and show dmesg.boot? -- WBR, Andrey V. Elsukov Exactly the same result with Safe mode The system doesn't have an operating system on it. This is initial instal. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
RE: Promise SX4060 on 7.1-BETA2
- ---Original Message-
From: Søren Schmidt [mailto:[EMAIL PROTECTED]
Sent: Friday, October 24, 2008 02:30
To: Jeremy Chadwick
Cc: David Boyd; freebsd-stable@freebsd.org; Andrey V. Elsukov; Søren Schmidt
Subject: Re: Promise SX4060 on 7.1-BETA2
On Thu, Oct 23, 2008 at 9:03 PM, Jeremy Chadwick [EMAIL PROTECTED] wrote:
On Thu, Oct 23, 2008 at 02:01:55PM -0400, David Boyd wrote:
I am attempting to install 7.1-BETA2 (from CD) onto a PC with a Promise
SX4060 RAID controller and two Seagate 120GB ATA disk drives.
The boot from CD keeps repeating the following (error) messages: (I'm
retyping here)
{snip -- for dmesg errors, see URL below}
You're the second person to report this problem recently. The other
person (see below) reported the same thing, also using a PATA
controller, and also using Seagate disks (though different models).
We now have two reproducible test cases where users are seeing continual
errors from the controller when attempting to set the transfer mode,
enable read and write caching, and SET_MULTI. The only similarity so
far is that they're both PATA users.
In Kristian's case, his disks were in a usable state, but we ultimately
determine the Silicon Image controller might be responsible for what he
was seeing (the SMART errors we saw in his logs could've been from any
time in the past; he saw errors on multiple disks, and not all of those
disks shown SMART log errors)... while David's not using a Silicon Image
controller at all.
Kristian's setup:
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046023.html
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046027.html
Silicon Image 0680 ATA100 (problem was also seen on Promise PDC20270)
ad4: Seagate ST3320620A 3.AAF at ata2-master PIO4
ad5: Seagate ST3320620A 3.AAF at ata2-slave PIO4
ad6: Seagate ST3750640A 3.AAE at ata3-master PIO4
ad7: Seagate ST3320620A 3.AAD at ata3-slave PIO4
David's setup (what we know so far):
http://lists.freebsd.org/pipermail/freebsd-stable/2008-October/046140.html
Promise SX4060
ad4: 114473MB Seagate ST3120814A 3.AAJ at ata2-master PIO4
ad8: 114473MB Seagate ST3120814A 3.AAJ at ata4-master PIO4
Soren/Andrey, can either of you comment on this? If at all possible, it
would be good to get this hammered out before 7.1-RELEASE is tagged.
Does it work if booted on a 8-current kernel ?
The driver path's used by the SiI0680 and the SX4060 are *very* different,
mind you.
-Søren
I tried the 200810 8.0-CURRENT snapshot CD.
The error messages were approximately the the same until:
Fatal trap 12: page fault while in kernel mode
...
current process = 12 (swi6: task queue)
[thread pid 12 tid 100014 ]
Stopped atata_promise_sx4_command+0x39: movl 0xc(%eax),%esi
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Promise SX4060 on 7.1-BETA2
I am attempting to install 7.1-BETA2 (from CD) onto a PC with a Promise SX4060 RAID controller and two Seagate 120GB ATA disk drives. The boot from CD keeps repeating the following (error) messages: (I'm retyping here) == ad4: WARNING - SETFEATURES SET TRANSFER MODE task queue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE RCACHE task queue timeout - completing request directly ad4: WARNING - SETFEATURES ENABLE WCACHE task queue timeout - completing request directly ad4: WARNING - SET_MULTI task queue timeout - completing request directly ad4: FAILURE - READ timed out LBA=0 ad4: FAILURE - READ retrying (1 retry left) LBA=0 ad4: FAILURE - READ timed out LBA=0 ad4: FAILURE - READ retrying (0 retries left) LBA=0 ad4: FAILURE - SETFEATURES SET TRANSFER MODE timed out ad4: FAILURE - SETFEATURES ENABLE RCACHE timed out ad4: FAILURE - SETFEATURES ENABLE WCACHE timed out ad4: FAILURE - SETFEATURES SET_MULTI timed out ad4: 114473MB Seagate ST3120814A 3.AAJ at ata2-master PIO4 ad8: WARNING - SETFEATURES SET TRANSFER MODE task queue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE RCACHE task queue timeout - completing request directly ad8: WARNING - SETFEATURES ENABLE WCACHE task queue timeout - completing request directly ad8: WARNING - SET_MULTI task queue timeout - completing request directly ad8: FAILURE - READ timed out LBA=0 ad8: FAILURE - READ retrying (1 retry left) LBA=0 ad8: FAILURE - READ timed out LBA=0 ad8: FAILURE - READ retrying (0 retries left) LBA=0 ad8: FAILURE - SETFEATURES SET TRANSFER MODE timed out ad8: FAILURE - SETFEATURES ENABLE RCACHE timed out ad8: FAILURE - SETFEATURES ENABLE WCACHE timed out ad8: FAILURE - SETFEATURES SET_MULTI timed out ad8: 114473MB Seagate ST3120814A 3.AAJ at ata4-master PIO4 == and then these messages (and minor variants) keep repeating (I've let it go for at least one hour). I have about three dozen of these computers (from a failed M$ project) and would very much like to use them with FreeBSD. Any ideas? I'm game for almost anything. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic in 6.2-RC2
The following panic occurs every one to three hours with 6.2-RC2.
This is the same problem as kern/88472 which is still open.
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
7key_spddelete: no SP found.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x23
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc074fc0c
stack pointer = 0x28:0xd0a4e8f8
frame pointer = 0x28:0xd0a4e908
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 695 (isakmpd)
trap number = 12
panic: page fault
Uptime: 1h2m52s
Dumping 255 MB (2 chunks)
chunk 0: 1MB (159 pages) ... ok
chunk 1: 255MB (65216 pages) 239 223 207 191 175 159 143 127 111 95 79 63
47 31 15
#0 doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) by t
#0 doadump () at pcpu.h:165
#1 0xc068c76e in boot (howto=260) at
/var/cvsup/usr/src/sys/kern/kern_shutdown.c:409
#2 0xc068ca04 in panic (fmt=0xc08c386a %s)
at /var/cvsup/usr/src/sys/kern/kern_shutdown.c:565
#3 0xc08690b4 in trap_fatal (frame=0xd0a4e8b8, eva=35)
at /var/cvsup/usr/src/sys/i386/i386/trap.c:837
#4 0xc0868e1b in trap_pfault (frame=0xd0a4e8b8, usermode=0, eva=35)
at /var/cvsup/usr/src/sys/i386/i386/trap.c:745
#5 0xc0868a59 in trap (frame=
{tf_fs = -1035665400, tf_es = -1035665368, tf_ds = 40, tf_edi = 3,
tf_esi = -1037761536, tf_ebp = -794498808, tf_isp = -794498844, tf_ebx
= -1030032896, tf_edx = 1, tf_ecx = 1466671235, tf_eax = 3, tf_trapno = 12,
tf_err = 0, tf_eip = -1066075124, tf_cs = 32, tf_eflags = 66054, tf_esp = 0,
tf_ss = -1030032896}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:435
#6 0xc085712a in calltrap () at
/var/cvsup/usr/src/sys/i386/i386/exception.s:139
#7 0xc074fc0c in key_getsavbyspi (sah=0xc2250400, spi=1466671235)
at /var/cvsup/usr/src/sys/netkey/key.c:2977
#8 0xc07527cd in key_delete (so=0xc2452164, m=0xc29af200, mhp=0xd0a4ea64)
at /var/cvsup/usr/src/sys/netkey/key.c:5427
#9 0xc07548b9 in key_parse (m=0xc29af200, so=0xc2452164)
at /var/cvsup/usr/src/sys/netkey/key.c:7149
#10 0xc0756081 in key_output (m=0xc29af200, so=0xc2452164)
at /var/cvsup/usr/src/sys/netkey/keysock.c:119
#11 0xc07074b0 in raw_usend (so=0x576ba083, flags=0, m=0x1, nam=0x0,
control=0x3,
td=0xc22a6a80) at /var/cvsup/usr/src/sys/net/raw_usrreq.c:263
#12 0xc07565e7 in key_send (so=0xc2452164, flags=0, m=0xc29af200, nam=0x0,
control=0x0,
p=0xc22a6a80) at /var/cvsup/usr/src/sys/netkey/keysock.c:430
#13 0xc06c5863 in sosend (so=0xc2452164, addr=0x0, uio=0xc2602100,
top=0xc29af200,
control=0x0, flags=0, td=0xc22a6a80) at
/var/cvsup/usr/src/sys/kern/uipc_socket.c:836
#14 0xc06b40ee in soo_write (fp=0x3, uio=0xc2602100, active_cred=0xc2447480,
flags=0,
td=0xc22a6a80) at /var/cvsup/usr/src/sys/kern/sys_socket.c:118
#15 0xc06ae7f7 in dofilewrite (td=0xc22a6a80, fd=5, fp=0xc23a2288,
auio=0xc2602100, offset=
) at file.h:252
#16 0xc06ae69b in kern_writev (td=0xc22a6a80, fd=5, auio=0xc2602100)
at /var/cvsup/usr/src/sys/kern/sys_generic.c:402
#17 0xc06ae644 in writev (td=0xc22a6a80, uap=0xd0a4ed04)
at /var/cvsup/usr/src/sys/kern/sys_generic.c:388
#18 0xc08693cb in syscall (frame=
{tf_fs = 59, tf_es = -1078001605, tf_ds = -1078001605, tf_edi =
136368064, tf_esi = -1077941328, tf_ebp = -1077941224, tf_isp = -794497692,
tf_ebx = 5, tf_edx = 23, tf_ecx = 0, tf_eax = 121, tf_trapno = 0, tf_err =
2, tf_eip = 673519919, tf_cs = 51, tf_eflags = 582, tf_esp = -1077941364,
tf_ss = 59}) at /var/cvsup/usr/src/sys/i386/i386/trap.c:983
#19 0xc085717f in Xint0x80_syscall () at
/var/cvsup/usr/src/sys/i386/i386/exception.s:200
#20 0x0033 in ?? ()
(kgdb) q
The following messages are logged just before the panic.
Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: isakmpd: quick mode done: src:
xxx.xxx.xxx.xxx dst: yyy.yyy.yyy.yyy
Jan 6 00:34:28 vpn-gateway2 isakmpd[452]: pf_key_v2_set_spi: ADD: Invalid
argument
The other end of the connection is reported to be Cisco-based.
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic/Reboot in 5.4-STABLE
Panics occur as often as every few hours (usually once or twice a day) on eight identical systems used as VPN devices in hospital radiology appliance maintenance network. One other system running 4.10-RELEASE on Soekris Net4801 doesn't experience this problem. dmesg output: WARNING: pseudo-random number generator used for IPsec processing Fatal trap 12: page fault while in kernel mode fault virtual address = 0x23 fault code = supervisor read, page not present instruction pointer = 0x8:0xc06c9530 stack pointer = 0x10:0xcc7378f4 frame pointer = 0x10:0xcc737904 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 498 (isakmpd) trap number = 12 panic: page fault Uptime: 18h55m51s Dumping 255 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... Copyright (c) 1992-2005 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.4-STABLE #1: Fri Oct 14 10:37:20 EDT 2005 [EMAIL PROTECTED]:/usr/obj/var/cvsup/usr/src/sys/RADIOLOGY WARNING: debug.mpsafenet forced to 0 as ipsec requires Giant WARNING: MPSAFE network stack disabled, expect reduced performance. Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Pentium(R) 4 CPU 1500MHz (1496.34-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf07 Stepping = 7 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,M CA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 268173312 (255 MB) avail memory = 252772352 (241 MB) npx0: math processor on motherboard npx0: INT 16 interface acpi0: GATEWA N0CPP063 on motherboard acpi0: Power Button (fixed) Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 cpu0: ACPI CPU on acpi0 acpi_button0: Sleep Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82850 host to AGP bridge mem 0xf800-0xfbff at device 0.0 on pci0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 xl0: 3Com 3c905C-TX Fast Etherlink XL port 0xdc00-0xdc7f mem 0xff9ffc00-0xff9ffc7f irq 3 at device 10.0 on pci2 miibus0: MII bus on xl0 xlphy0: 3c905C 10/100 internal PHY on miibus0 xlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto xl0: Ethernet address: 00:04:76:bb:82:cc rl0: D-Link DFE-530TX+ 10/100BaseTX port 0xd800-0xd8ff mem 0xff9ff800-0xff9ff8ff irq 9 at device 11.0 on pci2 miibus1: MII bus on rl0 rlphy0: RealTek internal media interface on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:0d:88:35:27:a3 rl1: D-Link DFE-530TX+ 10/100BaseTX port 0xd400-0xd4ff mem 0xff9ff400-0xff9ff4ff irq 10 at device 12.0 on pci2 miibus2: MII bus on rl1 rlphy1: RealTek internal media interface on miibus2 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl1: Ethernet address: 00:0d:88:35:27:89 isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH2 UDMA100 controller port 0xffa0-0xffaf,0x376,0x170-0x177,0x3f6,0x1f0-0x1f7 at device 31.1 on pci0 ata0: channel #0 on atapci0 ata1: channel #1 on atapci0 uhci0: Intel 82801BA/BAM (ICH2) USB controller USB-A port 0xef40-0xef5f irq 5 at device 31.2 on pci0 usb0: Intel 82801BA/BAM (ICH2) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered pci0: serial bus, SMBus at device 31.3 (no driver attached) uhci1: Intel 82801BA/BAM (ICH2) USB controller USB-B port 0xef80-0xef9f irq 9 at device 31.4 on pci0 usb1: Intel 82801BA/BAM (ICH2) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: floppy drive controller port 0x3f7,0x3f4-0x3f5,0x3f2-0x3f3,0x3f0-0x3f1 irq 6 drq 2 on acpi0 fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0: 16550A-compatible COM port port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 sio0: type 16550A, console ppc0: ECP parallel printer port port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 orm0:
