Re: Deprecating base system ftpd?
Hi all, > Am 03.04.2021 um 22:39 schrieb Ed Maste : > I'm happy to make a port for it if anyone needs it. Comments? A bit late to the party, but my take is: please just don't. I absolutely freaked out when Apple removed the telnet and ftp clients from Mac OS and I needed to reinstall them via MacPorts. People who manage any larger collection of networking gear *depend* on these outdated but simple services. Client and server side alike. TFTP is not going away, neither is FTP. I'm dead serious. Remote media via Supermicro IPMI in 2021? SMB1. Firmware updates for my UPS? FTP. Scanner/printer/fax all-in-one thingy? Uploads received fax transmissions via FTP. PBX? Uploads usage reports via FTP. This stuff is here to stay. In local networks, of course. But still even on "the Internet", FTP is the most used method for customers of static website hosting. You cannot teach these people what an SSH key is. Just my experience, but backed by a load of customer interactions over more than 20 years ... Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein signature.asc Description: Message signed with OpenPGP
Re: FreeBSD 13.0 RC1 UEFI RAID-10 boot problems under VMware Fusio
Hi Warner, > Am 09.03.2021 um 22:00 schrieb Warner Losh :One issue you > may run into is the size of the partition. If it is tiny, > you'll likely have to create a new ESP. Using /boot/boot1.efi may help and > can be used in the last step instead of loader.efi, but it's much less > flexible than loader.efi. What precisely is the difference between boot1.efi and loader.efi? Practically from a sysadmin point of view? I have been using boot1.efi exclusively the last couple of years to boot EFI based systems with ZFS ... Thanks! Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein signature.asc Description: Message signed with OpenPGP
Re: problem upgrading from 11.3 to 11.4 (loader init_state not found)
On Thu, 15 Oct 2020 16:10:17 +0200 Patrick Lamaiziere wrote: > Hello, > > We upgraded a virtual machine from 11.3-release-pX to 11.4-release via > freebsd-update. > > Since, the vm does not boot, the loader shows an incomplete menu with > an error : "Options: init_state(heart character) not found" > > I put a photo here : > https://filesender.renater.fr/?s=download=e17aa22f-bd1a-48a6-98d2-1aafdb4278ca > > Then if we type "boot" the machine boots properly. > > The menu looks like : > ---Welcome to FreeBSD > 1 <-[-11;6H. <-[-1107;8HYES > > Options: init_state not found > Error while including /boot/menu.rc on the line: menu-display > > Can't load 'kernel' > Type '?' for a list of commands, 'help' for more detailled help > --- > > /boot/loader.conf: > # divers > loader_logo=beastie > loader_color="YES" > > # modules > tcpmd5_load="YES" Well it boots fine if I comment loader_logo and loader_color. But I would love the return of Beastie :-) Regards, ___ 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"
problem upgrading from 11.3 to 11.4 (loader init_state not found)
Hello, We upgraded a virtual machine from 11.3-release-pX to 11.4-release via freebsd-update. Since, the vm does not boot, the loader shows an incomplete menu with an error : "Options: init_state(heart character) not found" I put a photo here : https://filesender.renater.fr/?s=download=e17aa22f-bd1a-48a6-98d2-1aafdb4278ca Then if we type "boot" the machine boots properly. The menu looks like : ---Welcome to FreeBSD 1 <-[-11;6H. <-[-1107;8HYES Options: init_state not found Error while including /boot/menu.rc on the line: menu-display Can't load 'kernel' Type '?' for a list of commands, 'help' for more detailled help --- /boot/loader.conf: # divers loader_logo=beastie loader_color="YES" # modules tcpmd5_load="YES" I read in /usr/src/UPDATING that there were some changes on the loader but /boot/loader is the same file as /boot/loader.4th so that looks good. Any clue ? Thanks regards. ___ 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: LUA ERROR: memory allocation error: block too big
Hi all, to add to the argument made by Kyle: > Am 03.06.2020 um 14:56 schrieb Kyle Evans : > As an aside, I'd appreciate it if other folks in this thread could > simply stop dumping all over the many many many hours of work that > were put into getting lua into shape to replace the high-quality forth > that was already in place. The reality is that lua won a popularity > contest long ago [outside of a FreeBSD context][ and lowers the barrier > to being able to hack on our loader menus, which should be viewed as a > great thing. I was equally annoyed at first because I happen to know a good deal of Forth (and use HP calculators ;-) and my reasoning was like „Lua is just as exotic as Forth so people need to learn the basics of a new language, anyway - why make *me* relearn everything?“ But in private conversation at one EuroBSDCon I learned that the „bus factor“ of the old bootloader (i.e. how many people have to be overrun by a bus to make that part of the project unmaintainable because there is zero knowledge left) was probably 2. Which is a perfectly good reason to replace a piece of software with a new one that hopefully more people understand. As for the choice of language I am actually pretty agnostic and willing to learn whatever is needed to get a particular task done. Just my 2ct. Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [FreeBSD-Announce] FreeBSD 12.0 end-of-life
Hi all, > Am 18.02.2020 um 18:44 schrieb Pete French : > Both the DRM issue and VirtualBox are fixed by making sure you recompile and > install the kernel modules from the source in /usr/ports when you upgrade the > OS, or if 'pkg upgrade' overwrites them. Its a bit annnoying, but hardly a > showstopper I find. `pkg lock` after installing from ports is your friend ;-) Kind regards, Patrick -- punkt.de GmbH Patrick M. Hausen .infrastructure Kaiserallee 13a 76133 Karlsruhe Tel. +49 721 9109500 https://infrastructure.punkt.de i...@punkt.de AG Mannheim 108285 Geschäftsführer: Jürgen Egeling, Daniel Lienert, Fabian Stein ___ 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: RELENG_10 to RELENG11 buildworld no possible ?
Hi all, > Am 08.07.2019 um 08:30 schrieb Thomas Mueller : > Or maybe via 11.2R, if that can be built from RELENG_10? I just completed a successful build of RELENG_11_2 on a RELENG_10_4 system … Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: fsck vs zvol
Hi all, > Am 12.06.2019 um 03:04 schrieb O'Connor, Daniel : > I have a small UFS partition that is the sysvol for Samba 4 (otherwise it > doesn't work due to ACL issues). AFAIK this was fixed by iX Systems for Samba 4.9: https://jira.ixsystems.com/browse/NAS-100698 You might want to check if they upstreamed it or if the patch can be incorporated in the FreeBSD port if not. Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: ZFS...
Hi all, > Am 09.05.2019 um 00:55 schrieb Michelle Sullivan : > No, one disk in the 16 disk zRAID2 ... previously unseen but it could be the > errors have occurred in the last 6 weeks... everytime I reboot it started > resilvering, gets to 761M resilvered and then stops. 16 disks in *one* RAIDZ2 vdev? That might be the cause of your insanely long scrubs. In general it is not recommended though I cannot find the source for that information quickly just now. Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: ZFS...
Hi! > Am 30.04.2019 um 18:07 schrieb Walter Cramer : > With even a 1Gbit ethernet connection to your main system, savvy use of (say) > rsync (net/rsync in Ports), and the sort of "know your data / divide & > conquer" tactics that Karl mentions, you should be able to complete initial > backups (on both backup servers) in <1 month. After that - rsync can > generally do incremental backups far, far faster. ZFS can do incremental snapshots and send/receive much faster than rsync on the file level. And e.g. FreeNAS comes with all the bells and whistles already in place - just a matter of point and click to replicate one set of datasets on one server to another one … *Local* replication is a piece of cake today, if you have the hardware. Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: ZFS...
Hi! > Am 01.05.2019 um 02:14 schrieb Michelle Sullivan : > And the irony is the FreeBSD policy to default to zfs on new installs using > the complete drive.. even when there is only one disk available and > regardless of the cpu or ram class... with one usb stick I have around here > it attempted to use zfs on one of my laptops. But *any* filesystem other than ZFS on a single disk and non-ECC memory is worse! So what’s gained by defaulting back to UFS in these cases? There’s the edge case of embedded/very low memory systems but people who build these probably know what they are doing? And of course I use UFS in VMs running on a host with ZFS … depending on whether I need the snapshot/replication features in the guest or not. Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
Some updates: https://www.ixsystems.com/community/threads/nvme-problems-are-there-nightlies-based-on-12-stable-already.75685 https://jira.ixsystems.com/browse/NAS-101427 Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
Hi! > Am 15.04.2019 um 10:51 schrieb Patrick M. Hausen : > Now, RELENG_12 kernel, 11.2-RELEASE userland: > > root@hurz:/var/tmp # uname -a > FreeBSD hurz 12.0-STABLE FreeBSD 12.0-STABLE r346220 GENERIC amd64 > root@hurz:/var/tmp # dd if=/dev/urandom of=hurz bs=10m > > Result: > > no problems, not with two of these jobs running in parallel, not with a zpool > scrub at the same time … After they ran for half an hour I find these in /var/log/messages: Apr 15 11:03:54 hurz kernel: nvme2: Missing interrupt Apr 15 11:07:07 hurz kernel: nvme3: Missing interrupt Apr 15 11:09:47 hurz kernel: nvme4: Missing interrupt They are the only occurrences. The system does not seem to hang or otherwise misbehave ... Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
> Am 15.04.2019 um 08:46 schrieb Patrick M. Hausen : > So I’ll test RELENG_12 next. If that works, I can probably craft > a FreeNAS 11.2 installation with a 12 kernel. I would be hesitating to run > HEAD in production, though. root@hurz:/var/tmp # uname -a FreeBSD hurz 11.2-RELEASE FreeBSD 11.2-RELEASE #0 r335510: Fri Jun 22 04:32:14 UTC 2018 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 root@hurz:/var/tmp # dd if=/dev/urandom of=hurz bs=10m Result: Apr 15 09:56:07 hurz kernel: nvme4: resetting controller Apr 15 09:56:07 hurz kernel: nvme3: resetting controller Apr 15 09:56:07 hurz kernel: nvme4: aborting outstanding i/o Apr 15 09:56:07 hurz kernel: nvme4: WRITE sqid:5 cid:126 nsid:1 lba:188361216 len:208 Apr 15 09:56:07 hurz kernel: nvme4: ABORTED - BY REQUEST (00/07) sqid:5 cid:126 cdw0:0 Apr 15 09:56:07 hurz kernel: nvme4: aborting outstanding i/o Apr 15 09:56:07 hurz kernel: nvme4: WRITE sqid:5 cid:127 nsid:1 lba:188368784 len:64 Apr 15 09:56:07 hurz kernel: nvme4: ABORTED - BY REQUEST (00/07) sqid:5 cid:127 cdw0:0 Apr 15 09:56:07 hurz kernel: nvme4: aborting outstanding i/o Apr 15 09:56:07 hurz kernel: nvme4: WRITE sqid:5 cid:125 nsid:1 lba:188371408 len:48 Apr 15 09:56:07 hurz kernel: nvme4: ABORTED - BY REQUEST (00/07) sqid:5 cid:125 cdw0:0 Apr 15 09:56:07 hurz kernel: nvme4: aborting outstanding i/o Apr 15 09:56:07 hurz kernel: nvme4: WRITE sqid:5 cid:124 nsid:1 lba:188371456 len:16 Apr 15 09:56:07 hurz kernel: nvme4: ABORTED - BY REQUEST (00/07) sqid:5 cid:124 cdw0:0 […] Now, RELENG_12 kernel, 11.2-RELEASE userland: root@hurz:/var/tmp # uname -a FreeBSD hurz 12.0-STABLE FreeBSD 12.0-STABLE r346220 GENERIC amd64 root@hurz:/var/tmp # dd if=/dev/urandom of=hurz bs=10m Result: no problems, not with two of these jobs running in parallel, not with a zpool scrub at the same time … I uploaded a complete dmesg of the system running RELENG_12: https://cloud.hausen.com/s/5dRMsewCtDFHRYA Is there anything else I should send? pciconf, nvmecontrol …? Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
Hi! > Am 14.04.2019 um 23:33 schrieb Patrick M. Hausen : > Since the system runs well with RELENG_11 and only 4 drives > and there is this question about the cabling and shared resources > I will try to set up a system with 5 drives, each of them *without* > another one in a „pair“ sharing the same MB connector. So much for that theory: with 5 drives arranged in that way I get the errors even during installation. https://cloud.hausen.com/s/2myrX2Jr3fgLWGj https://cloud.hausen.com/s/yryckgp56sH2CRe So I’ll test RELENG_12 next. If that works, I can probably craft a FreeNAS 11.2 installation with a 12 kernel. I would be hesitating to run HEAD in production, though. Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
Alright ... > Am 13.04.2019 um 02:37 schrieb Warner Losh : > > There's been some minor improvements in -current here. Any chance you could > > experimentally try that with this test? You won't get as many I/O abort > > errors (since we don't print those), and we have a few more workarounds for > > the reset path (though honestly, it's still kinda stinky). > > HEAD or RELENG_12, too? > > HEAD is preferred, but any recent snapshot will do. I could not reproduce the problem for a couple of hours with an otherwise identical system but only 4 of these Intel drives. Now the same test system with 6 drives just as our FreeNAS boxes - instantly reproducible. I’ll upgrade to HEAD and see if that changes anything. Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
Hi Warner, thanks for taking the time again … > OK. This means that whatever I/O workload we've done has caused the NVME card > to stop responding for 30s, so we reset it. I figured as much ;-) > So it's an intel card. Yes - I already added this info several times. 6 of them, 2.5“ NVME „disk drives“. > OK. That suggests Intel has a problem with their firmware. I came across this one: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211713 Is it more probable that Intel has got buggy firmware here than that „we“ are missing interrupts? The mainboard is the Supermicro H11SSW-NT. Two NVME drive bays share a connector on the mainboard: NVMe Ports ( NVMe 0~7, 10, 11, 14, 15) The H11SSW-iN/NT has tweleve (12) NVMe ports (2 ports per 1 Slim SAS connector) on the motherboard. These ports provide high-speed, low-latency PCI-E 3.0 x4 connections directly from the CPU to NVMe Solid State (SSD) drives. This greatly increases SSD data- throughput performance and significantly reduces PCI-E latency by simplifying driver/software requirements resulting from direct PCI-E interface from the CPU to the NVMe SSD drives. Is this purely mechanical or do two drives share PCI-E resources? Which would explain why the problems always come in pairs (nvme6 and nvme7, for example). This afternoon I set up a system with 4 drives and I was not able to reproduce the problem. (We just got 3 more machines which happened to have 4 drives each and no M.2 directly on the mainboard). I will change the config to 6 drives like with the two FreeNAS systems in our data center. > [… nda(4) ...] > I doubt that would have any effect. They both throw as much I/O onto the card > as possible in the default config. I found out - yes, just the same. > There's been some minor improvements in -current here. Any chance you could > experimentally try that with this test? You won't get as many I/O abort > errors (since we don't print those), and we have a few more workarounds for > the reset path (though honestly, it's still kinda stinky). HEAD or RELENG_12, too? Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o and controller resets
: No Error Log Page Entries: 64 Number of Power States: 1 NVM Command Set Attributes == Submission Queue Entry Size Max: 64 Min: 64 Completion Queue Entry Size Max: 16 Min: 16 Number of Namespaces:1 Compare Command: Not Supported Write Uncorrectable Command: Supported Dataset Management Command: Supported Volatile Write Cache:Not Present Namespace Drive Attributes == NVM total cap: 1000204886016 NVM unallocated cap: 0 = root@freenas01[~]# zpool status pool: freenas-boot state: ONLINE scan: scrub repaired 0 in 0 days 00:00:03 with 0 errors on Sun Apr 7 03:45:03 2019 config: NAMESTATE READ WRITE CKSUM freenas-boot ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 nvd0p2 ONLINE 0 0 0 nvd1p2 ONLINE 0 0 0 errors: No known data errors pool: zfs state: ONLINE scan: scrub repaired 0 in 0 days 00:01:53 with 0 errors on Fri Mar 22 19:53:37 2019 config: NAMESTATE READ WRITE CKSUM zfs ONLINE 0 0 0 raidz2-0 ONLINE 0 0 0 gptid/97d0a7ce-44e5-11e9-982e-0025905f99ac ONLINE 0 0 0 gptid/98053880-44e5-11e9-982e-0025905f99ac ONLINE 0 0 0 gptid/983a9468-44e5-11e9-982e-0025905f99ac ONLINE 0 0 0 gptid/987100f2-44e5-11e9-982e-0025905f99ac ONLINE 0 0 0 gptid/98aa6e88-44e5-11e9-982e-0025905f99ac ONLINE 0 0 0 gptid/98f20b8c-44e5-11e9-982e-0025905f99ac ONLINE 0 0 0 errors: No known data errors = The problem only appears on the data pool built from 6 INTEL SSDPE2KX010T8. The system pool built from two KXG50ZNV256G TOSHIBA does not show any problem with write load. All the Intel drives have the latest firmware according to the Intel support website. Could it possibly help to tweak dev.nvme.7.ioq0.num_entries and similar entries? What about switching to the nda device instead of nvd? Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: Rare NVME related freeze at boot (was: Re: NVME aborting outstanding i/o)
Hi! > Am 05.04.2019 um 16:36 schrieb Warner Losh : > What normally comes after the nvme6 line in boot? Often times it's the next > thing after the last message that's the issue, not the last thing. nvme7 ;-) And I had hangs at nvme1, nvme3, … as well. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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"
Rare NVME related freeze at boot (was: Re: NVME aborting outstanding i/o)
Hi all, in addition to the aborted commands every dozen of system boots or so (this order of magnitude) the kernel simply hangs during initialisation of one of the NVME devices: https://cloud.hausen.com/s/TxPTDFJwMe6sJr2 The particular device affected is not constant. A power cycle fixes it, the system has not shown hangs/freezes during multiuser operation, yet. Any ideas? Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o
Hi all, > Am 04.04.2019 um 17:11 schrieb Warner Losh : > There's a request that was sent down to the drive. It took longer than 30s to > respond. One of them, at least, was a trim request. > […] Thanks for the explanation. This further explains why I was seeing a lot more of those and the system occasionally froze for a couple of seconds after I increased these: vfs.zfs.vdev.async_write_max_active: 10 vfs.zfs.vdev.async_read_max_active: 3 vfs.zfs.vdev.sync_write_max_active: 10 vfs.zfs.vdev.sync_read_max_active: 10 as recommended by Allan Jude reasoning that NVME devices could work on up to 64 requests in parallel. I have since reverted that change and I am running with the defaults. If I understand correctly, this: > hw.nvme.per_cpu_io_queues=0 essentially limits the rate at which the system throws commands at the devices. Correct? So it’s not a real fix and there’s nothing fundamentally wrong with the per CPU queue or interrupt implementation. I will look into new firmware for my Intel devices and try tweaking the vfs.zfs.vdev.trim_max_active and related parameters. Out of curiosity: what happens if I disable TRIM? My knowledge is rather superficial and I just filed that under „TRIM is absolutely essential lest performance will suffer severely and your devices die - plus bad karma, of course …“ ;-) Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o
> Am 04.04.2019 um 16:51 schrieb Chuck Tuffli : > nvmecontrol identify nvme7 Controller Capabilities/Features Vendor ID: 8086 Subsystem Vendor ID:8086 Serial Number: BTLJ90230F1R1P0FGN Model Number: INTEL SSDPE2KX010T8 Firmware Version: VDV10131 Recommended Arb Burst: 0 IEEE OUI Identifier:e4 d2 5c Multi-Interface Cap:00 Max Data Transfer Size: 131072 Controller ID: 0x00 The server is a Supermicro AS-1113S-WN10RT Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: NVME aborting outstanding i/o
Hi, > Am 04.04.2019 um 10:37 schrieb Patrick M. Hausen : > But: > > root@freenas01[~]# sysctl hw.nvme.per_cpu_io_queues > sysctl: unknown oid 'hw.nvme.per_cpu_io_queues' > root@freenas01[~]# sysctl hw.nvme.min_cpus_per_ioq > sysctl: unknown oid 'hw.nvme.min_cpus_per_ioq' > root@freenas01[~]# sysctl hw.nvme.force_intx > sysctl: unknown oid 'hw.nvme.force_intx' Looks like these can be set via loader.conf and reboot although they are not visible in the running system. Even when set they are not visible afterwards ... hw.nvme.per_cpu_io_queues=0 seems to cure the NVME errors. I’m still curious about the root problem here, bit at least I can now continue to use the machines for some real loads. Kind regards, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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"
NVME aborting outstanding i/o
Hi all, I’m currently doing some load tests/burn in for two new servers. These feature all NVME SSDs and run FreeNAS, i.e. FreeBSD 11.2-STABLE. pcib17: at device 3.2 numa-domain 1 on pci15 pcib17: [GIANT-LOCKED] pci17: numa-domain 1 on pcib17 nvme7: mem 0xeca1-0xeca13fff at device 0.0 numa-domain 1 on pci17 When putting some moderate i/o load on the system, the log fills with these messages: nvme7: aborting outstanding i/o nvme7: DATASET MANAGEMENT sqid:41 cid:91 nsid:1 nvme7: ABORTED - BY REQUEST (00/07) sqid:41 cid:91 cdw0:0 There has been some discussion of this on on the iX Systems forum as well as various FreeBSD media and one person suggested setting: hw.nvme.per_cpu_io_queues=0 This is where I need some help now. This is from the manpage for nvme(4): -- To force a single I/O queue pair shared by all CPUs, set the following tunable value in loader.conf(5): hw.nvme.per_cpu_io_queues=0 To assign more than one CPU per I/O queue pair, thereby reducing the number of MSI-X vectors consumed by the device, set the following tunable value in loader.conf(5): hw.nvme.min_cpus_per_ioq=X To force legacy interrupts for all nvme driver instances, set the following tunable value in loader.conf(5): hw.nvme.force_intx=1 Note that use of INTx implies disabling of per-CPU I/O queue pairs. -- But: root@freenas01[~]# sysctl hw.nvme.per_cpu_io_queues sysctl: unknown oid 'hw.nvme.per_cpu_io_queues' root@freenas01[~]# sysctl hw.nvme.min_cpus_per_ioq sysctl: unknown oid 'hw.nvme.min_cpus_per_ioq' root@freenas01[~]# sysctl hw.nvme.force_intx sysctl: unknown oid 'hw.nvme.force_intx' Where do I go from here? Thanks! Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: libcrypto.so.111 linked binaries SIGSEGV (in bhyve guest)
Hello, I don’t know if this is related or not, but when I compile the Nextcloud client port https://svnweb.freebsd.org/ports/head/deskutils/nextcloudclient/ on 11.2 by setting DEFAULT_VERSIONS+=ssl=openssl111 it dumps core, too. Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: Binary update to -STABLE? And if so, what do I get?
Good morning, > Am 14.02.2019 um 19:11 schrieb Kevin Oberman : > Far and away the biggest is the requirement to build from sources. It's not > a big deal for me, but if I still had many systems to deal with, that would > be a pain. > […] > The bottom line is that the only real reasons I see for not running stable > is the lack of binary updates, and issues with systems being slightly out > of sync if all are not updated to the same SVN revision at all times. Those > are very big reasons for many. We build from sources centrally, then zfs send/receive /usr/src and /usr/obj to all of the machines, then just do the install(kernel|world) part on all of them. Kind regards Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: issue upgradning src
Hi! > Am 05.12.2018 um 16:45 schrieb Maciej Jan Broniarz : > I want to upgrade my 12.0-ALPHA8 to the latest release, yet I am unable to > update from source: > [...] > #freebsd-update fetch freebsd-update upgrade -r 12.0-RC3 HTH, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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"
Memory error logged in /var/log/messages
Hi all, one of our production servers, 11.2p3 is logging this every couple of minutes: Nov 19 11:48:06 ph002 kernel: MCA: CPU 0 COR (5) OVER MS channel 3 memory error Nov 19 11:48:06 ph002 kernel: MCA: Address 0x1f709a48c0 Nov 19 11:48:06 ph002 kernel: MCA: Misc 0x9001040188c Nov 19 11:48:06 ph002 kernel: MCA: Bank 12, Status 0xcc00010c000800c3 Nov 19 11:48:06 ph002 kernel: MCA: Global Cap 0x07000c16, Status 0x Nov 19 11:48:06 ph002 kernel: MCA: Vendor "GenuineIntel", ID 0x406f1, APIC ID 0 Address and core varies but it is always bank 12. It seems like applications are unaffected, we use, of course ECC memory. Is the OS able to work around these errors and just notifies us or is in-memory data already getting corrupted? I’m at a bit of a loss identifying which DIMM might be the cause so I contacted Supermicro support. They answered: > We can't really answer this, we do not know how various OS's map the memory > slots. > Our advise is always to look at IPMI, but if that doesn't log any issues then > we're not sure you're looking at a hardware issue. > > But assuming the OS looks at the ranks of a module as a bank and you use dual > rank memory then it should logically point at DIMMC2. They are right on the IPMI (I told them when opening the case) - there’s nothing at all in the event log. Can they be correct that it might not even be a hardware issue? If not how can I be sure which DIMM is to blame? Spare parts are ready but I’d like to have a rather short maintenance break outside regular business hours. I’ll attach a dmesg.boot. HW is a X10DRW-NT mainboard, SYS-1028R-WTNRT server platform. Thanks for any hints, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling Copyright (c) 1992-2018 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.2-RELEASE-p3 #4 r338821: Thu Sep 20 12:26:41 CEST 2018 r...@backupr05.karlsruhe.punkt.de:/usr/obj/usr/src/sys/VIMAGE amd64 FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) VT(vga): resolution 640x480 CPU: Intel(R) Xeon(R) CPU E5-2630L v4 @ 1.80GHz (1800.04-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406f1 Family=0x6 Model=0x4f Stepping=1 Features=0xbfebfbff Features2=0x7ffefbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21cbfbb XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 274873712640 (262140 MB) avail memory = 267225935872 (254846 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 40 CPUs FreeBSD/SMP: 2 package(s) x 10 core(s) x 2 hardware threads WARNING: VIMAGE (virtualized network stack) is a highly experimental feature. ioapic0 irqs 0-23 on motherboard ioapic1 irqs 24-47 on motherboard ioapic2 irqs 48-71 on motherboard SMP: AP CPU #1 Launched! SMP: AP CPU #29 Launched! SMP: AP CPU #6 Launched! SMP: AP CPU #35 Launched! SMP: AP CPU #17 Launched! SMP: AP CPU #24 Launched! SMP: AP CPU #14 Launched! SMP: AP CPU #5 Launched! SMP: AP CPU #19 Launched! SMP: AP CPU #11 Launched! SMP: AP CPU #33 Launched! SMP: AP CPU #12 Launched! SMP: AP CPU #26 Launched! SMP: AP CPU #25 Launched! SMP: AP CPU #18 Launched! SMP: AP CPU #23 Launched! SMP: AP CPU #21 Launched! SMP: AP CPU #34 Launched! SMP: AP CPU #39 Launched! SMP: AP CPU #4 Launched! SMP: AP CPU #30 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #37 Launched! SMP: AP CPU #13 Launched! SMP: AP CPU #27 Launched! SMP: AP CPU #7 Launched! SMP: AP CPU #36 Launched! SMP: AP CPU #28 Launched! SMP: AP CPU #38 Launched! SMP: AP CPU #22 Launched! SMP: AP CPU #2 Launched! SMP: AP CPU #15 Launched! SMP: AP CPU #20 Launched! SMP: AP CPU #32 Launched! SMP: AP CPU #16 Launched! SMP: AP CPU #31 Launched! SMP: AP CPU #10 Launched! SMP: AP CPU #9 Launched! SMP: AP CPU #8 Launched! Timecounter "TSC" frequency 1800041380 Hz quality 1000 random: entropy device external interface kbd1 at kbdmux0 netmap: loaded module module_register_init: MOD_LOAD (vesa, 0x8102d580, 0) error 19 random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" nexus0 vtvga0: on motherboard cryptosoft0: on motherboard acpi0: <> on motherboard acpi0: Power Button (fixed) cpu0: numa-domain 0 on acpi0 cpu1: numa-domain 0 on acpi0 cpu2: numa-domain 0 on acpi0 cpu3: numa-domain 0 on acpi0 cpu4: numa-domain 0 on acpi0 cpu5: numa-domain 0 on acpi0 cpu6: numa-domain 0 on acpi0 cpu
Re: ctld(8) 11.2-release lockup with w2k16 [Was: Re: ctld(8), multiple 'portal-group' on same socket (individual 'discovery-auth-group' restrictions)]
Hi, all, > Am 25.08.2018 um 15:04 schrieb Harry Schmalzbauer : > [...] > This is with 11.2 release. > It's a ESXi guest, which I used severla years with previous FreeBSD versions > without such massive iSCSI performance problems. > > Using the same /dev/zvol with istgt(1) on the same 11.2-release VM also > solves the performance issue. > > Is anybody using ctld(8) in production post 10.x? If so, without observing a > similar regression? Unfortunately I cannot directly help you here. My only iSCSI target server is still on 10.4 ... But a suggestion: Install the latest BETA of FreeNAS (11.2-BETA2), and try if that shows the same problems. It's based on 11.2-STABLE. If not, the FreeNAS source tree and/or the community might prove helpful. Heck, possibly their ctld config contains some tuning your's doesn't. Communication is via forum instead of mailing lists, but they are a generally kind bunch of guys. I figure the number of actual users of iSCSI might be larger in that community. HTH, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: PF problems with 11-stable
Le Thu, 26 Jul 2018 09:58:05 +0200, Patrick Lamaiziere a écrit : Hello, > > Hey, > > I am on > > 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 > > Sun Jul 22 14:08:38 CEST 2018 > > > > and I see 2 problems with PF that are still there: > > 1.) set skip on lo > > does not work even though ifconfig lo matches. > > SOLVED TEMPORARILY BY: set skip on lo0 > > I've seen this while upgrading from 10.3 to 11.2-RELEASE. I've added > lo0 to set skip too. > > When the problem occurs, lo is marked '(skip)' (pfctl -vs > Interfaces) but not lo0. > > But I can't reproduce this, this happened only one time. I don't know if this is related but there were some kernel logs about 'loopback' : Feb 15 17:11:48 fucop1 kernel: ifa_del_loopback_route: deletion failed: 47 Feb 15 17:11:48 fucop1 kernel: ifa_add_loopback_route: insertion failed: 47 Jul 16 13:50:36 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface igb1: 3 Jul 16 14:10:43 fucop1 kernel: ifa_maintain_loopback_route: insertion failed for interface igb0: 17 I've got two firewalls with carp and bird 2 (BGP). ___ 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: PF problems with 11-stable
Le Thu, 26 Jul 2018 09:58:05 +0200, Patrick Lamaiziere a écrit : Hello, > > Hey, > > I am on > > 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 > > Sun Jul 22 14:08:38 CEST 2018 > > > > and I see 2 problems with PF that are still there: > > 1.) set skip on lo > > does not work even though ifconfig lo matches. > > SOLVED TEMPORARILY BY: set skip on lo0 > > I've seen this while upgrading from 10.3 to 11.2-RELEASE. I've added > lo0 to set skip too. > > When the problem occurs, lo is marked '(skip)' (pfctl -vs > Interfaces) but not lo0. > > But I can't reproduce this, this happened only one time. I don't know if this is related but there were some kernel logs about 'loopback' : Feb 15 17:11:48 fucop1 kernel: ifa_del_loopback_route: deletion failed: 47 Feb 15 17:11:48 fucop1 kernel: ifa_add_loopback_route: insertion failed: 47 Jul 16 13:50:36 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface ix2: 3 Jul 16 14:07:31 fucop1 kernel: ifa_maintain_loopback_route: deletion failed for interface igb1: 3 Jul 16 14:10:43 fucop1 kernel: ifa_maintain_loopback_route: insertion failed for interface igb0: 17 I've got two firewalls with carp and bird 2 (BGP). ___ 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: PF problems with 11-stable
Le Sun, 22 Jul 2018 15:53:41 +0200, Lars Schotte a écrit : Hello, > Hey, > I am on > 11.2-STABLE FreeBSD 11.2-STABLE #9 r336597 > Sun Jul 22 14:08:38 CEST 2018 > > and I see 2 problems with PF that are still there: > 1.) set skip on lo > does not work even though ifconfig lo matches. > SOLVED TEMPORARILY BY: set skip on lo0 I've seen this while upgrading from 10.3 to 11.2-RELEASE. I've added lo0 to set skip too. When the problem occurs, lo is marked '(skip)' (pfctl -vs Interfaces) but not lo0. But I can't reproduce this, this happened only one time. While I'm here, another small change is that pfctl -n does not work any more without root credentials, I'm not sure if this is a bug or a feature : % pfctl -n -f /etc/pf.conf pfctl: pfi_get_ifaces: Bad file descriptor % ls -lah /etc/pf.conf -rw-r--r-- 1 root wheel97B Jul 26 09:37 /etc/pf.conf Regards, ___ 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: Spectre/Meltdown mitigation in 11.1-p10 bogging down zfs send/receive?
Hi! > Am 14.05.2018 um 17:35 schrieb Patrick M. Hausen <hau...@punkt.de>: > Possibly we are on the wrong track altogether. We were - please just forget it ... ZFS scrub running during our activity ... everybody who already put more than five minutes of thought into this deserves a beer at the next EuroBSDCon ;-) Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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"
Spectre/Meltdown mitigation in 11.1-p10 bogging down zfs send/receive?
Hey guys, as some might know we run our hosting products in ZFS and iocage based jails. The backup concept relies on recurring local snapshots and a copy of these on one (more planned) central storage server. The storage server does essentially nothing but run zfs receive for each dataset on each hosting node. 12x spinning rust and 128G of RAM. Lots of space ;-) In preparation of rolling out (among other patches) the Meltdown and Spectre mitigation fixes and microcode updates we already ran benchmarks that measured our primary applications - the TYPO3 and Neos CMS. We did not see much of an impact. We updated that central storage system last Friday. Today we provisioned a new server meaning a new hosting hardware and a couple of jails on that one. The new system already has got all the latest patches. Part of the provisioning process is creating an initial snapshot of every dataset and sending an initial copy to the storage server, so we can send nightly incrementals. That step took surprisingly long for the first of the new jails. At least an order of magnitude, I cannot provide exact measurements yet, because this is all part of rather complex Ansible task and it really caught us by surprise. We already received a couple of warnings from the Icinga service monitoring the nightly replication runs - we still need to investigate this. We suspect they ran slower than usual, too. To narrow down the cause of the problem we tried this in chronological order: 1. storage server (receiving end): Disable microcode update and hw.ibrs_active still slow Disable vm.pmap.pti still slow 2. new jail host (sending end): Disable both fast Re-enable microcode update and hw.ibrs_active still fast Re-enable vm.pmap.pti still fast Reboot as necessary, of course. And we double checked the current value of the respective sysctls before running the tests. That last step is *quite* unexpected, because it just does not make sense to me. Does anybody know what impact the fixes, both PTI and IBRS are *expected* to have on bulk zfs send/receive operations from/to two different hosts? Possibly we are on the wrong track altogether. We suspected the CPU fixes because of the general "what did you change last" approach ... Thank you very much Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: Notification for GMirror failures
Hi all, > Am 08.05.2018 um 09:28 schrieb Andrea Brancatelli <abrancate...@schema31.it>: > out of curiosity, does any kind of GMirror-failure notification tools > exist? http://soren.klintrup.dk/gmirror We use it in production. Works as designed. HTH, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: another question about zfs compression numbers
Hi all, > Am 04.04.2018 um 09:21 schrieb Eugene M. Zheganin <eug...@zhegan.in>: > I'm just trying to understand these numbers: > > file size is 232G, it's actual size on the lz4-compressed dataset is 18G, so > then why is the compressratio only 1.86x ? And why logicalused is 34.2G ? On > one hand, 34.2G exactlyfits to the 1.86x compresstaio, but still I don't get > it. dataset is on raidz, 3 spans across 5 disk vdevs, with total of 15 disks > if it matters: A sparse file, possibly? The ZFS numbers refer to blocks. "Skipping" zeroes at the VFS layer is not taken into account as fas as I know. Seriously, how should it? If I'm not mistaken, ZFS will never get to see these empty blocks. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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"
IPv6 connectivity lost when combining if_bridge with a VLAN ...
Hi all, a follow-up to my discovery that certain chipsets don't support 100baseTX any more. ;-) We use these servers as jail hosts and use if_bridge with VIMAGE and iocage a lot. Our tried and true setup used to be like this: - sysctl net.link.bridge.inherit_mac=1 - ifconfig_ixl0="up" ifconfig_ixl1="up" cloned_interfaces="bridge0 bridge1" ifconfig_bridge0_name="inet0" ifconfig_bridge1_name="mgmt0" ifconfig_inet0="up addm ixl0" ifconfig_inet0_alias0="inet /24" ifconfig_inet0_ipv6="inet6 /64 auto_linklocal" ifconfig_mgmt0="up addm ixl1" ifconfig_mgmt0_alias0="inet /16" ifconfig_mgmt0_ipv6="inet6 auto_linklocal" defaultrouter="" ipv6_defaultrouter="fe80::11%inet0" - So we use link-local v6 addresses for the default gateways in every VLAN. The last octet in the GW address is simply the VLAN number ... Now, because I had to run improvised wires to a different switch before we get to upgrading the entire rack to Gbit connectivity we tried to use a single cable and a trunk port: - sysctl net.link.bridge.inherit_mac=1 - ifconfig_ixl0="up" cloned_interfaces="vlan7 vlan11 bridge0 bridge1" ifconfig_vlan7="up vlan 7 vlandev ixl0" ifconfig_vlan11="up vlan 11 vlandev ixl0" ifconfig_bridge0_name="inet0" ifconfig_bridge1_name="mgmt0" ifconfig_inet0="up addm vlan7" ifconfig_inet0_alias0="inet /24" ifconfig_inet0_ipv6="inet6 /64 auto_linklocal" ifconfig_mgmt0="up addm vlan11" ifconfig_mgmt0_alias0="inet /16" ifconfig_mgmt0_ipv6="inet6 auto_linklocal" defaultrouter="" ipv6_defaultrouter="fe80::11%inet0" - Nothing overly fancy in my opinion, just an orthogonal combination of technologies. In principle this seems to work, but ... - IPv4 connectivity comes up reliably and stays up - external IPv6 connectivity does not come up at reboot - I can ping6 the default GW from the machine (link-local address) - I can ping6 other machines in the same VLAN (global unicast) - route -6 delete default; route -6 add default fe80::11%inet0 restores external connectivity - external connectivity get's lost again after a couple of hours Only IPv6 seems to be affected, not IPv4. Any ideas? ;-) Thanks, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD 11.1 ixl(4) interface does not negotiate at 100 Mbit/s
Hi all, > Am 19.03.2018 um 17:37 schrieb Eric Joyner <e...@freebsd.org>: > I'm guessing these are 10G copper LOMs using X722; those don't support 100Mb > speeds. Your guess is probably correct. Going to re-wire tomorrow. Thanks, everyone. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
FreeBSD 11.1 ixl(4) interface does not negotiate at 100 Mbit/s
Hi all, any ideas why a current RELENG_11_1 system with ixl(4) onboard interfaces might not negotiate with a switch that has only fast ethernet? status: no carrier on the host line protocol is down (notconnect) on the switch dmesg: https://imgur.com/9ri9is8 Thanks for any hints, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: iscsi target and VMware/esxi timeouts
Hello, > Am 14.11.2017 um 10:08 schrieb Daniel Braniss <da...@cs.huji.ac.il>: > > Hi, > we are experimenting issues with several esxi’s servers that use freebsd 10.2 > stable as a iscsi target. > ie: > Nov 11 17:58:16 store-07 kernel: WARNING: 132.65.11.201 > (iqn.1998-01.com.vmware:pe-02-2fa7cd9e): no ping reply (NOP-Out) after 5 > seconds; dropping connection > Nov 11 17:58:16 store-07 kernel: WARNING: 132.65.11.201 > (iqn.1998-01.com.vmware:pe-02-2fa7cd9e): no ping reply (NOP-Out) after 5 > seconds; dropping connection > Nov 11 17:58:16 store-07 kernel: WARNING: 132.65.11.205 > (iqn.1998-01.com.vmware:pe-03-13e8b52d): no ping reply (NOP-Out) after 5 > seconds; dropping connection > Nov 11 17:58:17 store-07 kernel: WARNING: 132.65.11.203 > (iqn.1998-01.com.vmware:pe-13-60e87d06): no ping reply (NOP-Out) after 5 > seconds; dropping connection > Nov 11 17:58:17 store-07 kernel: WARNING: 132.65.11.205 > (iqn.1998-01.com.vmware:pe-03-13e8b52d): no ping reply (NOP-Out) after 5 > seconds; dropping connection > > these are 3 different esxis that almost at the same time the target looses > connection to the initiators. > at the moment most ‘clients’ recover from the scsi error, but older freebsds > don’t. > > in any case, increasing the timeout is not helping. > > any clues are welcome :-) > > over the weekend i’m planning to upgrade the target to 11.1 and take for the > hills. Are you using istgt or ctld? We have did experience similar occasional problems with the former but never with the latter. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling ___ 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: ABI changes within stable branch
Morning, > Am 20.09.2017 um 19:27 schrieb Mark Linimon <lini...@lonesome.com>: > > On Tue, Sep 19, 2017 at 10:15:32AM +0200, Kurt Jaeger wrote: >> A pointer to the official policy would be nice 8-} > > 3rd paragraph of: > > http://www.freebsd.org/portmgr/policies_eol.html One comment: it's easy to overlook the implications of the word "supported" in "Package builds will use the oldest supported minor release within each major branch ..." Thanks for the link. Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling signature.asc Description: Message signed with OpenPGP
Re: ABI changes within stable branch
Hi! > Am 20.09.2017 um 04:09 schrieb Aristedes Maniatis <a...@ish.com.au>: > At the very least I need to remember to keep poudriere on the x.0 release > even after it is EOL, > until every one of my servers has been upgraded Not necessarily. You can run build jails with lower OS versions on an up-to-date poudriere system. In your specific case just build 11.0 and 11.1 packages (until 11.0 breaks ;-) and use the appropriate package repos on your various servers. You *cannot* build 11.1 packages on an 11.0 poudriere, at least not reliably. HTH, Patrick -- punkt.de GmbH Internet - Dienstleistungen - Beratung Kaiserallee 13a Tel.: 0721 9109-0 Fax: -100 76133 Karlsruhe i...@punkt.de http://punkt.de AG Mannheim 108285 Gf: Juergen Egeling signature.asc Description: Message signed with OpenPGP
Re: ABI changes within stable branch
Hi all, > Am 19.09.2017 um 10:32 schrieb Aristedes Maniatis <a...@ish.com.au>: > Then we have a problem since > https://pkg.freebsd.org/freebsd:11:x86:64/latest/All/ has been built on 11.1, > not on 11.0 (I just tested it with csync2 which I know fails). Packages there > may fail to run on 11.0, but there is no clear indication, just random > failures at runtime. > > Maybe we'd need specific 11.0, 11.1, 11.2 releases instead of quarterly > releases? This is precisely what we do on our own poudriere - build the quarterly ports branches on various FreeBSD release versions. Patrick signature.asc Description: Message signed with OpenPGP
Re: Bridged networking regression in 11.0?
OK, guys, more replying to myswlf ;-) > Am 30.08.2017 um 12:04 schrieb Patrick M. Hausen <hau...@punkt.de>: > > Hi, all, > >> Am 30.08.2017 um 09:29 schrieb Patrick M. Hausen <hau...@punkt.de>: >> one of the systems on which we run our jail based "proServer" product failed >> in a very odd way for the second time with a couple of days between the two >> incidents. >> [...] > > We found this open bug: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 > [...] To me it looks like not much changed in if_bridge.c from RELENG_10_3 to RELENG_11_0 ... https://svnweb.freebsd.org/base/releng/11.0/sys/net/if_bridge.c?view=diff=303975=296373_format=h The revisions are the topmost entries in https://svnweb.freebsd.org/base/releng/11.0/sys/net/if_bridge.c https://svnweb.freebsd.org/base/releng/10.3/sys/net/if_bridge.c respectively. Is this the correct/best way to answer the question what changed? The only real change relates to IF teardown and we did not change anything (stop/restart jails) when the outages occured. So ... the network interface driver? Probably? ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0x6020-0x603f mem 0xc7c0-0xc7df,0xc7e04000-0xc7e07fff irq 26 at device 0.0 numa-domain 0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 0c:c4:7a:34:ec:ba ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix0: netmap queues/slots: TX 8/2048, RX 8/2048 Patrick signature.asc Description: Message signed with OpenPGP
Re: Bridged networking regression in 11.0?
Hi, all, > Am 30.08.2017 um 09:29 schrieb Patrick M. Hausen <hau...@punkt.de>: > one of the systems on which we run our jail based "proServer" product failed > in a very odd way for the second time with a couple of days between the two > incidents. > [...] We found this open bug: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=217606 What puzzles me is the fact that the original reporter claims that ifconfig down/up fixes the problem temporarily for him. Which in my case it didn't. But possibly I should have down/up'ed *all* bridge members not only the physical IF ... Patrick signature.asc Description: Message signed with OpenPGP
Bridged networking regression in 11.0?
Hi, everyone, one of the systems on which we run our jail based "proServer" product failed in a very odd way for the second time with a couple of days between the two incidents. We run VIMAGE based jails (a lot) and bridge them with the physical interface of the machine. - cloned_interfaces="bridge0 bridge1" ifconfig_bridge0_name="inet0" ifconfig_inet0="addm ix0 up" ifconfig_inet0_alias0="inet 217.29.41.2/24" ifconfig_inet0_ipv6="inet6 2a00:b580:8000:11:44e8:ab80:816:7869/64 auto_linklocal" ifconfig_bridge1_name="mgmt0" ifconfig_mgmt0="addm ix1 up" ifconfig_mgmt0_alias0="inet 10.5.105.7/16" ifconfig_mgmt0_ipv6="inet6 auto_linklocal" - The rest is managed by iocage wich creates the needed epair(4) interfaces, for some reason renames them to "vnetX" and adds them as members to the bridge. E.g. - [ry93@ph002 ~]$ ifconfig inet0 inet0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500 ether 02:50:51:fe:cc:00 inet6 fe80::50:51ff:fefe:cc00%inet0 prefixlen 64 scopeid 0x4 inet6 2a00:b580:8000:11:44e8:ab80:816:7869 prefixlen 64 inet 217.29.41.2 netmask 0xff00 broadcast 217.29.41.255 nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL> groups: bridge id 00:00:00:00:00:00 priority 32768 hellotime 2 fwddelay 15 maxage 20 holdcnt 6 proto rstp maxaddr 2000 timeout 1200 root id 00:00:00:00:00:00 priority 32768 ifcost 0 port 0 member: vnet0:69 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 76 priority 128 path cost 2000 [... 50 vnet interfaces following ...] member: ix0 flags=143<LEARNING,DISCOVER,AUTOEDGE,AUTOPTP> ifmaxaddr 0 port 1 priority 128 path cost 2000 - When the system fails - no jail is reachable from the outside via IP - no jail is reachable from the host via IP - the host itself is reachable just fine - when we `iocage console` into a jail it can reach it's own IP addresses but nothing "outside" I tried - ifconfig ix0 down; ifconfig ix0 up - ifconfig inet0 down; ifconfig inet0 up # aka bridge0 - iocage stop ; iocage start The latter deletes the epair instance connected to the jail and creates a fresh one, then adds it to the bridge. No change in connectivity ... the start of the jail takes "forever" because various processes hang waiting DNS timeouts (no networking ;-) There's nothing in /var/log/messages or the dmesg buffer that relates to networking! Rebooting the host system "fixes" the situation. Now I'm well aware that this is too little information to draw some definite conclusions. Hence my first question is: what should I do (commands) when the situation arises again to gather more evidence? Or maybe we are just lucky and there is a known problem? Yes, I know VIMAGE is still considered experimental. We have been running this in production for months and it looks like it could be related to upgrading host and jails from 10.3 to 11.0 *or* switching the old shell based iocage for Brandon's new python based version. I cannot rule out iocage, yet it's not very probable - this is not a Docker like running service or network component, after all. Once the jails are up, iocage is done ... An then there's the chance that it is something with the ix driver and the way we use the interface ... so for completeness: - ix0: <Intel(R) PRO/10GbE PCI-Express Network Driver, Version - 3.1.13-k> port 0x6020-0x603f mem 0xc7c0-0xc7df,0xc7e04000-0xc7e07fff irq 26 at device 0.0 numa-domain 0 on pci3 ix0: Using MSIX interrupts with 9 vectors ix0: Ethernet address: 0c:c4:7a:34:ec:ba ix0: PCI Express Bus: Speed 5.0GT/s Width x8 ix0: netmap queues/slots: TX 8/2048, RX 8/2048 ix0: promiscuous mode enabled ix0: link state changed to UP - As usual thanks for any hints, Patrick signature.asc Description: Message signed with OpenPGP
Re: recommendations for file server based zfs appliance
Hi Stefan, > Am 18.08.2017 um 14:35 schrieb Stefan Hagen <freebsd-stable-l...@textmail.me>: >> What do you mean by "JBOD support"? Disable RAID in the systems BIOS >> setup, put ZFS on AHCI drives ... > > Activating JBOD deactivates the B120i raid controller. Unfortnately the > temperature sensor > is somehow controlled by the raid controller. So enabling JBOD technically > works, but the > machine is a lot louder than with enabled raid. As a workaround I've built 4 > raid arrays with one disk each. > > It works, but it doesn't feel right to me. Weird - the machine seems rather quiet to me, but it's in a separate room with the laser printers and no one actually working there. I don't know how to measure noise, unfortunately. I have another Gen8 at my wife's office for their not-for-profit organisation. Quiet as a mouse with FreeNAS 11. This time two also very quiet (most of the time) computer based office desks in that room. My machine here at my office: root@filer:~ # ipmitool sensor UID Light| 0x0| discrete | 0x0180| na| na| na | na| na| na Health LED | 0x0| discrete | 0x0180| na| na| na | na| na| na 01-Inlet Ambient | 28.000 | degrees C | ok| na| na| na | na| 42.000| 46.000 02-CPU | 40.000 | degrees C | ok| na| na| na | na| 70.000| na 03-P1 DIMM 1-2 | 42.000 | degrees C | ok| na| na| na | na| 87.000| na 04-HD Max| na || na| na| na| na | na| 60.000| na 05-Chipset | 63.000 | degrees C | ok| na| na| na | na| 105.000 | na 06-Chipset Zone | 48.000 | degrees C | ok| na| na| na | na| 68.000| 73.000 07-VR P1 Zone| 52.000 | degrees C | ok| na| na| na | na| 88.000| 93.000 08-Supercap Max | na || na| na| na| na | na| 65.000| na 09-iLO Zone | 47.000 | degrees C | ok| na| na| na | na| 72.000| 77.000 10-PCI 1 | na || na| na| na| na | na| 100.000 | na 11-PCI 1 Zone| 39.000 | degrees C | ok| na| na| na | na| 64.000| 69.000 12-Sys Exhaust | 48.000 | degrees C | ok| na| na| na | na| 68.000| 73.000 13-LOM | na || na| na| na| na | na| 100.000 | na Fan 1| 25.088 | percent| ok| na| na| na | na| na| na Power Supply 1 | 0x0| discrete | 0x0180| na| na| na | na| na| na Memory | 0x0| discrete | 0x4080| na| na| na | na| na| na So, temperature sensor working, too. Or are you referring to the *HDD* temperature? I never put disks to sleep in servers ... Patrick signature.asc Description: Message signed with OpenPGP
Re: recommendations for file server based zfs appliance
Hi! > Am 18.08.2017 um 14:03 schrieb Stefan Hagen <freebsd-stable-l...@textmail.me>: > > * Patrick M. Hausen wrote: >>> Am 18.08.2017 um 11:19 schrieb Pete French <petefre...@ingresso.co.uk>: >>> The HP micro servers work very well, and you can pick them up remakably >>> cheaply [...] >>> Not sure about ECC memory support there though. >> >> They do support ECC, no problem. >> >> They are available with different CPU configurations from >> as Pete said remarkably cheap Celeron D based systems >> up to Xeon CPUs. > > I've just sold my Microserver Gen8 (Xeon) just recently. > It's a beautiful little machine, but I didn't make me happy in the long run. > > Reasons: > - Limited to 8GB Ram in total > - Only 4 HDDs > - JBOD support is not great > - Harddrives are never going to sleep (not supported) > > Installing FreeBSD was harder than expected. The machine refused to boot > FreeBSD > from the internal non-raid SATA ports. I didn't try FreeNAS though. smbios.system.product="ProLiant MicroServer Gen8" CPU: Intel(R) Xeon(R) CPU E3-1220L V2 @ 2.30GHz (2294.80-MHz K8-class CPU) 16 GB RAM, FreeBSD installation was no problem at all. What do you mean by "JBOD support"? Disable RAID in the systems BIOS setup, put ZFS on AHCI drives ... ahci0: port 0x10c0-0x10c7,0x10c8-0x10cb,0x10d0-0x10d7,0x10d8-0x10db,0x10e0-0x10ff mem 0xfacd-0xfacd07ff irq 17 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 6Gbps ports, Port Multiplier supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: ATA-8 SATA 3.x device ada0: 600.000MB/s transfers (SATA 3.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 1907729MB (3907029168 512 byte sectors: 16H 63S/T 16383C) This is our office file, print and mail server. No FreeNAS this time, just plain FreeBSD. Patrick signature.asc Description: Message signed with OpenPGP
Re: recommendations for file server based zfs appliance
Hi all, > Am 18.08.2017 um 13:58 schrieb Pete French <petefre...@ingresso.co.uk>: > >> Maybe the folk that made hardware suggestions can post which net >> interface(s) they are using and whether they are seeing driver issues? > > The HP boxes have Broadcom ethernet controllers driven with the 'bge' > driver, and thatw orks fine. I stick to Intel or Broadcom controllers for > gigabit ether where I have a choice. The Supermicro system I mentioned features 4 Intel igb(4) interfaces. I bridge them to save an extra switch in my home network - works great. BTW: this Supermicro box looks suspiciously similar to at least one generation of the FreeNAS mini ... Patrick signature.asc Description: Message signed with OpenPGP
Re: recommendations for file server based zfs appliance
Hi, all, > Am 18.08.2017 um 11:19 schrieb Pete French <petefre...@ingresso.co.uk>: > The HP micro servers work very well, and you can pick them up remakably > cheaply [...] > Not sure about ECC memory support there though. They do support ECC, no problem. They are available with different CPU configurations from as Pete said remarkably cheap Celeron D based systems up to Xeon CPUs. If you want something that conserves power but still features 8 cores, Supermicro has got a small 8-core Atom based system: https://www.supermicro.nl/products/system/midtower/5028/SYS-5028A-TN4.cfm I run this at home and I am really satisfied with it. ECC too, of course. Capable of running VMs in bhyve ... I'd suggest just using FreeNAS if you intend to build a file server. And of course you can always order a preconfigured FreeNAS mini from iX Systems. HTH, Patrick signature.asc Description: Message signed with OpenPGP
What is /dev/zfs?
Hi, folks any pointer to an explanation would be nice, there seems to be no zfs(4) manpage ... Reason for asking: I have a piece of software that uses 14,000 ioctl() calls on that device during one execution and I'm asking myself what it tries to do. Thanks! Patrick signature.asc Description: Message signed with OpenPGP
Re: lang/gcc* package builds vs. release/11.0.1/ and the future release/11.1.0 because of vm_ooffset_t and vm_pindex_t changes and how the lang/gcc* work
ows categories for builds for 8.4 9.3 10.1 10.3 11.0 head (Nothing for stable/*/ .) But the 10.3 rows show no package builds. I would guess that they start once 10.1 stops (approximately). So it may be that 11.1 will not get package builds until 11.0 stops (approximately). If so unless lang/gcc* are changed to bootstrap differently they will configure to match release/11.0.1/ and will not be compatible with the vm_ooffset_t and vm_pindex_t changes in stable/11/ and release/11.1.0/ . But as I understand updating how the lang/gcc* builds work to remove such dependencies is under investigation. I do not know any timing relative to release/11.1.0/ if my understanding is right. Until then (if I was right): Unless there are separate packages made for targeting release/11.0.1/ vs. release/11.1.0/ it is not obvious when lang/gcc* packages will be generally compatible with various folks choices about what to install as the system version within the release/11.*/ and stable/11/ family. This would likely be true even if they were built on release/11.1.0/ : then release/11.0.1/ likely would have compatibility problems. The ABI versioning does not cover the specific issues involved based on how vm_ooffset_t and vm_pindex_t were changed and what the lang/gcc* builds do relative to such changes. Yet there is incompatibility for some fairly-significant-usage ports. Aspect #2: stable/10/ and release/10.4.0/ Just covered for completeness: I do not see a MFC of -r313194 to stable/10/ : its sys/sys/types.h dates back to 2015-Oct-10. So it looks like 10.x has a permanent difference in this area: 10.x continues to get separate lang/gcc* package builds from 11.x and later. No problem for this context as far as I know. Note: To simplify I choose to not be explicit about what authors wrote what original text. If that becomes an issue, it is correctable. Blame me for any errors in the above. === Mark Millard markmi at dsl-only.net ___ freebsd-po...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com ___ freebsd-stable@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: FreeBSD as VirtualBox guest panics when starting VBoxService
Hello, > Am 23.05.2017 um 23:10 schrieb jungle Boogie <jungleboog...@gmail.com>: > > Hi Patrick, > On 23 May 2017 at 05:52, Patrick M. Hausen <hau...@punkt.de> wrote: >> Hi, all, >> >> just for the record - today I published our own boxesat Hashicorp Atlas: >> >>https://atlas.hashicorp.com/punktde >> >> If you trust me enough, enjoy ;-) >> >> FreeBSD 11.0p10 - we intend to publish updated ones >> for every FreeBSD update. >> > > Thanks for making this. > > Using Windows 7 with VirtualBox version 5.1.22, the VM is in a > continuous reboot. My box? > Are you not experiencing this? Of course not. Vagrant 1.9.5, Virtualbox 5.1.22, Mac OS. We are using this box daily ... Patrick signature.asc Description: Message signed with OpenPGP
Re: FreeBSD as VirtualBox guest panics when starting VBoxService
Hi, all, just for the record - today I published our own boxesat Hashicorp Atlas: https://atlas.hashicorp.com/punktde If you trust me enough, enjoy ;-) FreeBSD 11.0p10 - we intend to publish updated ones for every FreeBSD update. Kind regards, Patrick signature.asc Description: Message signed with OpenPGP
Re: FreeBSD Vagrant Box Kernel Panic
Hello, > Am 10.05.2017 um 21:24 schrieb Robert Simmons <rsimmo...@gmail.com>: > It appears that the maintainer of the boxes should create a > 11.0-RELEASE-p10 box and revoke the -p1 box. The official Hashicorp boxes have been invoking freebsd-update on startup for a while, now. So every box automatically updates itself to the latest patchlevel. We have started to roll our own boxes, so I'm not perfectly up-to-date. Patrick signature.asc Description: Message signed with OpenPGP
Re: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On 04/27/17 13:59, Jung-uk Kim wrote: On 04/27/2017 12:45, Patrick Powell wrote: On 04/26/17 09:34, Jung-uk Kim wrote: On 04/26/2017 10:14, Patrick Powell wrote: First: a big thank-you to the support/fixit people for all of their work! I was doing some testing using FreeBSD 11.0-STABLE and some of my configure scripts died. However, they were working fine on FreeBSD 11.0 RELEASE. I found the problem, but I do not know how to resolve this. When you install the GCC compiler from the PKG repository it appears to create a modified set of include files from the system (default?) include files (/usr/include). However, when the modified /usr/include/sys/types.h file is created, the typedef for vm_ooffset_t is modified, and there is no reference to __vm_ooffset_t that the compiler can resolve. < typedef __int64_t vm_ooffset_t; --- typedef __vm_ooffset_t vm_ooffset_t; ... You have to rebuild lang/gcc from the ports tree to fix this problem. https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html Jung-uk Kim Does this mean that the GCC port/package needs to be updated? If so, should I file a PR report on this issue? I (temporarily) fixed this problem by hand editting the modified types.h file and things seem to work. I already wrote a patch (attached). :-) Jung-uk Kim Will the GCC port be updated with this patch? Any action needed by me on this? -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com ___ 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: GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
On 04/26/17 09:34, Jung-uk Kim wrote: On 04/26/2017 10:14, Patrick Powell wrote: First: a big thank-you to the support/fixit people for all of their work! I was doing some testing using FreeBSD 11.0-STABLE and some of my configure scripts died. However, they were working fine on FreeBSD 11.0 RELEASE. I found the problem, but I do not know how to resolve this. When you install the GCC compiler from the PKG repository it appears to create a modified set of include files from the system (default?) include files (/usr/include). However, when the modified /usr/include/sys/types.h file is created, the typedef for vm_ooffset_t is modified, and there is no reference to __vm_ooffset_t that the compiler can resolve. < typedef __int64_t vm_ooffset_t; --- typedef __vm_ooffset_t vm_ooffset_t; ... You have to rebuild lang/gcc from the ports tree to fix this problem. https://lists.freebsd.org/pipermail/freebsd-current/2017-February/064937.html Jung-uk Kim Does this mean that the GCC port/package needs to be updated? If so, should I file a PR report on this issue? I (temporarily) fixed this problem by hand editting the modified types.h file and things seem to work. -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com ___ 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"
GCC + FreeBSD 11.0 Stable - stat.h does not have vm_ooffset_t definition
First: a big thank-you to the support/fixit people for all of their work! I was doing some testing using FreeBSD 11.0-STABLE and some of my configure scripts died. However, they were working fine on FreeBSD 11.0 RELEASE. I found the problem, but I do not know how to resolve this. When you install the GCC compiler from the PKG repository it appears to create a modified set of include files from the system (default?) include files (/usr/include). However, when the modified /usr/include/sys/types.h file is created, the typedef for vm_ooffset_t is modified, and there is no reference to __vm_ooffset_t that the compiler can resolve. < typedef __int64_t vm_ooffset_t; --- > typedef __vm_ooffset_t vm_ooffset_t; I suspect that this change from __int64_t to __vm_offset_t is the cause of the problem. This editting (?) appears to be done by 'fixincludes' (as noted in the README files in the /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed directory. Details: Configuration: FreeBSD test11snapshot 11.0-STABLE FreeBSD 11.0-STABLE #0 r317153: Thu Apr 20 05:43:02 UTC 2017 r...@releng2.nyi.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 p#> pkg which /usr/local/bin/gcc /usr/local/bin/gcc was installed by package gcc-5.4.0_1 Test File: conftest.c /* confdefs.h */ #define PACKAGE_NAME "" #define PACKAGE_TARNAME "" #define PACKAGE_VERSION "" #define PACKAGE_STRING "" #define PACKAGE_BUGREPORT "" #define PACKAGE_URL "" #define PACKAGE "FEPT" #define VERSION "7.0.8" #define STDC_HEADERS 1 /* end confdefs.h. */ #include #ifdef HAVE_SYS_TYPES_H # include #endif #ifdef HAVE_SYS_STAT_H # include #endif #ifdef STDC_HEADERS # include # include #else # ifdef HAVE_STDLIB_H # include # endif #endif #ifdef HAVE_STRING_H # if !defined STDC_HEADERS && defined HAVE_MEMORY_H # include # endif # include #endif #ifdef HAVE_STRINGS_H # include #endif #ifdef HAVE_INTTYPES_H # include #endif #ifdef HAVE_STDINT_H # include #endif #ifdef HAVE_UNISTD_H # include #endif #include Compile: #> gcc -c -g -02 conftest.c In file included from conftest.c:46:0: /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:266:9: error: unknown type name '__vm_ooffset_t' typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h:268:9: error: unknown type name '__vm_pindex_t' typedef __vm_pindex_t vm_pindex_t; ^ root@test11snapshot:/usr/include # diff sys/types.h /usr/local/lib/gcc5/gcc/x86_64-portbld-freebsd11.0/5.4.0/include-fixed/sys/types.h |more 0a1,9 > /* DO NOT EDIT THIS FILE. > > It has been auto-edited by fixincludes from: > > "/usr/include/sys/types.h" > > This had to be done to correct non-standard usages in the > original, manufacturer supplied header file. */ > 35c44 < * $FreeBSD: stable/11/sys/sys/types.h 313574 2017-02-11 02:00:56Z kib $ --- > * $FreeBSD: releng/11.0/sys/sys/types.h 299571 2016-05-12 21:18:17Z cem $ 199c208,212 < typedef __size_tsize_t; --- > #if !defined(_GCC_SIZE_T) > #define _GCC_SIZE_T > typedef __SIZE_TYPE__ size_t; > #endif > 253c266 < typedef __int64_t vm_ooffset_t; --- > typedef __vm_ooffset_t vm_ooffset_t; 255c268 < typedef __uint64_t vm_pindex_t; --- > typedef __vm_pindex_t vm_pindex_t; root@test11snapshot:/usr/include # -- Patrick Powell Astart Technologies papow...@astart.com1530 Jamacha Rd, Suite X Network and System San Diego, CA 92019 Consulting Cell 858-518-7581 FAX 858-751-2435 Web: papowell at astart dot com ___ 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"
Kernel panic on production system - what now?
Hi all, Mar 24 02:39:36 ph001 kernel: kernel trap 12 with interrupts disabled Mar 24 02:39:36 ph001 kernel: Mar 24 02:39:36 ph001 kernel: Mar 24 02:39:36 ph001 kernel: Fatal trap 12: page fault while in kernel mode Mar 24 02:39:37 ph001 kernel: cpuid = 8; apic id = 08 Mar 24 02:39:37 ph001 kernel: fault virtual address = 0x0 Mar 24 02:39:37 ph001 kernel: fault code= supervisor read data, page not present Mar 24 02:39:37 ph001 kernel: instruction pointer = 0x20:0x809a4330 I must admit that this is a "first" for me. So where do I go from here? There is "stuff" in /var/crash that has got the right timestamps, it seems ... Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
Get Alerts for Asia’s Largest Event for Project Cargo & Breakbulk Industry
Breakbulk China, Asia's largest exhibition and conference for the project cargo and breakbulk industry, 13-16 March in Shanghai. Email not displaying correctly? View it in your browser http://go.pardot.com/webmail/272542/109865/44fdc0c6c180768e3a3fa31aa1a694965163e5a8c0f70a50893537c80a7ad94e. Logistics is complicated. Finding new business doesn't have to be. The movement of project cargo and breakbulk goods involves complex logistics, months and even years of planning and multi-million dollar contracts. Yours is a complicated job and in this tight economy, finding new business is a top priority. We can help. From 13-16 March 2017, Asia’s largest exhibition and conference for the project cargo and breakbulk industry will bring together 6,000 industry professionals, 200 exhibitors and more than 300 shippers at Breakbulk China in Shanghai. Hear from shippers, forwarders and specialized transport providers, as well as astute analysts, as they share their experiences and identify areas of opportunity for new business and development. With a full exhibition hall, you will be able to fill the 2 days with appointments that meet your business objectives. Find out more about exhibitors, sponsors, speakers and VIP Shippers. Sign Up for Alerts - http://go.pardot.com/e/272542/l-272542-2016-11-28-92b/d8x/109865 Facebook - http://go.pardot.com/e/272542/l-272542-2016-11-23-5z6/d8z/109865 Twitter - http://go.pardot.com/e/272542/l-272542-2016-11-23-5z8/d92/109865 LinkedIn - http://go.pardot.com/e/272542/l-272542-2016-11-23-5zb/d94/109865 YouTube - http://go.pardot.com/e/272542/l-272542-2016-11-23-5zd/d96/109865 SoundCloud - http://go.pardot.com/e/272542/l-272542-2016-11-23-5zg/d98/109865 Instagram - http://go.pardot.com/e/272542/l-272542-2016-11-23-5zj/d9b/109865 Copyright © 2016, all rights reserved. Our mailing address is: Breakbulk Events & Media 2 Penn Plaza 12th Floor Newark, NJ 07105 unsubscribe from all emails http://go.pardot.com/unsubscribe/u/272542/44fdc0c6c180768e3a3fa31aa1a694965163e5a8c0f70a50893537c80a7ad94e/109865 ___ 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: boot1.efifat's FAT12 volume label prevents booting (some systems)
Hi, > Am 07.11.2016 um 09:04 schrieb Harry Schmalzbauer <free...@omnilan.de>: >> create the EFI boot volume like this? >> >> gpart add -t efi -l efi -a 512k -s 512k >> newfs_msdos /dev/gpt/efi >> mount_msdosfs /dev/gpt/efi /mnt >> mkdir -p /mnt/efi/boot >> cp /boot/boot1.efi /mnt/efi/boot/bootx64.efi > > You are missing startup.nsh... > See > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214282https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214282 Care to elaborate? This is what we use in production - all systems booting just fine ;-) Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: boot1.efifat's FAT12 volume label prevents booting (some systems)
Hi, all, > Am 06.11.2016 um 18:14 schrieb Dimitry Andric <d...@freebsd.org>: > > Please do, so it is not forgotten. It is relatively easy to change the > volume label, by editing sys/boot/efi/boot1/generate-fat.sh, and then > regenerating the FAT templates. Why use the pre-generated image at all when you can easily create the EFI boot volume like this? gpart add -t efi -l efi -a 512k -s 512k newfs_msdos /dev/gpt/efi mount_msdosfs /dev/gpt/efi /mnt mkdir -p /mnt/efi/boot cp /boot/boot1.efi /mnt/efi/boot/bootx64.efi umount /mnt Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: boot0cfg on does not set default selection on gmirror device
Hi, all, > Am 24.10.2016 um 04:50 schrieb Ian Smith <smi...@nimnet.asn.au>: > > On Sun, 23 Oct 2016 15:53:59 +0200, Patrick M. Hausen wrote: > >> Actual reboot of this production machine in two weeks when we run our >> regular updates. But I expect that to "just work". > > Warner expected the existing boot0cfg code to "just work" too. And it > does, except that the upgrades to it failed to include a method to fix > existing installations retrospectively! If the boot0 code 2.0 was severely broken, don't you think we would have noticed? ;-) One more thing, I just checked: the machines for which it did work all the time are indeed younger and all have the 2.0 bootcode. Thanks for your help. Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: boot0cfg on does not set default selection on gmirror device
Hi, Ian, > Am 22.10.2016 um 05:36 schrieb Ian Smith <smi...@nimnet.asn.au>: > [...] > I wonder two things: > > Do 'boot0cfg -v ada0' and 'boot0cfg -v ada1' both report the same? OK, situation before I try to change anything: root@hd45:~ # boot0cfg -v mirror/m0 [...] default_selection=F1 (Slice 1) root@hd45:~ # boot0cfg -v ada0 [...] default_selection=F1 (Slice 1) root@hd45:~ # boot0cfg -v ada1 [...] default_selection=F1 (Slice 1) Now try to change it to F2 through the mirror device: root@hd45:~ # boot0cfg -s 2 mirror/m0 # No error message or other indication that something went wrong! root@hd45:~ # boot0cfg -v mirror/m0 [...] default_selection=F1 (Slice 1) root@hd45:~ # boot0cfg -v ada0 [...] default_selection=F1 (Slice 1) root@hd45:~ # boot0cfg -v ada1 [...] default_selection=F1 (Slice 1) > Might it work properly if you upgraded the boot sectors to version 2, > which is what you should get if you reinstall from current boot0cfg, > presumably without touching the MBR data, but you'll have backups .. Well ... root@hd45:~ # boot0cfg -B mirror/m0 root@hd45:~ # boot0cfg -s 2 mirror/m0 root@hd45:~ # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=2.0 drive=0x80 mask=0xf ticks=182 bell=# (0x23) options=packet,update,nosetdrv volume serial ID b100-808f default_selection=F2 (Slice 2) root@hd45:~ # boot0cfg -v ada0 [...] default_selection=F2 (Slice 2) root@hd45:~ # boot0cfg -v ada1 [...] default_selection=F2 (Slice 2) Revert the change: root@hd45:~ # boot0cfg -s 1 mirror/m0 root@hd45:~ # boot0cfg -v mirror/m0 [...] default_selection=F1 (Slice 1) That did it! These machines have been in production for some time starting with FreeBSD 8.x and have been upgraded via NanoBSD style dd followed by reboot all the time up to 10.3, now. Hence I never touched the bootcode. Actual reboot of this production machine in two weeks when we run our regular updates. But I expect that to "just work". Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: boot0cfg on does not set default selection on gmirror device
Hi, Warner, > Am 21.10.2016 um 20:25 schrieb Warner Losh <i...@bsdimp.com>: > Can you give us the strace output? amd64 - no strace. I need a hand here, what precisely do I need to enter? > It looks like it is reading the current blocks, setting the options, > and then writing it back to the device. If the write back fails, it > opens the device with geom and sends either the bootcode verb to geom > (for the PART (aka gpart)) case or the data for the MBR case. strace > should show that clearly. There's nothing in dmesg, right? Try this > again but set geom.debug_flags to 128 instead of 16. This will give a > verbose error in dmesg if there's any errors from the control message. I set the flag, then tried to change the slice from 1 to 2. Result: Dump of gctl request at 0xfe02392bd9e0: param:"class" [R5] = "PART" param:"arg0" [R10] = "mirror/m0" param:"verb" [R9] = "bootcode" param:"bootcode" [R512] = fc 31 c0 8e c0 8e d8 8e d0 bc 00 7c 89 e6 bf 00 06 b9 00 01 f3 a5 89 fd b1 08 f3 ab fe 45 f2 e9 00 8a f6 46 bb 20 75 08 84 d2 78 07 80 4e bb 40 8a 56 ba 88 56 00 e8 fc 00 52 bb c2 07 31 d2 88 6f fc 0f a3 56 bb 73 19 8a 07 bf 87 07 b1 03 f2 ae 74 0e b1 0b f2 ae 83 c7 09 8a 0d 01 cf e8 c5 00 42 80 c3 10 73 d8 58 2c 7f 3a 06 75 04 72 05 48 74 0d 30 c0 04 b0 88 46 b8 bf b2 07 e8 a6 00 be 7b 07 e8 b2 00 8a 56 b9 4e e8 8e 00 eb 05 b0 07 e8 b0 00 30 e4 cd 1a 89 d7 03 7e bc b4 01 cd 16 75 0d 30 e4 cd 1a 39 fa 72 f2 8a 46 b9 eb 16 30 e4 cd 16 88 e0 3c 1c 74 f1 2c 3b 3c 04 76 06 2c c7 3c 04 77 c9 98 0f a3 46 0c 73 c2 88 46 b9 be 00 08 8a 14 89 f3 3c 04 9c 74 0a c0 e0 04 05 be 07 93 c6 07 80 53 f6 46 bb 40 75 08 bb 00 06 b4 03 e8 59 00 5e 9d 75 06 8a 56 b8 80 ea 30 bb 00 7c b4 02 e8 47 00 72 86 81 bf fe 01 55 aa 0f 85 7c ff be 85 07 e8 19 00 ff e3 b0 46 e8 24 00 b0 31 00 d0 eb 17 0f ab 56 0c be 78 07 e8 eb ff 89 fe e8 03 00 be 85 07 ac a8 80 75 05 e8 04 00 eb f6 24 7f 53 bb 07 00 b4 0e cd 10 5b c3 8a 74 01 8b 4c 02 b0 01 56 89 e7 f6 46 bb 80 74 13 66 6a 00 66 ff 74 08 06 53 6a 01 6a 10 89 e6 48 80 cc 40 cd 13 89 fc 5e c3 20 20 a0 0a 44 65 66 61 75 6c 74 3a a0 0d 8a 00 05 0f 01 06 07 0b 0c 0e 83 a5 a6 a9 0d 0c 0b 0a 09 08 0a 0e 11 10 01 3f bf 44 4f d3 4c 69 6e 75 f8 46 72 65 65 42 53 c4 66 bb 44 72 69 76 65 20 b1 01 80 8f b6 00 80 00 01 01 a5 fe ff fe c1 3e 00 00 7e 86 fa 00 00 00 c1 ff a5 fe ff fc 3f c5 fa 00 7e 86 fa 00 00 00 c1 fd a5 fe ff 00 bd 4b f5 01 04 0e 7b 72 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 55 aa param:"flags" [R2] = "C" root@hd45:~ # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F1 (Slice 1) So again, no change. Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: boot0cfg on does not set default selection on gmirror device
Hi, all, > Am 21.10.2016 um 16:41 schrieb Warner Losh <i...@bsdimp.com>: > Any chance you can migrate to using gpart? Is boot0cfg still > referenced in NanoBSD somewhere? Not in NanoBSD but how would you configure boot0's default slice with gpart? It doesn't pay attention to the "active" flag. See Miroslav's mails for all the details. gpart would only be an option if we did not use the FreeBSD boot manager. But we need the "F1 ..., F2 ..." prompt, because being able to roll back to the last known-good system via the console is the entire point of using this NanoBSD setup. There's a presentation on the EuroBSDCon 2010 page about motivation and setup. Wonder who did that talk ... :-))) BTW: thanks, Miroslav. As for your question: it does work on the only two systems that use hardware RAID, yet have a gmirror built of only a single component to get consistent device names accross all servers. I'm not quite sure if it works from time to time, I've come to accept the "kern.geom.debugflags" dance. I had opened a similar discussion years ago for 7.x/8.x and I was told that geom was to provide an API for fdisk, boot0cfg and friends to manipulate the MBR. Because back in the days boot0cfg and fdisk both threw an error message when trying to work on a whole-disk mirror. I thought that was long solved - at least no error, anymore. But it's still not working in 10.x. Thanks to all and take care, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
boot0cfg on does not set default selection on gmirror device
Hi, all, we are repeatedly bitten by the following misbehaviour of boot0cfg: root@hd45:/usr/local # boot0cfg -s 1 mirror/m0 root@hd45:/usr/local # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F2 (Slice 2) So, while it should have set the default to slice 1, it simply didn't. gpart on the other hand works as expected: root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0 active set on mirror/m0s1 root@hd45:/usr/local # gpart show mirror/m0 =>63 1953525104 mirror/m0 MBR (932G) 63 16002 - free - (7.8M) 1606516418430 1 freebsd [active] (7.8G) 1643449516418430 2 freebsd (7.8G) 32852925 1920667140 3 freebsd (916G) 19535200655102 - free - (2.5M) But the "active" flag alone is not enough to convince boot0 to actually boot that partition. Additional info: root@hd45:/usr/local # uname -a FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 r306942: Mon Oct 10 10:29:14 UTC 2016 root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC amd64 root@hd45:/usr/local # gmirror status NameStatus Components mirror/m0 COMPLETE ada0 (ACTIVE) ada1 (ACTIVE) The only way to actually switch the boot0 default selection is: root@hd45:/usr/local # sysctl kern.geom.debugflags=16 kern.geom.debugflags: 0 -> 16 root@hd45:/usr/local # boot0cfg -s 1 ada0 root@hd45:/usr/local # boot0cfg -s 1 ada1 root@hd45:/usr/local # boot0cfg -v mirror/m0 # flag start chs type end chs offset size 1 0x80 1: 0: 1 0xa5 1022:254:6316065 16418430 2 0x00 1023: 0: 1 0xa5 1020:254:63 16434495 16418430 3 0x00 1021: 0: 1 0xa5768:254:63 32852925 1920667140 version=1.0 drive=0x80 mask=0xf ticks=182 bell= (0x7) options=packet,update,nosetdrv default_selection=F1 (Slice 1) Any hints what's going on, here? Obviously it is possible to manipulate the MBR of a gmirror device - as gpart proves. The boot0cfg pops up since FreeBSD 8 when we started using a mirrored NanoBSD setup. Thanks and kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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.3-RELEASE amd64 segmentation faults in wc, sh...
Le Thu, 30 Jun 2016 15:52:04 +0300, Konstantin Belousov <kostik...@gmail.com> a écrit : Hello, > On Thu, Jun 30, 2016 at 01:57:32PM +0200, Patrick Lamaiziere wrote: > > Hello, > > > > I'm building a pair of firewall with 10.3 and I see some rare > > segmentation faults (5 in a week) in processes like wc, sh or > > ifstated. ... > This is most likely the problems, reported and fixed in r300758, > PR 204764 r302063, and PR 204426 r302236. First and second commits > are already in stable/10, the third one will be merged in several > days. For the record, it looks like the first and second commits fixed this problem here. I've not yet tested the third one (don't know if it is already in 10/stable). Thanks again Konstantin. Regards, ___ 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"
10.3-RELEASE amd64 segmentation faults in wc, sh...
Hello, I'm building a pair of firewall with 10.3 and I see some rare segmentation faults (5 in a week) in processes like wc, sh or ifstated. wc, sh are used by some scripts who check the state of the interfaces and the state of bgp sessions. Ifstated called theses scripts too. I thought there was a bug in ifstated so I made a small program in perl to do the same thing but the problem is not in ifstated. The machines are some Dell R730, I've checked the memory with memtest86 for one week without error. The problem occurs on both firewalls so i don't think this is a hardware problem. Any idea? Thanks, regards. ifstated Core was generated by `ifstated'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libevent-2.0.so.5...(no debugging symbols found)...done. Loaded symbols for /usr/local/lib/libevent-2.0.so.5 Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800e23a67 in pthread_getspecific () from /lib/libthr.so.3 Cannot find new threads: generic error sh -- Core was generated by `sh'. Program terminated with signal 11, Segmentation fault. Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x00080063351b in _rtld_atfork_post () from /libexec/ld-elf.so.1 wc -- Core was generated by `wc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x000800612524 in _rtld_atfork_post () from /libexec/ld-elf.so.1 ___ 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: How to setup ethernet address and IPv4 address on interface?
Hi, all, > Am 29.06.2016 um 14:23 schrieb Slawa Olhovchenkov <s...@zxy.spb.ru>: > > On Wed, Jun 29, 2016 at 02:13:59PM +0200, Patrick M. Hausen wrote: > >> What about using a combination of >> >> ifconfig_em1 >> ipv4_addrs_em1 >> >> in rc.conf? > > What you mean? I am not rc.conf/network.subr hacker. ifconfig_em1="ether 00:30:48:63:19:04" ipv4_addrs_em1="192.168.2.1/24" Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: How to setup ethernet address and IPv4 address on interface?
Hi! > Am 29.06.2016 um 14:01 schrieb Slawa Olhovchenkov <s...@zxy.spb.ru>: > I am need in one call, multiple commands not allways allowed. > Using /etc/start_if.$IFNAME produce side effects and can mask errors > in rc.conf. What about using a combination of ifconfig_em1 ipv4_addrs_em1 in rc.conf? Kind regards Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
State of unionfs?
Hi, all, we were looking for a way to get overlay/copy-on-write mounts for ZFS datasets to ease jail management. Google turned up this old thread: https://lists.freebsd.org/pipermail/freebsd-fs/2010-September/009221.html So, clearly in September 2010 mount_unionfs(8) was not supported for ZFS datasets. A quick check on a current RELENG-10.3 system showed that this has changed .Union-mounting one dataset on top of another does indeed work at a superficial glance. Yet the manpage for mount_unionfs(8) still contains this disturbing note: BUGS THIS FILE SYSTEM TYPE IS NOT YET FULLY SUPPORTED (READ: IT DOESN'T WORK) AND USING IT MAY, IN FACT, DESTROY DATA ON YOUR SYSTEM. USE AT YOUR OWN RISK. BEWARE OF DOG. SLIPPERY WHEN WET. BATTERIES NOT INCLUDED. Is this still the case? Are there alternatives to our approach. What we would like to implement is e.g. a standard pre-populated /etc for each jail with only modified files being written to a separate per-jail dataset. Much like NanoBSD does when populating the /etc mfs at boot. While we can create a clone from a central snapshot for each jail, the problem with this way is that we cannot exchange the base snapshot later, e.g. after a major system update for the jail in question. Which is precisely the intention in the first place ;-) Thanks for any hints Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: OpenSSH changes between 10.2 and 10.3 ...
Hi, all, > Am 14.04.2016 um 12:20 schrieb Eugene Grosbein <eu...@grosbein.net>: > > It does change for me. And helps. Make double sure you have added > KexAlgorithms > to system wide defaults section of ssh_config and not after limiting "Host" > directive, > or similar. Thanks for that hint - much ado about nothing, sorry. My statement went into "Host ..." section by accident. Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
OpenSSH changes between 10.2 and 10.3 ...
Hi, all, minor problem/annoyance here: root@noc:/etc/ssh # ssh admin@10.4.0.62 Unable to negotiate with 10.4.0.62 port 22: no matching key exchange method found. Their offer: diffie-hellman-group1-sha1,none root@noc:/etc/ssh # uname -a FreeBSD noc.pluspunkthosting.de 10.3-RELEASE FreeBSD 10.3-RELEASE #3: Wed Apr 13 14:46:57 CEST 2016 r...@noc.pluspunkthosting.de:/usr/obj/usr/src/sys/GENERIC amd64 Of course I was able to find http://www.openssh.com/legacy.html myself. FreeBSD 10.2 uses OpenSSH 6.6.x while 10.3 imported 7.2. So far so good. The recommended method from the document above works on the command line: ssh -oKexAlgorithms=+diffie-hellman-group1-sha1 admin@10.4.0.62 But if I add KexAlgorithms +diffie-hellman-group1-sha1 to /etc/ssh/ssh_config, that does not change anything. Oddly enough, checking which algorithms are supported gives the same result regardless of any configuration options: root@noc:/etc/ssh # ssh -Q kex diffie-hellman-group1-sha1 diffie-hellman-group14-sha1 diffie-hellman-group-exchange-sha1 diffie-hellman-group-exchange-sha256 ecdh-sha2-nistp256 ecdh-sha2-nistp384 ecdh-sha2-nistp521 curve25519-sha...@libssh.org So, diffie-hellman-group1-sha1 is supported but not used unless specified on the command line? And there is no way to override that *globally*? This is an isolated management network with IPMI interfaces - we won't be getting updates for all of these machines' IPMI firmware ... Am I stuck with writing shell aliases or putting the config in each and every user's private ~/.ssh/config? Thanks for any hints, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: Best practices for ZFS setup for a strictly SSD based system?
Hi, all, > Am 10.02.2016 um 11:15 schrieb krad <kra...@gmail.com>: > > Dont forget alignment and ashift. You may also want to test compression as > well. IF you have spare cpu cycles I would imagine the systems cpu will > handle it faster than any onboard ssd compression. Benchmarking would be of > use here though. Correct. Just for the record: since 10.2 the FreeBSD installer does the right thing [tm]. ashift=12 and partitions are 1M aligned. Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
Best practices for ZFS setup for a strictly SSD based system?
Hi, all, while there is quite a bit of documentation on how to improve ZFS performance by using a combination of rotating disks and SSDs, I have not found much about an SSD only setup. We are planning to try a hosting server with 8 SATA SSDs with ZFS. Things I am not at all sure about: * Does the recommended limit of 6 disks for a RAIDZ2 still hold? 2x 4 disks is quite a bit of overhead, could I use all 8 in one vdev and get away with it? (The maximum of 6 recommendation is in some old Sun doc) * Will e.g. MySQL still profit from residing on a mirror instead of a RAIDZ2, even if all disks are SSDs? * Does a separate ZIL and/or ARC cache device still make sense? Any pointers or direct help greatly appreciated. Or should I take this to freebsd-fs@? Thanks and best regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: Best practices for ZFS setup for a strictly SSD based system?
Hi!
> Am 09.02.2016 um 17:32 schrieb Alan Somers <asom...@freebsd.org>:
> [...]
> http://blog.delphix.com/matt/2014/06/06/zfs-stripe-width/
>
>>
>> * Will e.g. MySQL still profit from residing on a mirror
>>instead of a RAIDZ2, even if all disks are SSDs?
>
> Yes, because a mirrored vdev has as many read IOPs as all of its disks
> combined. So a RAID10 of SSDs will have many read IOPs indeed.
Ah … yes. Now I remember :)
> […]
> Will MySQL access its files in fixed-size records? If so, you can set
> the recsize filesystem property accordingly. If not, you should
> probably leave recsize at the default. If you profile MySQL's disk
> accesses and determine that there is a dominant recordsize, then go
> ahead and set ZFS's recsize to the next highest power of two.
>
> As usual, disable atime.
We already knew these. But thanks a lot for the vdev setup
hints! So it will be a mirror for OS and DB and a 4+2 raidz2
for the rest of the data.
Our MySQL zvols are currently set up like this:
DB files:
recordsize=16k
atime=off
primarycache=metadata
InnoDB log files:
recordsize=128k
(rest inherited from above)
Kind regards,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
___
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"
NSS changes in releng/10.2?
Hi, all, I just upgraded an older system from 8.4 to 10.2 in a single go. No unexpected problems, until I tried to use "su": $ su - su: Sorry Well, I *am* a member of the wheel group: $ id uid=10093(ry93) gid=10001(intern) groups=10001(intern),0(wheel),10002(entwickler) Hmmm ... we pull all this information from LDAP. My nsswitch.conf has always been: group: files cache ldap passwd: files cache ldap Without the "compat" entries. Let's check the groups: $ pw group show -a wheel:*:0: wheel:*:0:ry22,ry96,ry90,ry93 Before the update the members were merged. The first line is coming from /etc/group, the second from LDAP. I do have to remove the "root" member in /etc/group from wheel on all systems for LDAP information to be merged in, even on the older systems. But for some reason that seems not to be sufficient, anymore. If I put myself (ry93) in the file, everything works as expected. Another way I tried was this for nsswitch.conf: group: compat group_compat: cache ldap and then the traditional "+:*:0:" entry in /etc/group. The outcome of "id" and "su -" is precisely the same as above. I am shown to be a member of group wheel, yet su won't let me. Any ideas? Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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"
PAM changes? (was: Re: NSS changes in releng/10.2?)
Hi, all,
sorry for not trying this earlier and now replying to myself, but I'm
slowly making progress isolating the problem.
> Am 23.11.2015 um 15:42 schrieb Patrick M. Hausen <hau...@punkt.de>:
>
> Hi, all,
>
> I just upgraded an older system from 8.4 to 10.2 in a single go.
> No unexpected problems, until I tried to use "su":
>
> $ su -
> su: Sorry
>
> Well, I *am* a member of the wheel group:
>
> $ id
> uid=10093(ry93) gid=10001(intern)
> groups=10001(intern),0(wheel),10002(entwickler)
>
> Hmmm ... we pull all this information from LDAP. My nsswitch.conf has always
> been:
>
> group: files cache ldap
> passwd: files cache ldap
And this part seems to be just as valid and working as before. I had the
implicit
assumption that su(1) was using something like getgroups() to determine if I am
a member of "wheel" - which it doesn't. I even hacked up 5 lines of C to quickly
get my supplementary group list and lo and behold:
$ ./groups
10002
0
10001
So, it is not NSS' or LDAP's fault.
I just looked at the source for su(1) and it looks like it uses PAM to check if
I am authorized to su to root:
retcode = pam_authenticate(pamh, 0);
if (retcode != PAM_SUCCESS) {
syslog(LOG_AUTH|LOG_WARNING, "BAD SU %s to %s on %s",
username, user, mytty);
errx(1, "Sorry");
My /etc/pam.d/system looks like this:
--- system ---
#
# $FreeBSD: releng/10.2/etc/pam.d/system 197769 2009-10-05 09:28:54Z des $
#
# System-wide defaults
#
# auth
authsufficient pam_opie.so no_warn no_fake_prompts
authrequisite pam_opieaccess.so no_warn allow_local
#auth sufficient pam_krb5.so no_warn try_first_pass
#auth sufficient pam_ssh.so no_warn try_first_pass
authsufficient /usr/local/lib/pam_ldap.so no_warn
try_first_pass
authrequiredpam_unix.so no_warn try_first_pass
nullok
# account
#accountrequiredpam_krb5.so
account requiredpam_login_access.so
account required/usr/local/lib/pam_ldap.so
ignore_authinfo_unavail ignore_unknown_user
account requiredpam_unix.so
# session
#sessionoptionalpam_ssh.so want_agent
session requiredpam_lastlog.so no_fail
# password
#password sufficient pam_krb5.so no_warn try_first_pass
passwordrequiredpam_unix.so no_warn try_first_pass
--
And /etc/pam.d/su like this:
--- su ---
#
# $FreeBSD: releng/10.2/etc/pam.d/su 219663 2011-03-15 10:13:35Z des $
#
# PAM configuration for the "su" service
#
# auth
authsufficient pam_rootok.so no_warn
authsufficient pam_self.so no_warn
authrequisite pam_group.sono_warn group=wheel
root_only fail_safe ruser
authinclude system
# account
account include system
# session
session requiredpam_permit.so
--
Any changes that I missed on the way from 8.4 to 10.2? Unfortunately
I do not have an older 10.x system that runs with an Active Directory
connection.
Only 8.4 ones - this one was the first to finally get updated to a current
FreeBSD
version.
As I stated this PAM configuration works as intended on 8.4. I generated the
10.2 files above by running mergemaster.
Thanks,
Patrick
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
___
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"
ZFS on labelled partitions (was: Re: LSI SAS2008 mps driver preferred firmware version)
Hi, all, > Am 16.11.2015 um 22:19 schrieb Freddie Cash <fjwc...@gmail.com>: > > You label the disks as they are added to the system the first time. That > way, you always know where each disk is located, and you only deal with the > labels. we do the same for obvious reasons. But I always wonder about the possible downsides, because ZFS documentation explicitly states: ZFS operates on raw devices, so it is possible to create a storage pool comprised of logical volumes, either software or hardware. This configuration is not recommended, as ZFS works best when it uses raw physical devices. Using logical volumes might sacrifice performance, reliability, or both, and should be avoided. (from http://docs.oracle.com/cd/E19253-01/819-5461/gbcik/index.html) Can anyone shed some lght on why not using raw devices might sacrifice performance or reliability? Or is this just outdated folklore? Thanks, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: zfs, mc, mcview and files opening
Hi, all, > Am 10.11.2015 um 12:54 schrieb Eugene M. Zheganin <e...@norma.perm.ru>: > > Hi, > > on 10.11.2015 15:05, Trond Endrestøl wrote: >> I blame file(1), it's hopelessly slow. mcview uses file(1) to deduce >> if it should just display the damn file or run the file through some >> filter. Maybe an option in mc/mcview to disable the use of file(1) is >> an acceptable compromise. > Yeah, you seem to be right. /usr/bin/time -h file /var/log/maillog gives > same time of 37-40 seconds to process the file. > The main answer is now why file(1) is that slow ? I tested it on files > of about same size and UFS - there's no lag at all. > > Is it worth to report this in bugzilla ? Could it be this problem you are experiencing? http://freebsd.1045724.n5.nabble.com/file-1-command-very-slow-td6037309.html Kind regards, Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Swap Questions
HI! Am 14.08.2015 um 15:15 schrieb Tim Daneliuk tun...@tundraware.com: I just built a 10.2 machine on a cloud-based VPS (Digital Ocean) that has 512M of memory and 1G of swap partition. I am seeing a ton of errors like this: [...] So, I added this to fstab (after creating /usr/swap0): Did you create it with dd or just with touch? You need to create a file that actually occupies the disk blocks with dd. HTH Patrick -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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: [SOLVED][BUG??] Unattended install using bsdinstall and ZFS
Hi, Claus,
Am 29.05.2015 um 19:17 schrieb Claus Andersen c...@wheel.dk:
Hi!
A quick re-cap: Want to do an unattended FreeBSD install using bsdinstall and
ZFS. I now have a workaround and consider crying wol^H^H^Hbug.
The following minimal install script works as expected for UFS:
[...]
Hours later I have figure out the following which works(tm):
install-zfs2.txt
DISTRIBUTIONS=kernel.txz base.txz
RELEASE=10.1
export ZFSBOOT_DISKS=da0 da1
export ZFSBOOT_VDEV_TYPE=mirror
export nonInteractive=YES
#!/bin/sh
echo Ready for post installation damage...
Thanks for your detailled report. I can confirm your findings and I was able to
do an unattended install using these settings:
DISTRIBUTIONS=base.txz doc.txz games.txz kernel.txz lib32.txz
INTERFACES=em0
export ZFSBOOT_DISKS=da0 da1
export ZFSBOOT_VDEV_TYPE=mirror
export ZFSBOOT_FORCE_4K_SECTORS=1
export ZFSBOOT_SWAP_SIZE=8g
export ZFSBOOT_SWAP_MIRROR=1
export ZFSBOOT_POOL_CREATE_OPTIONS=-O compress=lz4 -O checksum=fletcher4
export nonInteractive=YES
Yet, there are still 2 things that prevent a truly unattended installation.
First, at least for me,
the installer alway displays a dialog with debug messages which needs to be
explicitly
confirmed at the end of the installation. This is not the case if I use UFS.
With UFS it just
reboots into the freshly installed system.
I could work around that one by explicitly calling reboot at the end of the
shell script
part of installerconfig.
Second, if you do remote installation via IPMI and serial console over IP, the
standard install
environment copied from CD calls this code in /etc/rc.local:
[...]
else
# Serial or other console
echo
echo Welcome to FreeBSD!
echo
echo Please choose the appropriate terminal type for your system.
echo Common console types are:
echoansi Standard ANSI terminal
echovt100VT100 or compatible terminal
echoxtermxterm terminal emulator (or compatible)
echocons25w cons25w terminal
echo
echo -n Console type [vt100]:
read TERM
TERM=${TERM:-vt100}
fi
IMHO hardwiring this is not a good idea. Can be solved by simply commenting out
the unwanted
parts, but this should be configurable in installerconfig. Currently it quite
defeats the purpose of
*unattended* installations. At least I expect power on, get some coffee, login
via ssh into newly
installed system ;-)
Kind regards
Patrick M. Hausen
Leiter Netzwerke und Sicherheit
--
punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe
Tel. 0721 9109 0 * Fax 0721 9109 100
i...@punkt.de http://www.punkt.de
Gf: Jürgen Egeling AG Mannheim 108285
___
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.2-RELEASE stability?
Le Mon, 30 Sep 2013 13:01:26 -0600, Brett Glass br...@lariat.net a écrit : Hello, How stable are folks finding FreeBSD 9.2-RELEASE to be? The improvements are welcome, but there have been a few troubling messages about kernel panics and VM issues on the various mailing lists. It's never clear until the release drops whether these are actual problems with the software or hardware defects in individual systems, so I am eager to hear how the new release is working for everyone. I've seen two problems if you use poudriere (on ZFS only?) which occur in some loads (ie desktop running gvfsd). One fix is in 9-STABLE and the other one should be mfced soon. May be there will be an errata for 9.2-RELEASE for this ? I think that would be nice because 9.2 is stable as a Windows 3.11 with my load :-) Regards. ___ 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: Possible kqueue related issue on STABLE/RC.
Le Wed, 25 Sep 2013 11:06:33 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. Testing looks good with your latest patch. I was able to run a complete poudriere bulk (870 packages). I'm running another bulk to see.. I've made another bulk without problem (with complete patch) If you have other patches to test just ask, I have not updated my packages because there was a change to make gvfsd to ignore some poudriere activity. So I guess it will be harder to see this problem. Could you, please, test with the only patch http://people.freebsd.org/~kib/misc/vnode_filter.1.patch applied ? I wonder would it be enough. Looks good with this single patch too, one poudriere bulk is completed and I'm doing another just in case (but I think it would have already paniced, that's quite reproductible). Thanks, regards. ___ 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: Possible kqueue related issue on STABLE/RC.
Le Wed, 25 Sep 2013 00:21:27 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, On Tue, Sep 24, 2013 at 10:45:17AM -0700, John-Mark Gurney wrote: I'd like to understand why you think protecting these functions w/ the _DETACHED check is correct... In kern_event.c, all calls to f_detach are followed by knote_drop which will ensure that the knote is removed and free, so no more f_event calls will be called on that knote.. My current belief is that what happens is a glitch in the kqueue_register(). After a new knote is created and attached, the kq lock is dropped and then f_event() is called. If the vnode is reclaimed or possible freed meantime, f_event() seems to dereference freed memory, since kn_hook points to freed vnode. The issue as I see it is that vnode lifecycle is detached from the knote lifecycle. Might be, only the second patch, which acquires a hold reference on the vnode for each knote, is really needed. But before going into any conclusions, I want to see the testing results. Testing looks good with your latest patch. I was able to run a complete poudriere bulk (870 packages). I'm running another bulk to see. If you have other patches to test just ask, I have not updated my packages because there was a change to make gvfsd to ignore some poudriere activity. So I guess it will be harder to see this problem. Many thanks Konstantin, Regards ___ 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: Possible kqueue related issue on STABLE/RC.
Le Mon, 23 Sep 2013 23:31:41 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This may be better
because before the box paniced within minutes and now within hours
(still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000, hint=0)
at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status = 24,
kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp = 0xfe016949e190,
p_proc = 0xfe016949e190, p_aio = 0xfe016949e190,
p_lio = 0xfe016949e190}, kn_fop = 0x812fd440,
kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
Also, please follow
http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
to recompile kernel with the debugging options and try to recreate
the panic.
It's building.
Thanks, regards
___
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: Possible kqueue related issue on STABLE/RC.
Le Tue, 24 Sep 2013 11:29:09 +0300,
Konstantin Belousov kostik...@gmail.com a écrit :
Hello,
...
Ok This has been mfced to 9.2-STABLE. But I still see this panic
with 9-2/STABLE of today (Revision : 255811). This may be better
because before the box paniced within minutes and now within
hours (still using poudriere).
panic:
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x808ebfcd
stack pointer = 0x28:0xff824c2e0630
frame pointer = 0x28:0xff824c2e06a0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 54243 (gvfsd-trash)
trap number = 12
panic: page fault
cpuid = 2
KDB: stack backtrace:
#0 0x80939ad6 at kdb_backtrace+0x66
#1 0x808ffacd at panic+0x1cd
#2 0x80cdfbe9 at trap_fatal+0x289
#3 0x80cdff4f at trap_pfault+0x20f
#4 0x80ce0504 at trap+0x344
#5 0x80cc9b43 at calltrap+0x8
#6 0x8099d043 at filt_vfsvnode+0xf3
#7 0x808c4793 at kqueue_register+0x3e3
#8 0x808c4de8 at kern_kevent+0x108
#9 0x808c5950 at sys_kevent+0x90
#10 0x80cdf3a8 at amd64_syscall+0x5d8
#11 0x80cc9e27 at Xfast_syscall+0xf7
Full core.txt :
http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0
For start, please load the core into kgdb and for
frame 8
p *kn
(kgdb) frame 8
#8 0x8099d043 in filt_vfsvnode (kn=0xfe0147a7f000,
hint=0) at /usr/src/sys/kern/vfs_subr.c:4600
4600VI_LOCK(vp);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0x0},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0},
kn_kq = 0xfe01079a6200, kn_kevent = {ident = 62, filter = -4,
flags = 32784, fflags = 0, data = 0, udata = 0x0}, kn_status =
24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {p_fp =
0xfe016949e190, p_proc = 0xfe016949e190, p_aio =
0xfe016949e190, p_lio = 0xfe016949e190}, kn_fop =
0x812f0, kn_hook = 0xfe0119d0b1f8, kn_hookid = 0}
From the kgdb, also please do
p *(struct vnode *)0xfe0119d0b1f8
With a kernel with debug info, this panic becomes mtx_lock() of
destroyed mutex
panic: mtx_lock() of destroyed mutex
http://user.lamaiziere.net/patrick/public/panic_mtx_lock.txt
@ /usr/src/sys/kern/vfs_subr.c:4600 cpuid = 2
KDB: stack backtrace:
#0 0x80920286 at kdb_backtrace+0x66
#1 0x808e738d at panic+0x1cd
#2 0x808d58d6 at _mtx_lock_flags+0x116
#3 0x8098143b at filt_vfsvnode+0x3b
#4 0x808b213a at kqueue_register+0x4ca
#5 0x808b2688 at kern_kevent+0x108
#6 0x808b3190 at sys_kevent+0x90
#7 0x80cbd975 at amd64_syscall+0x2f5
#8 0x80ca8557 at Xfast_syscall+0xf7
(kgdb) frame 5
#5 0x808b213a in kqueue_register (kq=0xfe00ddc98900,
kev=0xff824bb5f880, td=0xfe00b1e7f000, waitok=1) at
/usr/src/sys/kern/kern_event.c:1136
1136event = kn-kn_fop-f_event(kn, 0);
(kgdb) p *kn
$1 = {kn_link = {sle_next = 0x0}, kn_selnext = {sle_next = 0xfe011c232b00},
kn_knlist = 0x0, kn_tqe = {tqe_next = 0x0, tqe_prev = 0x0}, kn_kq =
0xfe00ddc98900,
kn_kevent = {ident = 62, filter = -4, flags = 32784, fflags = 0, data = 0,
udata = 0x0}, kn_status = 24, kn_sfflags = 47, kn_sdata = 0, kn_ptr = {
p_fp = 0xfe00ddd4d870, p_proc = 0xfe00ddd4d870, p_aio =
0xfe00ddd4d870, p_lio = 0xfe00ddd4d870}, kn_fop = 0x812fcca0,
kn_hook = 0xfe02064a6000, kn_hookid = 0}
(kgdb) p *(struct vnode *)0xfe02064a6000
$2 = {v_type = VBAD, v_tag = 0x80d89084 none, v_op = 0x0, v_data =
0x0, v_mount = 0x0, v_nmntvnodes = {tqe_next = 0xfe020d3e6000,
tqe_prev = 0xfe0086625a68}, v_un = {vu_mount = 0x0, vu_socket = 0x0,
vu_cdev = 0x0, vu_fifoinfo = 0x0}, v_hashlist = {le_next = 0x0,
le_prev = 0xff8000de9698}, v_hash = 238022, v_cache_src = {lh_first =
0x0}, v_cache_dst = {tqh_first = 0x0, tqh_last = 0xfe02064a6060},
v_cache_dd = 0x0,
v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_lock = {lock_object =
{lo_name = 0x80f56e48 ufs, lo_flags = 91881472, lo_data = 0,
lo_witness = 0xff80006c3400}, lk_lock = 1, lk_exslpfail = 0, lk_timo
= 51, lk_pri = 96, lk_stack = {depth = 12, pcs = {18446744071571296822,
18446744071573768556, 18446744071576111075, 18446744071606114523,
18446744071576111075, 18446744071572113927, 18446744071572067653,
18446744071606111219,
18446744071572016126, 18446744071572018094, 18446744071575427445,
18446744071575340375, 0, 0, 0, 0, 0, 0}}}, v_interlock = {lock_object = {
lo_name = 0x80f6f8a3 vnode interlock, lo_flags
Re: Possible kqueue related issue on STABLE/RC.
Le Fri, 20 Sep 2013 15:17:05 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : Le Thu, 12 Sep 2013 10:36:43 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Might be, your issue is that some filesystems do not care about proper locking mode for the fifos. UFS carefully disables shared locking for VFIFO, but it seems ZFS is not. I can propose the following band-aid, which could help you. I have no idea is it the same issue as the kqueue panic. diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index c53030a..00bd998 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred *cred, return (error); } } + if (vp-v_type == VFIFO VOP_ISLOCKED(vp) != LK_EXCLUSIVE) + vn_lock(vp, LK_UPGRADE | LK_RETRY); if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) return (error); @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) struct mount *mp; int error, lock_flags; - if (!(flags FWRITE) vp-v_mount != NULL + if (vp-v_type != VFIFO !(flags FWRITE) vp-v_mount != NULL vp-v_mount-mnt_kern_flag MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; else Ok This has been mfced to 9.2-STABLE. But I still see this panic with 9-2/STABLE of today (Revision : 255811). This may be better because before the box paniced within minutes and now within hours (still using poudriere). panic: fault code = supervisor read data, page not present instruction pointer = 0x20:0x808ebfcd stack pointer = 0x28:0xff824c2e0630 frame pointer = 0x28:0xff824c2e06a0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 54243 (gvfsd-trash) trap number = 12 panic: page fault cpuid = 2 KDB: stack backtrace: #0 0x80939ad6 at kdb_backtrace+0x66 #1 0x808ffacd at panic+0x1cd #2 0x80cdfbe9 at trap_fatal+0x289 #3 0x80cdff4f at trap_pfault+0x20f #4 0x80ce0504 at trap+0x344 #5 0x80cc9b43 at calltrap+0x8 #6 0x8099d043 at filt_vfsvnode+0xf3 #7 0x808c4793 at kqueue_register+0x3e3 #8 0x808c4de8 at kern_kevent+0x108 #9 0x808c5950 at sys_kevent+0x90 #10 0x80cdf3a8 at amd64_syscall+0x5d8 #11 0x80cc9e27 at Xfast_syscall+0xf7 Full core.txt : http://user.lamaiziere.net/patrick/public/vfs_vnode-core.txt.0 Thanks, regards. ___ 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: Possible kqueue related issue on STABLE/RC.
Le Thu, 12 Sep 2013 10:36:43 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Might be, your issue is that some filesystems do not care about proper locking mode for the fifos. UFS carefully disables shared locking for VFIFO, but it seems ZFS is not. I can propose the following band-aid, which could help you. I have no idea is it the same issue as the kqueue panic. diff --git a/sys/kern/vfs_vnops.c b/sys/kern/vfs_vnops.c index c53030a..00bd998 100644 --- a/sys/kern/vfs_vnops.c +++ b/sys/kern/vfs_vnops.c @@ -267,6 +267,8 @@ vn_open_vnode(struct vnode *vp, int fmode, struct ucred *cred, return (error); } } + if (vp-v_type == VFIFO VOP_ISLOCKED(vp) != LK_EXCLUSIVE) + vn_lock(vp, LK_UPGRADE | LK_RETRY); if ((error = VOP_OPEN(vp, fmode, cred, td, fp)) != 0) return (error); @@ -358,7 +360,7 @@ vn_close(vp, flags, file_cred, td) struct mount *mp; int error, lock_flags; - if (!(flags FWRITE) vp-v_mount != NULL + if (vp-v_type != VFIFO !(flags FWRITE) vp-v_mount != NULL vp-v_mount-mnt_kern_flag MNTK_EXTENDED_SHARED) lock_flags = LK_SHARED; else Hmmm, So what is the fix for 9.2-STABLE ? As far I can see there is no function vn_open_vnode() here and I don't see where I should patch. I see this panic too (with STABLE of today), while using poudriere + ZFS like Jimmy. Thanks, regards ___ 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: java (openjdk6) segfaults when built with 9-stable clang
Le Fri, 26 Jul 2013 00:05:50 +0200, Baptiste Daroussin b...@freebsd.org a écrit : Hi all, Baptiste, Hi I recently upgraded my home NAS from 9.1-RELEASE to 9-stable (r253470 (9.2-BETA1)) I also upgraded my poudriere building jail. Since then, multimedia/xbmc port fails to build in configure stage : java segfaults (sig11). I use WITH_CLANG_IS_CC=YES, for world and build-jails. I found following workarounds: - use previously (with 9.1-RELEASE world and clang) build openjdk6 pkg (same version). - use USE_GCC=YES for java port. It's the only one place I use java (openjdk6-b27_4). So I cannot say if java works otherwise. Is this a java or clang bug ? Here is the bug http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6636110 Fixed in b27_6 Hmm, Isn't Openjdk7 affected too ? http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=2219304 Someone complains on the FreeBSD forums for openjdk7, I think it needs to be patched too. http://forums.freebsd.org/showthread.php?t=41181 Thanks, regards, ___ 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: Please remove Perl from ports
Le Thu, 1 Aug 2013 08:31:45 -0700 (PDT), Chris H bsd-li...@1command.com a écrit : Greetings, I currently manage several RELENG_8 servers. Recent changes in the manner in which base ports must be managed have resulted in more than a fair amount of grief. the migration from cv(sup) -- subversion required re-working long standing, carefully crafted management procedures to be pitched to the trash, and re-invented. A recent change to the Perl installation structure presents an entire new set of headaches, rendering up(grading|dating) near, if not completely impossible. that's not new. A perl upgrade was always painful. I suggest to use poudriere to build yours packages and pkgng to manage them. As poudriere produces a consistent set of packages, an upgrade is painless (pkg upgrade -f) and you can deploy them on several machines. In fact poudriere and pkg saved me :) Regards. ___ 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: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Wed, 17 Jul 2013 08:37:18 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Thanks Konstantin. I'm trying your patch and that looks better. poudriere runs since 3 hours now (before the box paniced few minutes after I start a poudriere bulk) (I've removed the previous change to panic on the warning WARNING: destroying knlist w/ knotes on it! / I guess it is ok ?) As far I can see gamin still works (xfce sees changes and the testgam tool works fine : https://people.gnome.org/~veillard/gamin/debug.html) Does stopping the gamin server work as well ? Yes. $ export GAMIN_DEBUG_SERVER=/usr/pkg/usr/ports/devel/gamin/work/gamin-0.1.10/server/gam_server $ export GAM_CLIENT_ID=test $ export GAM_DEBUG= $ /usr/pkg/usr/ports/devel/gamin/work/gamin-0.1.10/tests/testgam - connect test FAMOpen() Reusing socket directory /tmp/fam-patrick Asking to launch /usr/pkg/usr/ports/devel/gamin/work/gamin-0.1.10/server/gam_server with client id test /// (ps shows this process) mondir /poudriere_data/build/9amd64-default ... (some events) ^C $ Then after the end of the client testgam, the gam_server disappears so that looks good. Thanks Konstantin and Mateusz. Regards. ___ 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: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Tue, 16 Jul 2013 22:14:36 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : Hello, Thanks Konstantin. I'm trying your patch and that looks better. poudriere runs since 3 hours now (before the box paniced few minutes after I start a poudriere bulk) (I've removed the previous change to panic on the warning WARNING: destroying knlist w/ knotes on it! / I guess it is ok ?) As far I can see gamin still works (xfce sees changes and the testgam tool works fine : https://people.gnome.org/~veillard/gamin/debug.html) I will run few poudriere bulk tomorrow and report the result here. looks good :) Many thanks! Regards. ___ 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: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Tue, 16 Jul 2013 09:05:55 +0300, Konstantin Belousov kostik...@gmail.com a écrit : Hello, Thanks Konstantin. I'm trying your patch and that looks better. poudriere runs since 3 hours now (before the box paniced few minutes after I start a poudriere bulk) (I've removed the previous change to panic on the warning WARNING: destroying knlist w/ knotes on it! / I guess it is ok ?) As far I can see gamin still works (xfce sees changes and the testgam tool works fine : https://people.gnome.org/~veillard/gamin/debug.html) I will run few poudriere bulk tomorrow and report the result here. I've tried on my workstation at work which uses the same configuration as at home, but I was not able to reproduce this problem. The only big change is that it has 8 GB RAM versus 4 GB here. I don't know what can trigger this panic. If you have patch to test or idea, please let me know. Thanks, regards. ___ 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: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Mon, 15 Jul 2013 16:26:47 +0200, Mateusz Guzik mjgu...@gmail.com a écrit : Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt With WITNESS and ASSERTION on, I see a warning that looks related : Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it! and the box panics just after this. can you switch that printf to a panic and paste backtrace? Yes the full core.txt : http://user.lamaiziere.net/patrick/panic_knlist_wknotes.txt panic: WARNING: destroying knlist w/ knotes on it! Unread portion of the kernel message buffer: lock order reversal: 1st 0xfe00b678c098 ufs (ufs) @ /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:620 2nd 0x813ebda0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2822 KDB: stack backtrace: #0 0x8094bc26 at kdb_backtrace+0x66 #1 0x809603ae at _witness_debugger+0x2e #2 0x80961a85 at witness_checkorder+0x865 #3 0x8091b1ea at _sx_slock+0x5a #4 0x808d30ff at mountcheckdirs+0x3f #5 0x809a890f at dounmount+0x2df #6 0x809a913e at sys_unmount+0x3ce #7 0x80cec429 at amd64_syscall+0x2f9 #8 0x80cd6d47 at Xfast_syscall+0xf7 panic: WARNING: destroying knlist w/ knotes on it! cpuid = 3 KDB: stack backtrace: #0 0x8094bc26 at kdb_backtrace+0x66 #1 0x80912da8 at panic+0x1d8 #2 0x808db269 at knlist_destroy+0x39 #3 0x809afd7e at destroy_vpollinfo+0x1e #4 0x809b13ef at vdropl+0x18f #5 0x809b404c at vputx+0xac #6 0x8299ce13 at null_reclaim+0x103 #7 0x80d912eb at VOP_RECLAIM_APV+0xdb #8 0x809b20a2 at vgonel+0x112 #9 0x809b4cd9 at vflush+0x2b9 #10 0x8299bbb3 at nullfs_unmount+0x43 #11 0x809a8982 at dounmount+0x352 #12 0x809a913e at sys_unmount+0x3ce #13 0x80cec429 at amd64_syscall+0x2f9 #14 0x80cd6d47 at Xfast_syscall+0xf7 Uptime: 4m47s Dumping 915 out of 3544 MB:..2%..11%..21%..32%..41%..51%..62%..72%..81%..91% #0 doadump (textdump=value optimized out) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:234 #1 0x80913354 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x80912d79 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0x808db269 in knlist_destroy (knl=value optimized out) at /usr/src/sys/kern/kern_event.c:1961 #4 0x809afd7e in destroy_vpollinfo (vi=0xfe007ffec690) at /usr/src/sys/kern/vfs_subr.c:3583 #5 0x809b13ef in vdropl (vp=0xfe00b678c000) at /usr/src/sys/kern/vfs_subr.c:2530 #6 0x809b404c in vputx (vp=0xfe00b678c000, func=2) at /usr/src/sys/kern/vfs_subr.c:2358 #7 0x8299ce13 in ?? () #8 0x8299d510 in ?? () #9 0xfe0002ec in ?? () #10 0xff81090b8750 in ?? () #11 0x0246 in ?? () #12 0xfe002af55000 in ?? () #13 0x81576950 in w_locklistdata () #14 0x81322ce0 in pmc___lock_failed () #15 0x8299d8a0 in ?? () #16 0xff81090b87b0 in ?? () #17 0x in ?? () (kgdb) Thanks, regards ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
(9.2) panic under disk load (gam_server / knlist_remove_kq)
9.2 PRERELEASE (today) / amd64 Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x58 fault code = supervisor read data, page not present Unread portion of the kernel message buffer: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 02 fault virtual address = 0x58 fault code = supervisor read data, page not present instruction pointer = 0x20:0x808f1bf1 stack pointer = 0x28:0xff8108e12a40 frame pointer = 0x28:0xff8108e12a70 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 23557 (gam_server) trap number = 12 panic: page fault cpuid = 1 ... #0 doadump (textdump=value optimized out) at pcpu.h:234 234 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=value optimized out) at pcpu.h:234 #1 0x8092e4d6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:449 #2 0x8092e9d7 in panic (fmt=0x1 Address 0x1 out of bounds) at /usr/src/sys/kern/kern_shutdown.c:637 #3 0x80d13030 in trap_fatal (frame=0xc, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:879 #4 0x80d13391 in trap_pfault (frame=0xff8108e12990, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:795 #5 0x80d13944 in trap (frame=0xff8108e12990) at /usr/src/sys/amd64/amd64/trap.c:463 #6 0x80cfcc73 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:232 #7 0x808f1bf1 in knlist_remove_kq (knl=0x30, kn=0xfe003b70b280, knlislocked=0, kqislocked=0) at /usr/src/sys/kern/kern_event.c:1847 #8 0x808f4a5b in knote_fdclose (td=0xfe0009a34490, fd=9924) at /usr/src/sys/kern/kern_event.c:2065 #9 0x808ea573 in kern_close (td=0xfe0009a34490, fd=9924) at /usr/src/sys/kern/kern_descrip.c:1250 #10 0x80d127da in amd64_syscall (td=0xfe0009a34490, traced=0) at subr_syscall.c:135 #11 0x80cfcf57 in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #12 0x0008019e9a9c in ?? () Previous frame inner to this frame (corrupt stack?) (kgdb) Thanks, regards ___ 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: (9.2) panic under disk load (gam_server / knlist_remove_kq)
Le Sun, 14 Jul 2013 11:59:53 +0200, Patrick Lamaiziere patf...@davenulle.org a écrit : Hello, 9.2 PRERELEASE (today) / amd64 Hello, I'm seeing a panic while trying to build a poudriere repository. As far I can see it always happens when gam_server is started (ie xfce is running) and under disk load (poudriere bulk build) : (That is something new, the box was pretty stable) the complete crash dump (core.0.txt) is here: http://user.lamaiziere.net/patrick/panic_gam_server.txt With WITNESS and ASSERTION on, I see a warning that looks related : Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it! and the box panics just after this. Also there are too LOR just before the panic, I don't know it there are related or not : Jul 14 16:23:29 roxette kernel: lock order reversal: Jul 14 16:23:29 roxette kernel: 1st 0xfe0013335878 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1240 Jul 14 16:23:29 roxette kernel: 2nd 0xfe00495a5488 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2335 Jul 14 16:23:29 roxette kernel: KDB: stack backtrace: Jul 14 16:23:29 roxette kernel: #0 0x8094bc36 at kdb_backtrace+0x66 Jul 14 16:23:29 roxette kernel: #1 0x809603be at _witness_debugger+0x2e Jul 14 16:23:29 roxette kernel: #2 0x80961a95 at witness_checkorder+0x865 Jul 14 16:23:29 roxette kernel: #3 0x808f8e21 at __lockmgr_args+0x1161 Jul 14 16:23:29 roxette kernel: #4 0x8099f739 at vop_stdlock+0x39 Jul 14 16:23:29 roxette kernel: #5 0x80d93593 at VOP_LOCK1_APV+0xe3 Jul 14 16:23:29 roxette kernel: #6 0x809c0727 at _vn_lock+0x47 Jul 14 16:23:29 roxette kernel: #7 0x809b42d8 at vputx+0x328 Jul 14 16:23:29 roxette kernel: #8 0x809a88d4 at dounmount+0x294 Jul 14 16:23:29 roxette kernel: #9 0x809a914e at sys_unmount+0x3ce Jul 14 16:23:29 roxette kernel: #10 0x80cec439 at amd64_syscall+0x2f9 Jul 14 16:23:29 roxette kernel: #11 0x80cd6d57 at Xfast_syscall+0xf7 Jul 14 16:23:29 roxette kernel: lock order reversal: Jul 14 16:23:29 roxette kernel: 1st 0xfe006e1eac68 ufs (ufs) @ /usr/src/sys/modules/nullfs/../../fs/nullfs/null_vnops.c:620 Jul 14 16:23:29 roxette kernel: 2nd 0x813ebda0 allproc (allproc) @ /usr/src/sys/kern/kern_descrip.c:2822 Jul 14 16:23:29 roxette kernel: KDB: stack backtrace: Jul 14 16:23:29 roxette kernel: #0 0x8094bc36 at kdb_backtrace+0x66 Jul 14 16:23:29 roxette kernel: #1 0x809603be at _witness_debugger+0x2e Jul 14 16:23:29 roxette kernel: #2 0x80961a95 at witness_checkorder+0x865 Jul 14 16:23:29 roxette kernel: #3 0x8091b1fa at _sx_slock+0x5a Jul 14 16:23:29 roxette kernel: #4 0x808d30ff at mountcheckdirs+0x3f Jul 14 16:23:29 roxette kernel: #5 0x809a891f at dounmount+0x2df Jul 14 16:23:29 roxette kernel: #6 0x809a914e at sys_unmount+0x3ce Jul 14 16:23:29 roxette kernel: #7 0x80cec439 at amd64_syscall+0x2f9 Jul 14 16:23:29 roxette kernel: #8 0x80cd6d57 at Xfast_syscall+0xf7 Jul 14 16:23:29 roxette kernel: WARNING: destroying knlist w/ knotes on it! Thanks, regards ___ 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: EuroBSDcon 2013: Call for Proposals, Conference on September 28+29 2013
On 4/16/13 10:59 AM, Andre Oppermann wrote: On 15.04.2013 05:32, Julian Elischer wrote: On 4/11/13 5:18 PM, Andre Oppermann wrote: Excuse me for being slightly spammy but I've received feedback that we haven't spread this information widely enough outside the inner circles and interested people missed the announcement. EuroBSDcon 2013: September 28-29 in Malta = EuroBSDcon is the European technical conference for users and developers of BSD-based systems. The conference will take place Saturday and Sunday 28-29 September at the Hilton Conference Centre in St. Julian's, Malta (tutorials and FreeBSD Developer Summit on preceding Thursday and Friday, talks on Saturday and Sunday). [Yes, very nice weather at that time of year, about 26/19C sunny no rain, Social event on Saturday evening is going to be a sunset beach BBQ] The web page suggest I bring my wife AND my spouse.. what if they don't know about each other? Well, you have poorly managed your relationships then. ;) This web page is a place holder and will be updated with the all important details on venue/travel/hotels/schedule really soon now. Tweeted: BSDTV: EuroBSDcon 2013: September 28-29 in Malta : 2013.eurobsdcon.org Your family will actually want to travel with you! #BSD P ___ 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?
Hi, Am 09.04.2013 um 17:05 schrieb Patrick M. Hausen hau...@punkt.de: PORTSSUPFILE= -b base/head -l /usr/ports ports/head, of course. Regards Patrick M. Hausen Leiter Netzwerke und Sicherheit -- punkt.de GmbH * Kaiserallee 13a * 76133 Karlsruhe Tel. 0721 9109 0 * Fax 0721 9109 100 i...@punkt.de http://www.punkt.de Gf: Jürgen Egeling AG Mannheim 108285 ___ 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
