mfi(4) command timeout loop on boot on releng/8.2
Hello, I just filed PR kern/155499 regarding an mfi(4) command timeout loop when I try to boot an 8.2-RELEASE kernel. This system does not have any problems with 8.1-RELEASE. With MFI_DEBUG I get the following output: mfi0: COMMAND 0xff80002c6440 TIMEOUT AFTER 59 SECONDS mfi0: cm=0xff80002c6440 index=8 total_frame_size=52 extra_frames=0 mfi0: flags=83MAPPED,DATAIN,Q_BUSY mfi0: cmd=MFI_CMD_DCMD opcode=LD_GET_LIST data_len=1032 mfi0: flags=12SGL64,READ SG List: 0x1a3d000:001032 mfi0: mfi_timeout 2522 COMMAND 0xff80002c6440 S/G count bad 0 1032 1032 0x1a3d000 mfi0: cm=0xff80002c6440 index=8 total_frame_size=52 extra_frames=0 mfi0: flags=83MAPPED,DATAIN,Q_BUSY mfi0: cmd=MFI_CMD_DCMD opcode=LD_GET_LIST data_len=1032 mfi0: flags=12SGL64,READ SG List: 0x1a3d000:001032 This output repeats itself every 30 seconds (with the timeout counter increasing). The card is an LSI MegaRAID SAS 8408E: blee@genesis ~ $ pciconf -lv | grep -A4 mfi0 mfi0@pci0:6:14:0: class=0x010400 card=0x10011000 chip=0x04111000 rev=0x00 hdr=0x00 vendor = 'LSI Logic (Was: Symbios Logic, NCR)' device = 'MegaRAID Family RAID Controller' class = mass storage subclass = RAID blee@genesis ~ $ sudo mfiutil show adapter mfi0 Adapter: Product Name: MegaRAID SAS 8408E Serial Number: P186584707 Firmware: 7.0.1-0081 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 256M Minimum Stripe: 8K Maximum Stripe: 1M Upgrading to the latest firmware had no effect: blee@genesis ~ $ sudo mfiutil show firmware mfi0 Firmware Package Version: 7.0.1-0081 mfi0 Firmware Images: Name Version Date Time Status BTBL R.2.3.15 May 20 2008 16:09:27 active BIOS MT33 active MPT1 MPTFW-01.18.172.00-IT 01/31/11 16:49:08 active APP 1.12.310-1112 Dec 17 2010 14:54:35 active BCON 1.1-33j-e_11-Rel Aug 20 2009 21:16:24 active CTLR 1.04-019A Aug 13 2007 23:21:34 active MPT3 MPTFW-01.18.172.00-IT 01/31/11 16:49:29 active PCLI 01.00-011:#%1 Oct 10 2007 16:30:36 active Any suggestions? -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: Dumpdev issue in 6.4-STABLE
On 08/06/2010 02:24 PM, Mark Saad wrote: I then set in /boot/loader.conf dumpdev=/dev/da0s1b On 8-STABLE dumpdev should be defined in rc.conf(5). Not sure about 6-STABLE offhand. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On 07/17/2010 03:37 PM, Reko Turja wrote: Can you try reproducing the issue on 8-STABLE? I recently submitted a Heimdal patch against 8.1-STABLE and 9.0-CURRENT that resolves some libgssapi-related issues: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454 The patch breaks ABI, so you'll have to rebuild libgssapi-dependent applications. When linking cyrus-sasl2 against gssapi library from either the 1.0.1 official port or the inofficial 1.2.1 patchset cyradm works as expected and it logs a message from gssapi/kerberos telling that no KDC's are available - which is to be expected on a system that isn't using gssapi/kerberos in authenticating. So the present behaviour in 8-RELEASE and 8-PRERELASE updated Monday the 5th is clearly some kind of regression as system gsslib doesn't seem to recognize the mech used or segfaults. Benjamin, can you clarify how to apply your patch against the source tree - I tried 'patch the_patchset.diff' in /usr/src but it just created a bunch of files in the /usr/src which I think isn't the intention. Hi Reko, It looks like you've already figured it out (based on your responses elsewhere in the thread), but for the record you can apply the patch by running: cd /usr/src patch -p1 -E foo.diff That patch is over a month old now and no longer applies cleanly. I'll port it forward when I get a chance. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On 07/18/2010 06:52 AM, Reko Turja wrote: After manually changing the gssapi header used in /usr/src/include/rpc/rpcsec_gss.h to somewhat klunky #include /usr/src/crypto/heimdal/lib/gssapi/gssapi/gssapi.h system csupped yesterday built okay and after rebuilding cyrus-sasl, saslauthd and cyrus I get the following failures in log: Jul 18 16:37:35 moria perl: GSSAPI Error: Miscellaneous failure (see text)^B (open(/tmp/krb5cc_0): No such file or directory) -This is expected behaviour as Kerberos was not running at the moment, but with Benjamin's patch Kerberos/GSSAPI spat out a meaningful error message After dusting off my old Kerberos setup, doing basic kinit and running cyradm localhost I got: Jul 18 16:39:00 moria perl: GSSAPI Error: Miscellaneous failure (see text) (Server (imap/localh...@xxx.domain.com) unknown) -Again expected as there is no imap trust relationship defined. So at least after cursory testing it looks like that with Benjamin's patch there is a working GSSAPI/Kerberos backend available, instead of something that chokes on passed parameters that are ok for every other tested gssapi implementation. Of course, more thorough testing in proper kerberised/LDAP environment needs to be done, which is something I haven't got time at the moment. Thanks for your testing! Based on the lack of attention my PR has received it seems that not many people have noticed the regression in libgssapi, even though the breaking commit happened in -CURRENT way back in 2008. When you get a chance, please append your test results to PR kern/147454. That may be helpful in attracting some more attention to this issue. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
Re: openldap client GSSAPI authentication segfaults in fbsd8stablei386
On 07/17/2010 07:41 AM, Jeremy Chadwick wrote: The problem really looks to be with GSSAPI, which is part of the base system (src/lib/libgssapi). If I can reproduce the problem on the test i386 system I'm building, which will have the same port + configuration as the test amd64 system, then I would say it's purely a GSSAPI thing regardless if you're using GSSAPI w/ SASL or GSSAPI w/ Kerberos. Can you try reproducing the issue on 8-STABLE? I recently submitted a Heimdal patch against 8.1-STABLE and 9.0-CURRENT that resolves some libgssapi-related issues: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/147454 The patch breaks ABI, so you'll have to rebuild libgssapi-dependent applications. -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
[patch] Unbreak libgssapi and upgrade for heimdal-1.1
Hello, The following patch unbreaks libgssapi and upgrades it to be consistent with the previous heimdal-1.1 merge: http://www.b1c1l1.com/media/patches/libgssapi-9.0-CURRENT.diff.bz2 http://www.b1c1l1.com/media/patches/libgssapi-8.1-STABLE.diff.bz2 Currently, libgssapi is out of date because it was not upgraded when the rest of heimdal was upgraded to heimdal-1.1. Also, 3 new libraries (libgssapi_krb5, libgssapi_ntlm, libgssapi_spnego) were unnecessarily introduced -- MIT Kerberos separates these libraries, but Heimdal does not. This broke some libgssapi-dependent applications (e.g. www/mod_auth_kerb2, PR #147282). SHLIB_MAJOR is bumped from 10 to 11, so libgssapi-dependent applications must be rebuilt after applying this patch. I renamed some of upstream's files due to filename collisions. If buildworld can create corresponding subdirectories in obj/ to match src/, then the renames are not necessary. Feedback is appreciated. Thanks, -- Benjamin Lee http://www.b1c1l1.com/ signature.asc Description: OpenPGP digital signature
