Congratulations on the stable/13 release!
In case anyone's interested: for this morning's software maintenance session (at home) I upgraded my file server from FreeBSD stable/12 to the recently released stable/13. From source, in-place, on a running, on-line system. Despite the fact that the entire ZFS subsystem has been replaced, which is what caused me to wait for a couple of weeks, the upgrade appears to have been flawless. Not a single error message on boot-up. Not a single failed service. Everything is working perfectly. Zpool status told me that I should upgrade the pools, and did: that turned on a dozen or so new features that I'm sure are useful. Total downtime about a minute or so: just the time it took to reboot. I'm amazed. Good on the FreeBSD developers and (especially) the release engineers! cd /usr/src git switch stable/13 make -s -j20 buildworld kernel mergemaster -p make -s installworld mergemaster -U shutdown -r now zpool status zpool upgrade backup20 zpool upgrade root zpool upgrade tank Done! Cheers, Andrew ___ 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"
Upgrade-report: 12.1-RELEASE --> 12.2-RELEASE
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In a while I had not installed any package-upgrades, no idea how dns-resolving became de-registered, when that was solved by manually changing /etc/resolv.conf, sys-upgrade was a pure pleasure, it was so good, boring myself to death almost in the waiting-time, just perfect (inside the frame of today's possibilities, of course): [see my session transscipt:] https://attachment.irregulaire.info/FBSD12.1-upgrade-report.tx.xz Greetings, we need much more boredom and unspectacular software-upgrades, even system-upgrades without any regressions! -BEGIN PGP SIGNATURE- iF0EARECAB0WIQTF9uNaslvnJpWt8kXn6sEfJS3nCwUCYFC05gAKCRDn6sEfJS3n C43IAJ41TFeVeZ3TzWi0TBnItSU2fbRQ5ACeOHcObQYfhM6CSK1jEtf3Fpsxgfc= =0L9M -END PGP SIGNATURE- ___ 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: Curl giving (27) Out of memory error where it didn't before
Bother. Password leaked. Password changed. Thanks for the warning!
Cheers,
Andrew Reilly
M: 0409-824-272
arei...@bigpond.net.au
> On 15 Apr 2020, at 07:35 , Andrew Reilly wrote:
>
> Hi there,
>
> I have a cron job that is supposed to email me at a backup email account if
> my ISP ever changes my IP address. It doesn't happen very often, but it
> happened again this morning, and I was disappointed to find that the script
> that does the notification failed.
>
> Sending e-mail in this way requires SSL connection to my ISP's mail server
> (smtp.bigpond.com) and authentication, and I was pleased to discover, a while
> back, that curl can handle both of those details, as well as sending email.
> So I use this script (edited to elide passwords and addresses):
> email-myself.sh:
> #!/bin/sh
> /usr/local/bin/curl -v -T- --ssl-reqd smtps://smtp.bigpond.com --mail-from
> arei...@bigpond.net.au --mail-rcpt backup_addr...@me.com --mail-auth
> arei...@bigpond.net.au --user arei...@bigpond.net.au:password < From: Andrew Reilly
> To: Andrew Reilly
> Subject: $1
> Date: $(date -R)
>
> $2
> END
>
> As I said, previously that has worked perfectly, but today I'm getting the
> following in my logs (thanks to having verbose output turned on):
>
> % Total% Received % Xferd Average Speed TimeTime Time Current
> Dload Upload Total SpentLeft Speed
> 0 00 00 0 0 0 --:--:-- 0:00:05 --:--:--
> 0* Trying 203.36.137.240:465...
> * Connected to smtp.bigpond.com (203.36.137.240) port 465 (#0)
> * successfully set certificate verify locations:
> * CAfile: /usr/local/share/certs/ca-root-nss.crt
> CApath: none
> } [5 bytes data]
> * TLSv1.3 (OUT), TLS handshake, Client hello (1):
> } [512 bytes data]
> * TLSv1.3 (IN), TLS handshake, Server hello (2):
> { [91 bytes data]
> * TLSv1.2 (IN), TLS handshake, Certificate (11):
> { [4836 bytes data]
> * TLSv1.2 (IN), TLS handshake, Server key exchange (12):
> { [333 bytes data]
> * TLSv1.2 (IN), TLS handshake, Server finished (14):
> { [4 bytes data]
> * TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
> } [70 bytes data]
> * TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
> } [1 bytes data]
> * TLSv1.2 (OUT), TLS handshake, Finished (20):
> } [16 bytes data]
> * TLSv1.2 (IN), TLS handshake, Finished (20):
> { [16 bytes data]
> * SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
> * Server certificate:
> * subject: C=AU; ST=Victoria; L=Melbourne; O=Telstra Corporation Limited;
> OU=Technology Product Ownership CH10; CN=mail.bigpond.com
> * start date: Jan 23 03:57:06 2020 GMT
> * expire date: Jan 23 04:07:00 2022 GMT
> * subjectAltName: host "smtp.bigpond.com" matched cert's "smtp.bigpond.com"
> * issuer: C=BM; O=QuoVadis Limited; CN=QuoVadis Global SSL ICA G2
> * SSL certificate verify ok.
> { [5 bytes data]
> < 220 smtp.telstra.com ESMTP Service ready
> } [5 bytes data]
>> EHLO Zen
> { [5 bytes data]
> < 250-smtp.telstra.com
> < 250-8BITMIME
> < 250-PIPELINING
> < 250-HELP
> < 250-AUTH=LOGIN
> < 250-AUTH LOGIN PLAIN
> < 250-DELIVERBY 300
> < 250 SIZE 3000
> } [5 bytes data]
>> AUTH PLAIN
> { [5 bytes data]
> < 334 ?
> } [5 bytes data]
>> AGFyZWlsbHlAYmlncG9uZC5uZXQuYXUARnJhaGFuMHc=
> { [5 bytes data]
> < 235 PLAIN authentication successful
> 0 00 00 0 0 0 --:--:-- 0:00:05 --:--:-- 0
> } [5 bytes data]
>> QUIT
> { [5 bytes data]
> < 221 smtp.telstra.com QUIT
> * Closing connection 0
> } [5 bytes data]
> * TLSv1.2 (OUT), TLS alert, close notify (256):
> } [2 bytes data]
> curl: (27) Out of memory
>
> That looks to me as though the SSL setup worked fine, then the AUTH fine,
> then the message transfer all fine, and quitting too. So everything was
> fine, but then curl crashed with error 27 "out of memory", and I haven't
> received any messages.
>
> The web thinks that the two most likely ways for an out-of-date shared
> library linkage or a not-thread-safe programming bug. So I used portmaster
> -f to rebuild curl and all its dependencies, and it still crashes exactly as
> shown.
>
> The computer in question is running: (uname -a)
> FreeBSD Zen.local 12.1-STABLE FreeBSD 12.1-STABLE r359760 GENERIC amd64
>
> and has 32G of RAM and eight two-thread AMD 1700 cores.
>
> Any suggestions?
>
> Andrew Reilly
> M: 0409-824-272
> arei...@bigpond.net.au
>
>
>
> ___
> 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-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Curl giving (27) Out of memory error where it didn't before
Hi there,
I have a cron job that is supposed to email me at a backup email account if my
ISP ever changes my IP address. It doesn't happen very often, but it happened
again this morning, and I was disappointed to find that the script that does
the notification failed.
Sending e-mail in this way requires SSL connection to my ISP's mail server
(smtp.bigpond.com) and authentication, and I was pleased to discover, a while
back, that curl can handle both of those details, as well as sending email. So
I use this script (edited to elide passwords and addresses):
email-myself.sh:
#!/bin/sh
/usr/local/bin/curl -v -T- --ssl-reqd smtps://smtp.bigpond.com --mail-from
arei...@bigpond.net.au --mail-rcpt backup_addr...@me.com --mail-auth
arei...@bigpond.net.au --user arei...@bigpond.net.au:password <
To: Andrew Reilly
Subject: $1
Date: $(date -R)
$2
END
As I said, previously that has worked perfectly, but today I'm getting the
following in my logs (thanks to having verbose output turned on):
% Total% Received % Xferd Average Speed TimeTime Time Current
Dload Upload Total SpentLeft Speed
0 00 00 0 0 0 --:--:-- 0:00:05 --:--:-- 0*
Trying 203.36.137.240:465...
* Connected to smtp.bigpond.com (203.36.137.240) port 465 (#0)
* successfully set certificate verify locations:
* CAfile: /usr/local/share/certs/ca-root-nss.crt
CApath: none
} [5 bytes data]
* TLSv1.3 (OUT), TLS handshake, Client hello (1):
} [512 bytes data]
* TLSv1.3 (IN), TLS handshake, Server hello (2):
{ [91 bytes data]
* TLSv1.2 (IN), TLS handshake, Certificate (11):
{ [4836 bytes data]
* TLSv1.2 (IN), TLS handshake, Server key exchange (12):
{ [333 bytes data]
* TLSv1.2 (IN), TLS handshake, Server finished (14):
{ [4 bytes data]
* TLSv1.2 (OUT), TLS handshake, Client key exchange (16):
} [70 bytes data]
* TLSv1.2 (OUT), TLS change cipher, Change cipher spec (1):
} [1 bytes data]
* TLSv1.2 (OUT), TLS handshake, Finished (20):
} [16 bytes data]
* TLSv1.2 (IN), TLS handshake, Finished (20):
{ [16 bytes data]
* SSL connection using TLSv1.2 / ECDHE-RSA-AES128-GCM-SHA256
* Server certificate:
* subject: C=AU; ST=Victoria; L=Melbourne; O=Telstra Corporation Limited;
OU=Technology Product Ownership CH10; CN=mail.bigpond.com
* start date: Jan 23 03:57:06 2020 GMT
* expire date: Jan 23 04:07:00 2022 GMT
* subjectAltName: host "smtp.bigpond.com" matched cert's "smtp.bigpond.com"
* issuer: C=BM; O=QuoVadis Limited; CN=QuoVadis Global SSL ICA G2
* SSL certificate verify ok.
{ [5 bytes data]
< 220 smtp.telstra.com ESMTP Service ready
} [5 bytes data]
> EHLO Zen
{ [5 bytes data]
< 250-smtp.telstra.com
< 250-8BITMIME
< 250-PIPELINING
< 250-HELP
< 250-AUTH=LOGIN
< 250-AUTH LOGIN PLAIN
< 250-DELIVERBY 300
< 250 SIZE 3000
} [5 bytes data]
> AUTH PLAIN
{ [5 bytes data]
< 334 ?
} [5 bytes data]
> AGFyZWlsbHlAYmlncG9uZC5uZXQuYXUARnJhaGFuMHc=
{ [5 bytes data]
< 235 PLAIN authentication successful
0 00 00 0 0 0 --:--:-- 0:00:05 --:--:-- 0
} [5 bytes data]
> QUIT
{ [5 bytes data]
< 221 smtp.telstra.com QUIT
* Closing connection 0
} [5 bytes data]
* TLSv1.2 (OUT), TLS alert, close notify (256):
} [2 bytes data]
curl: (27) Out of memory
That looks to me as though the SSL setup worked fine, then the AUTH fine, then
the message transfer all fine, and quitting too. So everything was fine, but
then curl crashed with error 27 "out of memory", and I haven't received any
messages.
The web thinks that the two most likely ways for an out-of-date shared library
linkage or a not-thread-safe programming bug. So I used portmaster -f to
rebuild curl and all its dependencies, and it still crashes exactly as shown.
The computer in question is running: (uname -a)
FreeBSD Zen.local 12.1-STABLE FreeBSD 12.1-STABLE r359760 GENERIC amd64
and has 32G of RAM and eight two-thread AMD 1700 cores.
Any suggestions?
Andrew Reilly
M: 0409-824-272
arei...@bigpond.net.au
___
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: Samba version in ports
> On 14 Mar 2020, at 12:56 , Andrew Reilly wrote: > > By the way, the current Samba stable release is 4.12.0 (one week old) and > 4.11.0 was released last September. Is there some particular incompatibility > with FreeBSD that is keeping these out of Ports? I got quite close to trying > to build the newer version myself, but then the problem went away... OK, I've just had a closer look at the several-dozen patch files, and tried a couple of compilation attempts at 4.11.7, and concede that getting this into shape is more work than I have time for today. Sigh. Best of luck to the maintainer. Cheers, Andrew Reilly M: 0409-824-272 arei...@bigpond.net.au ___ 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: Long-shot: repeatable macOS samba share unmounting during Lightroom import
HI again, You might remember my Samba-related cry for help, last November. I'm writing again to report that the problem has been resolved on my systems, as near as I can tell. Perhaps my experience will help others. The "fix" has come as a result of some changes to my filesystem structure that I made as a result of a recent drive replacement (the 1.8T of photos from my last trip ran me out of storage). The upshot of that is that I don't know whether my previous troubles were misconfiguration on my part, or some sort of subtle bug in any of the players at the table: Samba on FreeBSD on ZFS or macOS Catalina's smbfs. After some experimentation I was able to conclude that Lightroom itself was unlikely to be the root problem: failure was easily repeatable with a find in a macOS terminal session. Quick summary of the problem: macOS Catalina would silently and seemingly-spontaneously disconnect from my Samba filesystems, exported from my FreeBSD-12-STABLE server when doing any activity that listed or stat-ed all of the files in a directory of some thousands. To make matters worse, before the macOS 10.15.3 release, this disconnection would leave the smbfs driver, or some other macOS kernel state broken, and it would not be possible to re-mount or properly eject the failed mount without a reboot. Since I was rebooting a lot, Apple were getting a lot of crash dumps from me, and their 10.15.3 release seems to have fixed whatever was stuck in the kernel - reboots were no longer required - but the disconnection problem persisted. I have a couple of users on the file server, with the usual home directories in /home/ and these were exported using Samba's [homes] configuration stanza, in the usual fashion. I also had a shared directory, at /home/us, which was exported by a separate Samba stanza with an explicit path = /home/us, because "us" isn't a user. When the drives filled up and I installed a new set, since I was going to restore from backups I took the opportunity to create a new zfs file system for "us" (/tank/us), and tweaked the smb4.conf accordingly. That seems to have returned the file systems/server/macOS combination to robust good health. I have not experienced a spontaneous-unmount since that change, and nothing else about the configuration has changed. My guess: SMB2 enhanced security rules, which Samba enforces, insist that each host can only log-in/mount a given share once: any secondary mount attempt should cause the server to drop all mounts. (Sorry, I can't remember which reference site pointed that out to me.) Perhaps Samba is interpreting the rule on the basis of underlying host-side filesystem structure? That would put the old /home/us and /home/uname shares on the same filesystem, and trigger the security rule? Well, I always had both "mounted", but perhaps there was a particular pattern of heavy or slow access that triggered something? Anyway, having all of the filesystems exported by Samba coming from unique zfs filesystems on the FreeBSD side has made everything happy. Yay? FWIW I'm running the latest Samba-4.10.13 from ports on FreeBSD 12.1-STABLE r358963 GENERIC amd64 on a AMD Ryzen 7 1700 Eight-Core Processor with hardware threads turned on. By the way, the current Samba stable release is 4.12.0 (one week old) and 4.11.0 was released last September. Is there some particular incompatibility with FreeBSD that is keeping these out of Ports? I got quite close to trying to build the newer version myself, but then the problem went away... Cheers, Andrew Reilly M: 0409-824-272 arei...@bigpond.net.au > On 24 Nov 2019, at 13:46 , Matt Garber wrote: > > On Sat, Nov 23, 2019 at 9:34 PM Andrew Reilly <mailto:arei...@bigpond.net.au>> wrote: > > The other protagonist in this tale, also connected to the gigabit > LAN, is an iMac running current-Catalina on APFS flash, mounting > three filesystems over SMB, from Samba 4.10.10. After appropriate > Samba tweaking this seems to be at least as reliable as it ever was > with netatalk or NFS, and apparently better supported by Apple. > > Considering all of the other bugs and instability introduced (or > reintroduced) in Catalina: did you have this same Lightroom import workflow > configured in Mojave (or whichever other previous macOS version you were > using), and if so, were you encountering the same issue? > > > Thanks, > — > Matt Garber > ___ 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: Long-shot: repeatable macOS samba share unmounting during Lightroom import
Hi Chris, > On 25 Nov 2019, at 05:12, Chris Gordon wrote: > > WARNING: Mostly deviating from a FreeBSD specific discion > >> On Nov 23, 2019, at 9:33 PM, Andrew Reilly wrote: >> >> Hi all, >> >> This is a long-shot question, because it involves a lot of moving >> pieces, most of which are opaque commercial, poorly documented >> things. Never the less, it does involve FreeBSD-stable as one of >> the players, and my experience over the years has been that FreeBSD >> folk are both knowledgeable and helpful, so here's hoping. Herwith >> my tale of computer-induced irritation: >> >> The story takes place at home, where the FreeBSD system in question >> is a local network file server. The FreeBSD tracks -STABLE every >> week. It boots from ZFS on NVM flash and has four 4TB Hitachi ATA >> drives in a RAIDZ. The current motherboard has a Ryzen 7 1700 >> 8-core locked at 3GHz by the bios to avoid a problem of going to >> sleep permanently by failing to come out of some sort of low-power >> state. It has 32G RAM. It has intel "PRO/1000 PCI-Express Network >> Driver" network connected to a simple gigabit switch, with both >> IPv4 and IPv6 configured and working. >> >> The other protagonist in this tale, also connected to the gigabit >> LAN, is an iMac running current-Catalina on APFS flash, mounting >> three filesystems over SMB, from Samba 4.10.10. After appropriate >> Samba tweaking this seems to be at least as reliable as it ever was >> with netatalk or NFS, and apparently better supported by Apple. >> >> I keep my Lightroom Classic catalogue on the mac's local (flash) >> drive, but the photo storage is on the network. The Import Backups >> directory is also on (a different) network drive. I use Lightroom's >> Import function to copy photos off SD cards using the mac's built-in >> SD card reader and register with the catalogue. So far so normal, >> I think. >> >> The problem arose about ?three or four? months ago: could be >> coincident with OS or Lightroom upgrades, I can't remember, but I >> haven't changed anything about the setup, configuration or workflow. >> Now, every single time Lightroom does an import, while it's doing >> the first scan of the SD card to identify photos that it's seen >> before, all three of the Samba filesystems unmount from the mac, >> silently. I can find no record of error in any of the logs, >> suggesting that the system thinks that it happened deliberately. >> Needless to say, this throws out the import workflow, although it >> manages to pick itself up OK if I just re-mount everything. >> >> Anyone have any similar experiences? Any thoughts of where I could >> poke it to find out why this might be happening? It feels like a >> time-out bug somewhere, but (a) there is no complaint, and (b) the >> network traffic is light at the time. Needless to say Apple >> documentation is useless. >> >> Probably another good reason to find an alternative to Lightroom... > > Other than the hardware specifics, I have the same exact workflow and same > players involved. > > Maybe an odd question, but how are you mounting the SMB shares? In the fallback instance, I mount them with Finder command-K (Go -> Connect to Server). Usually they mount automatically when I log in, because I have them in my Startup Items. > > Since updating to Catalina, I've found lots of problems dealing with SMB > using the Finder window and the items under the Locations side bar. For > instance: > - Mount a share. At some point overnight when nothing is using it, the share > is unmounted. I can't find anything in the logs to say why, when, what, etc. > Just unmounted. I haven't experienced any unattended unmounts. Just during Lightroom import. I _have_ noticed (in Catalina, not before), that the Finder Sidebar does not necessarily "keep up" with the mounted state of shares: after logging in, I have seen my shared folders appear on the desktop as they open, but the server listed in the side bar does not show the Eject icon that comes with being mounted. > - With a fresh start of the Finder process and I can access the SMB > server/shares. After some time, activity, something, I only get "Connection > Failed" and can't access anything. What's really crazy, is that I can't even > unmount mounted shares from under Locations when it gets in this state (I can > unmount via right click on the desktop item, CLI, etc). I see the share with > the eject button, but just get useless error message (i
Re: Long-shot: repeatable macOS samba share unmounting during Lightroom import
Hi Pete, Thanks for the suggestions. FWIW I've been running the fruit extensions and a few other tweaks for quite a while. My current global configuration contains: vfs objects = catia fruit streams_xattr zfsacl fruit:resource = xattr fruit:locking = netatalk fruit:time machine = yes #dflt: fruit:resource = file #dflt: fruit:locking = none fruit:advertise_fullsync = yes nfs4:mode = special nfs4:acedup = merge nfs4:chown = yes # could be derived from this article: # https://blogs.oracle.com/marks/entry/zfs_acls mangled names = no hide dot files = no # prevent created files having execute bit set? map archive = no # prevent SMB1, which seems to be bad: # https://www.cyberciti.biz/faq/how-to-configure-samba-to-use-smbv2-and-disable-smbv1-on-linux-or-unix/ min protocol = SMB2 # Seems to be required for Spotlight (tracker) support (see spotlight = yes on shares, below) # see: https://wiki.samba.org/index.php/Spotlight rpc_server:mdssd = fork rpc_server:mdssvc = external socket options = IPTOS_LOWDELAY TCP_NODELAY browseable = yes No, I haven't actually got Spotlight to work on the samba shares. Any hints on that front would be appreciated. The documentation on some of those Gnome-desktop background things is possibly worse than the Apple documentation... I find that quite a lot about modern computing resembles magical thinking, or occult practices: there is almost no way to actually understand what is going on, you just try things and stick to what seems to work. Superstition over science. Sigh. I can't remember why I'm not using fruit:encoding = private, but I think that it was because I wanted file names to be representable and compatible on both sides of the share, at the expense of occasionally having to "fix" names that turn out to be unrepresentable. I've bumped log level up to 2 and increased the size of the log files by a factor of ten (to 5000 (k)). I suspect that one reason why I wasn't seeing errors being reported could be that the logs were being turned over too quickly. We'll see. Cheers, Andrew Reilly E: arei...@bigpond.net.au M: +61-409-824-272 > On 24 Nov 2019, at 22:15, Pete French wrote: > > I have a very similar setup to you for serving files to my Mac from a FreeBSD > server. I haven't seen the unmount problem, but I di have a few oddities > until I added the 'fruit' module on the Samba side, which helps with > compatbiloty with the Mac. The appropriate bit of my config looks like this: > > vfs objects = fruit streams_xattr zfsacl > fruit:resource = xattr > fruit:encoding = private > > Don't ask me what they do anymore, I added them ages ago, but it does work > very nicely for me. You may already have this of course, but worth pointing > out just in case as it took me a few years to discover it! > > As someone else has said though, this may well be a Catalina bug. I am not > running that (MacBook too old, and not buying another until the new keyboards > are avilable n the replacement I want). > > -pete. > ___ > 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-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: Long-shot: repeatable macOS samba share unmounting during Lightroom import
Hi Matt, > On 24 Nov 2019, at 13:46 , Matt Garber wrote: > > On Sat, Nov 23, 2019 at 9:34 PM Andrew Reilly wrote: > > The other protagonist in this tale, also connected to the gigabit > LAN, is an iMac running current-Catalina on APFS flash, mounting > three filesystems over SMB, from Samba 4.10.10. After appropriate > Samba tweaking this seems to be at least as reliable as it ever was > with netatalk or NFS, and apparently better supported by Apple. > > Considering all of the other bugs and instability introduced (or > reintroduced) in Catalina: did you have this same Lightroom import workflow > configured in Mojave (or whichever other previous macOS version you were > using), and if so, were you encountering the same issue? Yes, I've been using the same workflow for "ever". Since before Lightroom was a subscription product. I know that a lot of unhappiness has been expressed on the net about Catalina, but I've personally experienced no obvious problems, except perhaps this one. Even so, I'm afraid that I didn't note when this problem started, so I can't say whether it was before, after, or coincident with the Catalina upgrade. Cheers, Andrew Reilly M: 0409-824-272 arei...@bigpond.net.au ___ 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: Long-shot: repeatable macOS samba share unmounting during Lightroom import
Hi Theron, > On 24 Nov 2019, at 13:53 , Theron wrote: > > On 2019-11-23 21:33, Andrew Reilly wrote: >> It feels like a >> time-out bug somewhere, but (a) there is no complaint, and (b) the >> network traffic is light at the time. Needless to say Apple >> documentation is useless. > Maybe there is a way to reproduce the Lightroom's file access pattern from a > shell script in a way that reproduces the problem. Then the same access > pattern could be done from a FreeBSD client to see whether it happens there > as well. As I half-expected, now that I've reported the problem, I can't reproduce it on demand, even using the same workflow. Perhaps it is triggered by having a certain number of photos on the card? I'll need to do some more experimentation. Cheers, Andrew Reilly M: 0409-824-272 arei...@bigpond.net.au ___ 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"
Long-shot: repeatable macOS samba share unmounting during Lightroom import
Hi all, This is a long-shot question, because it involves a lot of moving pieces, most of which are opaque commercial, poorly documented things. Never the less, it does involve FreeBSD-stable as one of the players, and my experience over the years has been that FreeBSD folk are both knowledgeable and helpful, so here's hoping. Herwith my tale of computer-induced irritation: The story takes place at home, where the FreeBSD system in question is a local network file server. The FreeBSD tracks -STABLE every week. It boots from ZFS on NVM flash and has four 4TB Hitachi ATA drives in a RAIDZ. The current motherboard has a Ryzen 7 1700 8-core locked at 3GHz by the bios to avoid a problem of going to sleep permanently by failing to come out of some sort of low-power state. It has 32G RAM. It has intel "PRO/1000 PCI-Express Network Driver" network connected to a simple gigabit switch, with both IPv4 and IPv6 configured and working. The other protagonist in this tale, also connected to the gigabit LAN, is an iMac running current-Catalina on APFS flash, mounting three filesystems over SMB, from Samba 4.10.10. After appropriate Samba tweaking this seems to be at least as reliable as it ever was with netatalk or NFS, and apparently better supported by Apple. I keep my Lightroom Classic catalogue on the mac's local (flash) drive, but the photo storage is on the network. The Import Backups directory is also on (a different) network drive. I use Lightroom's Import function to copy photos off SD cards using the mac's built-in SD card reader and register with the catalogue. So far so normal, I think. The problem arose about ?three or four? months ago: could be coincident with OS or Lightroom upgrades, I can't remember, but I haven't changed anything about the setup, configuration or workflow. Now, every single time Lightroom does an import, while it's doing the first scan of the SD card to identify photos that it's seen before, all three of the Samba filesystems unmount from the mac, silently. I can find no record of error in any of the logs, suggesting that the system thinks that it happened deliberately. Needless to say, this throws out the import workflow, although it manages to pick itself up OK if I just re-mount everything. Anyone have any similar experiences? Any thoughts of where I could poke it to find out why this might be happening? It feels like a time-out bug somewhere, but (a) there is no complaint, and (b) the network traffic is light at the time. Needless to say Apple documentation is useless. Probably another good reason to find an alternative to Lightroom... Cheers, Andrew Reilly M: 0409-824-272 arei...@bigpond.net.au ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
> On 5 Oct 2018, at 16:19, Warner Losh wrote: > > > > On Fri, Oct 5, 2018 at 9:05 AM Andrew Turner <mailto:and...@fubar.geek.nz>> wrote: > > > On 3 Oct 2018, at 22:05, Brooks Davis > <mailto:bro...@freebsd.org>> wrote: > > > >>>> Please direct replies to freebsd-arch <<< > > > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > <https://github.com/freebsd/fcp/blob/master/fcp-0101.md>) > > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > > and remove them in FreeBSD 13 to reduce the burden of maintaining and > > improving the network stack. We have discussed this within the > > core team and intend to move forward as proposed. We are solictiting > > feedback on the list of drivers to be excepted from removal. > > > > The current list of drivers slated for REMOVAL is: > > > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > > ste, tl, tx, txp, vx, wb, xe > > smc is found in the Arm models (simulators) [1]. I’ve seen it in the > Foundation and Architecture Envelope Models. I assume it’s also in the other > models, but don’t have a license for them to check. > > Do we currently support those simulators? I see it is in the VERSATILEPB > simulator that QEMU provides. Does that still work? Yes, I boot FreeBSD/arm64 on them in a local Jenkins instance. Andrew ___ 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: FCP-0101: Deprecating most 10/100 Ethernet drivers
> On 3 Oct 2018, at 22:05, Brooks Davis wrote: > >>>> Please direct replies to freebsd-arch <<< > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > and remove them in FreeBSD 13 to reduce the burden of maintaining and > improving the network stack. We have discussed this within the > core team and intend to move forward as proposed. We are solictiting > feedback on the list of drivers to be excepted from removal. > > The current list of drivers slated for REMOVAL is: > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > ste, tl, tx, txp, vx, wb, xe smc is found in the Arm models (simulators) [1]. I’ve seen it in the Foundation and Architecture Envelope Models. I assume it’s also in the other models, but don’t have a license for them to check. Andrew [1] https://developer.arm.com/products/system-design/fixed-virtual-platforms ___ 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: decent 40G network adapters
On 01/18/2017 12:48 PM, Eugene M. Zheganin wrote: Hi. Could someone recommend a decent 40Gbit adapter that are proven to be working under FreeBSD ? The intended purpose - iSCSI traffic, not much pps, but rates definitely above 10G. I've tried Supermicro-manufactured Intel XL710 ones (two boards, different servers - same sad story: packets loss, server unresponsive, spikes), seems like they have a problem in a driver (or firmware), and though Intel support states this is because the Supermicro tampered with the adapter, I'm still suspicious about ixl(4). I've also seen in the ML a guy reported the exact same problem with ixl(4) as I have found. So, what would you say ? Chelsio ? Hi, Solarflare SFN8542 with sfxge driver will do the job Andrew. Thanks. Eugene. ___ freebsd-...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ 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"
Did anything change WRT Jail network access in the last week or so? (10.3-STABLE #17 r298791)
Hi all,
Some time ago I resorted to setting up a Jail to support my
SqueezeBox system: the version in ports (audio/squeezeboxserver)
is not current, and needs an old version of mysql and an old
version of perl. A Jail seemed like the right answer. For a
while it worked OK (for small values of OK), but in the last
week, perhaps even with my most recent weekly upgrade to STABLE
(revision as above) the wheels have fallen off in the form that
the player devices no longer seem to be able to do whatever
network boot thing they do, against the server. One of them
has been power-cycled and seems dead to the world, the other
is still running from its last boot, but claims not to be able
to "see" the server. The server can't see either of them. I
assume that some sort of proprietary broadcast protocol is
involved in this discovery process, although the devices acquire
IP addresses from my 10.3 server's DHCPD.
My jail configuration (in /etc/jail.conf) is:
SB {
host.hostname = "SB.reilly.home";
path = "/usr/home/SB";
ip4.addr += "10.0.0.26/24";
allow.raw_sockets = 1;
exec.clean;
exec.system_user = "root";
exec.jail_user = "root";
exec.start += "/bin/sh /etc/rc";
exec.stop = "/bin/sh /etc/rc.shutdown";
exec.consolelog = "/var/log/jail_SB_console.log";
mount.devfs;
allow.set_hostname = 0;
allow.sysvipc = 0;
}
I believe that the "allow.raw_sockets = 1;" line is the part
that had previosuly allowed the auto-discovery protocol to work.
I'm not sure if it's redundant or not, but I also have the
following line in my /etc/rc.conf:
ifconfig_re0_alias0="inet 10.0.0.26 netmask 0xff00"
FWIW the host that this jail is running on is at 10.0.0.2/24.
As I said above, this was all working up to a week or so ago,
and all I've done in the mean time is a base upgrade and a
portmaster upgrade of installed ports (not the jail ports: they
haven't changed since installed.)
Cheers,
--
Andrew
___
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: dev/random warning on 10-STABLE after r292122 up till r292855
Mark, > At NYC*BUG we are looking into a warning seen on FreeBSD 10-STABLE amd64 > starting at or about r292122 and still up till r292855. > random device not loaded; using insecure entropy I noticed this message a while back and again yesterday on my i386 which runs no modules, just a custom kernel (including "device random", of course) and dismissed it as a probable false positive error from not loading random.ko. 8< FreeBSD 10.2-STABLE #0: Mon Jan 4 00:48:15 EST 2016 a...@hal10001.halplant.net:/usr/obj/usr/src/sys/HAL10001 i386 FreeBSD clang version 3.4.1 (tags/RELEASE_34/dot1-final 208032) 20140512 CPU: Genuine Intel(R) CPU T2500 @ 2.00GHz (1995.04-MHz 686-class CPU) Origin="GenuineIntel" Id=0x6e8 Family=0x6 Model=0xe Stepping=8 Features=0xbfe9fbff Features2=0xc1a9 AMD Features=0x10 VT-x: HLT,PAUSE TSC: P-state invariant, performance statistics real memory = 4294967296 (4096 MB) avail memory = 3417825280 (3259 MB) Event timer "LAPIC" quality 400 ACPI APIC Table: 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 random device not loaded; using insecure entropy 8< http://dmesgd.nycbug.org/index.cgi?action=dmesgd&do=view&id=2873 -- -Andrew J. Caines- Unix Systems Engineer a.j.cai...@halplant.com "Machines take me by surprise with great frequency" - Alan Turing ___ 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: 10.1-BETA2 possible kernel memory leak in routing table
Gleb, 2014-10-17 3:04 GMT+03:00 Gleb Smirnoff : > Merged to releng/10.1 will this fix be MFCed to releng/9.3? FreeBSD v9.3 suffers from this problem too. ___ 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: Rescuing a GPT ZFS boot setup
Alas, that did not work. But it does look to be BIOS related.
I think this new system has a UEFI bios.
I just read from https://wiki.freebsd.org/UEFI:
* Partitions not seen. When using GPT, FreeBSD will create a protective
MBR. This MBR has one partition entry covering the whole disk. FreeBSD marks
this partition active. This causes at least some UEFI implementations to ignore
the GPT. To fix this the partition needs to be marked inactive.
* Filesystem not seen. FreeBSD's FAT32 code appears to sometimes create
filesystems that the UEFI code can't properly read. If the filesystem is small
enough, use FAT16 or FAT12 instead.
I think this may be my issue. But 9.1 LiveCD does boot and I can see the data
once booted, so there must be a way to fix the boot loader on the drive to work.
Is there a way for me to reinstall the MBR or boot partition on the drives to
make it boot up with this BIOS? :(
Thanks.
--Andy
From: Volodymyr Kostyrko
To: Andrew Moran
Cc: "freebsd-stable@freebsd.org"
Sent: Thursday, September 19, 2013 12:51 AM
Subject: Re: Rescuing a GPT ZFS boot setup
19.09.2013 09:36, Andrew Moran wrote:
> 3 years ago I followed https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror
> for a FreeBSD 8.1 system (which has since been upgraded to 9.1). A couple
> days ago I had massive hardware failure, and wound up having to put the two
> drives into an entirely new PC system.
>
> Unfortunately I'm not able to get it to boot off the hard drives. It doesn't
> even show the FreeBSD bootloader menu it normally would. The BIOS sees both
> drives and it can boot off the 9.1 install/Live CD without any problems. In
> the LiveCD, I can see both drives partition tables ("gpart show ..") and I
> can import the zpool ("zpool import zroot"), and see all my data. I just
> can't seem to boot from it. I tried rerunning the "gpart bootcode" commands
> on both drives (no errors), but no effect.
>
> It's also not beyond the realm of possibility I have some BIOS setting wrong,
> but the drives do show up in the POST and BIOS setting.
>
> Does anyone know how I can make my drives bootable again?
Maybe the machine is just too picky about partitioning scheme? Try this
black magic:
printf '\ny\n\n\n\ny\n\ny\n\n\n\n\ny\n' | fdisk -u ${YourDiskName}
--
Sphinx of black quartz, judge my vow.
___
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"
Rescuing a GPT ZFS boot setup
Hey guys,
3 years ago I followed https://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror
for a FreeBSD 8.1 system (which has since been upgraded to 9.1). A couple
days ago I had massive hardware failure, and wound up having to put the two
drives into an entirely new PC system.
Unfortunately I'm not able to get it to boot off the hard drives. It doesn't
even show the FreeBSD bootloader menu it normally would. The BIOS sees both
drives and it can boot off the 9.1 install/Live CD without any problems. In
the LiveCD, I can see both drives partition tables ("gpart show ..") and I can
import the zpool ("zpool import zroot"), and see all my data. I just can't
seem to boot from it. I tried rerunning the "gpart bootcode" commands on both
drives (no errors), but no effect.
It's also not beyond the realm of possibility I have some BIOS setting wrong,
but the drives do show up in the POST and BIOS setting.
Does anyone know how I can make my drives bootable again?
Thanks.
--Andy
___
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: /usr/src over NFS: buildworld fail
On 05/02/2013 01:30 AM, Rick Macklem wrote:
> Andrew Romanenko wrote:
>> On 04/30/2013 02:51 AM, Jeremy Chadwick wrote:
>>> On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote:
>>>> Hi everyone!
>>>> /usr/src imported via NFS
>>>> make buildworld is always fails in the same place with error:
>>>> "make: result too large".
>>>> Localy its works fine
>>>> Does anybody know how to fix it?
>>>>
>>>> i386 FreeBSD 9-STABLE (r250044)
>>> Actual output would have been more useful than a paraphrased
>>> response.
>>> The same goes for actual NFS server and client details (OS, backing
>>> filesystems, make.conf, src.conf, rc.conf, loader.conf, sysctl.conf,
>>> etc.).
>>>
>>> "Result too large" is error ERANGE (see /usr/include/errno.h), errno
>>> 34,
>>> assuming that it has a capital "R" ("Result", not "result").
>>>
>>> I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is
>>> returned directly.
>>>
>>> I do not believe NFS returns ERANGE either.
>>>
>>> There may be cases where the backing filesystem (i.e. the filesystem
>>> used on the NFS server) could return ERANGE. I know ZFS does, but
>>> only
>>> in one specific case (only if the compression property is enabled).
>>> I do see some other cases in the ZFS code pertaining to UTF-8
>>> support
>>> that can return ERANGE but did not look at what those cases may be.
>>>
>>> You may end up having to do the following:
>>>
>>> rm -fr /usr/obj/*
>>> cd /usr/src
>>> ktrace -t+ -f /tmp/ktrace.out make buildworld
>>> {wait until the failure}
>>> cd /tmp
>>> kdump
>>>
>>> Then look to see what syscall/operation returns this. You may have
>>> to
>>> put this file up on the web somewhere (it should gzip quite well),
>>> and
>>> be aware there may be personal information in it (environment
>>> variables,
>>> contents of files, etc.), so choose wisely.
>>>
>>> Good luck.
>>>
>> Fixed. Trouble was in Linux NFS-server.
>> Also, thx Jeremy for the tip (ktrace + kdump)
>> thanks, everyone
>>
> Coule you please provide more information on the Linux NFS-server issue?
> It might be useful if/when others run into interoperability
> problems against a Linux NFS server.
>
> Thanks, rick
>
>> ___
>> 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"
Server: Linux Sabayon
(Linux localhost.localdomain 3.8.0-sabayon #1 SMP Fri Mar 29 13:54:24
UTC 2013 i686 Genuine Intel(R) CPU T2080 @ 1.73GHz GenuineIntel GNU/Linux)
Package: net-fs/nfs-utils-1.2.7
/etc/exports
/home/bsd/src
192.168.56.1/24(rw,async,no_subtree_check,root_squash,anonuid=1000,anongid=1001,fsid=1000)
Client: Freebsd 9-STABLE
(FreeBSD ion.uabsd.org 9.1-STABLE FreeBSD 9.1-STABLE #0 r250121: Wed
May 1 23:38:36 EEST 2013
r...@ion.uabsd.org:/usr/obj/usr/src/sys/GENERIC i386)
mount command:
mount -t nfs -o ro,nfsv3,tcp 192.168.56.1:/home/bsd/src /usr/src
Fix: add option fsid=(1000 or any number) to /etc/exports . I don't
understand, Why fsid is so important?
___
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: /usr/src over NFS: buildworld fail
On 04/30/2013 02:51 AM, Jeremy Chadwick wrote:
> On Mon, Apr 29, 2013 at 09:42:06PM +0300, Andrew Romanenko wrote:
>> Hi everyone!
>> /usr/src imported via NFS
>> make buildworld is always fails in the same place with error: "make: result
>> too large".
>> Localy its works fine
>> Does anybody know how to fix it?
>>
>> i386 FreeBSD 9-STABLE (r250044)
> Actual output would have been more useful than a paraphrased response.
> The same goes for actual NFS server and client details (OS, backing
> filesystems, make.conf, src.conf, rc.conf, loader.conf, sysctl.conf,
> etc.).
>
> "Result too large" is error ERANGE (see /usr/include/errno.h), errno 34,
> assuming that it has a capital "R" ("Result", not "result").
>
> I see no cases in src/usr.bin/make/* where ERANGE or errno 34 is
> returned directly.
>
> I do not believe NFS returns ERANGE either.
>
> There may be cases where the backing filesystem (i.e. the filesystem
> used on the NFS server) could return ERANGE. I know ZFS does, but only
> in one specific case (only if the compression property is enabled).
> I do see some other cases in the ZFS code pertaining to UTF-8 support
> that can return ERANGE but did not look at what those cases may be.
>
> You may end up having to do the following:
>
> rm -fr /usr/obj/*
> cd /usr/src
> ktrace -t+ -f /tmp/ktrace.out make buildworld
> {wait until the failure}
> cd /tmp
> kdump
>
> Then look to see what syscall/operation returns this. You may have to
> put this file up on the web somewhere (it should gzip quite well), and
> be aware there may be personal information in it (environment variables,
> contents of files, etc.), so choose wisely.
>
> Good luck.
>
Fixed. Trouble was in Linux NFS-server.
Also, thx Jeremy for the tip (ktrace + kdump)
thanks, everyone
___
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"
/usr/src over NFS: buildworld fail
Hi everyone! /usr/src imported via NFS make buildworld is always fails in the same place with error: "make: result too large". Localy its works fine Does anybody know how to fix it? i386 FreeBSD 9-STABLE (r250044) Best regards, Andrew Romanenko ___ 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: svn - but smaller?
On Thu, Jan 24, 2013 at 10:45:53AM +, Ben Morrow wrote: > At 9AM + on 24/01/13 you (Ben Morrow) wrote: > > Quoth 'Jeremy Chadwick' : > > > > > > Regarding your "svn-lite" theory of having that added to src/contrib/, > > > let me introduce you to Subversion's actual dependencies, and I'll > > > explain why these would have to remain enabled (for a "base system" > > > Subversion) as well: > > > > * APR (used for HTTP fetching (not necessarily HTTPS)) > > > -- License: http://www.apache.org/licenses/LICENSE-2.0.html > > > -- Not in the base system > > > > > > * Expat 2.x (XML parsing/generation library > > > -- License: http://en.wikipedia.org/wiki/MIT_License > > > -- Not in the base system > > Correction: expat is in base already, as libbsdxml (rather confusingly > built under lib/libexpat). > > So AFAICS the only remaining piece is APR (and svn itself), and I > suspect that if only the bits required for a svn client were brought in > (assuming the licence is deemed acceptable) that would be a lot smaller > than a full APR build. (Again, this would need to be built as libbsdapr > to avoid conflicts with real APR from ports.) If APR is only used for HTTP fetching, I wonder how hard it would be to replace those pieces with fetch(3), which is in base, or wrap fetch(3) in an APR-compatability shim? (Some work required, obviously.) No, I'm not volunteering: svn from ports works OK for me, and I'm in the process of investigating freebsd-update+portsnap to keep the source trees up to date... Took me a while to notice that freebsd-update can be told to *not* update executables and what-not, but I haven't tried it myself. Call me a massochist, but I like that my FreeBSD system is running code built from the source that's there... Part of FreeBSD's charm, in my opinion. Cheers, -- Andrew ___ 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: svn - but smaller?
On Thu, Jan 24, 2013 at 03:20:42PM +0100, Gyrd Thane Lange wrote: > On 23.01.2013 15:40, Oliver Brandmueller wrote: > > However, I either overlook something important or we are now at the > > point we had with cvsup in the early days: The software I need to > > (source-)update the system doens't come with the base and installing svn > > is a PITA. [...] > > It is not a well publicized fact, but I understand that the base utility > freebsd-update(8) through it's freebsd-update.conf(5) is able to pull > the base sources (/usr/src/) only instead of also updating your binaries. > > less /etc/freebsd-update.conf > ># Components of the base system which should be kept updated. >Components src world kernel > > The above setting is the default, but you may easily leave out > everything but "src". (Caveat: I have not tried it myself yet.) > It also have some optional settings for preserving local changes to the > source instead of blowing them away (default). > > This will allow you to use the sources for a custom build and install > yourself. I've been using svn from ports for a while, but would like to switch to a FreeBSD-self-contained update method, so I've just given that a shot. I've tweaked out world and kernel from the freebsd-update.conf (and also tweaked out the updateIfChanged and MergeIfChanged lines, just in case it tried to do something to my config.) Anyway, it failed thusly: $ sudo freebsd-update fetch Password: Looking up update.FreeBSD.org mirrors... 3 mirrors found. Fetching public key from update5.freebsd.org... failed. Fetching public key from update4.freebsd.org... failed. Fetching public key from update3.freebsd.org... failed. No mirrors remaining, giving up. Any thoughts on what is going wrong there? I would imagine that if there was a real problem, rather than pilot error, there would be considerable noise on the lists. Do I need to "prime" the system by grabbing some keys from somewhere? I have a fully-up-to-date /usr/src world and kernel thanks to the svn+UPDATING process, fwiw. > Also for ports we have the portsnap(8) utility, also in base. So it is > perfectly possible to get sources for everything using just the tools in > base. No csup or svnup is required. That manual page reads as though it downloads the whole tarball of the whole ports tree every time: that doesn't sound terribly efficient. Is there enough redundancy in the ports structure to make compressing a tarball a win, compared to uncompressed version differences at, say, weekly updates? Cheers, -- Andrew ___ 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: FreeBSD 9.0-STABLE problem with the Adaptec Storage Manager
Hello, On Saturday, July 07, 2012 2:17:33 am David Chisnall wrote: DC> 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. DC> This was accidentally removed in the xlocale refactoring. I've DC> restored it in r238182 and CC'd re@ for permission to merge to the 9.1 release branch. Do you plan on MFC'ing it to stable/9 and releng/9.1? It breaks sysutils/arcconf, I can't monitor a state of my raid controller. -- SY, Andrew Khlebutin ___ 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: LSI 9240-4i 4K alignment
On Sun, Aug 19, 2012 at 7:34 PM, Josh Paetzel wrote: > On the dmesg posted the firmware on the card is phase 11. This *must* > be in lockstep with the driver version or the card may not play nicely. > FreeBSD 8.3 and 9.0 have v13 of the driver, the upcoming 9.1 will have > v14. Note that v14 fixes a *ton* of stability bugs, including issues > where bad drives would hang the controller or prevent systems from booting. Oof, good to know. I happen to have a server with v9 9211 firmware and v13 mps drivers that's having stability problems under load; it will be interesting to see if updating the firmware solves the problem. Is there someplace I should have been checking to know that this was a requirement? Thanks, Andy ___ 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: IPMI hardware watchdogs Re: dell r420/r320 stable/9
On Jul 27, 2012, at 10:42 AM, Attilio Rao wrote: > On Fri, Jul 27, 2012 at 3:33 PM, Andrew Boyer wrote: >> >> On Jul 26, 2012, at 8:50 PM, Sean Bruno wrote: >> >>> For the time being I had to revert the following from my stable/9 tree. >>> Otherwise I would get a kernel panic on shutdown from ipmi(4). >>> >>> http://svnweb.freebsd.org/base?view=revision&revision=237839 >>> http://svnweb.freebsd.org/base?view=revision&revision=221121 >>> >> >> On a somewhat related note: We noticed recently that you can't pet or >> disable the IPMI hardware watchdog once SCHEDULER_STOPPED() is true. This >> means it can fire unexpectedly while you're dumping core or rebooting, >> depending on how long the timeout was on the pet before the panic. The ipmi >> driver will need to process the command differently if the scheduler is >> stopped. I haven't had time to look at a fix yet. > > I recall I fixed that internally for SV, but the key here is that we > need to find an unified (or a default policy). > More specifically, do we want the watchdog also covers the kernel dump > part (because of possible deadlocks when dumping). If the answer is > yes, we likely need pat the watchdog from within the dumping cycle > itself. If the answer is no, then we can just disable it when entering > the panic path. But anyway, we need to identify a default policy that > makes sense first. > > Attilio > For our use case, we need the system to reset if the dump hangs. As the code stands now, you can't disable the HW watchdog from the panic path. Prior to stopping the scheduler early in panic(), you don't know the lock state, so you can't safely initiate the IPMI command. (It hung the first time I tried it.) After stopping the scheduler, you can't pet it to turn it off. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
IPMI hardware watchdogs Re: dell r420/r320 stable/9
On Jul 26, 2012, at 8:50 PM, Sean Bruno wrote: > For the time being I had to revert the following from my stable/9 tree. > Otherwise I would get a kernel panic on shutdown from ipmi(4). > > http://svnweb.freebsd.org/base?view=revision&revision=237839 > http://svnweb.freebsd.org/base?view=revision&revision=221121 > On a somewhat related note: We noticed recently that you can't pet or disable the IPMI hardware watchdog once SCHEDULER_STOPPED() is true. This means it can fire unexpectedly while you're dumping core or rebooting, depending on how long the timeout was on the pet before the panic. The ipmi driver will need to process the command differently if the scheduler is stopped. I haven't had time to look at a fix yet. -Andrew ------ Andrew Boyerabo...@averesystems.com ___ 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: FreeBSD 8-STABLE on R620 w/ X520-DA2/Intel 82599
Please post the output of pciconf -lvc for these devices. -Andrew On Jun 29, 2012, at 10:50 AM, Rick Miller wrote: > Hi All, > > I have 2 hosts, HP DL360 G8 and Dell R620. Both have the > X520-DA2/Intel 82599 10G Fiber NIC. Both also have the same FreeBSD > 8-STABLE image. The Dell displays the following in dmesg and we are > unable to configure the ix0 or ix1 interfaces where the HP works just > fine. Wondering if anyone else has experienced this? > > pci4: at device 0.0 (no driver attached) > pci4: at device 0.1 (no driver attached) > > > -- > Take care > Rick Miller > ___ > 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" -- Andrew Boyerabo...@averesystems.com ___ 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: Intel X520-DA2 Supported in stable/8?
You can probably turn hw.ixgbe.num_queues down to 2 or 4 and cut your mbuf consumption dramatically without noticing any loss of performance. -A On Jun 22, 2012, at 6:19 PM, Rick Miller wrote: > On Fri, Jun 22, 2012 at 5:21 PM, Jack Vogel wrote: >> Increase your system mbuf pool size, you do not want that failure to happen. > > Thanks, Jack. I saw a thread where you discussed this. You are > referring to kern.ipc.nmbclusters, correct? > > Should I also adjust the following? > > hw.ixgbe.rxd > hw.ixgbe.txd > hw.ixgbe.num_queues > hw.intr_storm_threshold -- Andrew Boyerabo...@averesystems.com ___ 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: Intel X520-DA2 Supported in stable/8?
The ixgbe driver creates devices named ix0, etc. I believe you need to run 'ifconfig ix0 up' before it will attempt to get link. -Andrew On Jun 22, 2012, at 3:45 PM, Rick Miller wrote: > On Fri, Jun 22, 2012 at 3:13 PM, Rick Miller wrote: >> Hi All, >> >> Wondering if the Intel X520-DA2 10G Fibre NIC is supported in >> stable/8. Hardware notes don't specify it, but I have a system up and >> the interfaces appear to be loaded by the ix driver. However, status >> indicates "no carrier". > > Ok, brain fart. Please forgive my ineptitude. I once sent an email > inquiring about the Intel 82599, which is this NIC. Responses to that > mail say it's supported by the ixgbe driver. My stable/8 installation > (5/21/2012) probes it with an ix driver that I cannot find any info > on. The ixgbe manage indicates it only supports 82598 based > controllers. Not sure what to think here... > ___ > 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" -- Andrew Boyerabo...@averesystems.com ___ 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: if_bridge panic removing member
On 11 June 2012 08:48, David ROFFIAEN wrote: > Hi list, > > On FreeBSD 9-stable (csup from today) with amd64 arch (only, no poblem with > the same source on i386) kernel panic when removing member form the bridge : > to reproduce : > > # ifconfig bridge0 create addm em0 > # ifconfig bridge0 deletem em0 > > the problem is the same with all interfaces (tested with wlan vlan em) > > It seems to become for a new function in net/if_bridge.c : > bridge_linkstate, not existing previously when it worked on amd64 (one > month ago) > I introduced this issue in r234487, please try this patch. http://people.freebsd.org/~thompsa/bridge_link.diff regards, Andrew ___ 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: Why Are You Using FreeBSD?
On Wed, May 30, 2012 at 07:20:31PM +0100, David Chisnall wrote: > If you had to list > the three things you most like about FreeBSD, which would you > pick? Are they the same as when you first started using it? 1) Using it doesn't require changing me (well, at least change is gradual and continuous.) (BSD since '86, even though the hardware dies every few years.) 2) Incremental updates from source are easy. (What's running corresponds to the source on the system, so I can fix breakage as I find it. Not that that's common.) 3) ZFS turns out to be very cool, and seems to work really well. (3) is new, but (1) and (2) have been there since the beginning (since it was the patchkit.) [Another change, not listed among the three most-liked things, but still something that I like equivocally, is that I've stopped fighting GUIs, and relegated my FreeBSD boxes to servers. GUI work I've delegated to Macs. That could yet change back/again, if Macs keep getting worse...] Cheers, -- Andrew ___ 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: r232411 breaks onboard 1068 detection
On Wed, Apr 4, 2012 at 2:33 AM, Marius Strobl wrote: > On Wed, Apr 04, 2012 at 02:26:38AM +0400, Andrew Pantyukhin wrote: >> The device in question is a built-in 1068-based controller on a >> SuperMicro X8ST3 board. >> >> It can be converted to MegaRAID mode with a special addon "button" >> (AOC-IButton68). >> >> http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm > > Okay, so unless these devices also can be driven by mfi(4) when not > in MegaRAID mode, we need a way to tell both modes apart in the probe > functions of both drivers. mfi(4) obviously didn't attach, but if anyone is willing to provide a quick patch listing the IDs in mfi(4), I'll try. I wouldn't welcome the change though, as we prefer the JBOD way. ___ 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: r232411 breaks onboard 1068 detection
On Wed, Apr 4, 2012 at 1:57 AM, Marius Strobl wrote: > On Tue, Apr 03, 2012 at 03:52:14PM -0600, McConnell, Stephen wrote: >> Marius, >> >> Since the 0x59 device is a MegaRAID device, shouldn't you be using the >> MegaRAID driver. Why is the MPT driver being used in this case? The >> problem is that the MPT driver was wrongly attaching to some MegaRAID >> controllers and that was causing conflict problems, so that was fixed by >> removing MegaRAID ID's from the MPT driver. > > Apparently, the 0x59 devices worked just fine using mpt(4) before r232411. > Are MegaRAID devices backwards-compatible so they can alternatively be > driven by MPT drivers? The device in question is a built-in 1068-based controller on a SuperMicro X8ST3 board. It can be converted to MegaRAID mode with a special addon "button" (AOC-IButton68). http://www.supermicro.com/products/motherboard/Xeon3000/X58/X8ST3-F.cfm ___ 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"
r232411 breaks onboard 1068 detection
Hello, r232411 broke onboard 1068 detection on all boxes with SuperMicro X8ST3 motherboards for us. All of them are also equipped with two extra 1068 controllers, which are detected fine. Reverting to r231518 with otherwise latest stable kernel works around the problem. The issue is still there at r233425. Here's the disappearing device: mpt2@pci0:5:0:0:class=0x01 card=0x10001000 chip=0x00591000 rev=0x08 hdr=0x00 vendor = 'LSI Logic / Symbios Logic' device = 'MegaRAID SAS 8208ELP/8208ELP' class = mass storage subclass = SCSI Best, Andrew ___ 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"
Can someone do something about the extra svn mergeinfo?
For example: http://svnweb.freebsd.org/base/stable/8/sys/dev/e1000/?view=log This makes it very hard to figure out which changes are actually relevant to e1000. Thank you, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: Xeon Processors with AES instructions and geli encryption
FYI, there is a bug in 8.2 for 256b keys and was fixed in 8.2-stable. You may want to apply the fix if it causes you issues. http://www.FreeBSD.org/cgi/query-pr.cgi?pr=155118 Andrew On 8 March 2012 04:59, Karl Denninger wrote: > Thanks; the machines in question are on 8.2, so this sounds pretty good. > > On 3/7/2012 9:55 AM, Ian Lepore wrote: >> On Wed, 2012-03-07 at 09:09 -0600, Karl Denninger wrote: >>> Does the crypto(9) framework recognize and use these instructions? >>> Looks like the Windmere-series Xeons will drop into my system boards; I >>> gain two cores per CPU at the same time, so I'll go from an 8-way SMP >>> system to a 12-way one. >>> >>> I am considering spending the money to upgrade a couple of servers here >>> that run geli-encrypted disks, as during heavy I/O they spend a LOT of >>> their CPU time on the disk encryption. The differences I see in the use >>> of TrueCrypt on Windows machines that have AES instructions .vs. those >>> that do not are very significant and I'm curious if this carries over to >>> FreeBSD. >>> >>> Thanks in advance! >>> >> It looks like it does as of 8.2 when the aesni driver was added. >> >> -- Ian >> >> >> ___ >> 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" >> >> >> %SPAMBLOCK-SYS: Matched [@freebsd.org+], message ok > > -- > -- Karl Denninger > /The Market Ticker ®/ <http://market-ticker.org> > Cuda Systems LLC > ___ > 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" ___ 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: hang during dump (reproducible)
On Feb 10, 2012, at 9:50 PM, Jake Holland wrote: > > Many thanks to Attilio Rao, Kostik Belousov, and Andriy Gapon. And anybody > else involved. > > However, when I looked at the commit I noticed this: >> $ svn log -r228424 svn://svn.freebsd.org/base > ... >> MFC after: 3 months (or never) > > I'm not sure whether "never" is still considered an option, but it would be > useful for me if 8.3 release, when it comes, does not hang this way during > panic. But thanks for the patch, regardless. > Agreed - if this commit could be MFC'd for 8.3 it would be much appreciated. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
Kernel panics under 8.2 due to ATA timeouts
Hello Alexander, I have a system that appears to have a flaky SATA controller (one of the Intel ESB2 variants) and it seems to be exposing a weakness in the ATA driver (not using ATA_CAM). If a command with ATA_R_DIRECT set times out, the channel gets reinitialized, but from the soft interrupt context. It panics when it tries to sleep in ata_queue_request(). Timeouts work if ATA_R_DIRECT isn't set because in that case it uses a taskqueue to complete the request. Here is the backtrace: > #0 kdb_enter (why=0x80962cfa "panic", msg=0xa bounds>) at ../../../kern/subr_kdb.c:349 > #1 0x805d6d0b in panic (fmt=Variable "fmt" is not available. > ) at ../../../kern/kern_shutdown.c:689 > #2 0x8061bc53 in sleepq_add (wchan=0xff00052c3e58, > lock=0xff00052c3e38, wmesg=0x808fa213 "ATA request done", > flags=1, queue=0) at ../../../kern/subr_sleepqueue.c:320 > #3 0x80590c95 in _cv_timedwait (cvp=0xff00052c3e58, > lock=0xff00052c3e38, timo=4) at ../../../kern/kern_condvar.c:313 > #4 0x805d61af in _sema_timedwait (sema=0xff00052c3e38, > timo=4, file=0x808fa1f6 "../../../dev/ata/ata-queue.c", > line=118) at ../../../kern/kern_sema.c:123 > #5 0x8028559f in ata_queue_request (request=0xff00052c3dc0) at > ../../../dev/ata/ata-queue.c:117 > #6 0x80286628 in ata_controlcmd (dev=0xff0002e83d00, command=239 > '?', feature=Variable "feature" is not available. > ) at ../../../dev/ata/ata-queue.c:153 > #7 0x8027ffd3 in ata_setmode (dev=0xff0002e83d00) at > ../../../dev/ata/ata-all.c:637 > #8 0x802a0af9 in ad_init (dev=0xff0002e83d00) at > ../../../dev/ata/ata-disk.c:405 > #9 0x802a0c29 in ad_reinit (dev=0xff0002e83d00) at > ../../../dev/ata/ata-disk.c:221 > #10 0x80280cad in ata_reinit (dev=0xff0002902800) at ata_if.h:79 > #11 0x802856c4 in ata_completed (context=Variable "context" is not > available. > ) at ../../../dev/ata/ata-queue.c:313 > #12 0x80285ffb in ata_finish (request=0xff00054ec8c0) at > ../../../dev/ata/ata-queue.c:265 > #13 0x805ed419 in softclock (arg=Variable "arg" is not available. > ) at ../../../kern/kern_timeout.c:430 This is very repeatable. I'm not sure what's the best fix - always use a taskqueue on timeouts? Don't reinit if direct commands fail? -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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"
mfip and smartctl Re: smartctl / mpt on 9.0-RC1
On Nov 7, 2011, at 6:24 AM, Marat N.Afanasyev wrote: > > this is an output on mfi controller with mfip loaded: > > # smartctl -a /dev/pass1 > smartctl 5.41 2011-06-09 r3365 [FreeBSD 8.2-RELEASE amd64] (local build) > Copyright (C) 2002-11 by Bruce Allen, http://smartmontools.sourceforge.net > > Vendor: SEAGATE > Product: ST3146356SS > Revision: 0007 > User Capacity:146,815,737,856 bytes [146 GB] > Logical block size: 512 bytes > Logical Unit id: 0x5000c50028f8a56f > Serial number:3QN4PWHS9130JLKB > Device type: <31> > Transport protocol: SAS > Local Time is:Mon Nov 7 15:20:27 2011 MSK > Device supports SMART and is Enabled > Temperature Warning Enabled > SMART Health Status: OK > > Current Drive Temperature: 26 C > Drive Trip Temperature:68 C > > Error counter log: > Errors Corrected by Total Correction GigabytesTotal > ECC rereads/errors algorithm processed > uncorrected > fast | delayed rewrites corrected invocations [10^9 bytes] > errors > read:93821240 0 93821249382124 3436.782 > 0 > write: 00 0 0 0 8978.360 > 0 > verify: 6634330 0663433 663433332.651 > 0 > > Non-medium error count:7 > > [GLTSD (Global Logging Target Save Disable) set. Enable Save with '-S on'] > No self-tests have been logged > Long (extended) Self Test duration: 1740 seconds [29.0 minutes] > > btw, 3dm can tell about reallocated sector count on sas somehow, while > smartctl cannot, even on supported controller :( Notice how the device type is "<31>"? The mfip driver masks off the SCSI INQUIRY peripheral device type bits to prevent CAM from attached da* devices to the disks. See sys/dev/mfi/mfi_cam.c, search for T_DIRECT. That confuses smartctl and prevents it from displaying information like the Grown Defect List. I added a local hack to smartctl to interpret a peripheral device type of 0x1f (unknown or missing) to 0x0 (disk), but I don't think the hack is appropriate for general consumption. What we need is better way for mfi and aac to block CAM from attaching without corrupting the inquiry results. -Andrew > -- > SY, Marat > -- Andrew Boyerabo...@averesystems.com ___ 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"
WITHOUT_SYSINSTALL (stable-9)
I was able to buildworld, buildkernel to 9.0-RC1 from 8-stable without incident. Yay. However, I noticed a new sysinstall executable in /usr/sbin even though I included WITHOUT_SYSINSTALL="yes" in /etc/src.conf. My src.conf looks like it's in good order, and the other WITHOUT_ options were heeded. Thanks, Andrew Lankford PS will we be able to compile out bsdinstall and pc-sysinstall with STABLE-9? ___ 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: Timing of 9.0-RC1?
On 17 October 2011 11:22, Brett Glass wrote: > Any word regarding timing of FreeBSD 9.0-RC1? Building machines, and would > like to build with at least a release candidate rather than a beta. > If you see this commit, it looks like the RC1 build is underway. I would guess the isos will be out in 24-48+ hours. http://svnweb.freebsd.org/base?view=revision&revision=226438 Andrew ___ 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: Fw: zfs snapshot: Bad file descriptor
2011/8/25 Gerrit Kühn > Sorry for crossposting, but I got no answer at all from freebsd-fs. Anyone > in here having any ideas/suggestions on this? Is this the same thing as kern/156781? -Andy > > Begin forwarded message: > > Date: Tue, 23 Aug 2011 17:02:55 +0200 > From: Gerrit Kühn > To: freebsd...@freebsd.org > Subject: zfs snapshot: Bad file descriptor > > > Hi all, > > since upgrading some of my storage machines to recent 8.2-stable and > zfs-v28 I see the following on some filesystems after some time of > operation: > > --- > mclane# ll /tank/home/pt/.zfs > ls: snapshot: Bad file descriptor > total 0 > --- > > > I make quite heavy use of snapshots on all my machines and use rsync to > backup snapshots to other machines. > Googleing around I found several people reporting similar problems, but no > real solution (apart from rebooting, which is not really a thing you want > to do every time you run into this). > Is there any knowledge/ideas available over the list here how to improve > this situation? Am I just one of the few unlucky people who see this, or is > there an actual reason for this happening that could be fixed or > circumvented? > > > cu > Gerrit > ___ > freebsd...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-fs > To unsubscribe, send any mail to "freebsd-fs-unsubscr...@freebsd.org" > > ___ > 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" ___ 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"
USB/coredump hangs in 8 and 9
Re: panic: bufwrite: buffer is not busy??? (originally on freebsd-net) Re: debugging frequent kernel panics on 8.2-RELEASE (originally on freebsd-stable) Re: System hang in USB umass module while processing panic (originally on freebsd-usb) Hello Andriy and Hans, Sorry for tying in so many discussions on this topic, but I think I have an explanation for the problems we have been reporting* with hanging coredumps on multicore systems on 8.2-RELEASE, and it has implications for Andriy's proposed scheduler patch** and for USB. In today's 8.X and 9.X branches, nothing that I can find stops the other CPUs when the kernel panics, but many parts of the locking code get disabled (grep on 'panicstr'). The 'bufwrite: buffer is not busy???' panic is caused by the syncer encountering an error. If that happens when it's on the dumping CPU everything hangs. If it's running on a different CPU, it will be blocked and hidden by the panic_cpu spinlock in panic(), and the dump continues, polling every attached keyboard for a Ctl-C. But, the new 8.X USB stack relies on multithreading. (The new stack is the variable that broke coredumps for us in the 7.1->8.2 transition, I think.) SVN 224223 fixes a hang that would happen when dumpsys() polls the USB keyboard (IPMI KVM, in our case). That helps, but it only gets as far as usb_process(), where it hangs in a loop around a cv_wait() call. This is easy to reproduce by adding code to the watchdog to break into the debugger if panicstr is set. I am experimenting with Andriy's patch** to stop the scheduler and it seems to be most of the way there, stopping the CPUs and disabling the rest of locking. There are a few places that still reference panicstr, but that's minor. These are the changes I made to the patch: * Changed ukbd_do_poll() to return immediately if SCHEDULER_STOPPED() is true, so that we don't hang up in USB. ukbd_yield() locks up in DROP_GIANT(), and if you skip ukbd_yield(), usbd_transfer_poll() locks up trying to drop mutexes. * Changed the call to spinlock_enter() back to critical_enter(), so that interrupts stay enabled and the hardclock still functions. * Added code in the beginning of panic() to switch to CPU 0, so that we're able to service the hardclock interrupts and so that watchdog panics get through. This has worked 100% for me so far, although anyone using a USB keyboard or dump device would still be out of luck. Thoughts? It seems like stopping all of the other CPUs is the right thing to do on a panic (what are they doing otherwise?). Are the USB issues fixable? If Andriy's patch get committed it might just involve short-circuiting all of the locking in the polling path, but I haven't gotten that far yet. I bet dumping to NFS will have the same problem. Thanks, Andrew * - http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/155421 ** - http://people.freebsd.org/~avg/stop_scheduler_on_panic.8.x.diff -- Andrew Boyerabo...@averesystems.com ___ 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: Heads up: you'll need to do a fresh "config KERNEL" etc
On May 19, 2011, at 6:53 PM, Rick Macklem wrote: > Assuming that you are using the regular 8.n client (and not the new > one), there have been some commits related to krpc bugs that could have > fixed cases which would have caused poor perf., although all of those > (except one where a client would hang on a TCP reconnect attempt) are in > 8.2. Are you referring to r221934? If not, which change? (Trying to make sure I have them all...) Thanks, Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: [releng_8 tinderbox] failure on arm/arm
On 29 April 2011 11:30, Jeremy Chadwick wrote: > On Thu, Apr 28, 2011 at 09:06:32PM +, FreeBSD Tinderbox wrote: > > ===> usr.sbin/usbdump (all) > > cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W > -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes > -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow > -Wcast-align -Wunused-parameter -Wno-uninitialized -Wno-pointer-sign -c > /src/usr.sbin/usbdump/usbdump.c > > cc1: warnings being treated as errors > > /src/usr.sbin/usbdump/usbdump.c: In function 'print_apacket': > > /src/usr.sbin/usbdump/usbdump.c:353: warning: cast increases required > alignment of target type > > /src/usr.sbin/usbdump/usbdump.c: In function 'print_packets': > > /src/usr.sbin/usbdump/usbdump.c:399: warning: cast increases required > alignment of target type > > *** Error code 1 > > > > Stop in /src/usr.sbin/usbdump. > > *** Error code 1 > > CC'ing hselasky and thompsa for review of this. > > For failure logs (so far ia64 and arm), please see end of this page: > > http://lists.freebsd.org/pipermail/freebsd-stable/2011-April/thread.html > > Commit question is revision 1.6.2.2 to RELENG_8: > > http://www.freebsd.org/cgi/cvsweb.cgi/src/usr.sbin/usbdump/usbdump.c > > Relevant code bits: > I merged the missing rev a few hours ago, http://svnweb.freebsd.org/base?view=revision&revision=221185 Andrew ___ 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: Network throughput: Never get more than 112MB/s über two NICs
On 11 April 2011 22:00, Denny Schierz wrote: > hi, > > after testing severals loadbalancing (LACP) types with Cisco, we saw, > that we never get more than 112MB/s with two network cards and iperf. > > So, we tested without loadbalancing, 4 Clients (iperf -f M -c ) and > two target IPs. Every IP has his own 1Gb/s network card. > On the end, two clients had a connection to IP 1 and the second two to > IP 2. > > First we used the two onboard NICs and then, one onboard and one > external NIC, but without success. We never get more then 112MB/s > > All are connected through a Cisco Catalyst WS-X4515. > > The mainboard is a Intel S3420GP. > > any suggestion? Are you doing LACP from the FreeBSD host? (ie. lagg(4) interface). The current hash just uses the mac and IP addresses (not tcp/udp ports) so you need to make sure your multiple streams have different mac/ip numbers in order to load balance over multiple links. Andrew ___ 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: About "panic: bufwrite: buffer is not busy???"
On Feb 20, 2011, at 10:46 AM, Jeremy Chadwick wrote: > On Sun, Feb 20, 2011 at 10:30:52AM -0500, Mike Tancsa wrote: >> On 2/20/2011 9:33 AM, Andrey Smagin wrote: >>> On week -current I have same problem, my box paniced every 2-15 min. I >>> resolve problem by next steps - unplug network connectors from 2 intel em >>> (82574L) cards. I think last time that mpd5 related panic, but mpd5 work >>> with another re interface interated on MB. I think it may be em related >>> panic, or em+mpd5. >> >> The latest panic I saw didnt have anything to do with em. Are you sure >> your crashes are because of the nic drive ? > > Not to mention, the error string the OP provided (see Subject) is only > contained in one file: sys/ufs/ffs/ffs_vfsops.c, function > ffs_bufwrite(). So, that would be some kind of weird filesystem-related > issue, not NIC-specific. I have no idea how to debug said problem. > The issue is the file system activity occurring in parallel with the coredump, which is strange. It seems like everything else should be halted before the dump begins but I couldn't find a place in the code that actually tries to stop the other CPUs. My question isn't about the initial panic (I was using the sysctl to provoke one), but about the secondary panic. This is on 8-core systems. -Andrew -- Andrew Boyerabo...@averesystems.com ___ 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: About "panic: bufwrite: buffer is not busy???"
Moving this to -current and -stable and following up... Something is broken with coredumps on stable/8 amd64. I tried a vanilla 8.2-RC3 and yesterday's csup of stable/8; neither can dump a core with 'sysctl debug.kdb.panic=1'. For the 8.2-RC3 / amd64 / GENERIC install, I used the memstick image, installed on ad7 (a 250GB SATA drive), used the default partition map, and set dumpdev to AUTO. I added enough tracing to show that the second panic is due to the syncer process flushing buffers to the other filesystems in parallel with the dump. I've seen this panic and a similar one 'buffer not locked' coming from ffs_write(). One time out of about 30 the core ran to completion, but slowly (~1MB/sec). Other times the dump just locks up completely with no other output. Does anyone know what might have changed to expose this problem? I don't ever see it under 7.1. Thanks, Andrew On Feb 3, 2011, at 12:11 AM, Eugene Grosbein wrote: > On 02.02.2011 00:50, Gleb Smirnoff wrote: > >> E> Uptime: 8h3m51s >> E> Dumping 4087 MB (3 chunks) >> E> chunk 0: 1MB (150 pages) ... ok >> E> chunk 1: 3575MB (915088 pages) 3559 3543panic: bufwrite: buffer is not >> busy??? >> E> cpuid = 3 >> E> Uptime: 8h3m52s >> E> Automatic reboot in 15 seconds - press a key on the console to abort >> Can you add KDB_TRACE option to kernel? Your boxes for some reason can't >> dump core, but with this option we will have at least trace. > > I see Mike Tancsa's box has "bufwrite: buffer is not busy???" problem too. > Has anyone a thought how to fix generation of crashdumps? > > Eugene Grosbein > > > ___ > freebsd-...@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" -- Andrew Boyerabo...@averesystems.com ___ 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: KERN - mfi driver for Dell raid h200 on r210 servers
On 30 January 2011 06:20, Damien Fleuriot wrote: > Hello lists, > > > > I'm trying to get FreeBSD 8.0 or 8.1 to run on a Dell poweredge r210 server. > > It ships with a SATA/SAS h200 RAID controller. > This card may need the mps(4) driver which is only in HEAD at the moment. Andrew ___ 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: NFSv4 - how to set up at FreeBSD 8.1 ?
On 7 January 2011 14:25, Jean-Yves Avenard wrote: > On 7 January 2011 08:16, Rick Macklem wrote: > >> When I said I recalled that they didn't do TCP because of excessive >> overhead, I forgot to mention that my recollection could be wrong. >> Also, I suspect you are correct w.r.t. the above statement. (ie. Sun's >> official position vs something I heard.) >> >> Anyhow, appologies if I gave the impression that I was correcting your >> statement. My intent was just to throw out another statement that I >> vaguely recalled someone an Sun stating. > > After hitting yet another serious bug in 8.2 ; I reverted back to 8.1 Has the problem been reported? There is still time to fix serious bugs in 8.2 Andrew ___ 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: ZFS backups: retrieving a few files?
On Tue, Nov 23, 2010 at 01:56:01PM +0100, Thomas Ronner wrote: > On 11/23/10 1:45 PM, Andrew Reilly wrote: > >No, I don't like tar, rsync and friends for backups: they don't > >deal well with hard links, special files or sparse files. > > rsync -avHxS --delete --numeric-ids /src/. /dst/. > > Handles sparse files (S) and hard links (H). Never had any trouble with > special files. What sort of special files are not handled correctly by > rsync? I'd like to know because I'm relying on rsync for backups for > years on my home network. I remember having problems with hard links, but it's possible that I wasn't using rsync correctly. Of special files, I don't remember non-dump backups doing well with the unix-domain sockets that were liberally used and tricky to set up right for djb's daemon-tools. Most uses of sockets put them in /tmp, don't get backed up, and they don't need to persist. Dan puts them in /var, and they're expected to persist across reboots, which means they need to be backed-up. Maybe rsync and modern tar handle these OK, but I remember at least one of them getting wedged just trying to read one as a file. The special files in /dev used to be a problem too, but that's gone away, now that we have devfs. I really like dump/restore. I expect that I will miss them. Cheers, -- Andrew ___ 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: ZFS backups: retrieving a few files?
On Mon, Nov 22, 2010 at 10:26:30AM -0500, Jonathan Stewart wrote: > On 11/22/2010 6:35 AM, Andrew Reilly wrote: > >Dump/restore doesn't work for ZFS. I *think* that I'm running > >backups in the appropriate equivalent fashion: I take file > >system snapshots (both absolute == level 0) and relative > >(incremental), and zfs send those to files on the backup disk. > > This is actively discouraged, there is no recovery ability when > receiving zfs streams so 1 bad bit would invalidate your entire backup. > > The currently accepted practice is to create a ZFS file system on the > backup drive and just keep sending incremental snapshots to it. As long > as the backup drive and host system have a snapshot in common you can do > incremental transfers. This way you only have to keep the most recent > snapshot on the main system and can keep as many as you have space for > on the backup drive. You also have direct access to any backed up > version of every file. For those playing along at home, I'll issue a small warning, based on today's frolics: Say, for example, one had done a: zfs send -vR tank/h...@0 | zfs receive -d /backup/snapshots in order to experiment with this strategy. One would then become alarmed when one discovered that the receive mechanism also invoked the mountpoint= parameter of the source filesystem, and the zfs propensity for just doing stuff, and boom: you have a read-only version of your home directory mounted *on top of* your actual home directory... Required a reboot to single user mode, to go in and reset the mountpoint setting for the newly created file system (by way of hitting the power switch, after using zfs unmount -f to royally screw things up, preventing subsequent network logins.) Left wondering how to manage that change as part of an automated backup schedule. I think that this backup strategy has a few sharp edges... No, I don't like tar, rsync and friends for backups: they don't deal well with hard links, special files or sparse files. Cheers, -- Andrew ___ 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: ZFS backups: retrieving a few files?
On Mon, Nov 22, 2010 at 10:26:30AM -0500, Jonathan Stewart wrote: > On 11/22/2010 6:35 AM, Andrew Reilly wrote: > >Dump/restore doesn't work for ZFS. I *think* that I'm running > >backups in the appropriate equivalent fashion: I take file > >system snapshots (both absolute == level 0) and relative > >(incremental), and zfs send those to files on the backup disk. > > This is actively discouraged, there is no recovery ability when > receiving zfs streams so 1 bad bit would invalidate your entire backup. Hmm. Isn't that a problem that also affects the "sending snapshots" scheme that you describe, below? > The currently accepted practice is to create a ZFS file system on the > backup drive and just keep sending incremental snapshots to it. As long > as the backup drive and host system have a snapshot in common you can do > incremental transfers. This way you only have to keep the most recent > snapshot on the main system and can keep as many as you have space for > on the backup drive. You also have direct access to any backed up > version of every file. That sounds like a very cool notion. Not unlike the time-machine scheme. Interesting how different capabilities require going back and re-thinking the problem, rather than just trying to implement the old solution with the new tools. I'll see how I go with it... Cheers, -- Andrew ___ 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"
ZFS backups: retrieving a few files?
Hi there, Being a cutting-edge hipster, my new personal server is using a ZFS RAIDZ array, where my older system used UFS on a GMIRROR. This is, by and large, a joy: ZFS rocks. One issue that I'm having difficulty coming to grips with, though, is that of backup. I used to do a weekly cycle (with a two week retention) of incremental backups to an external hard drive. Dump/restore allowed this to be useful both for disaster (hardware failure) recovery and for clumsiness (file destruction) recovery. Dump/restore doesn't work for ZFS. I *think* that I'm running backups in the appropriate equivalent fashion: I take file system snapshots (both absolute == level 0) and relative (incremental), and zfs send those to files on the backup disk. I haven't tried the recovery procedure yet, but it seems that one would zfs receive the same files to snapshots, and then either grab the files scrunged or perform the snapshot->working file system upgrade process described in the manual, depending on the situation. The troubling aspect of this plan is that it would seem that grabbing just a few files would require space in the working zpool equivalent to the whole backed-up file system, for the zfs receive of the snapshot. Contrast this with restore, which had a nice interactive (or command line) mode of operation that could retrieve nominated files or directories, requiring only space for the results. Is there any similar tool that can operate on a ZFS "send" serialization? It would seem that the information must be "in" there somewhere, but I've not heard of it. Clues? How does everyone else manage this? Cheers, -- Andrew ___ 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: TTY task group scheduling
On Thu, Nov 18, 2010 at 06:23:24PM +, Alexander Best wrote: > you think so? judging from the videos the changes are having a huge impact > imo. On Linux. Have you ever seen those sorts of UI problems on FreeBSD? I don't watch much video on my systems, but I haven't seen that. FreeBSD has always been good at keeping user-interactive processes responsive while compiles or what-not are going on in the background. Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On Tue, Nov 16, 2010 at 07:41:02PM -0500, Jung-uk Kim wrote: > On Tuesday 16 November 2010 06:55 pm, Andrew Reilly wrote: > > On Tue, Nov 16, 2010 at 06:36:16PM -0500, Jung-uk Kim wrote: > > > You may try "sysctl hw.acpi.handle_reboot=1". If it works, just > > > add it in /etc/sysctl.conf. > > > > > > FYI, it is automatically set since r213755 and MFC'd to stable/8 > > > as r215006. > > > > I've just checked, and my system has that sysctl knob set to 1 > > already. I don't know how long that has been the case, though: > > perhaps it has only been since my last boot anyway? I will > > give reboot another try when I am next in the same room as the > > machine... > > I guess you already have r215006, then. :-) > > If it appeared automagically, that means your system supports the ACPI > reset register. If you still have reboot issues, please let me know. I'm happy to report that (probably as a result of this MFC), my system has just survived its first warm reboot! Yay! Thanks very much. (Need for console access just got much smaller!) Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
Hi John, On 18/11/2010, at 23:59 , John Baldwin wrote: > You used devinfo -v, so it shows the devices that exist even if they failed > to attach. Try just using 'devinfo' and seeing if est1 still shows up. OK, you're right: running without -v shows only est0: nexus0 apic0 ram0 acpi0 cpu0 acpi_perf0 est0 p4tcc0 cpufreq0 cpu1 p4tcc1 cpufreq1 acpi_button0 pcib0 <...> Is est. involved in the reboot question? Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
Hi Alexandre,
On Wed, Nov 17, 2010 at 06:56:53PM -0500, Alexandre Sunny Kovalenko wrote:
> On Thu, 2010-11-18 at 10:40 +1100, Andrew Reilly wrote:
> > dev.cpu.0.%desc: ACPI CPU
> > dev.cpu.0.%driver: cpu
> > dev.cpu.0.%location: handle=\_PR_.CPU0
> > dev.cpu.0.%pnpinfo: _HID=none _UID=0
> > dev.cpu.0.%parent: acpi0
> > dev.cpu.0.freq: 2933
> > dev.cpu.0.freq_levels: 2933/9 2799/83000 2666/77000 2533/71000
> > 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000
> > 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250
> > 599/5000 449/3750 299/2500 149/1250
> > dev.cpu.0.cx_supported: C1/3 C2/205 C3/245
> > dev.cpu.0.cx_lowest: C1
> > dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us
> > dev.cpu.1.%desc: ACPI CPU
> > dev.cpu.1.%driver: cpu
> > dev.cpu.1.%location: handle=\_PR_.CPU1
> > dev.cpu.1.%pnpinfo: _HID=none _UID=0
> > dev.cpu.1.%parent: acpi0
> > dev.cpu.1.cx_supported: C1/3 C2/205 C3/245
> > dev.cpu.1.cx_lowest: C1
> > dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us
> >
> > Since the cpufreq man page lists the inability to set the
> > frequency of different CPUs differently, perhaps this isn't a
> > bug at all?
> >
> > Cheers,
> >
>
> Does portion of 'devinfo -rv' similar to the snippet below show 'est'
> attached to both CPUs?
> <...>
> cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0
> ACPI I/O ports:
> 0x1014
> 0x1015
> acpi_perf0
> acpi_throttle0
> coretemp0
> ==> est0
> p4tcc0
> cpufreq0
> cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1
> ACPI I/O ports:
> 0x1014
> 0x1015
> acpi_perf1
> acpi_throttle1
> coretemp1
> ==> est1
> p4tcc1
> cpufreq1
> <...>
Yes, but as you can see they are not nested under coretemp. devices:
cpu0 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU0
ACPI I/O ports:
0x414
0x415
acpi_perf0
est0
p4tcc0
cpufreq0
cpu1 pnpinfo _HID=none _UID=0 at handle=\_PR_.CPU1
ACPI I/O ports:
0x414
0x415
acpi_perf1
est1
p4tcc1
cpufreq1
This seems to be at odds with the dmesg and sysctl view of things?
Cheers,
--
Andrew
___
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: Console options for legacy-free mini-itx server?
On Wed, Nov 17, 2010 at 06:26:56PM -0500, Alexandre Sunny Kovalenko wrote: > On Thu, 2010-11-18 at 10:06 +1100, Andrew Reilly wrote: > > On Wed, Nov 17, 2010 at 01:42:15PM +1100, Ian Smith wrote: > > > I'm used to seeing est either attach to both CPUs, or fail to attach to > > > either CPU. Here it's attached to cpu0, but not to cpu1. Is that odd? > > > > It seems odd, but since I don't know what est does (there isn't > > a man page), I'm not sure how it (possibly) being broken > > affects me. > > > > Cheers, > > > > Faint reference to 'est' could be found in 'man cpufreq'. Thanks for the reference! From reading that, it seems as though the sysctl-exposed functionality matches the dmesg.boot description (speed controls only available on cpu 0): dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_PR_.CPU0 dev.cpu.0.%pnpinfo: _HID=none _UID=0 dev.cpu.0.%parent: acpi0 dev.cpu.0.freq: 2933 dev.cpu.0.freq_levels: 2933/9 2799/83000 2666/77000 2533/71000 2399/65000 2266/59000 2133/53000 1999/46000 1866/4 1733/34000 1599/28000 1466/22000 1333/16000 1199/1 1049/8750 899/7500 749/6250 599/5000 449/3750 299/2500 149/1250 dev.cpu.0.cx_supported: C1/3 C2/205 C3/245 dev.cpu.0.cx_lowest: C1 dev.cpu.0.cx_usage: 100.00% 0.00% 0.00% last 311us dev.cpu.1.%desc: ACPI CPU dev.cpu.1.%driver: cpu dev.cpu.1.%location: handle=\_PR_.CPU1 dev.cpu.1.%pnpinfo: _HID=none _UID=0 dev.cpu.1.%parent: acpi0 dev.cpu.1.cx_supported: C1/3 C2/205 C3/245 dev.cpu.1.cx_lowest: C1 dev.cpu.1.cx_usage: 100.00% 0.00% 0.00% last 191us Since the cpufreq man page lists the inability to set the frequency of different CPUs differently, perhaps this isn't a bug at all? Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On Wed, Nov 17, 2010 at 01:42:15PM +1100, Ian Smith wrote: > I'm used to seeing est either attach to both CPUs, or fail to attach to > either CPU. Here it's attached to cpu0, but not to cpu1. Is that odd? It seems odd, but since I don't know what est does (there isn't a man page), I'm not sure how it (possibly) being broken affects me. Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On Tue, Nov 16, 2010 at 06:36:16PM -0500, Jung-uk Kim wrote: > On Sunday 14 November 2010 11:55 pm, Andrew Reilly wrote: > > Oh: the other thing about this system: I can't warm-start > > it, have to power down and then manually hit the power-on > > button. Attempting to reboot leaves the console sitting at > > something like "Stopping other CPUs" forever. I assume that > > this is a BIOS config problem, but haven't found the right > > control knob yet. I've tried turning hyperthreading on and off: > > no difference. Reading the kernel code around that message > > suggests that rebooting involves getting the keyboard controller > > to send an NMI, and I wonder if the legacy-free no-keyboard > > state of my system is having an effect on that, too? > > You may try "sysctl hw.acpi.handle_reboot=1". If it works, just add > it in /etc/sysctl.conf. > > FYI, it is automatically set since r213755 and MFC'd to stable/8 as > r215006. I've just checked, and my system has that sysctl knob set to 1 already. I don't know how long that has been the case, though: perhaps it has only been since my last boot anyway? I will give reboot another try when I am next in the same room as the machine... I still track -stable with csup, because I believed that to be the officially preferred method. Is it OK to track directly with svn, now? More specifically, how can one correlate svn revision numbers against a csup-extracted source tree? Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On Mon, Nov 15, 2010 at 12:03:38PM +, Bob Bishop wrote: > Your board has a serial port: > [...more stuff deleted...] > > > uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0 > > uart0: [FILTER] > [etc] Ha! I'd not noticed that. Wasn't looking for it, I guess. > The diagram on page 12 of > http://downloadmirror.intel.com/18702/eng/DH57JG_ProductGuide03_English.pdf > shows the connector (labelled R). Thanks! I'll have to find a cable or something Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
On Mon, Nov 15, 2010 at 10:52:10AM +0200, Andriy Gapon wrote: > > If I find a USB-to-RS232 dongle, will the console mechanism be > > able to find it? I worry that only legacy-16550-ish serial > > ports need apply. > > > > Any other possibilities or common practices? > > Is there a firewire port? I'm afraid not. Also, I'm using the single PCIe slot for more SATA ports. Cheers, -- Andrew ___ 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: Console options for legacy-free mini-itx server?
It's been suggested that I make the output of dmidecode (from ports/sysutils), pciconf -lv and dmesg.boot available, to help answer my previosu question. Since all of that output is relatively small and I don't really have a good web site to put it, I'll just include it, below. Hope this helps! dmidecode: # dmidecode 2.10 SMBIOS 2.5 present. 25 structures occupying 1318 bytes. Table at 0x000EB240. Handle 0x, DMI type 4, 35 bytes Processor Information Socket Designation: XU1 Type: Central Processor Family: Other Manufacturer: Intel(R) Corporation ID: 52 06 02 00 FF FB EB BF Version: Intel(R) Core(TM) i3 CPU 530 @ 2.93GHz Voltage: 1.1 V External Clock: 133 MHz Max Speed: 4000 MHz Current Speed: 2935 MHz Status: Populated, Enabled Upgrade: Other L1 Cache Handle: 0x0004 L2 Cache Handle: 0x0003 L3 Cache Handle: 0x0001 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Handle 0x0001, DMI type 7, 19 bytes Cache Information Socket Designation: Unknown Configuration: Enabled, Not Socketed, Level 3 Operational Mode: Write Back Location: Internal Installed Size: 4096 kB Maximum Size: 4096 kB Supported SRAM Types: Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 16-way Set-associative Handle 0x0002, DMI type 7, 19 bytes Cache Information Socket Designation: Unknown Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Single-bit ECC System Type: Data Associativity: 8-way Set-associative Handle 0x0003, DMI type 7, 19 bytes Cache Information Socket Designation: Unknown Configuration: Enabled, Not Socketed, Level 2 Operational Mode: Write Back Location: Internal Installed Size: 256 kB Maximum Size: 256 kB Supported SRAM Types: Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Single-bit ECC System Type: Unified Associativity: 8-way Set-associative Handle 0x0004, DMI type 7, 19 bytes Cache Information Socket Designation: Unknown Configuration: Enabled, Not Socketed, Level 1 Operational Mode: Write Back Location: Internal Installed Size: 32 kB Maximum Size: 32 kB Supported SRAM Types: Asynchronous Installed SRAM Type: Asynchronous Speed: Unknown Error Correction Type: Single-bit ECC System Type: Instruction Associativity: 4-way Set-associative Handle 0x0005, DMI type 0, 24 bytes BIOS Information Vendor: Intel Corp. Version: JGIBX10J.86A.0217.2010.0120.2350 Release Date: 01/20/2010 Address: 0xF Runtime Size: 64 kB ROM Size: 8192 kB Characteristics: PCI is supported BIOS is upgradeable BIOS shadowing is allowed Boot from CD is supported Selectable boot is supported EDD is supported 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Function key-initiated network boot is supported Targeted content distribution is supported BIOS Revision: 0.0 Firmware Revision: 0.0 Handle 0x0006, DMI type 1, 27 bytes System Information Manufacturer: Product Name: Version: Serial Number: UUID: 9AC7F680-1607-11DF-8BC1-00270E0FB8E9 Wake-up Type: Power Switch SKU Number: Not Specified Family: Not Specified Handle 0x0007, DMI type 2, 20 bytes Base Board Information Manufacturer: Intel Corporation Product Name: DH57JG Version: AAE70930-302 Serial Number: BTJG006000R9 Asset Tag: Base Board Asset Tag Features: Board is a hosting board Board is replaceable Location In Chassis: Base Bo
Console options for legacy-free mini-itx server?
Hi there, I've replaced my old desktop with a laptop and a server, which is mostly working great. Naturally, the server is running FreeBSD-stable. It's built on an intel i3 MiniITX motherboard that has lots of SATA sockets, a respectable number of USB sockets, gigabit ethernet, eSATA, DVI, ... but no serial ports or PS/2 keyboard or mouse ports. Most of the time this is fine, but I've found that sometimes it is very nice to be able to debug something at a console. Particularly if something goes wrong when doing an upgrade of some sort. I've discovered that I can use the old VGA screen and USB keyboard for a console if I have them plugged in at boot time, but if something goes wrong after boot, plugging a keyboard in doesn't seem to help. If I find a USB-to-RS232 dongle, will the console mechanism be able to find it? I worry that only legacy-16550-ish serial ports need apply. Any other possibilities or common practices? Oh: the other thing about this system: I can't warm-start it, have to power down and then manually hit the power-on button. Attempting to reboot leaves the console sitting at something like "Stopping other CPUs" forever. I assume that this is a BIOS config problem, but haven't found the right control knob yet. I've tried turning hyperthreading on and off: no difference. Reading the kernel code around that message suggests that rebooting involves getting the keyboard controller to send an NMI, and I wonder if the legacy-free no-keyboard state of my system is having an effect on that, too? Cheers, -- Andrew ___ 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: ts_to_ct flood on 8.1-STABLE
Jeremy, Thanks for the quick response. The source/responsible code for the printing is in function clock_ts_to_ct() in: src/sys/kern/subr_clock.c I took a look at the code in an attempt to divine the reason for the frequent messages, without success. Any idea why I see so many? I'm not aware of any special timing related configuration. I do run ntpd, of course. In examples I've found, others seem to get just the one ts_to_ct message. 52 #define ct_debug bootverbose Are your systems booting verbosely? By default, yes. I'd like to keep it that way without having to hack the source. Is there another option? -- -Andrew J. Caines- Unix Systems Engineer a.j.cai...@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing ___ 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"
ts_to_ct flood on 8.1-STABLE
Since installing 8.1-RC2 and now on up-to-date RELENG_8 I am frequently getting kern.crit messages like ts_to_ct(1281661818.743348859) = [2010-08-13 01:10:18] and have been unable so far to determine their origin or purpose. I saw no such messages while running 7.x or earlier releases. AFAICT the system[1] is running fine. Athlon XP, 2GB, nVidia mobo and GPU, Intel and Realtek NICs, various ATA and USB disks all in a custom kernel. I've posted details of the system configuration[2]. Advice would be appreciated. [1] http://halplant.com:2001/systems.html#HAL1 [2] http://halplant.com:2001/server/config/HAL1/ -- -Andrew J. Caines- Unix Systems Engineer a.j.cai...@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing ___ 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: FreeBSD 8.1 make world FAILED!
James, I install FreeBSD 8.1 RELEASE today and want use "make world" to upgrade to 8.1-STABLE, See the instructions on updating your system at the end of src/UPDATING, specifically "To rebuild everything and install it on the current system", and the Handbook. -- -Andrew J. Caines- Unix Systems Engineer a.j.cai...@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing ___ 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: More buzzing fun with snd_emu10kx - but now with more determinism!
On 07/11/2010 17:03, Garrett Cooper wrote:
The problem appears to be with vchan-related code. If I start up 4+
applications on my machine that access the audio device, all goes
wonky on the 4+ allocation
I can confirm this behaviour, which seems odd with hw.snd.maxautovchans
defaulting to 16. It does not appear to be affected by increasing
dev.pcm.0.play.vchans up fron the default of 2 (as I apparently did at
some point up to 7.x), though reading sound(4) it's clear I don't fully
understand vchans.
A problem I encountered with snd_emu10kx in a clean 8.1RC2 install which
was not present in any previous version is a faint rapid mechanical
clicking sound adjustable with the "cd" mixer setting.
The only non-default audio setting I have is in loader.conf:
hint.emu10kx.0.multichannel_disabled="1"
hint.emu10kx.1.disabled="1"
pcm0: on emu10kx0
pcm0:
pcm0: Codec features 5 bit master volume, no 3D Stereo Enhancement
FreeBSD Audio Driver (newpcm: 32bit 2009061500/i386)
Installed devices:
pcm0: on emu10kx0 (4p:2v/1r:1v) default
snddev flags=0x2e2
[pcm0:play:dsp0.p0]: spd 48000, fmt 0x00200010, flags 0x2100,
0x0004
interrupts 726, underruns 0, feed 5, ready 0
[b:4096/2048/2|bs:4096/2048/2]
channel flags=0x2100
...
--
-Andrew J. Caines- Unix Systems Engineer a.j.cai...@halplant.com
FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/
"Machines take me by surprise with great frequency" - Alan Turing
___
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: Unable to boot FreeBSD 8.0-p3
GNUbie, > Kindly check the screenshot at http://imagebin.org/102605 for the > screen output during bootup. I don't know how to recover this system > and hopefully someone could help me on how to do it. Can you boot the old kernel[1]? [1] See http://www.freebsd.org/doc/en/books/handbook/kernelconfig-trouble.html -- -Andrew J. Caines- Unix Systems Engineer a.j.cai...@halplant.com FreeBSD/Linux/Solaris, Web/Mail/Proxy/... http://halplant.com:2001/ "Machines take me by surprise with great frequency" - Alan Turing ___ 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: Enabling watchdog
On Sat, May 8, 2010 at 2:06 PM, rihad wrote: > Hi, I'm thinking of enabling the watchdog on our Dell PowerEdge 2950 / > FreeBSD 8.0 amd64, so that it reboots the machine in case of lockups. > Right now it doesn't work: > I installed watchdogd on a few 8-core Dell PowerEdge 1950, which I assume are similar to the 2950s. I wrote about how to do this on my blog[1] last year. However, something in the last couple of months has broken watchdog and my machines causing them to regularly lock up. I'm unsure what has changed, and I didn't have time to investigate so I just turned it off and everything is now fine. Andrew [1] http://bramp.net/blog/freebsd-software-watchdog ___ 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"
Is swap on ZFS supposed to work?
I have a machine where I enabled swap on ZFS somewhat accidentally (really wanted to dump to ZFS, but that didn't pan out) and then forgot about it. A month later, under a heavy load (make -j8 buildworld) it hung with: swap_pager: indefinite wait buffer: bufobj: 0, blkno: 289218, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 290789, size: 4096 swap_pager: indefinite wait buffer: bufobj: 0, blkno: 305343, size: 4096 <...> scrolling on console. I made 2 more attempts to buildworld before I finally remembered the ZFS swap partition and removed it, which allowed the buildworld to complete without hanging the machine. It is running 8.0-STABLE #1 r205446M (amd64) and has very little (512MB) RAM. Drew ___ 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: gmirror(8) rebuild speed
On Thu, 22 Apr 2010 11:07:43 +0200 "Patrick M. Hausen" wrote: > When the rebuild is bringing your production system to > a crawl and you are willing to face the tradeoff - hopefully > because you have an additional backup for the worst case. Fair enough. I've noticed some slowdowns with re-builds, but I generally thought it best to get it over-with as quickly as possible. It's possible to turn off auto-synch, so that you can start the re-build at the beginning of a quiet-time, if there is one. I guess if the system is in demand 24/7 you'll need something else though. Cheers, -- Andrew ___ 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: gmirror(8) rebuild speed
On Thu, Apr 22, 2010 at 09:19:29AM +0200, Jordi Espasa Clofent wrote: > I wonder if is possible to configure the gmirror rebuild speed. > Neither I've found any related info in the net nor the man pages. To make it slower, I assume? When is that a good idea? Cheers, -- Andrew ___ 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: rc(8) script -- waiting for the network to become usable
On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote: > I'd like to discuss the possibility of introduction of a new script into > /etc/rc.d base system a script, which when enabled, would provide a way > to wait until the IP networking layer (using ping(8)) is up and usable > before continuing with daemon startup. > > Let's discuss. :-) > > > HISTORY > = > The situation which brought this debacle to my attention: > > I found that on reboot of some of our systems, ntpdate (used to sync the > clock initially before ntpd would be started) wouldn't work. The daemon > would report that it couldn't resolve any of the FQDNs within ntp.conf, > and would therefore act as a no-op before continuing on. By way of discussion, I'd just like to re-iterate what I said the first time around: it must be understood that this sort of thing is a (necessary) hacky-workaround that should ultimately be unnecessary. In preference, we should work on the failing daemons or hassle up-stream daemon authors so that the daemons in question either (a) retry until they *do* get the information they're after or (b) fail properly, so that they can be restarted by an external process monitoring framework like sysutils/daemontools or launchd. The reasoning is simple: network outage is something that can happen even after startup, and when network connectivity returns, the routing and addresses that are visible won't necessarily be the same. Consider laptops that suspend, as a particular example. Or mobile devices that switch from wi-fi to cellular networking to no connectivity on a regular basis. The "get it right at boot time" model is important and traditional, but (I think) a fragile and diminishing fraction of use cases. Our rc-ng framework favours solution (a). I'm more a fan of approach (b), myself: I use daemontools for many services, and I like the way that launchd works on my Mac laptops. Cheers, -- Andrew ___ 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: Freeze on my laptop.
Demelier David wrote: I'm so sad because FreeBSD is the one which can runs almost perfectly on my laptop. But it freezes. Sometime I just do anything and I want to click on a link in firefox, or open a terminal and then freeze. Sounds like a problem with the X graphics driver.. when it next happens, can you press Alt+F1 or Ctrl+Alt+F1 to get back to a text console? You might like to try upgrading your version of X to a newer version. - Andrew ___ 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: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
The statements about the scheduler flipping between cores is also somewhat false, ULE does the right thing now for long-running computational threads. Furthermore, I can't see how a Gflops benchmark which fits in the CPU cache has anything to do with the memory architecture of the operating system. I assume to reach these results the benchmark was multi-threaded, and so I think I'd start by looking at the scheduler. Before that I'd probably look at the libraries, how they were compiled, differences in the compiler etc. - Andrew ___ 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: Jails & 8.0
> Date: Thu, 11 Mar 2010 22:53:43 -0500 > From: st...@ibctech.ca > To: freebsd-stable@freebsd.org > CC: freebsd-j...@freebsd.org > Subject: Jails & 8.0 > > Sorry for the cross-post, but this is a 'thank-you', not a request for help. > > I want to express my sincere appreciation for all of those who made > FreeBSD jails a viable virtual server solution for us who required > multiple IPs, particularly those who demand/require IPv6 support: > > > Not only that, FreeBSD 8 is just absolutely fantastic. Although I've > only been using FreeBSD since 4.3, I never could have dreamt that the OS > would ever have a release that is so close to its core values, but at > the same time so feature rich and stable, particularly for those who > like to use the OS as a network (L2/L3) platform in many cases. > > My hats off. Thanks all! What a tremendous job. > I couldn't agree more: FreeBSD today is really able to bring a tremendous value to a lot of enterprise-grade environments. Coming from a deep Microsoft experience as multi-certified MSFT specialist, I have been playing with FreeBSD since the 6.0-RELEASE, and I must say that FreeBSD is perhaps the best OS when you need to effectively consolidate workloads and administration efforts. The Jail system is simply amazing, and I'm really excited to see how the VIMAGE feature, when it will be released as "producion-ready", will increase even more this value. To meet the always evolving business requirements today, IT pros need a simplified architecture to keep TCP as low as possible, while sustaining more and more workloads. Tools such ezjail, which allow to maintain a lot of jails as they were almost only one, make businesses to obtain a true "consolidation", whom other proprietary and open-sourced OSes are far away to reach. So... thank you very much, to anyone who contributed and still works to make this great project to evolve! I guess to to help you a bit by advocating FreeBSD as much as I can among customers, partners and institutions in my country. But a big work still remains to be done: to bring to BSD technologies the visibility they deserve among IT managers and professionals working in business environments. I'll do my best to make this happen in my country, I hope, also with the support of the FreeBSD Foundation and the BSD Certification Group, whom I'm in the process to make a few proposals to. Sincerely. Andrew _ Your E-mail and More On-the-Go. Get Windows Live Hotmail Free. https://signup.live.com/signup.aspx?id=60969___ 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"
Neighbors inactivity
I have a few NASes based on FreeBSD 7.2 and quagga 0.99.14, they all have same configuration with little changes. When I add to network a test server based on FreeBSD 8.0-STABLE with quagga 0.99.15, other servers doesn't receive HELLO packets from him. nas9# tcpdump -i vr0 proto ospf 13:24:04.591907 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:09.594136 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:14.596375 IP 193.62.62.14a> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:19.598678 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:24.600867 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:29.603050 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:34.605322 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:39.607564 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 13:24:44.609799 IP 193.62.62.14> OSPF-ALL.MCAST.NET: OSPFv2, Hello, length 44 Counter of multicast packets on switch port constantly increasing. What the reason of inaccessibility other servers over multicast? ___ 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: hardware for home use large storage
http://www.supermicro.com/products/motherboard/ATOM/ICH9/X7SPA.cfm?typ=H Supermicro just released a new Mini-ITX fanless Atom server board with 6xSATA ports (based on Intel ICH9) and a PCIe 16x slot. It takes up to 4GB of RAM, and there's even a version with KVM-over-LAN for headless operation and remote management. ___ 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: ionice in FreeBSD?
Jordi Espasa Clofent wrote: ¿Is there some ionice(1) equivalent in FreeBSD? No. - Andrew ___ 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: 32-bit jails on a 64-bit system?
> Date: Thu, 21 Jan 2010 10:12:20 +0100 > From: 000.f...@quip.cz > To: sp...@bway.net > CC: freebsd-j...@freebsd.org; freebsd-stable@freebsd.org > Subject: Re: 32-bit jails on a 64-bit system? > >> The jail(8) subsystem has been updated. Changes include: >> >> Compatibility support which permits 32-bit jail binaries to be used on >> 64-bit systems to manage jails has been added. >> >> >> I know prior to 8.0 with some fancy footwork you could do some >> interesting things (for example, I have a jail running a bunch of 32-bit >> 4.11 stuff on a 7.2 amd64 box), but it was not easy. >> >> Looking at the jail manpage and handbook entries, I'm not seeing >> anything that further explains the changes. I've been able to get some >> things working in a test setup, but not everything. Any pointers to what >> exactly that blurb in the release notes actually means? Google is >> getting me nowhere. >> > > (freebsd-jail@ was added in to Cc:) > > I think it is nothing new to 8.0, it is the same as release note for 7.2. > > I didn't test it, but I think you can install (copy) i386 jail (or whole > system) in to amd64 host and just run it as any other jail. > It might be useful this thread about 32-bit jail on 64-bit host: http://lists.freebsd.org/pipermail/freebsd-i386/2009-January/007553.html Regards. Andrew _ Windows Live Hotmail: Your friends can get your Facebook updates, right from Hotmail®. http://www.microsoft.com/middleeast/windows/windowslive/see-it-in-action/social-network-basics.aspx?ocid=PID23461::T:WLMTAGL:ON:WL:en-xm:SI_SB_4:092009___ 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: An old gripe: Reading via mmap stinks
Hi Mikhail, I assume these tests were done on UFS. Have you tried ZFS? I'm curious to see the results. - Andrew ___ 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: ZFS performance degradation over time
Ivan Voras wrote: It is true that ZFS in theory doesn't do very well with random writes of any kind - the kind that torrent clients do should actually be the worst case for ZFS, *but*, this very much depends on the actual workload. ZFS has aggressive read-ahead for sequential read-aheads, so its worth noting that the performance problem can be mitigated by having lots of RAM free for read-ahead, as well as multiple vdevs in the zpool (so that it can be seeking all disks at once) - Andrew ___ 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: amd64/139859: commit references a PR
On Thu, Oct 29, 2009 at 03:50:05PM +, dfilter service wrote: > Modified: releng/8.0/UPDATING > > == > --- releng/8.0/UPDATING Thu Oct 29 15:39:30 2009(r198605) > +++ releng/8.0/UPDATING Thu Oct 29 15:42:50 2009(r198606) > @@ -566,6 +566,15 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 8. > userland (libpmc(3)) and the kernel module (hwpmc(4)) in > sync. > > +20081009: > +atapci kernel module now includes only generic PCI ATA > +driver. AHCI driver moved to ataahci kernel module. That probably wants to say 20091029? Cheers, -- Andrew ___ 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: uart(4) on stable/7
On Mon, Oct 26, 2009 at 02:57:42PM -0700, Matthew Fleming wrote: > I am interested in using uart(4) instead of sio(4) on stable/7, to ease > our eventual transition to stable/8 or CURRENT. I added device uart and > changed up /boot/device.hints (there were no entries in /etc/ttys that > mentioned sio) ... It doesnt mention sio but you do need to change ttyd* to ttyu*, which are the sio and uart tty devices respectively. Andrew ___ 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: Some questions about da0 on USB2 (recent bad behaviour)
On Sat, Oct 24, 2009 at 07:07:00PM +, b. f. wrote: > >That is: it seems to work fine for some fraction of a minute > >(doesn't seem to be longer than a minute, anyway), and then > >stops completely for several minutes (processes reading or > >writing sit in "D" state in ps) and then starts again, after > >logging "Request completed with CAM_REQ_CMP_ERR\nRetrying > >Command". > > In the past week or so, Alexander Motin (m...@freebsd.org) and Andrew > Thompson (thom...@freebsd.org) have made a number of related changes > to cam and usb in the P4 repository, and in 9-CURRENT. Some of these > may address your problem. I'm not sure when they will be back-ported > to 8.X. You may wish to try out the latest version of -CURRENT, to > see if it solves your problem(s); or to contact them. I've done this, and it seems to have worked. It seems possible that the bulk throughput (measured by systat while doing a cat /backup/bigfile >/dev/null) might even have increased a bit, but maybe not. The big improvement is that the transfer isn't pausing any more. No more CAM_REQ_CMP_ERR messages. Thanks b. f. for the suggestion, and thanks Alexander and Andrew for the fixes! I haven't run -current for, probably, ten years, and the occasional messages about lock-order-reversals worry me a bit, but don't seem to be doing any harm. Should I report them? In a PR? Please count this message as a vote for MFC'ing those cam and usb changes to 8-STABLE. Cheers, -- Andrew ___ 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: Some questions about da0 on USB2 (recent bad behaviour)
Just a follow-up with some more information: I now doubt that the problem that I reported in the original message is the drive dying: I've just done some read tests (cat largefile >/dev/null) on the other USB2-attached drive (also a Western Digital MyBook, but this one is a USB2+Firewire one with 1TB, while the other one was just USB2 with 750G.) I'm seeing essentially the same behaviour on that drive, too. That is: it seems to work fine for some fraction of a minute (doesn't seem to be longer than a minute, anyway), and then stops completely for several minutes (processes reading or writing sit in "D" state in ps) and then starts again, after logging "Request completed with CAM_REQ_CMP_ERR\nRetrying Command". I reckon that the duty cycle of useful behaviour is is a bit less than a third. Any chance this is some new badness in the USB+umass stack? Anything that I can poke or prod to make it behave better? Any way that I can find out where it's going awry? I don't have kdb in my kernel, but everything not directly connected to these USB devices seem to be behaving themselves completely. Oh: stoppage on the two drives doesn't seem to be chronologically correllated. Cheers, -- Andrew ___ 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"
Some questions about da0 on USB2 (recent bad behaviour)
Hi there, I have a system with a couple of Western Digital "MyBook" USB2 drives connected to it, and have started seeing some odd behaviour that I am not sure how to identify the cause of. Perhaps someone could offer a suggestion or two? The behaviour that I've noticed (and I can't remember any particular event precipitating this, but I do track 8-STABLE approximately weekly, so things do change from time to time...) is that the drive will just stop for a couple of minutes, and then continue what it was doing. For a while that's all I could see: no error messages at all. The last time I booted, I turned on verbose booting and now I see that these periods of inactivity result in streams of syslog messages like: Oct 24 12:48:55 duncan kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Oct 24 12:48:55 duncan kernel: (da0:umass-sim0:0:0:0): Retrying Command Oct 24 12:50:24 duncan kernel: (da0:umass-sim0:0:0:0): Request completed with CAM_REQ_CMP_ERR Oct 24 12:50:24 duncan kernel: (da0:umass-sim0:0:0:0): Retrying Command The retry seems to be successful, because I'm not getting any hard error messages anywhere, and the disk activity does seem to proceed afterwards. The disk drive isn't making any bad/broken noises, either. That drive is, according to dmesg.boot: ugen1.2: at usbus1 umass0: on usbus1 umass0: SCSI over Bulk-Only; quirks = 0x Root mount waiting for: usbus1 umass0:1:0:-1: Attached to scbus1 (probe0:umass-sim0:0:0:0): Down reving Protocol Version from 2 to 0? pass0 at umass-sim0 bus 0 target 0 lun 0 pass0: Fixed Direct Access SCSI-0 device pass0: 40.000MB/s transfers GEOM: new disk da0 da0 at umass-sim0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 715404MB (1465149168 512 byte sectors: 255H 63S/T 91201C) What is the likelihood that these pauses and command retries are a sign that this specific drive is in the process of dying, physically? If that were the case, are there any diagnostic tools that I could run against it to show, say, internal error logs? What is the significance of the "sim" part of the device designation umass-sim0? I've looked in all of the manual pages I can think of, but that clearly isn't enough. usbdevs -v says "no USB controllers found", which I thought a bit unuseful. I assume it is *supposed* to work, is there a trick? usbconfig shows my connected USB devices and hubs: ugen0.1: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON ugen1.1: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.2: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen1.3: at usbus1, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON ugen0.2: at usbus0, cfg=0 md=HOST spd=LOW (1.5Mbps) pwr=ON ugen0.3: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON At this rate the dump/restore backup that I'm running to get the data off it will take a little over a day to finish (according to dump), even though systat shows the drive doing about 8MB/s while it's working, which would allow the dump to finish in about eight hours. These modern, large drives are all very well, but they make doing any kind of system reconfiguration or backup really time consuming... Cheers, -- Andrew ___ 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: Excessivly cheap USB device issue
On Tue, Sep 29, 2009 at 05:11:24AM -0500, Robert Noland wrote: > On Tue, 2009-09-29 at 14:35 +0930, Daniel O'Connor wrote: > > On Mon, 28 Sep 2009, Mike Tancsa wrote: > > > >I also have a similar device, which I've been messing with a bit the > > > >last couple of days. In your case, it isn't seeing the media, just > > > > the "drive". I've had to try various combinations of unplugging > > > > the adapter from usb, inserting the media then plugging it back in. > > > > It does seem to work fairly reliably if you boot with the media > > > > already inserted, but it doesn't seem to detect media change at > > > > all. > > > > > > I get around it (on my cheap reader) by always doing a > > > cat /dev/null > /dev/da1 > > > whever I change or insert new media into the reader > > > > > > That seems to work with the gear I have 99% of the time. > > > > Hmm OK, I sort of expected fdisk da1 to fail straightaway though (it > > takes ~30 seconds to fail for me). > > > > I have unplugged it for now, it interacts annoyingly with SANE because > > that scans the SCSI bus(es) looking for scanner and each umass takes > > 30+ seconds to fail. > > FWIW, on yesterdays kernel, mine seems to be working properly and > detecting media change. I'm not sure what change helped. Note that I > am running -CURRENT. Was that after the sync to Hans's repo? There were around 20 commits so if anyone can narrow it down to a single rev then it may be able to be merged. Andrew ___ 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: Source level upgrade from 4.9 to CURRENT..
On Tue, Sep 15, 2009 at 05:38:16PM +, Rom Albuquerque wrote: > to halt. So, 4.9 is installed and working, is there a source level > backward compatibility issue between 7.x and anything older than 6.0 ? > In other words, upgrading from the sources with such an old > distribution is a doable task ? It's "doable", in that many of us have indeed upgraded through those control points with source, but it can't necessarily be done in one step. Is it worth trying to do in multiple steps? Maybe not: you'll almost certainly want a larger root partition, and may very well want to change to UFS2, both of which mean that you're going to have to dump to backup, repartition, reformat and restore at some stage (and that stage is one of the intermediate stops, because you don't have UFS2 in 4.9). So: you're going to need to be able to boot from the 7.2 (or whatever) kernel+fixit combination to do the reformat anyway, so why not go the whole hog and reinstall directly to 7.2 (or so) at the same time? That's what I did when I hit the UFS2 barrier, and I'm otherwise a died-in-the-wool source upgrader. If you're having trouble getting 7.1 to boot from CD, then try 7.2 or otherwise sort out that problem, because not having a bootable CD fallback position is not a comfortable place to be, anyway. Cheers, -- Andrew ___ 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: gconcat file system damage
Peter C. Lai wrote: What is the status of growfs(8) then? As far as I can tell, it doesn't work reliably with UFS2 partitions, and it doesn't work at all with large partitions. People who do try to use it, can end up with corrupted filesystems... and the code is currently unmaintained. - Andrew ___ 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: How to enable CPU turbo mode on FreeBSD?
Pierre-Luc Drouin wrote: I have an overclocked i7 920 CPU for which I have enabled Turbo Mode in the BIOS (21x multiplier). The base clock is set at 190 MHz, so the CPU frequency with Turbo mode activated should be 3990 MHz. However the maximum value FreeBSD amd64 shows for the CPU frequency in dmesg and sysctl is 3790 MHz. How can I enable the Turbo Mode? The turbo mode doesn't show up in dmesg or sysctl, it dynamically overclocks inside the CPU. Also, some motherboards silently disable turbo mode when you overclock the base clock. You may need to use a benchmark running on 1 vs 4 cores to see if turbo mode is having any effect. - Andrew ___ 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: gconcat file system damage
How did you expand the filesystem onto the new volume? UFS2 expansion is not supported. I originally created the concatted disk in two steps. First I created the concat on my new mirrored disks and copied the files from my existing mirror in there. Second I appended the existing mirror to my concatted disk. It seemed to work fine, but now I'm seeing so much errors that I can only mount the concat r/o! ___ 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: Cannot rm files when ZFS is full
The performance of ZFS is quite bad when the volume is nearly full anyway. I would recommend creating a parent filesystem with a space limit of 90% of the pool size, and then creating your other filesystems under that. ___ 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: Weird portmaster behaviour -- everything fails to install
On Mon, Jul 27, 2009 at 06:13:07PM -0700, Doug Barton wrote: > On Tue, 28 Jul 2009, Andrew Reilly wrote: > >corresponding to port revisions. Portmaster was checking the > >installed version against the MD5 hashes in the "old" version > >+CONTENTS file, and they weren't matching. > > FYI, portmaster doesn't do anything with the md5 hashes in +CONTENTS, but > duplicate entries will definitely cause "issues." Hmm. Well, *something* was whinging about the MD5 hashes not matching (and indeed they weren't), just before the install failed. Could it have been the process that builds a backup package from the installed files? Thanks for making portmaster, btw. It's a great tool, and I find that I prefer it to portupgrade, although I can't say that I can put my finger on why, exactly... Cheers, -- Andrew ___ 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: Weird portmaster behaviour -- everything fails to install
On Tue, Jul 28, 2009 at 09:23:03AM +0200, Václav Haisman wrote: > Andrew Reilly wrote: > > Problem solved! > > > > In case anyone is interested, or has encountered a similar > > problem, I believe that my problem was that somehow my > > /var/db/pkg directory had a whole pile of near-duplicate entries > > corresponding to port revisions. Portmaster was checking the > > installed version against the MD5 hashes in the "old" version > > +CONTENTS file, and they weren't matching. I assume that I > > acquired all of these out-of-date pkg entries through a backup > > restore mishap: I've been having gmirror issues lately (not > > gmirror's fault, I think -- just a series of dodgy hard drives.) > > > > All is good again. No duplicate db/pkg entries at last, and > > portmaster runs to completion as intended. > How have you managed to fix the duplicate entries? Can pkgdb -Ffu or > such fix that? I think that pkgdb is a portupgrade mechanism, and portmaster doesn't need it. By "duplicate entries" I mean multiple directories in the /var/db/pkg directory that differ only in version number or port version number. When I realized that this is what was going on, there were only four such duplicates left, and I just deleted the older directory of the pair, as that was the one that didn't match the installed files. All of the previous duplicates seemed to have been tidied up (or removed) by the "make deinstall reinstall" exercise. I did a final portmaster --check-depends, and that did a *lot* of +REQUIRED_BY fixing, so I suspect that some of the previous dependency notation must have been going into the incorrect (older) versions (I guess that they sort first). Cheers, -- Andrew ___ 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: Weird portmaster behaviour -- everything fails to install
Problem solved! In case anyone is interested, or has encountered a similar problem, I believe that my problem was that somehow my /var/db/pkg directory had a whole pile of near-duplicate entries corresponding to port revisions. Portmaster was checking the installed version against the MD5 hashes in the "old" version +CONTENTS file, and they weren't matching. I assume that I acquired all of these out-of-date pkg entries through a backup restore mishap: I've been having gmirror issues lately (not gmirror's fault, I think -- just a series of dodgy hard drives.) All is good again. No duplicate db/pkg entries at last, and portmaster runs to completion as intended. Cheers, -- Andrew On Mon, Jul 27, 2009 at 08:24:03AM +1000, Andrew Reilly wrote: > I've spent the weekend doing a ports catch-up: there seems to > have been a lot of activity recently! It's taking a long time > at least partly because portmaster doesn't seem to be "doing the > right thing" all of a sudden: it will happily trace the > dependencies and build the first superceded port, but fails to > re-install it. On every occsaion this weekend, it gets to > ===> Installing for foo-0.123_2 > ===> Generating temporary packing list > ===> Checking if graphics/foo already installed > ===> foo-0.123_2 is already installed > You may wish to "make deinstall" and blah, blah, blah... > > Of course it's installed, that's why I'm running portmaster! > > So I go into the directory, run make deinstall reinstall clean, > and that goes without a hitch. Restart portmaster -uBd -a and > half an hour later it will fail in the same way, and I'll have > to do the same dance. > > It's most likely something dumb that I've got misconfigured: can > anyone suggest to me where I should look? ___ 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"
