4k sector disks
Is there any special configuration needed to use 4k sector disks efficiently ? I have a couple of SATA drives with 4k sectors, the disklabels for them give a sector size of 512 bytes but 'atactl identify' shows the true sector size. I used 'newfs -S 4096' on one of them, a new SSD, but am wondering whether to copy stuff off the other one and repartition. Robert Swindells
Re: More amd64 drmkms radeon
The good news is that DRMKMS doesn't crash any more on boot on that machine; Xorg shows the cursor in the screen centre and a small white rectangle in the top left corner; the machine is reachable from outside, but the console is unresponsive from this moment on; if I try something further (like startx or [kg]dm), I get a hard reset. Chavdar On 23 August 2014 17:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 23:39, Chavdar Ivanov ci4...@gmail.com wrote: On 22 August 2014 22:35, Robert Swindells r...@fdy2.co.uk wrote: Chavdar Ivanov wrote: On 22 August 2014 16:56, Taylor R Campbell riastr...@netbsd.org wrote: Date: Fri, 22 Aug 2014 10:18:59 +0100 From: Chavdar Ivanov ci4...@gmail.com A DRMKMS kernel from 15th works as suggested above - switches to 1280x1024 and is fine after (Xorg panics earlier; with the latest build from yesterday it even wedged the machine completely). On the other hand yesterday's kernel panics as follows: [...] drm kern error: radeon_cp: Failed to load firmware radeon/R300_cp.bin Do you still have /usr/libdata/firmware/radeon/R300_cp.bin on the root file system? Yes, the kernel from 15th of August loads it fine: $ uname -a NetBSD uksup1.delcam.local 7.99.1 NetBSD 7.99.1 (DRMKMS) #1: Fri Aug 15 14:06:51 BST 2014 root@support6.delcam.local:/root/a64/compile/DRMKMS amd64 $ ls -l /usr/libdata/firmware/radeon/R300_cp.bin -r--r--r-- 1 root wheel 2048 Jul 6 2010 /usr/libdata/firmware/radeon/R300_cp.bin $ dmesg | grep Microcode drm: Loading R300 Microcode ... I tried a custom kernel with sources from yesterday on i386 with a R300 and it works fine. We really ought to have a better story if it's not, but that's my first guess about the problem. panic: kernel diagnostic assertion ttm-caching_state == tt_cached failed: file ../../../../external/bsd/drm2/dist/drm/ttm/ttm_tt.c, line 423 This is a bug in the rat's nest of error branches in the Radeon code, ugh... Well, it doesn't show up in the earlier version, so it looks a regression. The panic is triggered while cleaning up from the failure to load the microcode. One change between your working kernel and now was to enable wedges, they are disabled in my custom kernel. I have to say, this came to my mind as well. However, that machine has been using raidframe and wedges for ages: ~ df -k -t ffs Filesystem1K-blocks Used Avail %Cap Mounted on /dev/raid0a 105311462 31680686 68365204 31% / However, I have to notice that in the case of the working non-default-slice kernel, the root is not on a wedge, so there may be something about the order in which the wedges are recognized and the firmware loaded. Chavdar /dev/dk0 116306664 65608 110425728 0% /spare /dev/dk1 71674768 615579126533120 90% /data ~ raidctl -s raid0 Components: /dev/wd5a: optimal /dev/wd4a: optimal ... ~ raidctl -s raid1 Components: /dev/wd0a: optimal /dev/wd2a: optimal /dev/wd3a: optimal ... ~ gpt show raid0 start size index contents 0 234441472 ~ gpt show raid1 start size index contents 0 1 PMBR 1 1 Pri GPT header 2 32 Pri GPT table 34 144607293 1 GPT part - NetBSD FFSv1/FFSv2 144607327 32 Sec GPT table 144607359 1 Sec GPT header ~ dkctl raid1 listwedges /dev/rraid1d: 1 wedge: dk1: 5b5a0ae5-1568-11e3-8834-000fea5d15a1, 144607293 blocks at 34, type: ffs (from the working kernel from 15th). Robert Swindells Chavdar -- -- --
Re: 5 GHz band support for Intel WiFi chips?
Anders Magnusson ra...@ludd.ltu.se writes: my impression from various web sites is that the Intel WiFi device in my Lenovo T400s laptop has support for the 5 GHz band channels. However, it seems to never associate with any access points using such channels. It always ends up using some of the 2.4 GHz channels instead, or not being able to associate with any access point at all. Just FYI: There are versions of the T400 that do not have 5GHz. You need to check the exact chip ID. According to the NetBSD pcidevs file iwn0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4236 (rev. 0x00) translates to product INTEL WIFI_LINK_5300_2 0x4236 WiFi Link 5300 and the product brief[*] on Intel's web pages states that this is part of a series that supports the dual bands 2.4 GHz / 5 GHz. Is there an even more detailed chip ID I should look for? Also, ifconfig -m iwn0 lists a number of 'mode 11a' media types. I did also compile a kernel with IWN_DEBUG defined and set the iwn_debug variable to 2 and got the following output: iwn0 at pci2 dev 0 function 0: vendor 0x8086 product 0x4236 (rev. 0x00) iwn0: interrupting at ioapic0 pin 17 EEPROM found SKU capabilities=0x00f0 radio config=0x7708 adding chan 1 flags=0x6f maxpwr=15 adding chan 2 flags=0x6f maxpwr=15 adding chan 3 flags=0x6f maxpwr=15 adding chan 4 flags=0x6f maxpwr=15 adding chan 5 flags=0x6f maxpwr=15 adding chan 6 flags=0x6f maxpwr=15 adding chan 7 flags=0x6f maxpwr=15 adding chan 8 flags=0x6f maxpwr=15 adding chan 9 flags=0x6f maxpwr=15 adding chan 10 flags=0x6f maxpwr=15 adding chan 11 flags=0x6f maxpwr=15 adding chan 12 flags=0x61 maxpwr=15 adding chan 13 flags=0x61 maxpwr=15 adding chan 36 flags=0xe1 maxpwr=15 adding chan 40 flags=0xe1 maxpwr=15 adding chan 44 flags=0xe1 maxpwr=15 adding chan 48 flags=0xe1 maxpwr=15 adding chan 52 flags=0x31 maxpwr=15 adding chan 56 flags=0x31 maxpwr=15 adding chan 60 flags=0x31 maxpwr=15 adding chan 64 flags=0x31 maxpwr=15 adding chan 100 flags=0x31 maxpwr=15 adding chan 104 flags=0x31 maxpwr=15 adding chan 108 flags=0x31 maxpwr=15 adding chan 112 flags=0x31 maxpwr=15 adding chan 116 flags=0x31 maxpwr=15 adding chan 120 flags=0x31 maxpwr=15 adding chan 124 flags=0x31 maxpwr=15 adding chan 128 flags=0x31 maxpwr=15 adding chan 132 flags=0x31 maxpwr=15 adding chan 136 flags=0x31 maxpwr=15 adding chan 140 flags=0x31 maxpwr=15 adding chan 149 flags=0xa1 maxpwr=15 adding chan 153 flags=0xa1 maxpwr=15 adding chan 157 flags=0xa1 maxpwr=15 adding chan 161 flags=0xa1 maxpwr=15 adding chan 165 flags=0xa1 maxpwr=15 calib version=4 pa type=0 voltage=0 crystal calibration 0x00770077 iwn0: MIMO 3T3R, MoW, address xx:xx:xx:xx:xx:xx iwn0: 11a rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps iwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps iwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps I believe the channels from 36 and upwards are part of the 11a set, and should be found in the 5 GHz band. Now, it is of course entirely possible that this is just something that the chip itself supports, and that the device that the chip is part of is not wired to support these channels. How could I get to know that? Furthermore, if I do 'ifconfig iwn0 mode 11a up', and then run 'wlanctl -a | grep -B 1 freq' from time to time, I get: ess chan 44 freq 5220MHz flags 0340ofdm,5GHz,passive scan -- ess chan 1 freq 2412MHz flags 04e0cck,ofdm,2.4GHz,dynamic cck-ofdm -- ess chan 120 freq 5600MHz flags 0340ofdm,5GHz,passive scan -- ess chan 13 freq 2472MHz flags 06e0cck,ofdm,2.4GHz,passive scan,dynamic cck-ofdm -- ess chan 116 freq 5580MHz flags 0340ofdm,5GHz,passive scan -- ess chan 157 freq 5785MHz flags 0340ofdm,5GHz,passive scan -- ess chan 36 freq 5180MHz flags 0340ofdm,5GHz,passive scan -- ess chan 100 freq 5500MHz flags 0340ofdm,5GHz,passive scan -- ess chan 132 freq 5660MHz flags 0340ofdm,5GHz,passive scan -- ess chan 165 freq 5825MHz flags 0340ofdm,5GHz,passive scan -- ess chan 40 freq 5200MHz flags 0340ofdm,5GHz,passive scan -- ess chan 100 freq 5500MHz flags 0340ofdm,5GHz,passive scan -- ess chan 128 freq 5640MHz flags 0340ofdm,5GHz,passive scan -- ess chan 161 freq 5805MHz flags 0340ofdm,5GHz,passive scan -- ess chan 13 freq 2472MHz flags 06e0cck,ofdm,2.4GHz,passive scan,dynamic cck-ofdm so to me it seems that the driver is cycling through the 11a channel set trying (unsuccessfully) to find a network to which to associate. Any suggestions to what more I might try? Or can someone offer authoritative insights whether this can be made to work at all, with our current 802.11 framework and the iwn driver? -jarle
Re: cgdconfig: ioctl: Device busy
On Wed, Sep 03, 2014 at 07:57:07PM +0100, trebol wrote: I have this error or 'Inappropiate ioctl for device' (depends on the device I try to use) with any kernel since 'NetBSD 6.99.46'. I update the userland (and etc files) too, but the problem persists. Luckily I don't have any error using the old kernel with it. For the device-is-busy, look in your dmesg if a dk* device as provided on top of the cgd. You need to mount using that then. Thomas
NetBSD Security Advisory 2014-008: Multiple OpenSSL vulnerabilities (updated)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 NetBSD Security Advisory 2014-008 = Topic: Multiple OpenSSL vulnerabilities Version:NetBSD-current: prior to Aug 10th, 2014 NetBSD 6.1 - 6.1.4: affected NetBSD 6.0 - 6.0.5: affected NetBSD 5.1 - 5.1.4: partially affected NetBSD 5.2 - 5.2.2: partially affected Severity: MitM, Remote Code Execution, Remote DoS, Local Information Leak Fixed: NetBSD-current: Aug 10th, 2014 NetBSD-6-0 branch: Aug 16th, 2014 NetBSD-6-1 branch: Aug 16th, 2014 NetBSD-6 branch:Aug 16th, 2014 NetBSD-5-2 branch: Aug 28th, 2014 NetBSD-5-1 branch: Aug 28th, 2014 NetBSD-5 branch:Aug 28th, 2014 Teeny versions released later than the fix date will contain the fix. Please note that NetBSD releases prior to 5.1 are no longer supported. It is recommended that all users upgrade to a supported release. Abstract Information leak in pretty printing functions (CVE-2014-3508) Double Free when processing DTLS packets (CVE-2014-3505) DTLS memory exhaustion (CVE-2014-3506) DTLS memory leak from zero-length fragments (CVE-2014-3507) OpenSSL DTLS anonymous EC(DH) denial of service (CVE-2014-3510) Race condition in ssl_parse_serverhello_tlsext (CVE-2014-3509) OpenSSL TLS protocol downgrade attack (CVE-2014-3511) only in NetBSD-6 and NetBSD-current: Crash with SRP ciphersuite in Server Hello message (CVE-2014-5139) SRP buffer overrun (CVE-2014-3512) Technical Details = See http://www.openssl.org/news/secadv_20140806.txt Solutions and Workarounds = Update the OpenSSL libraries and make sure the old libssl and libcrypto are no longer used. - From source: +--- Update src and rebuild and install. Note: OpenSSL in NetBSD-6 and NetBSD-current has been updated to version 1.0.1i; updating the entire src tree is recommended. - From tarballs: +- To obtain fixed binaries, fetch the appropriate base.tgz and comp.tgz from a daily build later than the fix dates, from http://nyftp.netbsd.org/pub/NetBSD-daily/rel/date/arch/binary/sets/ with a date 20140828* or larger, and your release version and architecture (e.g. http://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-6-1/201408280100Z/amd64/binary/sets/), and then extract the files: Shared libraries: tar xzpf base.tgz \*libssl\* \*libcrypto\* And static libraries and linker config files: tar xzpf comp.tgz \*libssl\* \*libcrypto\* Get the fixed library into use +- Since the vulnerability is in a shared library, getting the old library purged and the fixed one into use requires restarting all programs that load libssl and libcrypto. The easiest way to do this is to reboot the system. Another method: using /bin/sh, ps ax -o pid | (while read pid; do \ pmap $pid | egrep '(libssl|libcrypto)' echo found $pid ;\ done) will find non-chrooted programs that have the affected libraries open; restart them. sshd will not show up in this list since it runs chrooted and re-exec'ed but also needs to be restartet. ldd programname will show the shared libraries a programs is wont to use. Lastly, remove the vulnerable libraries to make sure they won't get used accidentially: rm /usr/lib/libssl.so.10.3 /lib/libcrypto.so.8.2 /usr/lib/libcrypto.so.8.2 Fixed versions -- files relative to src/crypto/external/bsd/openssl/dist/ssl branch d1_both.ct1_lib.c s3_clnt.cs23_srvr.c -- --- --- --- netbsd-6-0 1.1.1.4.4.1.4.3 1.5.4.1.4.3 1.4.4.1.4.3 1.1.1.3.10.1 netbsd-6-1 1.1.1.4.4.1.6.3 1.5.4.1.6.3 .4.4.1.6.3 1.1.1.3.18.1 netbsd-61.1.1.4.4.4 1.5.4.4 1.4.4.4 1.1.1.3.4.1 HEAD1.1.1.9 1.13 1.10 1.1.1.4 files relative to src/crypto/external/bsd/openssl/dist/crypto branch asn1/a_object.c objects/obj_dat.c srp/srp_lib.c -- --- - - netbsd-6-0 1.1.1.3.4.1.4.1 1.1.1.2.14.1 1.1.1.1.10.2 netbsd-6-1 1.1.1.3.4.1.6.1 1.1.1.2.22.1 1.1.1.1.18.2 netbsd-61.1.1.3.4.2 1.1.1.2.8.11.1.1.1.4.2 HEAD1.1.1.5 1.1.1.31.1.1.3 files relative to crypto/dist/openssl/ssl branch d1_both.ct1_lib.c s3_clnt.c s23_srvr.c -- --- --- netbsd-5-1 1.3.4.2.2.2 1.2.12.4 1.12.4.2.2.3 1.6.12.1 netbsd-5-2 1.3.4.2.6.2 1.2.4.3.2.1 1.12.4.3.4.2 1.6.2.1 netbsd-51.3.4.4 1.2.4.4 1.12.4.5 1.6.4.1 files relative to crypto/dist/openssl/crypto branch asn1/a_object.c asn1/asn1.h
daily CVS update output
Updating src tree: P src/build.sh U src/common/lib/libc/arch/or1k/atomic/Makefile.inc U src/common/lib/libc/arch/or1k/atomic/atomic_add_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_and_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_cas_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_dec_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_inc_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_nand_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_op_asm.h U src/common/lib/libc/arch/or1k/atomic/atomic_or_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_swap_32.S U src/common/lib/libc/arch/or1k/atomic/atomic_xor_32.S U src/common/lib/libc/arch/or1k/atomic/membar_ops.S U src/common/lib/libc/arch/or1k/atomic/sync_bool_compare_and_swap_4.S U src/common/lib/libc/arch/or1k/gen/mulsi3.S U src/common/lib/libc/arch/or1k/string/bcopy.S U src/common/lib/libc/arch/or1k/string/bzero.S U src/common/lib/libc/arch/or1k/string/clz.S U src/common/lib/libc/arch/or1k/string/ctz.S U src/common/lib/libc/arch/or1k/string/ffs.S U src/common/lib/libc/arch/or1k/string/memcmp.S U src/common/lib/libc/arch/or1k/string/memcpy.c U src/common/lib/libc/arch/or1k/string/memmove.S U src/common/lib/libc/arch/or1k/string/memset.S U src/common/lib/libc/arch/or1k/string/strlen.S P src/common/lib/libc/atomic/atomic_cas_by_cas32.c U src/distrib/sets/lists/comp/md.or1k P src/doc/CHANGES U src/etc/etc.or1k/MAKEDEV.conf U src/etc/etc.or1k/Makefile.inc U src/etc/etc.or1k/ttys P src/external/gpl3/binutils/dist/config.sub P src/external/gpl3/binutils/dist/bfd/Makefile.in P src/external/gpl3/binutils/dist/bfd/archures.c P src/external/gpl3/binutils/dist/bfd/bfd-in2.h cvs update: `src/external/gpl3/binutils/dist/bfd/coff-or32.c' is no longer in the repository P src/external/gpl3/binutils/dist/bfd/coffcode.h P src/external/gpl3/binutils/dist/bfd/config.bfd P src/external/gpl3/binutils/dist/bfd/configure P src/external/gpl3/binutils/dist/bfd/configure.in U src/external/gpl3/binutils/dist/bfd/cpu-or1k.c cvs update: `src/external/gpl3/binutils/dist/bfd/cpu-or32.c' is no longer in the repository P src/external/gpl3/binutils/dist/bfd/elf-bfd.h cvs update: `src/external/gpl3/binutils/dist/bfd/elf32-openrisc.c' is no longer in the repository U src/external/gpl3/binutils/dist/bfd/elf32-or1k.c cvs update: `src/external/gpl3/binutils/dist/bfd/elf32-or32.c' is no longer in the repository P src/external/gpl3/binutils/dist/bfd/libbfd.h P src/external/gpl3/binutils/dist/bfd/targets.c P src/external/gpl3/binutils/dist/binutils/readelf.c cvs update: `src/external/gpl3/binutils/dist/cpu/openrisc.cpu' is no longer in the repository cvs update: `src/external/gpl3/binutils/dist/cpu/openrisc.opc' is no longer in the repository U src/external/gpl3/binutils/dist/cpu/or1k.cpu U src/external/gpl3/binutils/dist/cpu/or1k.opc U src/external/gpl3/binutils/dist/cpu/or1kcommon.cpu U src/external/gpl3/binutils/dist/cpu/or1korbis.cpu U src/external/gpl3/binutils/dist/cpu/or1korfpx.cpu P src/external/gpl3/binutils/dist/gas/Makefile.am P src/external/gpl3/binutils/dist/gas/Makefile.in P src/external/gpl3/binutils/dist/gas/configure P src/external/gpl3/binutils/dist/gas/configure.in P src/external/gpl3/binutils/dist/gas/configure.tgt cvs update: `src/external/gpl3/binutils/dist/gas/config/tc-openrisc.c' is no longer in the repository cvs update: `src/external/gpl3/binutils/dist/gas/config/tc-openrisc.h' is no longer in the repository U src/external/gpl3/binutils/dist/gas/config/tc-or1k.c U src/external/gpl3/binutils/dist/gas/config/tc-or1k.h cvs update: `src/external/gpl3/binutils/dist/gas/config/tc-or32.c' is no longer in the repository cvs update: `src/external/gpl3/binutils/dist/gas/config/tc-or32.h' is no longer in the repository P src/external/gpl3/binutils/dist/include/dis-asm.h P src/external/gpl3/binutils/dist/include/elf/common.h cvs update: `src/external/gpl3/binutils/dist/include/elf/openrisc.h' is no longer in the repository U src/external/gpl3/binutils/dist/include/elf/or1k.h cvs update: `src/external/gpl3/binutils/dist/include/elf/or32.h' is no longer in the repository P src/external/gpl3/binutils/dist/ld/Makefile.am P src/external/gpl3/binutils/dist/ld/Makefile.in P src/external/gpl3/binutils/dist/ld/configure.tgt cvs update: `src/external/gpl3/binutils/dist/ld/emulparams/elf32openrisc.sh' is no longer in the repository U src/external/gpl3/binutils/dist/ld/emulparams/elf32or1k.sh U src/external/gpl3/binutils/dist/ld/emulparams/elf32or1k_linux.sh U src/external/gpl3/binutils/dist/ld/emulparams/elf32or1k_nbsd.sh cvs update: `src/external/gpl3/binutils/dist/ld/emulparams/or32.sh' is no longer in the repository cvs update: `src/external/gpl3/binutils/dist/ld/emulparams/or32elf.sh' is no longer in the repository P src/external/gpl3/binutils/dist/opcodes/Makefile.am P src/external/gpl3/binutils/dist/opcodes/Makefile.in P src/external/gpl3/binutils/dist/opcodes/configure P src/external/gpl3/binutils/dist/opcodes/configure.in P
