Re: Intel 82574 issue reported on Slashdot
In all honesty.. The blog post (and your email) are basically information free, they don't name names and provide no script or downloadable code that will allow end users to check if they are affected. A link with a little bit more information: http://blog.krisk.org/2013/02/packets-of-death.html Daniel O'Connor software and network engineer --Johnny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: uath panic on insert.
Hans Petter Selasky wrote: On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: Hans Petter Selasky wrote: Hi, Your problem should be fixed by: http://svnweb.freebsd.org/changeset/base/246565 Please test and report back if it doesn't. It doesn't panic anymore. Thanks. There's a new problem though: uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/246570 ugen1.5: Atheros Communications Inc at usbus1 Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 Ethernet address: 00:11:95:d3:4a:af uath_cmdsend: empty inactive queue could not init Tx queues, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 at uhub2, port 2, addr 5 (disconnected) --- uath_cmdsend: empty inactive queue uath_cmdsend: empty inactive queue ugen1.5: Atheros Communications Inc at usbus1 (disconnected) The card still disconnects after attempting to scan unsupported frequencies. The sequence above happens when I 'ifconfig wlan1 up'. Also, the uath driver reports 2.4GHz and 5GHz as supported channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz device. Is this a problem for Adrian to look at? Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: uath panic on insert.
On Saturday 09 February 2013 09:47:46 Ian FREISLICH wrote: Hans Petter Selasky wrote: On Friday 08 February 2013 22:43:17 Ian FREISLICH wrote: Hans Petter Selasky wrote: Hi, Your problem should be fixed by: http://svnweb.freebsd.org/changeset/base/246565 Please test and report back if it doesn't. It doesn't panic anymore. Thanks. There's a new problem though: uath0: Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 wlan1: Ethernet address: 00:11:95:d3:4a:af Hi, Can you try this patch: http://svnweb.freebsd.org/changeset/base/246570 ugen1.5: Atheros Communications Inc at usbus1 Atheros Communications Inc USB WLAN Device, rev 2.00/0.01, addr 5 on usbus1 Ethernet address: 00:11:95:d3:4a:af uath_cmdsend: empty inactive queue could not init Tx queues, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 uath_cmdsend: empty inactive queue could not set channel, error 55 at uhub2, port 2, addr 5 (disconnected) --- uath_cmdsend: empty inactive queue uath_cmdsend: empty inactive queue ugen1.5: Atheros Communications Inc at usbus1 (disconnected) The card still disconnects after attempting to scan unsupported frequencies. The sequence above happens when I 'ifconfig wlan1 up'. Also, the uath driver reports 2.4GHz and 5GHz as supported channels for this chip but it's a D-Link DWL-G132 which is a 2.4GHz device. Is this a problem for Adrian to look at? Hi, I see the same over here. I think it is not a USB problem. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 09-02-2013 8:32, Joel Dahl wrote: Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device ??? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device ?? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. BOOM -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: On 09-02-2013 8:32, Joel Dahl wrote: Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device ??? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device ?? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. Hi, You can try to set the no-synchronize cache quirk in sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but else I suspect it is not an USB issue. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel 82574 issue reported on Slashdot
On 09/02/2013, at 20:42, Parv p...@pair.com wrote: Contact your motherboard manufacturer is much more time consuming than Run sysctl... | grep foo | awk ... to see if your system is affected. Gift^WStraight from horse's mouth ... http://blog.krisk.org/2013/02/packets-of-death.html I've already read this. http://www.kriskinc.com/intel-pod I'd really rather a test which reads the EEPROM and tells me if it's a problem rather than hang the interface on a machine :) In any case that isn't the point - this may be a vendor issue but it reflects poorly on Intel that they didn't take proper ownership of the issue. It would be far, far better for their image to say some systems may have the fault, go to http:// to find a way to test for your operating system. -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Summary of junk emails blocked - 1 Junk Emails Blocked
Junk Box Summary for: curr...@freebsd.org The 1 emails listed below have been placed in your personal Junk Box since your last Junk Box Summary and will be deleted after 30 days. To retrieve any of these messages, visit your Junk Box at: http://10.10.10.17:10080 Login using your standard username/password combination. Junk Box Summary - n...@gmail.com =?windows-1251?B?W8rIxcJdIMLA0NjAwtHKwN8gwcjQxsAg1sXNzd... - Junk blocking by SonicWALL ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel 82574 issue reported on Slashdot
Am 02/09/13 09:15, schrieb Johnny Eriksson: In all honesty.. The blog post (and your email) are basically information free, they don't name names and provide no script or downloadable code that will allow end users to check if they are affected. A link with a little bit more information: http://blog.krisk.org/2013/02/packets-of-death.html Daniel O'Connor software and network engineer --Johnny We don't even have the tool tcpreplay in the ports mentioned in that BLOG. oh signature.asc Description: OpenPGP digital signature
Re: geli(8) breaks after a couple hours of uptime
Eitan Adler li...@eitanadler.com wrote: On 8 February 2013 07:46, Andriy Gapon a...@freebsd.org wrote: on 08/02/2013 13:48 Ulrich Spörlein said the following: It looks like 128k as a limit is still too low for geli(8) to work, and I've set it to 256k now, so that I can use sudo geli. Can you maybe revise the patch to not use 1024k as an arbitrary limit, but rather make sure you test for precisely as much memory as will be needed? IIRC 256K didn't work for me, 512K did, so I doubled it to have some leg room. I'm not sure it's possible to reliably estimate the required memory without first changing geli to mlock less generously, something Konstantin suggested in: http://lists.freebsd.org/pipermail/svn-src-all/2013-January/063939.html While I agree that mlocking less generously would technically be a better solution than increasing the limit, it would also require a lot more work, additional audits to make sure it's done correctly and in case of geli I don't really see a problem with mlocking 1024K for a few seconds. Also, can we maybe revisit the new 64k default limit, as it will obviously make peoples work with geli a bit painful, this should work out of the box. I have some, IMO, better suggestions: - use -c option with sudo I usually execute sudo geli through a wrapper (zogftw) so this makes patching geli optional for me. Thanks for mentioning it (again). - tune your system for your needs - [major] abolish the silliness of tying resource limits to login class and apply resource limits based on user and group IDs; including after su/sudo (subject to local policies) While we are dreaming, it would be nice to have more resource limits that apply to all the processes belonging to the user combined. It also wouldn't hurt to document why a 64K per-process limit with an unlimited number of processes per user is considered a good default in the first place. The default settings should not make another feature unusable. At a minimum it should be documented in geli's man page that such tuning is required. If the consensus is that 1024K are too much for geli and nobody can be bothered to come up with a more fine grained mlocking patch, geli could be changed to check the mlock limit and exit with a useful error message if it's too low. This would at least prevent the segfault. Fabian signature.asc Description: PGP signature
Re: Intel 82574 issue reported on Slashdot
in message a18965a6-8d17-4919-9947-fe43d2503...@gsoft.com.au, wrote Daniel O'Connor thusly... On 09/02/2013, at 4:46, Jack Vogel jfvo...@gmail.com wrote: recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted. Here is the link: http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement Any questions or concerns may be sent to me. In all honesty.. The blog post (and your email) are basically information free, they don't name names and provide no script or downloadable code that will allow end users to check if they are affected. Contact your motherboard manufacturer is much more time consuming than Run sysctl... | grep foo | awk ... to see if your system is affected. Gift^WStraight from horse's mouth ... http://blog.krisk.org/2013/02/packets-of-death.html http://www.kriskinc.com/intel-pod - parv -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Physbio changes final call for tests and reviews
Konstantin Belousov kostik...@gmail.com wrote: I finished the last (insignificant) missed bits in the Jeff' physbio work. Now I am asking for the last round of testing and review, esp. for the !x86 architectures. Another testing focus are the SCSI HBAs and RAID controllers which drivers are changed by the patchset. Please do test this before the patchset is committed into HEAD ! I could only test on amd64 without fancy SCSI controllers, but it works for me. Fabian signature.asc Description: PGP signature
Re: Intel 82574 issue reported on Slashdot
## O. Hartmann (ohart...@zedat.fu-berlin.de): We don't even have the tool tcpreplay in the ports mentioned in that BLOG. It's in net-mgmt/tcpreplay. Regards, Christoph -- Spare Space ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Destroying ZFS snapshots too quickly: xpt_scan_lun: can't allocate CCB, can't continue
Before the introduction of async_destroy I wrote a script to destroy ZFS snapshots in parallel to speed up the process. It's available at: http://www.fabiankeil.de/sourcecode/zfs-snapshot-destroyer/zsd.pl A couple of years ago the only downside seemed to be that it requires more memory and file descriptors (due to multiple zfs processes running at the same time) and that errors are ignored (implementation detail of the script). Recently I noticed that destroying several hundred (500) snapshots this way risks rendering the system unresponsive. I rarely do that, so it might not actually be a regression. When using X the screen freezes and keyboard input is ignored so it's hard to tell what's going on. When running the script on the console alt+Fx are often still accepted to switch consoles, but other keyboard input like entering commands or trying to login has no visible effect. A running top is killed and the system frequently logs: xpt_scan_lun: can't allocate CCB, can't continue. Plugging in USB devices still result in the expected messages, but other than this the system seems to be unresponsive and doesn't recover (I only waited a couple of minutes, though). A CCB seems to be rather small: http://fxr.watson.org/fxr/source/cam/cam_xpt.c#L4386 therefore I suspect that ZFS got greedy and didn't play nice with the rest of the system. I have no proof that ZFS isn't merely triggering a problem in another subsystem, though. So far I haven't been able to reproduce the problem with snapshots intentionally created for testing, but I also used a somewhat simplistic approach to populate the snapshots. Is this considered a bug or is quickly destroying snapshots just something for the don't do this or not without proper tuning departments? I would also be interested to know if there's a way to somehow roughly figure out from userland how many snapshots can be safely destroyed in a row. Example: Look at some system state, destroy a safe amount of snapshots, look at some system state again and interpolate. Before top gets killed it usually shows that zfskern takes more than 50% WCPU, but this can also happen when the system doesn't become unresponsive and thus probably isn't a good metric (the delay also doesn't help of course). Fabian signature.asc Description: PGP signature
Re: geli(8) breaks after a couple hours of uptime
On 2/9/13 5:07 PM, Fabian Keil wrote: This would at least prevent the segfault. I see two possibilities to get segfault: - no checking for result from memory allocation functions - too big stack I have no found any broken memory allocation checking, but I found two big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change these two to malloc(), then we can handle error from malloc(), print some useful message and prevent segfault. -- Andrey Zonov signature.asc Description: OpenPGP digital signature
Re: Intel 82574 issue reported on Slashdot
On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder c...@burggraben.net wrote: ## O. Hartmann (ohart...@zedat.fu-berlin.de): We don't even have the tool tcpreplay in the ports mentioned in that BLOG. It's in net-mgmt/tcpreplay. And I managed to build mentioned Ostinato packet crafting utility with no problem on my FreeBSD 9.1-RELEASE AMD64. If they provide package and release (which I already asked from the authors) I will make a port for this tool as well :-) Best regards :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geli(8) breaks after a couple hours of uptime
on 09/02/2013 15:07 Fabian Keil said the following: It also wouldn't hurt to document why a 64K per-process limit with an unlimited number of processes per user is considered a good default in the first place. I don't think that maxproc=unlimited is a good default regardless of memorylocked. OTOH, we have kern.maxprocperuid. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geli(8) breaks after a couple hours of uptime
on 09/02/2013 17:04 Andrey Zonov said the following: On 2/9/13 5:07 PM, Fabian Keil wrote: This would at least prevent the segfault. I see two possibilities to get segfault: - no checking for result from memory allocation functions - too big stack I have no found any broken memory allocation checking, but I found two big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change these two to malloc(), then we can handle error from malloc(), print some useful message and prevent segfault. I'd rather do what Kostik suggested and Fabian mentioned: instead of mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated) buffers that can contain sensitive data. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [patch] Userland DTrace
On 08/02/2013 20:04, Matt Burke wrote: I've been spending some time trying to get the fasttrap provider to work on FreeBSD without panicing. I believe I have succeeded, at least to the point where it's no longer panicing. There were two panic causes. The first was http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of fasttrap.c caused ftp_rcount to be left 0. To fix this I've got rid of the early return and reverted to the opensolaris way. A second panic then showed up intermittently when fasttrap_pid_cleanup_cb was run while something in userland had locks. Using sx_try_xlock calls has stopped the panics and shouldn't affect operation AFAICT. This is against r246454. Although this has fixed the panics for me, I'm finding a lot of stuff just isn't actually working, with dtrace and the traced process just chewing CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I have no idea what the target is doing... CPU time is split 2:1 dtrace:target Also noteworthy is the LOR on the first time you try to use the fasttrap provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479 The lock order there seems right, so I'm guessing something else must have done it wrong first? How can I find out what the something else is? Hi Matt, It might be worth posting the question to the dtrace list if your question is unanswered. http://dtrace.org/blogs/mailing-list/ Regards, Sevan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 09.02.2013 12:15, Hans Petter Selasky wrote: On Saturday 09 February 2013 10:26:59 Joel Dahl wrote: On 09-02-2013 8:32, Joel Dahl wrote: Hi, I suspect something is broken with memsticks built from HEAD. I noticed that I couldn't boot the latest HEAD (amd64) memstick snapshot on two machines (Lenovo X220 and HP ProLiant ML350 G5). Trying snapshots from the FreeBSD.org FTP or allbsd.org makes no difference. I compared output from booting RELENG_9 and HEAD: RELENG_9: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:4:0:-1: Attached to scbus4 da0 at umass-sim0 bus 0 scbus4 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-2 device ??? da0: 40.000MB/s transfers da0: 1905MB (3903264 512 byte sectors: 255H 63S/T 24SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... Starting file system checks: /dev/ufs/FreeBSD_Install: FILE SYSTEM CLEAN; SKIPPING CHECKS /dev/ufs/FreeBSD_Install: clean, 43155 free (507 frags, 5331 blocks, 0.1% fragmentation) Mounting local file systems:. and it works. HEAD: ugen2.3: Kingston at usbus2 umass0: Kingston DataDtraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over Bulk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device ?? da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470SC) (da0-umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 0 0 0 1 0 (da0-umass-sim0:0:0:0): CAM status: SCSI Status Error (da0-umass-sim0:0:0:0): SCSI status: Check Condition (da0-umass-sim0:0:0:0): SCSI sense: No sense data present (da0-umass-sim0:0:0:0): Retrying command (per sense data) SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT SNIP LOTS OF REDUNDANT OUTPUT (da0-umass-sim0:0:0:0): Error 5, Retries exhausted (da0-umass-sim0:0:0:0): got CAM status 0x8c (da0-umass-sim0:0:0:0): fatal error, failed to attach to device (da0-umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0-umass-sim0:0:0:0): removing device entry ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro,noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. Hi, You can try to set the no-synchronize cache quirk in sys/dev/usb/quirk/usb_quirk.c for your device. I'm not sure if it helps, but else I suspect it is not an USB issue. How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Intel 82574 issue reported on Slashdot
On 02/09/13 09:15, Johnny Eriksson wrote: In all honesty.. The blog post (and your email) are basically information free, they don't name names and provide no script or downloadable code that will allow end users to check if they are affected. A link with a little bit more information: http://blog.krisk.org/2013/02/packets-of-death.html Daniel O'Connor software and network engineer --Johnny ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org Did anyone check to see if the Intel announcement had a 2 at 0x47f? :) I do have a machine with these controllers that had a bridge hang in a very odd fashion a while back, but it didn't repeat. It wasn't a SuperMicro board, which is what some posters were saying were affected. I would imagine a large ping packet (as used to test MTU) should inoculate any affected interface if issued at boot, I don't think our padding lines up with the problem. Once an interface sees a packet with anything else at 0x47f, it's no longer affected, so there's a narrow window of vulnerability in affected NICs. Matt ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
some usb troubles
Hi all, trying to run macbookpro10,1 on HEAD: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) Between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can find here: http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt pciconf: http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt any help would be greatly apprecated. -- Have fun! chd pgpX2XRXgWJHB.pgp Description: PGP signature
Re: [patch] Userland DTrace
On Fri, Feb 08, 2013 at 04:04:38PM +, Matt Burke wrote:
I've been spending some time trying to get the fasttrap provider to work
on FreeBSD without panicing. I believe I have succeeded, at least to the
point where it's no longer panicing.
There were two panic causes. The first was
http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
fasttrap.c caused ftp_rcount to be left 0. To fix this I've got rid of
the early return and reverted to the opensolaris way.
A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
was run while something in userland had locks. Using sx_try_xlock calls
has stopped the panics and shouldn't affect operation AFAICT.
I've run into this too. It can happen even when I'm not using DTrace
since fasttrap.ko is always loaded on my system. The problem is that
fasttrap_exec_exit() is called every time a process exits in this case;
the caller acquires dtrace_lock, and the panic occurs when a callout
thread tries to acquire the lock at the same time.
This is against r246454.
Although this has fixed the panics for me, I'm finding a lot of stuff just
isn't actually working, with dtrace and the traced process just chewing
CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
have no idea what the target is doing... CPU time is split 2:1
dtrace:target
Another panic can occur with an INVARIANTS kernel if a DTrace victim
process forks. I've supplied a patch which fixes this for me here:
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171360
Also noteworthy is the LOR on the first time you try to use the fasttrap
provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
The lock order there seems right, so I'm guessing something else must
have done it wrong first? How can I find out what the something else
is?
Thanks
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
@@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id)
return (EBUSY);
}
} else {
+#if defined(sun)
mutex_enter(dtrace_provider_lock);
mutex_enter(mod_lock);
mutex_enter(dtrace_lock);
+#else
+ if (sx_try_xlock(dtrace_provider_lock) == 0)
+ return (EBUSY);
+ if (sx_try_xlock(mod_lock) == 0) {
+ mutex_exit(dtrace_provider_lock);
+ return (EBUSY);
+ }
+ if (sx_try_xlock(dtrace_lock) == 0) {
+ mutex_exit(mod_lock);
+ mutex_exit(dtrace_provider_lock);
+ return (EBUSY);
+ }
+#endif
}
/*
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
@@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
ASSERT(id == probe-ftp_id);
- mutex_enter(provider-ftp_mtx);
-
/*
* We won't be able to acquire a /proc-esque lock on the process
* iff the process is dead and gone. In this case, we rely on the
* provider lock as a point of mutual exclusion to prevent other
* DTrace consumers from disabling this probe.
*/
- if ((p = pfind(probe-ftp_pid)) == NULL) {
- mutex_exit(provider-ftp_mtx);
- return;
+
+#if defined(sun)
+ if ((p = sprlock(probe-ftp_pid)) != NULL) {
+ ASSERT(!(p-p_flag SVFORK));
+ mutex_exit(p-p_lock);
+ }
+#else
+ if ((p = pfind(probe-ftp_pid)) != NULL) {
+ _PHOLD(p);
+ PROC_UNLOCK(p);
}
-#ifdef __FreeBSD__
- _PHOLD(p);
- PROC_UNLOCK(p);
#endif
+ mutex_enter(provider-ftp_mtx);
+
+
/*
* Disable all the associated tracepoints (for fully enabled probes).
*/
@@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (provider-ftp_retired !provider-ftp_marked)
whack = provider-ftp_marked = 1;
mutex_exit(provider-ftp_mtx);
+
+#if defined(sun)
+ mutex_enter(p-p_lock);
+ sprunlock(p);
+#else
+ PRELE(p);
+#endif
} else {
/*
* If the process is dead, we're just waiting for the
@@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (whack)
fasttrap_pid_cleanup();
-#ifdef __FreeBSD__
- PRELE(p);
-#endif
if (!probe-ftp_enabled)
return;
--
Sorry for the following...
The information contained in this message is confidential and intended for
the addressee only. If you have
Re: Intel 82574 issue reported on Slashdot
On Sat, Feb 9, 2013 at 4:25 PM, CeDeROM cede...@tlen.pl wrote: On Sat, Feb 9, 2013 at 3:44 PM, Christoph Moench-Tegeder c...@burggraben.net wrote: ## O. Hartmann (ohart...@zedat.fu-berlin.de): We don't even have the tool tcpreplay in the ports mentioned in that BLOG. It's in net-mgmt/tcpreplay. And I managed to build mentioned Ostinato packet crafting utility with no problem on my FreeBSD 9.1-RELEASE AMD64. If they provide package and release (which I already asked from the authors) I will make a port for this tool as well :-) There it goes http://www.freebsd.org/cgi/query-pr.cgi?pr=175993 have fun! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[dcha...@freebsd.org: some usb troubles]
Hi all, trying to run HEAD on macbookpro10,1: 1) usb3.0 does not work at 9.1 and HEAD (r246587) 2) between stable/9 and HEAD (r246587) we are lost uhid devices (external keyboard and mouse) and umass. dmesg on the same hw can be find here: http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.stable9.txt http://people.freebsd.org/~dchagin/macbookpro/dmesg.generic.HEAD.txt pciconf: http://people.freebsd.org/~dchagin/macbookpro/pciconf.txt any help would be greatly apprecated. -- Have fun! chd pgpTaQ__nKjSt.pgp Description: PGP signature
Re: [patch] Userland DTrace
On 2/8/13 8:04 PM, Matt Burke wrote:
I've been spending some time trying to get the fasttrap provider to work
on FreeBSD without panicing. I believe I have succeeded, at least to the
point where it's no longer panicing.
There were two panic causes. The first was
http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of
fasttrap.c caused ftp_rcount to be left 0. To fix this I've got rid of
the early return and reverted to the opensolaris way.
A second panic then showed up intermittently when fasttrap_pid_cleanup_cb
was run while something in userland had locks. Using sx_try_xlock calls
has stopped the panics and shouldn't affect operation AFAICT.
This is against r246454.
Although this has fixed the panics for me, I'm finding a lot of stuff just
isn't actually working, with dtrace and the traced process just chewing
CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I
have no idea what the target is doing... CPU time is split 2:1
dtrace:target
Great! This fixes panics for me too, but I still cannot get something
useful tracing and after detaching by ctrl+c my programs still segfaults.
Please look at one style comment below.
Also noteworthy is the LOR on the first time you try to use the fasttrap
provider: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165479
The lock order there seems right, so I'm guessing something else must
have done it wrong first? How can I find out what the something else
is?
Thanks
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/dtrace.c
@@ -7536,9 +7536,23 @@ dtrace_unregister(dtrace_provider_id_t id)
return (EBUSY);
}
} else {
+#if defined(sun)
mutex_enter(dtrace_provider_lock);
mutex_enter(mod_lock);
mutex_enter(dtrace_lock);
+#else
+ if (sx_try_xlock(dtrace_provider_lock) == 0)
s/sx_try_xlock/mutex_tryenter/
Look at sys/cddl/compat/opensolaris/sys/mutex.h
+ return (EBUSY);
+ if (sx_try_xlock(mod_lock) == 0) {
+ mutex_exit(dtrace_provider_lock);
+ return (EBUSY);
+ }
+ if (sx_try_xlock(dtrace_lock) == 0) {
+ mutex_exit(mod_lock);
+ mutex_exit(dtrace_provider_lock);
+ return (EBUSY);
+ }
+#endif
}
/*
--- a/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
+++ b/sys/cddl/contrib/opensolaris/uts/common/dtrace/fasttrap.c
@@ -1116,23 +1116,28 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
ASSERT(id == probe-ftp_id);
- mutex_enter(provider-ftp_mtx);
-
/*
* We won't be able to acquire a /proc-esque lock on the process
* iff the process is dead and gone. In this case, we rely on the
* provider lock as a point of mutual exclusion to prevent other
* DTrace consumers from disabling this probe.
*/
- if ((p = pfind(probe-ftp_pid)) == NULL) {
- mutex_exit(provider-ftp_mtx);
- return;
+
+#if defined(sun)
+ if ((p = sprlock(probe-ftp_pid)) != NULL) {
+ ASSERT(!(p-p_flag SVFORK));
+ mutex_exit(p-p_lock);
+ }
+#else
+ if ((p = pfind(probe-ftp_pid)) != NULL) {
+ _PHOLD(p);
+ PROC_UNLOCK(p);
}
-#ifdef __FreeBSD__
- _PHOLD(p);
- PROC_UNLOCK(p);
#endif
+ mutex_enter(provider-ftp_mtx);
+
+
/*
* Disable all the associated tracepoints (for fully enabled probes).
*/
@@ -1154,6 +1159,13 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (provider-ftp_retired !provider-ftp_marked)
whack = provider-ftp_marked = 1;
mutex_exit(provider-ftp_mtx);
+
+#if defined(sun)
+ mutex_enter(p-p_lock);
+ sprunlock(p);
+#else
+ PRELE(p);
+#endif
} else {
/*
* If the process is dead, we're just waiting for the
@@ -1167,9 +1179,6 @@ fasttrap_pid_disable(void *arg, dtrace_id_t id, void
*parg)
if (whack)
fasttrap_pid_cleanup();
-#ifdef __FreeBSD__
- PRELE(p);
-#endif
if (!probe-ftp_enabled)
return;
--
Andrey Zonov
signature.asc
Description: OpenPGP digital signature
Re: [patch] Userland DTrace
On 2/10/13 1:47 AM, Mark Johnston wrote: On Fri, Feb 08, 2013 at 04:04:38PM +, Matt Burke wrote: I've been spending some time trying to get the fasttrap provider to work on FreeBSD without panicing. I believe I have succeeded, at least to the point where it's no longer panicing. There were two panic causes. The first was http://www.freebsd.org/cgi/query-pr.cgi?pr=165541 - the FreeBSD port of fasttrap.c caused ftp_rcount to be left 0. To fix this I've got rid of the early return and reverted to the opensolaris way. A second panic then showed up intermittently when fasttrap_pid_cleanup_cb was run while something in userland had locks. Using sx_try_xlock calls has stopped the panics and shouldn't affect operation AFAICT. I've run into this too. It can happen even when I'm not using DTrace since fasttrap.ko is always loaded on my system. The problem is that fasttrap_exec_exit() is called every time a process exits in this case; the caller acquires dtrace_lock, and the panic occurs when a callout thread tries to acquire the lock at the same time. This is against r246454. Although this has fixed the panics for me, I'm finding a lot of stuff just isn't actually working, with dtrace and the traced process just chewing CPU. Truss on the dtrace shows a heck of a lot of ptrace() calls and I have no idea what the target is doing... CPU time is split 2:1 dtrace:target Another panic can occur with an INVARIANTS kernel if a DTrace victim process forks. I've supplied a patch which fixes this for me here: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/171360 I think you have to carefully ping George, and if he won't answer go ahead with your patches. Someone has to take care of userland dtrace. -- Andrey Zonov signature.asc Description: OpenPGP digital signature
Re: HEAD memsticks broken? [USB/CAM Problems?]
On 09-02-2013 20:28, Alexander Motin wrote: How long ago that HEAD was built? Could you get full dmesg? I don't think that PREVENT ALLOW MEDIUM REMOVAL should cause device drop. No sense data present also doesn't look right. As I mentioned earlier, I've tried several HEAD snapshots. This is booting a r246472 memstick. I currently have no way to get a full dmesg, but I have hand-typed the last parts below: usbus0: 480Mbps High Speed USB v2.0 usbus1: 5.0Gbps Super Speed USB v3.0 usbus2: 480Mbps High Speed USB v2.0 ugen0.1: Intel at usbus0 uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 ugen1.1: 0x1033 at usbus1 uhub1: 0x1033 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1 on usbus1 ugen2.1: Intel at usbus2 uhub2: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus2 ses0 at ahciem0 bus 0 scbus3 target 0 lun 0 ses0: AHCI SGPIO Enclosure 1.00 0001 SEMB S-E-S 2.00 device ses0: SEMB SES Device ada0 at ahcich0 bus 0 scbus0 target 0 lun 0 ada0: Intel SSDSA2BW160G3L 4PC1LE05 ATA-8 SATA 2.x device ada0: 300.000MB/s transfers (SATA 2.x, UDMA6, PIO 8192bytes) ada0: Command Queueing enabled ada0: 152627MB (312581808 512 byte sectors: 1H 63S/T 16383C) ada0: Previously was known as ad4 SMP: AP CPU #1 Launched! SMP: AP CPU #3 Launched! SMP: AP CPU #2 Launched! Timecounter TSC-low frequency 1395499430 Hz quality 1000 WARNING: WITNESS option enabled, expect reduced performance. uhub1: 4 ports with 4 removable, self powered Root mount waiting for: usbus2 usbus0 uhub0: 3 ports with 3 removable, self powered uhub2: 3 ports with 3 removable, self powered ugen0.2: vendor 0x8087 at usbus0 uhub3: vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2 on usbus0 ugen2.2: vendor 0x8087 at usbus2 uhub4: vendor 0x8087 product 0x0024, class 9/0, rev 2.00/0.00, addr 2 on usbus2 Root mount wating for: usbus2 usbus0 ugen0.4: Broadcom Corp at usbus0 ugen0.5: Chicony Electronics Cp,. Ltd. at usbus0 ugen2.3: Kingston at usbus2 umass0: Kingston DataTraveler G3, class 0/0, rev 2.00/1.00, addr 3 on usbus2 umass0: SCSI over BUlk-Only; quirks = 0x0100 umass0:5:0:-1: Attached to scbus5 da0 at umass-sim0 bus 0 scbus5 target 0 lun 0 da0: Kingston DataTraveler G3 1.00 Removable Direct Access SCSI-0 device da0: 40.000MB/s transfers da0: 3690MB (7557704 512 byte sectors: 255H 63S/T 470C) (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): PREVENT ALLOW MEDIUM REMOVAL. CDB: 1e 00 00 00 01 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): SYNCHRONIZE CACHE(10). CDB: 35 00 00 00 00 00 00 00 00 00 (da0:umass-sim0:0:0:0): CAM status: Auto-Sense Retrieval Failed (da0:umass-sim0:0:0:0): Error 5, Unretryable error (da0:umass-sim0:0:0:0): got CAM status 0x50 (da0:umass-sim0:0:0:0): fatal error, failed to attach to device (da0:umass-sim0:0:0:0): lost device - 0 outstanding, 4 refs (da0:umass-sim0:0:0:0): removing device entry Root mount waiting for: usbus2 ugen2.4: Lenovo at usbus2 Trying to mount root from ufs:/dev/ufs/FreeBSD_Install [ro, noatime]... mountroot: waiting for device /dev/ufs/FreeBSD_Install ... Mounting from ufs:/dev/ufs/FreeBSD_Install failed with error 19. mountroot I can probably take a couple of pictures of the entire dmesg, if that would be of any interest. -- Joel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geli(8) breaks after a couple hours of uptime
On Sat, Feb 09, 2013 at 06:00:53PM +0200, Andriy Gapon wrote: on 09/02/2013 17:04 Andrey Zonov said the following: On 2/9/13 5:07 PM, Fabian Keil wrote: This would at least prevent the segfault. I see two possibilities to get segfault: - no checking for result from memory allocation functions - too big stack I have no found any broken memory allocation checking, but I found two big objects on the stack. One is buf[MAXPHYS] in eli_genkey_files() and another is passbuf[MAXPHYS] in eli_genkey_passphrase(). If we change these two to malloc(), then we can handle error from malloc(), print some useful message and prevent segfault. I'd rather do what Kostik suggested and Fabian mentioned: instead of mlockall(MCL_FUTURE) the code should mlock only the (explicitly designated) buffers that can contain sensitive data. geli(8) almost exclusively deals with sensitive data. Even mlocking MAXPHYS would fail with current limits, but this is bad idea. With mlockall() I am sure I didn't miss anything - be it forgetting about mlocking some buffer or zeroing it before munlock. I'm also sure someone else who can modify geli(8) in the future won't miss anything too. geli(8) is relatively simple program, it doesn't allocate megabytes of memory for different pruposes and just needs few pages for sensitive data. As I said most of the memory it uses is for sensitive data. The obvious problem is allocating MAXPHYS on the stack. This has to be changed, especially that we may want to rise MAXPHYS in the future. Other than that I expect thing would be tuned properly so that geli(8) can work by default. I'm happy to use smaller buffers than MAXPHYS - keyfiles are far smaller usually than 128kB, so there shouldn't be any issue with this. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://tupytaj.pl pgpjcefoSL7Mf.pgp Description: PGP signature
7+ days of dogfood
In a long thread started by Peter Wemm on developers@, he described the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10. A part of his description included the need to test top-of-tree under actual real-world conditions. In his words, FreeBSD should eat its own dogfood. The new installation on FreeBSD.org, of course, would test FreeBSD-10 under (heavy) server load. So, I decided to test FreeBSD-10 under a user desktop condition. In so doing, I upgraded the circa August 2012 FreeBSD-current that ran on my Dell Latitude D530 (which ran rock-solid) to top-of-tree. This included re-installing all ports under the pkgng paradigm. I can only describe this experience as slowly shoving an icepick into my ear channel. Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait state and never becomes responsive. Libreoffice displays its splash screen and immediately segfaults. Xorg does not start because it cannot load the xf86-video-driver (unless it is explicitly recompiled with /usr/bin/gcc). Once I got Xorg working, there were a few silent reboots (ie., nothing in /var/log/message, no core file, etc). I spent a few days trying to hunt down the issues. I rebult libc, libthr, libc++, and libcxxrt with debugging symbols and and firefox and chrome under gdb751. Nothing too informative to learn: gdb751 /usr/local/share/chromium/chrome ... (try going to seattle-times.com and get stuck) ... (gdb) bt #0 0x4d0323ab in _umtx_op_err () from /lib/libthr.so.3 #1 0x4d0274da in _thr_umtx_timedwait_uint () from /lib/libthr.so.3 #2 0x4d02d76f in _thr_sleep () from /lib/libthr.so.3 #3 0x4d0304b0 in ?? () from /lib/libthr.so.3 #4 0x4d030705 in pthread_cond_timedwait () from /lib/libthr.so.3 #5 0x086e7578 in ?? () #6 0x086f8d1b in ?? () #7 0x086f91c9 in ?? () #8 0x086f0c06 in ?? () #9 0x4d0255e6 in ?? () from /lib/libthr.so.3 #10 0x in ?? () gdb751 /usr/local/bin/firefox (gdb) run Starting program: /usr/local/bin/firefox [New LWP 100227] [New Thread 48501080 (LWP 100227)] [New Thread 4ec11500 (LWP 100245 StreamTrans #3)] Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 48501080 (LWP 100227)] 0x48c03295 in ?? () from /usr/local/lib/firefox/libxul.so (gdb) bt #0 0x48c03295 in ?? () from /usr/local/lib/firefox/libxul.so #1 0x48aaf4b0 in ?? () from /usr/local/lib/firefox/libxul.so Backtrace stopped: previous frame inner to this frame (corrupt stack?) Unfortunately, trying to build firefox with debugging leads reveals a broken port and building chrome with debugging leads to a file system full issue (because it is a laptop with only limited disk space). Given that I need the laptop for work next week, I decide to rebuild everything again. Only this time I used the following /etc/make.conf: KERNCONF=MOBILE CPUTYPE?=core2 #DISABLE_MAKE_JOBS=YES WITHOUT_CLANG=YES WITH_GCC=YES WITHOUT_PROFILE=yes FFLAGS = -O2 -pipe -march=native -mtune=native FFLAGS+= -funroll-loops -ftree-vectorize # added by use.perl 2013-02-07 20:58:29 PERL_VERSION=5.14.2 I now have an almost functioning desktop environment on my laptop. firefox, xorg, and chrome all work. Sound has developed a pronounced studder, that did not occur with the Aug 2012 freebsd-10. Libreoffice currently does not build, but that's not totally unexpected as compiling libreoffice seems to be a hit-or-miss proposition. My conclusion: on at least my not-so-new laptop, FreeBSD-10 can be used in a desktop environment if one takes some care during the installation. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
building custom kernel on -current: unknown option COMPAT_LINUX
This is on amd64 r246552 I added options COMPAT_43 options COMPAT_LINUX options COMPAT_LINUX32 to the kernel config, following sys/amd64/conf/NOTES On buildkernel I get: unknown option COMPAT_LINUX What am I missing? Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
Date: Sat, 9 Feb 2013 16:07:23 -0800 From: Steve Kargl s...@troutmask.apl.washington.edu To: freebsd-current@freebsd.org Subject: 7+ days of dogfood In a long thread started by Peter Wemm on developers@, he described the move/upgrade of the FreeBSD.org cluster to using FreeBSD-10. A part of his description included the need to test top-of-tree under actual real-world conditions. In his words, FreeBSD should eat its own dogfood. The new installation on FreeBSD.org, of course, would test FreeBSD-10 under (heavy) server load. So, I decided to test FreeBSD-10 under a user desktop condition. In so doing, I upgraded the circa August 2012 FreeBSD-current that ran on my Dell Latitude D530 (which ran rock-solid) to top-of-tree. This included re-installing all ports under the pkgng paradigm. I can only describe this experience as slowly shoving an icepick into my ear channel. *skip the details* My experience is more positive. I've r246552 on a Lenovo T61p amd64 laptop. X works fine with Nvidia card with nvidia-driver-304.64: x11/nvidia-driver and with hald and dbus. firefox-18.0.2,1: www/firefox works fine (so far). I haven't added flash yet. sound seems fine, at least in alienblaster-1.1.0_5: games/alienblaster wireless works ok (I'm not sure, but it seems to show some problems under load. I need to investigate this further) with device iwn # Intel 4965/1000/5000/6000 wireless NICs. device iwn4965fw All this with # cat /etc/make.conf SENDMAIL_CFLAGS+= -I/usr/local/include -DSASL=2 SENDMAIL_LDFLAGS+= -L/usr/local/lib SENDMAIL_LDADD+=-lsasl2 WITH_PKGNG=yes PERL_VERSION=5.16.2 # Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
On Sat, Feb 09, 2013 at 04:07:23PM -0800, Steve Kargl wrote:
Libreoffice currently does not build, but that's not totally
unexpected as compiling libreoffice seems to be a hit-or-miss
proposition.
laptop:root[201] cd
/usr/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2/l10ntools/
laptop:root[202] gmake
[ build LNK ] Executable/HelpIndexer
S=/usr/ports/editors/libreoffice/work/libreoffice-core-3.6.5.2
O=/tmp/lobuild/solver/unxfbsdi.pro W=/tmp/lobuild/workdir/unxfbsdi.pro
mkdir -p $W/LinkTarget/Executable/ g++46
'-Wl,-z,origin,-rpath,$ORIGIN/../lib:$ORIGIN' -Wl,-rpath-link,$O/lib
-Wl,-rpath-link,/lib:/usr/lib -Wl,-z,combreloc -L$S/solenv/unxfbsdi/lib
-L$O/lib -L$S/solenv/unxfbsdi/lib -L/usr/local/lib -Wl,--hash-style=gnu
-Wl,--dynamic-list-cpp-new -Wl,--dynamic-list-cpp-typeinfo
-Wl,-Bsymbolic-functions
$W/CxxObject/l10ntools/source/help/HelpIndexer_main.o -Wl,--start-group
-Wl,--end-group -Wl,--no-as-needed -lexpat -lxslt -lz -liconv -lm
-L/usr/local/lib -lxml2 -L/usr/local/lib -lxml2 -L/usr/local/lib/db42
-ldb-4.2 -L/usr/local/lib/ -lclucene-core -lclucene-contribs-lib -luno_sal
-lhelplinkerlo -o $W/LinkTarget/Executable/HelpIndexer
/usr/local/lib/libclucene-core.so: undefined reference to `logl@GLIBCXX_3.4'
collect2: ld returned 1 exit status
Huh? logl@GLIBCXX_3.4
laptop:kargl[189] cat a.c
#include stdio.h
#include math.h
int
main(void)
{
long double x;
x = (long double) M_PI;
printf(%Le %Le\n, x, logl(x));
return (0);
}
laptop:kargl[190] cc -o z a.c -lm ./z
3.141593e+00 1.144730e+00
laptop:kargl[191] nm --dynamic z
w _Jv_RegisterClasses
08049804 D __progname
08049818 A _end
U _init_tls
U atexit
08049814 B environ
U exit
U logl
U printf
laptop:kargl[193] nm --dynamic /usr/lib/libm.so | grep logl
58f0 T logl
--
Steve
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building custom kernel on -current: unknown option COMPAT_LINUX
From free...@edvax.de Sun Feb 10 00:29:36 2013 On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: This is on amd64 r246552 I added options COMPAT_43 options COMPAT_LINUX options COMPAT_LINUX32 to the kernel config, following sys/amd64/conf/NOTES On buildkernel I get: unknown option COMPAT_LINUX What am I missing? Do you also have those (from a working i386 system): # Linux support options COMPAT_LINUX# Enable Linux ABI emulation options LINPROCFS # Enable the linux-like proc filesystemsupport (requires COMPAT_LINUX and PSEUDOFS) options LINSYSFS# Enable the linux-like sys filesystem support (requires COMPAT_LINUX and PSEUDOFS) device lindev options COMPAT_AOUT # Enable i386 a.out binary support (note PSEUDOFS is also needed) No, I haven't added those. Are these necessary to have the linux binary compatibility? The handbook only mentions COMPAT_LINUX. Thanks Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building custom kernel on -current: unknown option COMPAT_LINUX
From free...@edvax.de Sun Feb 10 00:42:11 2013 On Sun, 10 Feb 2013 00:31:44 GMT, Anton Shterenlikht wrote: From free...@edvax.de Sun Feb 10 00:29:36 2013 On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: This is on amd64 r246552 I added options COMPAT_43 options COMPAT_LINUX options COMPAT_LINUX32 to the kernel config, following sys/amd64/conf/NOTES On buildkernel I get: unknown option COMPAT_LINUX What am I missing? Do you also have those (from a working i386 system): # Linux support options COMPAT_LINUX# Enable Linux ABI emulation options LINPROCFS # Enable the linux-like proc filesystemsupport (requires COMPAT_LINUX and PSEUDOFS) options LINSYSFS# Enable the linux-like sys filesystem support (requires COMPAT_LINUX and PSEUDOFS) device lindev options COMPAT_AOUT # Enable i386 a.out binary support (note PSEUDOFS is also needed) No, I haven't added those. Are these necessary to have the linux binary compatibility? The handbook only mentions COMPAT_LINUX. I think I had the same question some time ago and found out that if those options are present, the Linux functionality will build properly in the kernel. So I assume they are required. I removed COMPAT_LINUX, and only left options COMPAT_43 options COMPAT_LINUX32 This seems enough to get flash working with firefox, exactly as per the handbook instructions. Anton ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
Hi, On Sat, 9 Feb 2013 16:07:23 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote: actual real-world conditions. In his words, FreeBSD should eat its own dogfood. The new installation on FreeBSD.org, of course, would I am on dog food since last May/June. How should I phrase it? Every can tastes different. Most cans have a perfect taste but some cans are really off. So, when I see a bad can, I go back to my old can, wait a day and get me then a new can. This is then - most likely - good again. This is the real reason why it is not possible to run important machines on dog food. If one can is bad, the machine is down. As FreeBSD.org sits next to the canning machine, it can run on dog food. Erich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building custom kernel on -current: unknown option COMPAT_LINUX
On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: This is on amd64 r246552 I added options COMPAT_43 options COMPAT_LINUX options COMPAT_LINUX32 to the kernel config, following sys/amd64/conf/NOTES On buildkernel I get: unknown option COMPAT_LINUX What am I missing? Do you also have those (from a working i386 system): # Linux support options COMPAT_LINUX# Enable Linux ABI emulation options LINPROCFS # Enable the linux-like proc filesystemsupport (requires COMPAT_LINUX and PSEUDOFS) options LINSYSFS# Enable the linux-like sys filesystem support (requires COMPAT_LINUX and PSEUDOFS) device lindev options COMPAT_AOUT # Enable i386 a.out binary support (note PSEUDOFS is also needed) -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building custom kernel on -current: unknown option COMPAT_LINUX
On Sun, 10 Feb 2013 00:31:44 GMT, Anton Shterenlikht wrote: From free...@edvax.de Sun Feb 10 00:29:36 2013 On Sun, 10 Feb 2013 00:18:06 GMT, Anton Shterenlikht wrote: This is on amd64 r246552 I added options COMPAT_43 options COMPAT_LINUX options COMPAT_LINUX32 to the kernel config, following sys/amd64/conf/NOTES On buildkernel I get: unknown option COMPAT_LINUX What am I missing? Do you also have those (from a working i386 system): # Linux support options COMPAT_LINUX# Enable Linux ABI emulation options LINPROCFS # Enable the linux-like proc filesystemsupport (requires COMPAT_LINUX and PSEUDOFS) options LINSYSFS# Enable the linux-like sys filesystem support (requires COMPAT_LINUX and PSEUDOFS) device lindev options COMPAT_AOUT # Enable i386 a.out binary support (note PSEUDOFS is also needed) No, I haven't added those. Are these necessary to have the linux binary compatibility? The handbook only mentions COMPAT_LINUX. I think I had the same question some time ago and found out that if those options are present, the Linux functionality will build properly in the kernel. So I assume they are required. -- Polytropon Magdeburg, Germany Happy FreeBSD user since 4.0 Andra moi ennepe, Mousa, ... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building custom kernel on -current: unknown option COMPAT_LINUX
On 9 February 2013 20:26, Anton Shterenlikht me...@bristol.ac.uk wrote: I removed COMPAT_LINUX, and only left options COMPAT_43 options COMPAT_LINUX32 From /usr/src/sys/amd64/conf/NOTES (9.1-RELEASE): # Enable Linux ABI emulation #XXX#optionsCOMPAT_LINUX # Enable 32-bit Linux ABI emulation (requires COMPAT_43 and COMPAT_FREEBSD32) options COMPAT_LINUX32 I think I first ran up against this when I moved to 9.0 some time ago, but yes, amd64 uses a different kernel config option than i386 for linux compat. I tend to leave it as a module load it if I perchance need it. This also allows rebuilding reloading the modules without a reboot, should it need it. The modules seems to build fine without having to fiddle about with kernel config jiggerypokey. -- -- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
Steve Kargl wrote: Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait state and never becomes responsive. Libreoffice displays its splash screen and immediately segfaults. Xorg does not start because it cannot load the xf86-video-driver (unless it is explicitly recompiled with /usr/bin/gcc). Once I got Xorg working, there were a few silent reboots (ie., nothing in /var/log/message, no core file, etc). snip KERNCONF=MOBILE CPUTYPE?=core2 #DISABLE_MAKE_JOBS=YES WITHOUT_CLANG=YES WITH_GCC=YES Shouldn't this be WITHOUT_CLANG_IS_CC=yes? I must say that my experience of -CURRENT dogfood has been entirely different. I can't remember the last time I didn't run -CURRENT as my desktop. I also have run -CURRENT in production for the last several years although it's a ruating load, not a compute load. Others might not agree with what I'm about to say. 1. WITHOUT_CLANG_IS_CC=yes I don't think clang is ready for prime time in FreeBSD, or FreeBSD isn't ready to use clang in prime time. I got a new laptop (ASUS UX31A) and found that a lot of the ports I needed to install didn't compile or core dumped. (Sorry I didn't report these to the project). This option sorted that problem out. However you will need to rebuild everything including world and kernel with gcc before you start building ports with gcc or you will still have problems. 2. MALLOC_PRODUCTION=yes Maybe it's the placebo effect. Binaries are smaller in memory and things seem faster 3. xorg, firefox18, WITH_NEW_XORG=yes, WITH_KMS=yes I've found that HAL is a waste of time with X. It's hit and miss when it comes to reporting hardware to X, better to just not use it. Xorg has always worked well for me. My new laptop required that I use the new xorg port to get anything resembling decent performance. Getting KMS to work was a bit unsettling and X only seems to work when it's launched by hand from a real terminal. xdm won't start from /etc/ttys with NEW_XORG, but I can live with that. I've just upgraded firefox-18.0 to firefox-18.0.2 without a hitch. I have flash working without a hitch. Even the acroread plugin works for viewing PDFs in browser. 4. Sound. I've had less success with this, but I think my problems would be the same on 8 and 9. It seems common for HDA these days to put the useful sound bits on different devices: pcm0: Realtek ALC269 (Internal Analog) (play/rec) default pcm1: Realtek ALC269 (Left Analog Headphones) (play) pcm2: Intel Panther Point (HDMI/DP 8ch) (play) So my headphone jack doesn't work. On my other laptor, the builtin mic doesn't work because it's on pcm1 and there's not a way to make pcm1 the default input device and pcm0 the default output device. I need to spend some time with a verbose boot and see if I can figure out the audio routing. Ian -- Ian Freislich ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
On Feb 9, 2013, at 10:33 PM, Ian FREISLICH wrote: 2. MALLOC_PRODUCTION=yes Maybe it's the placebo effect. Binaries are smaller in memory and things seem faster There have been significant improvements in this area very recently. Please give it another try without this setting and let us know. Tim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 7+ days of dogfood
On Sun, Feb 10, 2013 at 08:33:25AM +0200, Ian FREISLICH wrote: Steve Kargl wrote: Firefox segfaults after ~10 seconds. Chrome gets stuck in a uwait state and never becomes responsive. Libreoffice displays its splash screen and immediately segfaults. Xorg does not start because it cannot load the xf86-video-driver (unless it is explicitly recompiled with /usr/bin/gcc). Once I got Xorg working, there were a few silent reboots (ie., nothing in /var/log/message, no core file, etc). snip KERNCONF=MOBILE CPUTYPE?=core2 #DISABLE_MAKE_JOBS=YES WITHOUT_CLANG=YES WITH_GCC=YES Shouldn't this be WITHOUT_CLANG_IS_CC=yes? I haven't looked at the difference, but I would assume that WITHOUT_CLANG doesn't waste time building clang while WITHOUT_CLANG_IS_CC builds clang but doesn't install it as cc. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: geli(8) breaks after a couple hours of uptime
on 10/02/2013 01:35 Pawel Jakub Dawidek said the following: geli(8) almost exclusively deals with sensitive data. Even mlocking MAXPHYS would fail with current limits, but this is bad idea. With mlockall() I am sure I didn't miss anything - be it forgetting about mlocking some buffer or zeroing it before munlock. I'm also sure someone else who can modify geli(8) in the future won't miss anything too. Well, the geli is not such a complex program really. It seems to use only two or so buffers for sensitive data. As far as I can see geli deals only with some key management (reading keys, generating key from key material, etc). There is definitely no need to mlock the code, etc. geli(8) is relatively simple program, it doesn't allocate megabytes of memory for different pruposes and just needs few pages for sensitive data. As I said most of the memory it uses is for sensitive data. Right, except for code (from geli and from shared libraries) and other stuff that is really not sensitive at all. The obvious problem is allocating MAXPHYS on the stack. This has to be changed, especially that we may want to rise MAXPHYS in the future. Yes, I do not see any relation between what geli does and MAXPHYS. Other than that I expect thing would be tuned properly so that geli(8) can work by default. I'm happy to use smaller buffers than MAXPHYS - keyfiles are far smaller usually than 128kB, so there shouldn't be any issue with this. I think that PAGE_SIZE (or at most a small multiple of it) should be sufficient. I don't think that we currently have (or expect to see in the near future) algorithms where keys with more than 4096 size provide any additional security. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
