Re: autofs -hosts maps

[Daniel Braniss]

> On 18 Nov 2023, at 5:47, Cy Schubert  wrote:
> 
> Hi,
> 
> The discussion about NFS exports of ZFS snapshots prompted me to play 
> around with -hosts maps on my network. -hosts maps are mounted on /net.
> 
> I've discovered that -hosts maps don't work with most shares but do with 
> others. I've only played with this for a few minutes so I don't fully 
> understand why some maps work and others not. Some of underlying 
> directories that don't work are ZFS while others are UFS.
> 
> Yet, auto_home maps mounting the same directories does work. And mounting 
> the shares by hand (using mount_nfs) also works.
> 
> Just putting this out there should someone else have noticed this.
> 
> I'll play around with this a little over the weekend.
> 
> 

it’s subdirectories that don’t work?
if so it’s a bug/feature of -hosts.

danny

> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  https://FreeBSD.org
> NTP:   Web:  https://nwtime.org
> 
>   e^(i*pi)+1=0
> 
> 
> 
> 

Daniel Braniss
da...@cs.huji.ac.il

Re: rc.d/zpool should require (rw) root?

[Daniel Braniss]

> On 4 Feb 2022, at 12:07, Andriy Gapon  wrote:
> 
> 
> It seems that in some cases zpool import -c requires read/write access to the 
> zpool.cache file.  So, it probably makes sense to import "other" pools 
> (non-root) after upgrading / to rw.
> What do you think?
> 

what if root is ro? i.e: diskless?

danny

> -- 
> Andriy Gapon
> 

Re: Arduino IDF -> make/automake based environment

[Daniel Braniss]

> On 29 Dec 2021, at 14:06, FreeBSD User  wrote:
> 
> On Wed, 29 Dec 2021 09:10:02 +0200
> Daniel Braniss mailto:da...@cs.huji.ac.il>> wrote:
> 
>>> On 29 Dec 2021, at 01:25, FreeBSD User >> <mailto:free...@walstatt-de.de>> wrote:
>>> 
>>> On Mon, 20 Dec 2021 14:35:10 +0100
>>> Marc Fonvieille mailto:black...@freebsd.org> 
>>> <mailto:black...@freebsd.org <mailto:black...@freebsd.org>>> wrote:
>>> 
>>>> Le 19.12.2021 21:03, Andrew Stevenson a écrit :  
>>>>> 
>>>>> 
>>>>>> On 19. Dec 2021, at 12:18, FreeBSD User  wrote:
>>>>>> 
>>>>>> environment. Since I'm interested in coding for some smaller AMTEL MCUs 
>>>>>> and ESP32
>>>>>> and like to digg a bit deeper than simply clicking a host base from a 
>>>>>> menu, I'm not
>>>>>> afraid of doing some larger basic setup if needed.
>>>>> 
>>>>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in 
>>>>> ports.
>>>>> 
>>>> 
>>>> For ESP32, you should look at:
>>>> https://wiki.freebsd.org/electronics/arduino/esp32  
>>> 
>>> Following these instructions with the most recent required ports on the 
>>> latest
>>> 13-STABLE, results in an linker error:
>>> 
>>> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
>>> cannot find crt1-sim.o: No such file or directory
>>> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
>>> cannot find _vectors.o: No such file or directory
>>> collect2: error: ld returned 1 exit status
>>> 
>>> 
>>>> and
>>>> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
>>>>  
>>>> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/>
>>>> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
>>>>  
>>>> <https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/>>
>>>> 
>> i gave up compiling the xtensa stuff, specially after espressif came out 
>> with a riscv
>> version. so I downloaded the oficial idf and under FreeBSD-13 it almost 
>> worked  out of
>> the box, if you want I can search my notes …
>> 
>> danny
>> 
> 
> Hello.
> 
> I think, that will be the first step in the right direction (using the 
> official eps-idf).
> Since I didn't come along with the salvation of the linker error reported 
> earlier, I
> switched back to an older project from January this year. It is also based on 
> the
> official FreeBSD Arduino 1.8.5 port and the xtensa compiler 5.2.0 from ports, 
> but I used
> within sketchbook/hardware/esp32 the esp32 git branch release/v1.0 instead of 
> master on
> which I faced the crt1-sim.o error. The goal is to compile HyperionLED (as a 
> side
> product) with the recommended libraries for this project.
> It doesn't compile with ESP32 branch release/v1.0, the error is now
> 
> [...]
> libraries/FastLED/src/platforms/esp/32/clockless_rmt_esp32.h:149:33: error:
> 'cpu_hal_get_cycle_count' was not declared ...
> [...]
> 
> which lead me to the conclusion that a more recent version is required. With 
> the recent
> version of ESP32 stuff in place, I face the mentioned crt1-sim.o error.

same here, apart from the need for a different compiler for the riskv chips.

> 
> Searching the web for that error leads to a discrepancy of ESP-IDF and the 
> compiler stuff.
> 
> I'll try the original esp-idf as you suggested (it is a pity it is backed by 
> cmake, I'm
> not quite familiar with cmake yet).
> 
> Any advice is highly appreciated.

espidf version i’m using is 5 (master) and it needs linux emulation and yes, 
cmake, but it’s not that difficult to master,
just check the examples CMakefile’s.

if you need more specific help just yell :-)

danny



> 
> Kind regards,
> oh

Re: Arduino IDF -> make/automake based environment

[Daniel Braniss]

> On 29 Dec 2021, at 01:25, FreeBSD User  wrote:
> 
> On Mon, 20 Dec 2021 14:35:10 +0100
> Marc Fonvieille mailto:black...@freebsd.org>> wrote:
> 
>> Le 19.12.2021 21:03, Andrew Stevenson a écrit :
>>> 
>>> 
 On 19. Dec 2021, at 12:18, FreeBSD User  wrote:
 
 environment. Since I'm interested in coding for some smaller AMTEL MCUs 
 and ESP32
 and like to digg a bit deeper than simply clicking a host base from a 
 menu, I'm not
 afraid of doing some larger basic setup if needed.  
>>> 
>>> If by small AMTEL MCUs you mean AVRs then avr-gcc and avrdude are in ports.
>>> 
>> 
>> For ESP32, you should look at:
>> https://wiki.freebsd.org/electronics/arduino/esp32
> 
> Following these instructions with the most recent required ports on the 
> latest 13-STABLE,
> results in an linker error:
> 
> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
> cannot find crt1-sim.o: No such file or directory
> /usr/local/xtensa-esp32-elf/bin/../lib/gcc/xtensa-esp32-elf/5.2.0/../../../../xtensa-esp32-elf/bin/ld:
> cannot find _vectors.o: No such file or directory
> collect2: error: ld returned 1 exit status
> 
> 
>> and
>> https://forums.freebsd.org/threads/a-guide-for-installing-esp32-board-for-arduino-on-freebsd12-update-2021-08-17.78408/
>>  
>> 
i gave up compiling the xtensa stuff, specially after espressif came out with a 
riscv version.
so I downloaded the oficial idf and under FreeBSD-13 it almost worked  out of 
the box,
if you want I can search my notes …

danny

Re: Is amd automount still supported in 13.0 or not?

[Daniel Braniss]

> On 9 Mar 2020, at 19:26, Bob Willcox  wrote:
> 
> On Mon, Mar 09, 2020 at 08:35:58AM -0700, Cy Schubert wrote:
>> On March 9, 2020 7:49:34 AM PDT, Ed Maste  wrote:
>>> On Sun, 8 Mar 2020 at 13:23, Bob Willcox  wrote:
 
 Thanks for the tip! That worked for me. I guess from reading the
>>> documentation
 I didn't pick up on staying with the symlinks and simply changing
>>> host to net.
>>> 
>>> Glad it's working for you! Is there anything else that you found
>>> tricky or surprising in migrating? Perhaps we could produce a
>>> quick-reference transition guide.
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to
>>> "freebsd-current-unsubscr...@freebsd.org"
>> 
>> /net and indirect maps should be simple conversations. Direct maps may or 
>> may not be easy. Autofs doesn't support nested direct maps like amd does. 
>> You may need to mount elsewhere or use /net with symlinks.
>> 
>> We do have a port as well. The port will be retired after a reasonable 
>> amount of time to allow people to convert. Amd upstream has told me he no 
>> longer supports amd. His advice is to use autofs.
> 
> Yes, and I considered installing the amd port but that just seemed like I'd 
> be postponing
> the inevitable. Since I had a simple use case of just using symlinks to about 
> four of my
> remote filesystems, switching from using the /host symlink to the /net 
> symlink was pretty
> easy.
> 
> 
> -- 
> Bob Willcox| It's possible that the whole purpose of your life is to
> b...@immure.com  | serve as a warning to others.
> Austin, TX |
> ___
> freebsd-current@freebsd.org  mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> 
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> ”

short version:
 www.cs.huji.ac.il/~danny/autofs.py  
is a python script that converts old hesiod based am-utils maps to autofs
and has been in used for several years now.

long version:
we have been using amd (later am-utils) since sunos days, when we moved to BSD, 
there was no NIS support,
so we switched to hesiod (clever move then since we were all the time getting  
’NIS server not responding’)

with am-utils we had some issues, so when autofs finally made it to Linux, and 
then to FreeBSD, it has been
very solid indeed! 
BTW, autofs is heavily used here, for home directories, binaries etc.

my 2cents.

danny


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD Core Team Response to Controversial Social Media Posts

[Daniel Braniss]

BIKE SHED SYNDROME?

danny
PS: intentionally top posting :-)

> On 19 May 2019, at 22:43, Igor Mozolevsky  wrote:
> 
> On Sun, 19 May 2019 at 20:16, Warner Losh wrote:
>> 
>> On Sun, May 19, 2019 at 11:34 AM Igor Mozolevsky wrote:
>>> 
>>> On Sun, 19 May 2019 at 17:54, Warner Losh wrote:
> 
> 
> 
 Yes. There will always be limits, just like in real life. You can't tell
 fire in a theater, and claim freedom of expression, for example.
>>> 
>>> 
>>> 
>>> While that is an often cited example, it is rather tenuous as far as
>>> "freedom of expression" is concerned: yelling "Fire!" in a crowded
>>> theatre is by no measure an expression of one's views, thoughts, or
>>> opinions. At the same time, the invocation of a CoC ctte review is
>>> triggered by precisely the latter.
>> 
>> 
>> It is a difficult problem. The project needs to protect itself and its
>> members from harm. Sometimes, though rarely, that harm
>> comes from expressing ones views in a way that's so extreme
>> it causes real and lasting problems either for the cohesiveness
>> of the project, or its effect on the project's reputation is so
>> extreme, people can't separate the two and stop using it. There
>> needs to be a review mechanism for cases that are extreme.
> 
> It's very difficult to subscribe to that view! The first problem you
> encounter is "what is an objectively extreme expression"--what is
> extreme to one, might be entirely common place to another. I'm sure
> whatever religious book one takes there is a passage that goes along
> the lines of "judge people by their deeds not by their words"...
> Secondly, the greatest legal minds in the US wrangled with that and
> came up with one answer: *ANY* expression is protected for otherwise
> it would not be "freedom."
> 
> 
>> At the same time, reviews are detrimental if they are triggered
>> for 'ordinary' conduct: they take time and energy away from
>> the project that could otherwise be spent on making things
>> better. The trick is to have any such review reflect the broad
>> consensus within the project of what's clearly out of bounds,
>> as well as having a fair and just response by the board in
>> the cases that require some action.
> 
> 
> Agreement by consensus is most dangerous, for, usually, the loudest
> wins because people with no backbone fall in-line; the best
> explanation of democracy I have ever heard was: "two wolves and a
> sheep deciding what to have for dinner!"
> 
> 
> --
> Igor M.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ALPHA8/r338991 gpart coredumps

[Daniel Braniss]

made a new image/sd and the problem disappeared! freaky.
sorry for the noice

danny


> On 28 Sep 2018, at 10:07, Daniel Braniss  wrote:
> 
> Hi,
> this is happening on an arm/h3, is this only me?
> this is the output of truss:
> truss gpart show
> mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0x15) = 
> 537104384 (0x20039000)
> issetugid()  = 0 (0x0)
> openat(AT_FDCWD,"/etc/libmap.conf",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
> fstat(3,{ mode=-rw-r--r-- ,inode=81462,size=47,blksize=32768 }) = 0 (0x0)
> read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
> close(3) = 0 (0x0)
> open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145)
>  ERR#2 'No such file or directory'
> openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
> read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80)
> fstat(3,{ mode=-r--r--r-- ,inode=244811,size=158,blksize=32768 }) = 0 (0x0)
> pread(3,"/lib:/usr/lib:/usr/lib/compat\0",30,0x0) = 30 (0x1e)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libgeom.so.5",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241318,size=26436,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,32768,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537239552 
> (0x2005a000)
> mmap(0x2005a000,8192,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537239552 (0x2005a000)
> mmap(0x2005c000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537247744 (0x2005c000)
> mmap(0x2005f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537260032 (0x2005f000)
> mmap(0x20061000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 537268224 (0x20061000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libutil.so.9",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241436,size=71928,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,81920,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537272320 
> (0x20062000)
> mmap(0x20062000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537272320 (0x20062000)
> mmap(0x20066000,49152,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537288704 (0x20066000)
> mmap(0x20072000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537337856 (0x20072000)
> mmap(0x20074000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 537346048 (0x20074000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=244782,size=1683256,blksize=32768 }) = 0 
> (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,1826816,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 
> 537354240 (0x20076000)
> mmap(0x20076000,245760,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 537354240 (0x20076000)
> mmap(0x200b2000,1400832,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 53760 (0x200b2000)
> mmap(0x20208000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
>  = 539000832 (0x20208000)
> mmap(0x20211000,143360,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
>  = 539037696 (0x20211000)
> munmap(0x20059000,4096)  = 0 (0x0)
> close(3) = 0 (0x0)
> openat(AT_FDCWD,"/lib/libbsdxml.so.4",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 
> (0x3)
> fstat(3,{ mode=-r--r--r-- ,inode=241314,size=150688,blksize=32768 }) = 0 (0x0)
> mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
>  = 537235456 (0x20059000)
> mmap(0x0,151552,PROT_NONE,

ALPHA8/r338991 gpart coredumps

[Daniel Braniss]

Hi,
this is happening on an arm/h3, is this only me?
this is the output of truss:
truss gpart show
mmap(0x0,131072,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_ANON,4096,0x15) = 
537104384 (0x20039000)
issetugid()  = 0 (0x0)
openat(AT_FDCWD,"/etc/libmap.conf",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
fstat(3,{ mode=-rw-r--r-- ,inode=81462,size=47,blksize=32768 }) = 0 (0x0)
read(3,"# $FreeBSD$\nincludedir /usr/loc"...,47) = 47 (0x2f)
close(3) = 0 (0x0)
open("/usr/local/etc/libmap.d",O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC,0145) 
ERR#2 'No such file or directory'
openat(AT_FDCWD,"/var/run/ld-elf.so.hints",O_RDONLY|O_CLOEXEC,00) = 3 (0x3)
read(3,"Ehnt\^A\0\0\0\M^@\0\0\0\^^\0\0\0"...,128) = 128 (0x80)
fstat(3,{ mode=-r--r--r-- ,inode=244811,size=158,blksize=32768 }) = 0 (0x0)
pread(3,"/lib:/usr/lib:/usr/lib/compat\0",30,0x0) = 30 (0x1e)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libgeom.so.5",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241318,size=26436,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,32768,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537239552 
(0x2005a000)
mmap(0x2005a000,8192,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537239552 (0x2005a000)
mmap(0x2005c000,12288,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537247744 (0x2005c000)
mmap(0x2005f000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537260032 (0x2005f000)
mmap(0x20061000,4096,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 537268224 (0x20061000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libutil.so.9",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241436,size=71928,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,81920,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537272320 
(0x20062000)
mmap(0x20062000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537272320 (0x20062000)
mmap(0x20066000,49152,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537288704 (0x20066000)
mmap(0x20072000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537337856 (0x20072000)
mmap(0x20074000,8192,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 537346048 (0x20074000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libc.so.7",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=244782,size=1683256,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,1826816,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 537354240 
(0x20076000)
mmap(0x20076000,245760,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 537354240 (0x20076000)
mmap(0x200b2000,1400832,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 53760 (0x200b2000)
mmap(0x20208000,36864,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539000832 (0x20208000)
mmap(0x20211000,143360,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_ANON,537235540,0x2005909420059074)
 = 539037696 (0x20211000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/libbsdxml.so.4",O_RDONLY|O_CLOEXEC|O_VERIFY,00) = 3 (0x3)
fstat(3,{ mode=-r--r--r-- ,inode=241314,size=150688,blksize=32768 }) = 0 (0x0)
mmap(0x0,4096,PROT_READ,MAP_PRIVATE|MAP_PREFAULT_READ,-1077947392,0xbfbfd3d82002d758)
 = 537235456 (0x20059000)
mmap(0x0,151552,PROT_NONE,MAP_GUARD,537235540,0x2005909420059074) = 539181056 
(0x20234000)
mmap(0x20234000,16384,PROT_READ,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539181056 (0x20234000)
mmap(0x20238000,122880,PROT_READ|PROT_EXEC,MAP_PRIVATE|MAP_FIXED|MAP_NOCORE|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539197440 (0x20238000)
mmap(0x20256000,12288,PROT_READ|PROT_WRITE,MAP_PRIVATE|MAP_FIXED|MAP_PREFAULT_READ,537235540,0x2005909420059074)
 = 539320320 (0x20256000)
munmap(0x20059000,4096)  = 0 (0x0)
close(3) = 0 (0x0)
openat(AT_FDCWD,"/lib/l

Re: usb rtwn not loaded properly at boot

[Daniel Braniss]

> On 18 Sep 2018, at 10:32, Johannes Lundberg  wrote:
> 
> On Tue, Sep 18, 2018 at 9:27 AM Yuri Pankov  wrote:
> 
>> Johannes Lundberg wrote:
>>> Hi
>>> 
>>> I have (with 12-ALPHA5)
>>> 
>>> /boot/loader.conf
>>> rtwn_load="YES"
>>> if_urtw_usb_load="YES"
>> 
>> rtwn(4) thinks this should be if_rtwn_usb_load="YES".
>> 
> 
> Ah yes. Sorry about that. I still suffer confusion from the rename.
> Still, it doesn't change anything since if_rtwn_usb was loaded anyway.
> 
> 
>>> /etc/rc.conf
>>> wlans_rtwn0="wlan0"
>>> ifconfig_wlan0="WPA DHCP"
>>> 
>>> but still after boot only lo0 exists and all modules are loaded.
>>> 
>>> Manually running
>>> ifconfig wlan0 create wlandev rtwn0
>>> sets up the interface correctly.
>>> 
>>> In my kernel config I have
>>> MODULES_OVERRIDE="usb rtwn_usb rtwn "
>>> 
>>> I'm pretty sure this has worked before... Any clues?
>> 


devd is not calling netif!
try running ’service netif start’ and see what happens.

danny

> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

netif not started by devd?

[Daniel Braniss]

with latest current, but can tell when this stopped working,
the wifi dongle is recognised, ie there is a net.wlan.devices,
depending on the dongle it’s run0 or  rtwn0
but only if I type
service netif start
does it become operational.

so what am I missing?

cheers,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

declient without capsicum failes

[Daniel Braniss]

hi,
latest change to dhclient added chroot if there is no capsicum - my case,
so  chroot failes because /var/empty belongs to root and setgid/setgid/seteuid 
to user dhclient is performed before.

need a pr?

danny



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ntpd user/group issue

[Daniel Braniss]

Hi,
I am cross compiling, which means i’m using for example an 11.1 to compile 
current, for
another host - an image which is different from the one i'm using to compile.

make install checks for ntpd in /etc, instead, should it look elsewhere? 
DESTDIR perhaps?

cheers,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zfsloader: messy output on Dell iDrac serial console

[Daniel Braniss]

> On 7 Apr 2018, at 7:21, Julian Elischer  wrote:
> 
> running on *some* Dell servers the serial console looks messed up at the time 
> of the FreeBSD menu.
> it looks like it's dropping (or adding? but that's less likely) characters.
> 
>  |  5. [K]ernel: kernel (1 of 2)   |  .- .-.
>  |  6. Configure Boot [O]ptions... |2  --| y/   -.   -/`   -o/
>  |137. Select Boot [E]nvironment...| `:`  `:` 
> ::/sy++:.
>  | H| .-- `--. --  /6H`:  
> :`
>  | | .---..
> 
> IS there an RTS/CTS input we should be attending to?
> 
> I will add that some of the other modules (e.g. the mfi raid setup section) 
> also get affected,
> so it's not just a bug in our code.

I’m using Serial-Over-LAN via ipmi/drac and am noticing this too on a Dell 
C6220,
don’t know when this started though, It’s only recently that I’m working on
this kind of hosts. It drives the xterm/rxvt crazy, but it’s only the output 
from the
boot/loader, once the kernel takes over, all is back to normal. the serial 
speed is
set to 115200, but changing it as far as i remember did not help. will try 
lowering soon.
I had to disable the menu to get some sense of the output, and usually have to 
hit ^B to remove most of the
garbage.



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devdmatch: Can't read linker file.

[Daniel Braniss]

> On 13 Mar 2018, at 19:12, Edward Napierala  wrote:
> 
> I think it's only needed for kernels that are cross-built.  That's due to
> kldxref(8) being unable to handle kernels for other architectures.
> 
my case exactly.

> 2018-03-13 13:34 GMT+00:00 Warner Losh  <mailto:i...@bsdimp.com>>:
> I wonder why that isn't the default, or why the linker.hints isn't at least
> created by the make installkernel step...
> 
> Warner
> 
> On Tue, Mar 13, 2018 at 2:40 AM, Edward Tomasz Napierała  <mailto:tr...@freebsd.org>>
> wrote:
> 
> > FWIW, it seems to be a common problem, see https://reviews.freebsd.org/ 
> > <https://reviews.freebsd.org/>
> > D14534.
> >
> > On 0312T1027, Warner Losh wrote:
> > > Well, is there a /boot/kernel/linker.hints?
> > >
> > > Warner
> > >
> > > On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss  > > <mailto:da...@cs.huji.ac.il>>
> > wrote:
> > >
> > > > Hi,
> > > > the above i get on arm/nanopi-neo. (it’s the only platform I run
> > current
> > > > :-)
> > > >
> > > > cheers,
> > > > danny
> > > >
> > > >
> > > ___
> > > freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing 
> > > list
> > > https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> > > <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@
> > freebsd.org <http://freebsd.org/>"
> >
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> <mailto:freebsd-current-unsubscr...@freebsd.org>"
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: devdmatch: Can't read linker file.

[Daniel Braniss]

> On 12 Mar 2018, at 18:27, Warner Losh  wrote:
> 
> Well, is there a /boot/kernel/linker.hints?
> 
no, but that was enough to do a grep and the run kldxref.

thanks,
danny
PS: just remembered: reach out and grep someone

> Warner
> 
> On Mon, Mar 12, 2018 at 9:56 AM, Daniel Braniss  <mailto:da...@cs.huji.ac.il>> wrote:
> Hi,
> the above i get on arm/nanopi-neo. (it’s the only platform I run current :-)
> 
> cheers,
> danny
> 
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

devdmatch: Can't read linker file.

[Daniel Braniss]

Hi,
the above i get on arm/nanopi-neo. (it’s the only platform I run current :-)

cheers,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: how to produce dtb from dts?

[Daniel Braniss]

> On 4 Dec 2017, at 20:31, Ian Lepore  wrote:
> 
> On Mon, 2017-12-04 at 19:06 +0200, Daniel Braniss wrote:
>> Hi,
>> what’s the current official procedure to compile/convert a dts file,
>> I’m my case sun8i-h3-nanopi-neo.dts
>> to its dtb?
>> 
>> thanks,
>>  danny
>> 
> 
> make builddtb FDT_DTS_FILE= DTBOUTPUTPATH=
> 
> -- Ian

thanks, will try ASAP.

danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

how to produce dtb from dts?

[Daniel Braniss]

Hi,
what’s the current official procedure to compile/convert a dts file, I’m my 
case sun8i-h3-nanopi-neo.dts
to its dtb?

thanks,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: what happened to src/sys/boot?

[Daniel Braniss]

> On 3 Dec 2017, at 8:42, Daniel Braniss  wrote:
> 
> 
> 
>> On 2 Dec 2017, at 22:31, Warner Losh > <mailto:i...@bsdimp.com>> wrote:
>> 
>> 
>> 
>> On Sat, Dec 2, 2017 at 1:26 PM, Daniel Braniss > <mailto:da...@cs.huji.ac.il> <mailto:da...@cs.huji.ac.il 
>> <mailto:da...@cs.huji.ac.il>>> wrote:
>> 
>> 
>>> On 2 Dec 2017, at 17:42, Warner Losh >> <mailto:i...@bsdimp.com> <mailto:i...@bsdimp.com <mailto:i...@bsdimp.com>>> 
>>> wrote:
>>> 
>>> 
>>> 
>>> On Sat, Dec 2, 2017 at 6:42 AM, Daniel Braniss >> <mailto:da...@cs.huji.ac.il> <mailto:da...@cs.huji.ac.il 
>>> <mailto:da...@cs.huji.ac.il>>> wrote:
>>> Hi,
>>> it seems to have disappeared.
>>> 
>>> After discussion on arch@, they were move to src/stand. They aren't part of 
>>> the kernel, and this was the previous historic place for them. This will 
>>> make things like the lua boot loader a bit easier, though we still have a 
>>> bit too much accumulated debt in the boot loader that needs to be addressed 
>>> first.
>>> 
>>> Warner 
>> 
>> this is what happens when you are at the BEOT :-)
>> now lets see how difficult it is to get ubldr for allwinner to compile.
>> 
>> Builds for me. Lemme know if that's not true for you.
>> 
>> Warner 
> 
> changed sys/boot to stand in crochet/lib/freebsd.sh,
> now will check if all this works!

ok, the image created now boots on both orangepi-one and nanopi-neo,
but without ethernet! 
time to figure out what’s missing in the dtb’s
cheers,
danny

> 
> thanks,
>   danny
> 
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> <mailto:freebsd-current-unsubscr...@freebsd.org>"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: what happened to src/sys/boot?

[Daniel Braniss]

> On 2 Dec 2017, at 22:31, Warner Losh  wrote:
> 
> 
> 
> On Sat, Dec 2, 2017 at 1:26 PM, Daniel Braniss  <mailto:da...@cs.huji.ac.il>> wrote:
> 
> 
>> On 2 Dec 2017, at 17:42, Warner Losh > <mailto:i...@bsdimp.com>> wrote:
>> 
>> 
>> 
>> On Sat, Dec 2, 2017 at 6:42 AM, Daniel Braniss > <mailto:da...@cs.huji.ac.il>> wrote:
>> Hi,
>> it seems to have disappeared.
>> 
>> After discussion on arch@, they were move to src/stand. They aren't part of 
>> the kernel, and this was the previous historic place for them. This will 
>> make things like the lua boot loader a bit easier, though we still have a 
>> bit too much accumulated debt in the boot loader that needs to be addressed 
>> first.
>> 
>> Warner 
> 
> this is what happens when you are at the BEOT :-)
> now lets see how difficult it is to get ubldr for allwinner to compile.
> 
> Builds for me. Lemme know if that's not true for you.
> 
> Warner 

changed sys/boot to stand in crochet/lib/freebsd.sh,
now will check if all this works!

thanks,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: what happened to src/sys/boot?

[Daniel Braniss]

> On 2 Dec 2017, at 17:42, Warner Losh  wrote:
> 
> 
> 
> On Sat, Dec 2, 2017 at 6:42 AM, Daniel Braniss  <mailto:da...@cs.huji.ac.il>> wrote:
> Hi,
> it seems to have disappeared.
> 
> After discussion on arch@, they were move to src/stand. They aren't part of 
> the kernel, and this was the previous historic place for them. This will make 
> things like the lua boot loader a bit easier, though we still have a bit too 
> much accumulated debt in the boot loader that needs to be addressed first.
> 
> Warner 

this is what happens when you are at the BEOT :-)
now lets see how difficult it is to get ubldr for allwinner to compile.

cheers,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: what happened to src/sys/boot?

[Daniel Braniss]

> On 2 Dec 2017, at 16:00, David Wolfskill  wrote:
> 
> On Sat, Dec 02, 2017 at 03:42:07PM +0200, Daniel Braniss wrote:
>> Hi,
>> it seems to have disappeared.
>> ...
> 
> Ref. r325834:
> 
> 
> r325834 | imp | 2017-11-14 15:02:19 -0800 (Tue, 14 Nov 2017) | 4 lines
> 
> Move sys/boot to stand. Fix all references to new location
> 
> Sponsored by:   Netflix
> 
> 
> 
grr :-), should have started my allwinner project two weeks ago.
thanks,
danny


> Peace,
> david
> -- 
> David H. Wolfskillda...@catwhisker.org
> Trump is an incompetent, lying bully who is unfit for any public office.
> 
> See http://www.catwhisker.org/~david/publickey.gpg for my public key.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

what happened to src/sys/boot?

[Daniel Braniss]

Hi,
it seems to have disappeared.

danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Can't NFS mount ZFS volume

[Daniel Braniss]

> On 1 Oct 2017, at 14:41, Rick Macklem  wrote:
> 
> Michael Butler wrote:
>> I have no idea why but using ..
>> 
>> sudo /sbin/mount vm01:/usr/local/exports/ /mnt
> This is weird. I would have thought they would both result in the same
> behaviour.
>> .. instead of ..
>> 
>> sudo /sbin/mount -t nfs vm01:/usr/local/exports/ /mnt
> Did this work with the older system?.
> I'll admit I always go "su" and then do the mount command as
> # mount -t nfs vm01:/usr/local/exports /mnt"
> Please let us know if this doesn't work.
> (If you try this and it doesn't work, then something is definitely broken.)
> 
> I don't even have sudo. (It's a port and my guess would be some issue
> related to how either it or "mount" parses things.)
> 

the not working is :
mount host:/path some-local-path

which should default to -t nfs, and at least in 11.1 it works
danny

> rick
> 
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: usb dongle Mediatek 7601 wireless driver?

[Daniel Braniss]

> On 12 May 2017, at 12:13 PM, tj  wrote:
> 
> On Fri, May 12, 2017 at 10:45:21AM +0200, Gary Jennejohn wrote:
>> On Fri, 12 May 2017 09:58:16 +0300
>> Daniel Braniss  wrote:
>> 
>>> Hi,
>>> I could swear that I had one before working on an Raspberry PI,
>>> but this new one nothing:
>>> ugen0.2:  at usbus0, cfg=0 md=HOST 
>>> spd=HIGH (480Mbps) pwr=ON (160mA)
>>> 
>> 
>> According to this
>> http://freebsd-wireless.freebsd.narkive.com/09J7PGke/support-to-wireless-dongle-vendor-0x148f-product-0x7601
>> it's not supported.  Of course, that may have changed since then.
> 
> As far as I know this driver is not supported. I have started work on
> porting the linux driver, but progress is slow.
> 
> Code is here:
> 
> https://github.com/adventureloop/mt7610u_wifi_sta_v3002_dpo_20130916/
> 
> I am currently working on getting the firmware running on the device.
> 
> - [tj]
let me know if I can help,I also have an edimax ac600 lying around.

danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

usb dongle Mediatek 7601 wireless driver?

[Daniel Braniss]

Hi,
I could swear that I had one before working on an Raspberry PI,
but this new one nothing:
ugen0.2:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (160mA)

cheers,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NFSv2 boot & OLD_NFSV2

[Daniel Braniss]

> On 21 Mar 2017, at 10:13, Baptiste Daroussin  wrote:
> 
> On Tue, Mar 21, 2017 at 09:58:21AM +0200, Daniel Braniss wrote:
>> 
>>> On 20 Mar 2017, at 23:55, Toomas Soome  wrote:
>>> 
>>>> 
>>>> On 20. märts 2017, at 23:53, Rick Macklem  wrote:
>>>> 
>>>> Baptiste Daroussin wrote:
>>>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
>>>>>> Hi!
>>>>>> 
>>>>>> The current boot code is building NFSv3, with preprocessor conditional 
>>>>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
>>>>>> 
>>>>>> rgds,
>>>>>> toomas
>>>>> 
>>>>> I vote burn
>>>>> 
>>>>> Bapt
>>>> I would be happy to see NFSv2 go away. However, depending on how people 
>>>> configure
>>>> their diskless root fs, they do end up using NFSv2 for their root fs.
>>>> 
>>>> Does booting over NFSv3 affect this?
>>>> 
>>>> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle 
>>>> is the same as
>>>> the NFSv3 one, except padded with 0 bytes to 32bytes long).
>>>> However, there might be non-FreeBSD NFS servers where the NFSv2 file 
>>>> handle is different
>>>> than the NFSv3 one and for that case, the user would need NFSv2 boot code 
>>>> (or
>>>> reconfigure their root fs to use NFSv3).
>>>> 
>>>> To be honest, I suspect few realize that they are using NFSv2 for their 
>>>> root fs.
>>>> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
>>>> probably
>>>> think they are using NFSv3 for their root fs.)
>>>> 
>>>> rick
>>> 
>>> if they do not suspect, they most likely use v3 - due to simple fact that 
>>> you have to rebuild loader to use NFSv2 - it is compile time option.
>>> 
>> 
>> old systems, 8.x, still use/boot v2, and so do old linux.
>> NetApp has discontinued support for v2, so we had to move this machines to 
>> use FreeBSD server and the day was
>> saved. So, till these machines get upgraded/discontinued we have a problem. 
>> There are several solutions
>> to this issue, but as long as it's a matter of getting rid for the sake of 
>> it, I would vote to keep it a while longer.
>> 
>> danny
>> 
>> 
> Given you are speaking of 8.x I suppose you are using the loader that comes 
> with
> it, meaning you are safe if we remove it from the loader in 12.0 (note as said
> by Toomas that is it is already off by default in the 12.0 loader) am I 
> missing
> something?
> 

as usual, did not read the whole thread, I assumed - wrongly - that support for 
v2 would be discontinued.
removing v2 support from the boot process is fine! great, go for it. It will 
only involve newer
hosts, and simplifying the boot process is always a good idea.

sorry for the noise.
danny


> Best regards,
> Bapt

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NFSv2 boot & OLD_NFSV2

[Daniel Braniss]

> On 20 Mar 2017, at 23:55, Toomas Soome  wrote:
> 
>> 
>> On 20. märts 2017, at 23:53, Rick Macklem  wrote:
>> 
>> Baptiste Daroussin wrote:
>>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
 Hi!
 
 The current boot code is building NFSv3, with preprocessor conditional 
 OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
 
 rgds,
 toomas
>>> 
>>> I vote burn
>>> 
>>> Bapt
>> I would be happy to see NFSv2 go away. However, depending on how people 
>> configure
>> their diskless root fs, they do end up using NFSv2 for their root fs.
>> 
>> Does booting over NFSv3 affect this?
>> 
>> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle 
>> is the same as
>> the NFSv3 one, except padded with 0 bytes to 32bytes long).
>> However, there might be non-FreeBSD NFS servers where the NFSv2 file handle 
>> is different
>> than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
>> reconfigure their root fs to use NFSv3).
>> 
>> To be honest, I suspect few realize that they are using NFSv2 for their root 
>> fs.
>> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
>> probably
>> think they are using NFSv3 for their root fs.)
>> 
>> rick
> 
> if they do not suspect, they most likely use v3 - due to simple fact that you 
> have to rebuild loader to use NFSv2 - it is compile time option.
> 

old systems, 8.x, still use/boot v2, and so do old linux.
NetApp has discontinued support for v2, so we had to move this machines to use 
FreeBSD server and the day was
saved. So, till these machines get upgraded/discontinued we have a problem. 
There are several solutions
to this issue, but as long as it's a matter of getting rid for the sake of it, 
I would vote to keep it a while longer.

danny


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: NFSv2 boot & OLD_NFSV2

[Daniel Braniss]

> On 20 Mar 2017, at 23:53, Rick Macklem  wrote:
> 
> Baptiste Daroussin wrote:
>> On Mon, Mar 20, 2017 at 08:22:12PM +0200, Toomas Soome wrote:
>>> Hi!
>>> 
>>> The current boot code is building NFSv3, with preprocessor conditional 
>>> OLD_NFSV2. Should NFSv2 code still be kept around or can we burn it?
>>> 
>>> rgds,
>>> toomas
>> 
>> I vote burn
>> 
>> Bapt
> I would be happy to see NFSv2 go away. However, depending on how people 
> configure
> their diskless root fs, they do end up using NFSv2 for their root fs.
> 
> Does booting over NFSv3 affect this?
> 
> I think the answer is no for a FreeBSD server (since the NFSv2 File Handle is 
> the same as
> the NFSv3 one, except padded with 0 bytes to 32bytes long).
> However, there might be non-FreeBSD NFS servers where the NFSv2 file handle 
> is different
> than the NFSv3 one and for that case, the user would need NFSv2 boot code (or
> reconfigure their root fs to use NFSv3).
> 
> To be honest, I suspect few realize that they are using NFSv2 for their root 
> fs.
> (They'd see it in a packet trace or via "nfsstat -m", but otherwise they 
> probably
>  think they are using NFSv3 for their root fs.)

this just what happened here, we upgraded our main NetApp, and few machines 
started working funny,
so we moved them to use FreeBSD instead and all was ok again. 

danny


> 
> rick
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: syslogd: select: Bad File descriptor

[Daniel Braniss]

> On 24 Dec 2016, at 2:51 PM, Ngie Cooper (yaneurabeya)  
> wrote:
> 
> 
>> On Dec 24, 2016, at 04:16, Daniel Braniss  wrote:
>> 
>> latest changes is causing cpu load and ‘last message repeated  
>> times, I guess the eggnog is affecting too early
> 
> Fixed in r310504.
> Thanks,
> -Ngie

thanks!

Season Greetings,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

syslogd: select: Bad File descriptor

[Daniel Braniss]

latest changes is causing cpu load and ‘last message repeated  times, I 
guess the eggnog is affecting too early

cheers,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwm -> rtwm

[Daniel Braniss]

> On 2 Nov 2016, at 15:54, Mattia Rossi  
> wrote:
> 
> 
>>> Hi!
>>> 
>>> rtwn_usb(4) depends on rtwn(4) module; you can try to
>>> 1) add them to the kernel config;
>>> 2) check / fix WITHOUT_MODULES and MODULES_OVERRIDE make.conf(5) variables
>>> 3) compile / install them manually
>>> 
>>> P.S. There is no 'rtwm' module in the tree; what is the exact error message
>>> where it was?
>> the problem was that if_rtwn.ko was not compiled!
>> all the others where, i.e. if_rtwn_[pci,usb].ko.
>> I added all of them to the config, and now it seems to work
>> 
>> so the problem is that the loadable module if_rtwn.ko is NOT compiled
>> by default, while all the others are,
>> what is the magic to have it compiled?
> From my experience you always have to specify all modules and the modules 
> they depend on. I for example had to specify this for zfs support in the 
> config file:
> 
> makeoptions MODULES_OVERRIDE="zfs opensolaris acl_nfs4"
> 
> I actually only wanted zfs, which depends on opensolaris which then again 
> depends on acl_nfs4 (probably because I sepcified nfs4 support in the config 
> file)
> 

not from my experience, the fact that all the other rtwn- where there means that
somewhere there is a missing directive.

> I only found out after a few tries. It's really not ideal, that module 
> dependencies are not resolved.
> But once you know about it, you can live with it :-)
> 
>> 
>> BTW, I tried this on RPI2, and now will try on an orangepi one.
> Is that the SDIO based internal WiFi? Let me know if it works!
> 

no, this is the cheapest orange one, with one usb, so it’s a wifi dongle.
my orange pi plus, with the onboard wifi, i managed to fry :-(

cheers,
danny

> Cheers,
> 
> Mat
> 
>>>>> On 30 Oct 2016, at 14:07, Daniel Braniss  wrote:
>>>>> 
>>>>> hi,
>>>>> between r30666 and r30808 i lost my wireless,
>>>> s/r30666/r306333/ and s/r30808/r308087/
>>>> 
>>>>> so reading UPDATE clarified why, I also did a mergemaster so now devd 
>>>>> et.all. seem to be in sync,
>>>>> but now devd complains that if_rtwn_usb depends on rtwm and there is no 
>>>>> rtwn, instead there are
>>>>> several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko
>>>>> 
>>>>> this is what the old urtwn has to say:
>>>>> ...
>>>>> Starting devd.
>>>>> wlan: <802.11 Link Layer>
>>>>> urtwn0 on uhub1
>>>>> urtwn0:  on usbus0
>>>>> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
>>>>> urtwn0: enabling 11n
>>>>> urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>>>>> urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 
>>>>> 24Mbps 36Mbps 48Mbps 54Mbps
>>>>> urtwn0: 1T1R
>>>>> urtwn0: 11ng MCS 20MHz
>>>>> urtwn0: MCS 0-7: 6.5Mbps - 65Mbps
>>>>> 
>>>>> please help
>>>>> 
>>>>> thanks,
>>>>>   danny
>>>>> 
>>>>> ___
>>>>> freebsd-current@freebsd.org mailing list
>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>>>> ___
>>>> freebsd-wirel...@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>>> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"
>> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
> 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwm -> rtwm

[Daniel Braniss]

> On 1 Nov 2016, at 23:13, Idwer Vollering  wrote:
> 
> 2016-10-31 20:37 GMT+01:00 Andriy Voskoboinyk  <mailto:a...@freebsd.org>>:
>> Sun, 30 Oct 2016 14:32:18 +0200 було написано Daniel Braniss
>> mailto:da...@cs.huji.ac.il>>:
>> 
>> Hi!
>> 
>> rtwn_usb(4) depends on rtwn(4) module; you can try to
> 
> These change(s) require you to manually run 'service netif start
> wlan', in order to have an (USB) device associate and configure an
> IP address.
> Is this change related:
> https://svnweb.freebsd.org/base/head/etc/devd.conf?r1=304504&r2=307529 
> <https://svnweb.freebsd.org/base/head/etc/devd.conf?r1=304504&r2=307529>
> ?

that is not my problem.
the problem was that the driver if_rtwn.ko was not available/compiled.
only when I added device rtwn to the config file, the missing driver was 
compiled.


> 
>> 1) add them to the kernel config;
>> 2) check / fix WITHOUT_MODULES and MODULES_OVERRIDE make.conf(5) variables
>> 3) compile / install them manually
>> 
>> P.S. There is no 'rtwm' module in the tree; what is the exact error message
>> where it was?
>> 
>> 
>>> 
>>>> On 30 Oct 2016, at 14:07, Daniel Braniss  wrote:
>>>> 
>>>> hi,
>>>> between r30666 and r30808 i lost my wireless,
>>> 
>>> s/r30666/r306333/ and s/r30808/r308087/
>>> 
>>>> so reading UPDATE clarified why, I also did a mergemaster so now devd
>>>> et.all. seem to be in sync,
>>>> but now devd complains that if_rtwn_usb depends on rtwm and there is no
>>>> rtwn, instead there are
>>>> several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko
>>>> 
>>>> this is what the old urtwn has to say:
>>>> ...
>>>> Starting devd.
>>>> wlan: <802.11 Link Layer>
>>>> urtwn0 on uhub1
>>>> urtwn0:  on usbus0
>>>> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
>>>> urtwn0: enabling 11n
>>>> urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>>>> urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps
>>>> 24Mbps 36Mbps 48Mbps 54Mbps
>>>> urtwn0: 1T1R
>>>> urtwn0: 11ng MCS 20MHz
>>>> urtwn0: MCS 0-7: 6.5Mbps - 65Mbps
>>>> 
>>>> please help
>>>> 
>>>> thanks,
>>>>danny
>>>> 
>>>> ___
>>>> freebsd-current@freebsd.org mailing list
>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>> To unsubscribe, send any mail to
>>>> "freebsd-current-unsubscr...@freebsd.org"
>>> 
>>> 
>>> ___
>>> freebsd-wirel...@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>>> To unsubscribe, send any mail to
>>> "freebsd-wireless-unsubscr...@freebsd.org"
>> 
>> ___
>> freebsd-wirel...@freebsd.org <mailto:freebsd-wirel...@freebsd.org> mailing 
>> list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless 
>> <https://lists.freebsd.org/mailman/listinfo/freebsd-wireless>
>> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org 
>> <mailto:freebsd-wireless-unsubscr...@freebsd.org>"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwm -> rtwm

[Daniel Braniss]

> On 31 Oct 2016, at 21:37, Andriy Voskoboinyk  wrote:
> 
> Sun, 30 Oct 2016 14:32:18 +0200 було написано Daniel Braniss 
> :
> 
> Hi!
> 
> rtwn_usb(4) depends on rtwn(4) module; you can try to
> 1) add them to the kernel config;
> 2) check / fix WITHOUT_MODULES and MODULES_OVERRIDE make.conf(5) variables
> 3) compile / install them manually
> 
> P.S. There is no 'rtwm' module in the tree; what is the exact error message
> where it was?

the problem was that if_rtwn.ko was not compiled!
all the others where, i.e. if_rtwn_[pci,usb].ko.
I added all of them to the config, and now it seems to work

so the problem is that the loadable module if_rtwn.ko is NOT compiled
by default, while all the others are, 
what is the magic to have it compiled?

BTW, I tried this on RPI2, and now will try on an orangepi one.

thanks,
    danny

> 
>> 
>>> On 30 Oct 2016, at 14:07, Daniel Braniss  wrote:
>>> 
>>> hi,
>>> between r30666 and r30808 i lost my wireless,
>> s/r30666/r306333/ and s/r30808/r308087/
>> 
>>> so reading UPDATE clarified why, I also did a mergemaster so now devd 
>>> et.all. seem to be in sync,
>>> but now devd complains that if_rtwn_usb depends on rtwm and there is no 
>>> rtwn, instead there are
>>> several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko
>>> 
>>> this is what the old urtwn has to say:
>>> ...
>>> Starting devd.
>>> wlan: <802.11 Link Layer>
>>> urtwn0 on uhub1
>>> urtwn0:  on usbus0
>>> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
>>> urtwn0: enabling 11n
>>> urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
>>> urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 
>>> 24Mbps 36Mbps 48Mbps 54Mbps
>>> urtwn0: 1T1R
>>> urtwn0: 11ng MCS 20MHz
>>> urtwn0: MCS 0-7: 6.5Mbps - 65Mbps
>>> 
>>> please help
>>> 
>>> thanks,
>>> danny
>>> 
>>> ___
>>> freebsd-current@freebsd.org mailing list
>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>> 
>> ___
>> freebsd-wirel...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-wireless
>> To unsubscribe, send any mail to "freebsd-wireless-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: urtwm -> rtwm

[Daniel Braniss]

> On 30 Oct 2016, at 14:07, Daniel Braniss  wrote:
> 
> hi,
> between r30666 and r30808 i lost my wireless,
s/r30666/r306333/ and s/r30808/r308087/

> so reading UPDATE clarified why, I also did a mergemaster so now devd et.all. 
> seem to be in sync,
> but now devd complains that if_rtwn_usb depends on rtwm and there is no rtwn, 
> instead there are
> several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko
> 
> this is what the old urtwn has to say:
> ...
> Starting devd.
> wlan: <802.11 Link Layer>
> urtwn0 on uhub1
> urtwn0:  on usbus0
> urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
> urtwn0: enabling 11n
> urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
> urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 
> 24Mbps 36Mbps 48Mbps 54Mbps
> urtwn0: 1T1R
> urtwn0: 11ng MCS 20MHz
> urtwn0: MCS 0-7: 6.5Mbps - 65Mbps
> 
> please help
> 
> thanks,
>   danny
> 
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

urtwm -> rtwm

[Daniel Braniss]

hi,
between r30666 and r30808 i lost my wireless,
so reading UPDATE clarified why, I also did a mergemaster so now devd et.all. 
seem to be in sync,
but now devd complains that if_rtwn_usb depends on rtwm and there is no rtwn, 
instead there are
several rtwn-rtl8…., the closest being rtwn-rt18188eufw.ko

this is what the old urtwn has to say:
...
Starting devd.
wlan: <802.11 Link Layer>
urtwn0 on uhub1
urtwn0:  on usbus0
urtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
urtwn0: enabling 11n
urtwn0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
urtwn0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 
36Mbps 48Mbps 54Mbps
urtwn0: 1T1R
urtwn0: 11ng MCS 20MHz
urtwn0: MCS 0-7: 6.5Mbps - 65Mbps

please help

thanks,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ZFS - Abyssal slow on copying

[Daniel Braniss]

> On 3 Oct 2016, at 12:30 PM, O. Hartmann  wrote:
> 
> Am Sun, 2 Oct 2016 15:30:41 -0400
> Allan Jude mailto:allanj...@freebsd.org>> schrieb:
> 
>> On 2016-10-02 15:25, O. Hartmann wrote:
>>> 
>>> Running 12-CURRENT (FreeBSD 12.0-CURRENT #32 r306579: Sun Oct  2 09:34:50 
>>> CEST 2016
>>> ), I have a NanoBSD setup which creates an image for a router device.
>>> 
>>> The problem I face is related to ZFS. The system has a system's SSD 
>>> (Samsung 850 Pro,
>>> 256GB) which has an UFS filesystem. Aditionally, I have also a backup and a 
>>> data HDD,
>>> both WD, one 3 TB WD RED Pro, on 4 TB WD RED (the backup device). Both the 
>>> sources for
>>> the NanoBSD and the object tree as well as the NANO_WORLDDIR are residing 
>>> on the 3 TB
>>> data drive. 
>>> 
>>> The box itself has 8 GB RAM. When it comes to create the memory disk, which 
>>> is ~ 1,3
>>> GB in size, the NanoBSD script starts creating the memory disk and then 
>>> installing
>>> world into this memory disk. And this part is a kind of abyssal in terms of 
>>> the speed.
>>> 
>>> The drive sounds like hell, the heads are moving rapidly. The copy speed is 
>>> incredibly
>>> slow compared to another box I usually use in the lab with UFS filesystem 
>>> only
>>> (different type of HDD).
>>> 
>>> The whole stuff the nanbsd is installed from and to is on a separate ZFS 
>>> partition,
>>> but in the same pool as everything else. When I first setup the new 
>>> partitions, I
>>> switched on deduplication, but I quickly deactivated it, because it had a 
>>> tremendous
>>> impact on the working speed and memory consumption on that box. But 
>>> something seems
>>> not right since then - as I initially described, the copy/initialisation
>>> speed/bandwith is abyssal. Well, I also fear that I did something wrong 
>>> when I firt
>>> initialised the HDD - there is this 125bytes/4k block discussion and I do 
>>> not know
>>> how to check whether I'm affected to that or not (or even causing the 
>>> problems) and
>>> how to check whether DEDUPLICATION is definitely OFF (apart from the usual 
>>> stuff list
>>> features via "zfs get all").
>>> 
>>> As an example: the nanbosd script takes ~ 1 minute to copy /boot/loader 
>>> from source to
>>> memory disk and the HDD makes sounds like hell and close to loosing the r/w 
>>> heads. On
>>> other boxes this task is done in a blink of an eye ...
>>> 
>>> Thanks for your patience,
>>> 
>>> Regards,
>>> oh
>>> 
>> 
>> Turning deduplication off, only stops new blocks from being
>> deduplicated. Any data written while deduplication was on, are still
>> deduplicated. You would need to zfs send | zfs recv, or
>> backup/destroy/restore to get the data back to normal.
>> 
>> If the drive is making that much noise, have you considered that the
>> drive might be failing?
>> 
> 
> Hello.
> 
> Might there be any hint I can investigate on that ZFS partition showing me 
> that the
> particular partition is still doing deduplication? If I wouldn't know that I 
> switch
> dedup on and later off, I would blame the OS instead. So, for further 
> forensik analysis
> in the future, it would be nice to know how to look at it - if it is doable 
> via simple
> checking the features of the ZFS partition ...
> 
> Thanks,
> oh 

not really an answer, but zpool has a nice command: history, it sometimes helps 
to find what and when
nfs commands where given.
 
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: rpi-b leds

[Daniel Braniss]

> On 23 Aug 2016, at 09:00, Daniel Braniss  wrote:
> 
>> 
>> On 23 Aug 2016, at 01:00, Luiz Otavio O Souza  wrote:
>> 
>> On 22 August 2016 at 08:55, Andrey Fesenko wrote:
>>> On Mon, Aug 22, 2016 at 1:29 PM, Daniel Braniss wrote:
>>>> Hi,
>>>> I see that now both leds on the rpi-2 are operational,
>>>> any chance it can happen on the rpi-b too?
>>>> 
>>> 
>>> A year or two ago, rpi-b had operational leds, it's make not working
>>> after rework fdt/std layer
>> 
>> I tested the leds on two different rpi-b and the leds are working.
>> Maybe you are talking about the b+ model ?
>> 
>> The ACT or OK led for the old boards (< b+) are wired to gpio 16. The
>> b+ has two leds, they are wired to pins 47 and 35.
>> 
>> For a quick fix, edit your dts and the leds will work.
>> 
>> Can you check the board revision for your rpi ? (sysctl hw.board.revision)
>> 
>> These are the ones I tested:
>> 
>> hw.board.revision: 3
>> hw.board.revision: 14
>> 
>> Tested with r301978.
> tested with revision 303422:
> hw.board.revision: 16
> 
> and it’s a b+
> 
> managed to get pin 35 to work, but not 47.
> 50% success!
> thanks,
>   danny
> 

maybe this can shed some light:

gpio0:  mem 0x20-0x2000af on simplebus0
gpio0: read-only pins: 46-53.
gpio0: reserved pins: 48-53.
gpiobus0:  on gpio0
gpioled0:  at pin 16 on gpiobus0
gpioled1:  at pin 47 on gpiobus0
gpioled2:  at pin 35 on gpiobus0
gpioled3:  at pin 6 on gpiobus0
gpioled4:  at pin 12 on gpiobus0
gpioled5:  at pin 13 on gpiobus0
gpiobus0: warning: pin 16 is already mapped
gpioled6:  at pin 22 on gpiobus0
gpioled7:  at pin 23 on gpiobus0
gpioled8:  at pin 24 on gpiobus0
gpioled9:  at pin 5 on gpiobus0
gpioc0:  on gpio0

>> 
>> 
>> Luiz
> 
> ___
> freebsd-current@freebsd.org <mailto:freebsd-current@freebsd.org> mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current 
> <https://lists.freebsd.org/mailman/listinfo/freebsd-current>
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org 
> <mailto:freebsd-current-unsubscr...@freebsd.org>"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: rpi-b leds

[Daniel Braniss]

> On 23 Aug 2016, at 01:00, Luiz Otavio O Souza  wrote:
> 
> On 22 August 2016 at 08:55, Andrey Fesenko wrote:
>> On Mon, Aug 22, 2016 at 1:29 PM, Daniel Braniss wrote:
>>> Hi,
>>> I see that now both leds on the rpi-2 are operational,
>>> any chance it can happen on the rpi-b too?
>>> 
>> 
>> A year or two ago, rpi-b had operational leds, it's make not working
>> after rework fdt/std layer
> 
> I tested the leds on two different rpi-b and the leds are working.
> Maybe you are talking about the b+ model ?
> 
> The ACT or OK led for the old boards (< b+) are wired to gpio 16. The
> b+ has two leds, they are wired to pins 47 and 35.
> 
> For a quick fix, edit your dts and the leds will work.
> 
> Can you check the board revision for your rpi ? (sysctl hw.board.revision)
> 
> These are the ones I tested:
> 
> hw.board.revision: 3
> hw.board.revision: 14
> 
> Tested with r301978.
tested with revision 303422:
hw.board.revision: 16

and it’s a b+

managed to get pin 35 to work, but not 47.
50% success!
thanks,
danny

> 
> 
> Luiz

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Wierd issues with wifi in hostap mode in FreeBSD 11

[Daniel Braniss]

> On 3 Aug 2016, at 14:52, Kurt Jaeger  wrote:
> 
> Hi!
> 
>> But wat is very strange for me is that I do not see ath0 device on ifconfig:
> 
> The listing of the hardware specific interfaces, like ath0 etc
> was removed in 11.
> 
> There's a sysctl for it now, I don't remember which one 8-(

sysctl net.wlan.devices


> 
> -- 
> p...@opsec.eu+49 171 3101372 4 years to 
> go !
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [CFT] ypldap testing against OpenLDAP and Microsoft Active Directory

[Daniel Braniss]

> On 15 Jun 2016, at 04:22, David Wolfskill  wrote:
> 
> On Tue, Jun 14, 2016 at 05:17:19PM -0700, Chris H wrote:
>> ...
>> Honestly, I think the best way to motivate people to do the right thing(tm)
>> Would be to remove Yellow Pages from the tree, entirely. :-)
>> It's been dead for *years*, and as you say, isn't safe, anyway..
>> 
> 
> "Safe" for what, precisely?
> 
> It's a lookup service.  It is not limited to looking up authentication
> information, and never has been.
> 
> And it's a mechanism that has been widely implemented.
> 
> The catchphrase "Tools, not policy" comes to mind.
> 
> Peace,
> david

probably this is a bit too late, but we have been using MIT’s DNS/Hesiod since 
the days
when:
ypserver not responding
was popular, and true, it’s not only for password/group.

my .5 cents

danny


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Daniel Braniss]

> On 29 Dec 2015, at 19:42, Adrian Chadd  wrote:
> 
> I'll go order one and take a crack at it soon.
> 
> (I saw this when looking at the r92su and realtek linux drivers - they
> do a whole bunch of extra endpoint gymnastics that we don't..)

great, let me know, and I can help out debugging.

danny

> 
> 
> -a
> 
> 
> On 29 December 2015 at 06:19, Kevin Lo  wrote:
>> On Tue, Dec 29, 2015 at 03:02:35PM +0100, Hans Petter Selasky wrote:
>>> On 12/29/15 14:00, Daniel Braniss wrote:
>>>> 
>>>>> On 29 Dec 2015, at 14:44, Hans Petter Selasky  wrote:
>>>>> 
>>>>> On 12/29/15 13:36, Daniel Braniss wrote:
>>>>>> 
>>>>> 
>>>>> Until /etc/devd/usb.conf is regenerated, you'll need to manually load the 
>>>>> kernel module for urtwn. Did you do that?
>>>>> 
>>>>> --HPS
>>>>> 
>>>> ok, set if_urtwn_load=yes
>>>> and now I get:
>>>> 
>>>> ugen0.4:  at usbus0
>>>> urtwn0:  on usbus0
>>>> urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
>>>> Fatal kernel mode data abort: 'Translation Fault (L1)' on write
>>>> trapframe: 0xda29fb88
>>>> FSR=0805, FAR=, spsr=6013
>>>> r0 =, r1 =, r2 =c0a72cb0, r3 =0165
>>>> r4 =c2cd, r5 =c0a86650, r6 =c2cd1a80, r7 =
>>>> r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20
>>>> r12=, ssp=da29fc18, slr=0004, pc =c0a3f7cc
>>>> 
>>>> [ thread pid 13 tid 100045 ]
>>>> Stopped at  ieee80211_ifdetach+0x4c:str r0, [r1]
>>>> db>
>>>> 
>>>> btw, as long as you are willing to help, I will keep testing,
>>>> in other words, i’m ok.
>>> 
>>> Hi Andriy,
>>> 
>>> Can you fix the crash above and verify this error patch?
>>> 
>>> Andriy:
>>> 
>>> After:
>>> usbd_transfer_unsetup(sc->sc_xfer, URTWN_N_TRANSFER);
>>> There is no need for:
>>>  usbd_transfer_drain(sc->sc_xfer[x]);
>> 
>> As I mentioned previously we don't support rtl8192eu.  One difference
>> between those is the the number of endpoints and its addresses.
>> 
>>> --HPS
>> ___
>> freebsd-...@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
>> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"
> ___
> freebsd-...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-arm
> To unsubscribe, send any mail to "freebsd-arm-unsubscr...@freebsd.org"

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Daniel Braniss]

> On 29 Dec 2015, at 14:44, Hans Petter Selasky  wrote:
> 
> On 12/29/15 13:36, Daniel Braniss wrote:
>> 
> 
> Until /etc/devd/usb.conf is regenerated, you'll need to manually load the 
> kernel module for urtwn. Did you do that?
> 
> --HPS
> 
ok, set if_urtwn_load=yes
and now I get:

ugen0.4:  at usbus0
urtwn0:  on usbus0
urtwn0: could not allocate USB transfers, err=USB_ERR_NO_PIPE
Fatal kernel mode data abort: 'Translation Fault (L1)' on write
trapframe: 0xda29fb88
FSR=0805, FAR=, spsr=6013
r0 =, r1 =, r2 =c0a72cb0, r3 =0165
r4 =c2cd, r5 =c0a86650, r6 =c2cd1a80, r7 =
r8 =c2cd1dd8, r9 =c2cd1a20, r10=c2a85dd0, r11=da29fc20
r12=, ssp=da29fc18, slr=0004, pc =c0a3f7cc

[ thread pid 13 tid 100045 ]
Stopped at  ieee80211_ifdetach+0x4c:str r0, [r1]
db> 

btw, as long as you are willing to help, I will keep testing,
in other words, i’m ok.

thanks,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Daniel Braniss]

> On 29 Dec 2015, at 14:31, Hans Petter Selasky  wrote:
> 
> On 12/29/15 13:26, Daniel Braniss wrote:
>> 
>>> On 29 Dec 2015, at 12:20, Hans Petter Selasky  wrote:
>>> 
>>> On 12/29/15 11:12, Daniel Braniss wrote:
>>>> 
>>>> https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c
>>>>   
>>>> <https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c>
>>>> and look at line 216
>>>> 
>>>> danny
>>> 
>>> Hi,
>>> 
>>> You should be able to get this device working by adding a device entry to:
>>> 
>>> src/sys/dev/usb/wlan/if_urtwn.c
>>> 
>>> Can you make a patch and PR for this, and I'll submit upstream. I recommend 
>>> you test using an 11-current kernel.
>>> 
>>> --HPS
>> 
>> clearly, I’m missing something, because it’s not working :-(
>> the only visible change is now
>> ugen0.4: <802.11n WLAN Adapter RealtekWireless N Nano USB A> at usbus0, 
>> cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
>> before it was
>> ugen0.4:  at usbus0, cfg=0 md=HOST 
>> spd=HIGH (480Mbps) pwr=ON (500mA)
>> 
>> rnd> svn diff
>> Index: usbdevs
>> ===
>> --- usbdevs (revision 291745)
>> +++ usbdevs (working copy)
>> @@ -1657,6 +1657,7 @@
>>  product DLINK2 RTL8192SU_1 0x3300  RTL8192SU
>>  product DLINK2 RTL8192SU_2 0x3302  RTL8192SU
>>  product DLINK2 DWA131A10x3303  DWA-131 A1
>> +product DLINK  DWA131  0x3319  DWA-131
>>  product DLINK2 DWA160A20x3a09  DWA-160 A2
>>  product DLINK2 DWA120  0x3a0c  DWA-120
>>  product DLINK2 DWA120_NF   0x3a0d  DWA-120 (no firmware)
>> Index: wlan/if_urtwn.c
>> ===
>> --- wlan/if_urtwn.c (revision 291745)
>> +++ wlan/if_urtwn.c (working copy)
>> @@ -116,6 +116,7 @@
>> URTWN_DEV(DLINK,RTL8192CU_2),
>> URTWN_DEV(DLINK,RTL8192CU_3),
>> URTWN_DEV(DLINK,DWA131B),
>> +   URTWN_DEV(DLINK,DWA131), // danny
>> URTWN_DEV(EDIMAX,   EW7811UN),
>> URTWN_DEV(EDIMAX,   RTL8192CU),
>> URTWN_DEV(FEIXUN,   RTL8188CU),
>> 
> 
> Hi,
> 
> You should use vendor RALINK (according to your usbconfig dump)
> 
> vendor RALINK 0x148f  Ralink Technology

you are confusing Vladimir’s with mine.
here is mine again:
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)

 bLength = 0x0012 
 bDescriptorType = 0x0001 
 bcdUSB = 0x0210 
 bDeviceClass = 0x  
 bDeviceSubClass = 0x 
 bDeviceProtocol = 0x 
 bMaxPacketSize0 = 0x0040 
 idVendor = 0x2001  <== D-LINK
 idProduct = 0x3319 
 bcdDevice = 0x0200 
 iManufacturer = 0x0001  
 iProduct = 0x0002  
 iSerialNumber = 0x0003  <00e04c01>
 bNumConfigurations = 0x0001 

danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Daniel Braniss]

> On 29 Dec 2015, at 12:20, Hans Petter Selasky  wrote:
> 
> On 12/29/15 11:12, Daniel Braniss wrote:
>> 
>> https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c
>>   
>> <https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c>
>> and look at line 216
>> 
>> danny
> 
> Hi,
> 
> You should be able to get this device working by adding a device entry to:
> 
> src/sys/dev/usb/wlan/if_urtwn.c
> 
> Can you make a patch and PR for this, and I'll submit upstream. I recommend 
> you test using an 11-current kernel.
> 
> --HPS

clearly, I’m missing something, because it’s not working :-(
the only visible change is now
ugen0.4: <802.11n WLAN Adapter RealtekWireless N Nano USB A> at usbus0, cfg=0 
md=HOST spd=HIGH (480Mbps) pwr=ON (500mA)
before it was
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)

rnd> svn diff
Index: usbdevs
===
--- usbdevs (revision 291745)
+++ usbdevs (working copy)
@@ -1657,6 +1657,7 @@
 product DLINK2 RTL8192SU_1 0x3300  RTL8192SU
 product DLINK2 RTL8192SU_2 0x3302  RTL8192SU
 product DLINK2 DWA131A10x3303  DWA-131 A1
+product DLINK  DWA131  0x3319  DWA-131
 product DLINK2 DWA160A20x3a09  DWA-160 A2
 product DLINK2 DWA120  0x3a0c  DWA-120
 product DLINK2 DWA120_NF   0x3a0d  DWA-120 (no firmware)
Index: wlan/if_urtwn.c
===
--- wlan/if_urtwn.c (revision 291745)
+++ wlan/if_urtwn.c (working copy)
@@ -116,6 +116,7 @@
URTWN_DEV(DLINK,RTL8192CU_2),
URTWN_DEV(DLINK,RTL8192CU_3),
URTWN_DEV(DLINK,DWA131B),
+   URTWN_DEV(DLINK,DWA131), // danny
URTWN_DEV(EDIMAX,   EW7811UN),
URTWN_DEV(EDIMAX,   RTL8192CU),
URTWN_DEV(FEIXUN,   RTL8188CU),

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Daniel Braniss]

> On 29 Dec 2015, at 11:53, Hans Petter Selasky  wrote:
> 
> On 12/29/15 10:42, Daniel Braniss wrote:
>> 
>>> On 29 Dec 2015, at 11:33, Vladimir Botka  wrote:
>>> 
>>> Hi Danny,
>>> 
>>> On Tue, 29 Dec 2015 11:16:27 +0200
>>> Daniel Braniss  wrote:
>>>> Hi All,
>>>> I have a working tp-link usb (realtek), but can’t get a d-link(also 
>>>> realtek) to work.
>>>> usbconfig:
>>>>ugen0.4:  at usbus0, cfg=0 md=HOST 
>>>> spd=HIGH (480Mbps) pwr=ON (500mA)
>>>> This is on a raspberry pi running a resent current.
>>>> cheers & season greetings,
>>>>danny
>>> 
>>> I've added freebsd-wireless list.
>>> 
>>> My 2 cents. It might be helpful to see more details about the adapters.
>>> For example:
>>> 
>>> # usbconfig -u 0 -a 7 dump_device_desc
>>> ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=0 md=HOST spd=HIGH
>>> (480Mbps) pwr=ON (450mA)
>>>  bLength = 0x0012
>>>  bDescriptorType = 0x0001
>>>  bcdUSB = 0x0200
>>>  bDeviceClass = 0x  
>>>  bDeviceSubClass = 0x
>>>  bDeviceProtocol = 0x
>>>  bMaxPacketSize0 = 0x0040
>>>  idVendor = 0x148f
>>>  idProduct = 0x5370
>>>  bcdDevice = 0x0101
>>>  iManufacturer = 0x0001  
>>>  iProduct = 0x0002  <802.11 n WLAN>
>>>  iSerialNumber = 0x0003  <1.0>
>>>  bNumConfigurations = 0x0001
>> 
>> 
>> so here it is:
>> root@:~ # usbconfig -u 0 -a 4 dump_device_desc
>> ugen0.4:  at usbus0, cfg=0 md=HOST 
>> spd=HIGH (480Mbps) pwr=ON (500mA)
>> 
>>   bLength = 0x0012
>>   bDescriptorType = 0x0001
>>   bcdUSB = 0x0210
>>   bDeviceClass = 0x  
>>   bDeviceSubClass = 0x
>>   bDeviceProtocol = 0x
>>   bMaxPacketSize0 = 0x0040
>>   idVendor = 0x2001
>>   idProduct = 0x3319
>>   bcdDevice = 0x0200
>>   iManufacturer = 0x0001  
>>   iProduct = 0x0002  
>>   iSerialNumber = 0x0003  <00e04c01>
>>   bNumConfigurations = 0x0001
>> 
>> thanks,
>>  danny
>> 
> 
> Did you google the idVendor and idProduct values and see if Linux has a 
> driver already?
> 
> —HPS
> 


https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c
 
<https://github.com/Mange/rtl8192eu-linux-driver/blob/master/os_dep/linux/usb_intf.c>
and look at line 216

danny


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: D-link wireless not detected

[Daniel Braniss]

> On 29 Dec 2015, at 11:33, Vladimir Botka  wrote:
> 
> Hi Danny,
> 
> On Tue, 29 Dec 2015 11:16:27 +0200
> Daniel Braniss  wrote:
>> Hi All,
>> I have a working tp-link usb (realtek), but can’t get a d-link(also realtek) 
>> to work.
>> usbconfig:
>>  ugen0.4:  at usbus0, cfg=0 md=HOST 
>> spd=HIGH (480Mbps) pwr=ON (500mA)
>> This is on a raspberry pi running a resent current.
>> cheers & season greetings,
>>  danny
> 
> I've added freebsd-wireless list.
> 
> My 2 cents. It might be helpful to see more details about the adapters.
> For example:
> 
> # usbconfig -u 0 -a 7 dump_device_desc
> ugen0.7: <802.11 n WLAN Ralink> at usbus0, cfg=0 md=HOST spd=HIGH
> (480Mbps) pwr=ON (450mA)
>  bLength = 0x0012 
>  bDescriptorType = 0x0001 
>  bcdUSB = 0x0200 
>  bDeviceClass = 0x  
>  bDeviceSubClass = 0x 
>  bDeviceProtocol = 0x 
>  bMaxPacketSize0 = 0x0040 
>  idVendor = 0x148f 
>  idProduct = 0x5370 
>  bcdDevice = 0x0101 
>  iManufacturer = 0x0001  
>  iProduct = 0x0002  <802.11 n WLAN>
>  iSerialNumber = 0x0003  <1.0>
>  bNumConfigurations = 0x0001


so here it is:
root@:~ # usbconfig -u 0 -a 4 dump_device_desc
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)

  bLength = 0x0012 
  bDescriptorType = 0x0001 
  bcdUSB = 0x0210 
  bDeviceClass = 0x  
  bDeviceSubClass = 0x 
  bDeviceProtocol = 0x 
  bMaxPacketSize0 = 0x0040 
  idVendor = 0x2001 
  idProduct = 0x3319 
  bcdDevice = 0x0200 
  iManufacturer = 0x0001  
  iProduct = 0x0002  
  iSerialNumber = 0x0003  <00e04c01>
  bNumConfigurations = 0x0001 

thanks,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

D-link wireless not detected

[Daniel Braniss]

Hi All,
I have a working tp-link usb (realtek), but can’t get a d-link(also realtek) to 
work.
usbconfig:
ugen0.4:  at usbus0, cfg=0 md=HOST 
spd=HIGH (480Mbps) pwr=ON (500mA)
This is on a raspberry pi running a resent current.

cheers & season greetings,
danny

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: OF_getprop weirdness - raspberry pi

[Daniel Braniss]

> On May 21, 2015, at 5:25 PM, Ian Lepore  wrote:
> 
> On Thu, 2015-05-21 at 09:41 +0300, Daniel Braniss wrote:
>> Hi,
>> I’m running current as of last week on a raspberry pi B.
>> 
>> i don’t know if this only related to arm, but this is what I have in my 
>> rpi-b.dts:
>>  ….
>>  spi0 {
>>   rfid0 {
>> compatible = "rfid,mfrc5";
>> spi-chipselect = <0>;
>> reset {
>>   compatible = "pcd-reset";
>>   gpios = <&gpio 6 2>;
>> };
>> lock {
>>  compatible = "lock-1";
>>  gpios = <&gpio 13 2>;
>> };
>> sense {
>>   compatible = "sense-1";
>>   gpios = <&gpio 19 1>;
>> }; 
>>   };
>> …
>> and a call to
>>  uint32_t data[3];
>>  
>>  OF_getprop(node, “gpios”, data, sizeof(data)); // node is ‘pcd-reset'
>>  returns:
>>  data[0]: 0x0300
>>  data[1]: 0x0600
>>  data[2]: 0x0200
>> 
>> which looks to me that it’s in the wrong endian?
>> 
>> cheers,
>>  danny
> 
> FDT data is always big-endian, use OF_getencprop() to unpack it to host
> format.
> 

thanks!
is there (apart from the source), some man pages, doc? so far I found outdated,
or incomplete info.

danny

> -- Ian

___
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"

OF_getprop weirdness - raspberry pi

[Daniel Braniss]

Hi,
I’m running current as of last week on a raspberry pi B.

i don’t know if this only related to arm, but this is what I have in my 
rpi-b.dts:
….
spi0 {
 rfid0 {
   compatible = "rfid,mfrc5";
   spi-chipselect = <0>;
   reset {
 compatible = "pcd-reset";
 gpios = <&gpio 6 2>;
   };
   lock {
compatible = "lock-1";
gpios = <&gpio 13 2>;
   };
   sense {
 compatible = "sense-1";
 gpios = <&gpio 19 1>;
   }; 
 };
…
and a call to
uint32_t data[3];

OF_getprop(node, “gpios”, data, sizeof(data)); // node is ‘pcd-reset'
returns:
data[0]: 0x0300
data[1]: 0x0600
data[2]: 0x0200

which looks to me that it’s in the wrong endian?

cheers,
danny

___
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: Some NFS server V4 questions

[Daniel Braniss]

> On Oct 26, 2014, at 10:48 AM, Beeblebrox  wrote:
> 
> Sorry guys, we have a considerable time-zone difference.
> 
>>> It appears that the sysctl must be set before mountd, nfsd are
>>> started to take effect. (Or they must be restarted after it is set.)
> I had apparently re-started nfsd but not mountd. This time re-starting both 
> and launching the PXE client fails at mount_root stage as expected:
> exec /sbin/init: error 43
> exec /rescue/init: error 43
> panic: no init
> 
> One cannot set "sysctl vfs.nfsd.server_min_nfsvers=4" until one of 
> mountd/nfsd is started however, otherwise it gives an error. I have not 
> tried, but I suppose this error does not happen when placeed in 
> /etc/sysctl.conf?
> sysctl: unknown oid 'vfs.nfsd.server_min_nfsvers': No such file or directory
> 
>>> Maybe it was the talk about getting rid of the oldnfs stuff that
>>> made you think V2, 3 were going away?
> Yes, that was it and I obviously misunderstood that thread.
> 
> What's the max NFS version that supports mount_root from PXE clients then? As 
> I recall, this would be V3. However, root is consistently being mounted as V2.

to get pxeboot to do v3, add:
boot-nfsroot-options=“nfsv3”
to /boot/loader.conf

> The fstab for diskless clients:
> 192.168.2.1:/data/amd64 /   nfs ro,nfsv30  0
> 192.168.2.1:/usr/local /usr/local nfs   ro,nfsv40  0
> 192.168.2.1:/home   /home   nfs rw,nfsv4,hard,intr  0  0
> 
> nfsstat shows "/" as NFSV2, while the other two are NFSV4. Changing fstab 
> entry to nfsv4 for root gives same result.
> I tried set "sysctl vfs.nfsd.server_min_nfsvers=3" and I get the same 
> mount_root error as when this was set to 4. Im I missing something? It does 
> not seem that "vfs.nfsd.server_min_nfsvers" will be of much use to me, unless 
> I can get > V2 to mount as root.
> 
> Regards.
> 
> 
> 
> 
> -
> FreeBSD-11-current_amd64_root-on-zfs_RadeonKMS
> --
> View this message in context: 
> http://freebsd.1045724.n5.nabble.com/Some-NFS-server-V4-questions-tp5959433p5959595.html
> Sent from the freebsd-current mailing list archive at Nabble.com.
> ___
> 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"

___
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: nscd not caching

[Daniel Braniss]

On Aug 18, 2014, at 10:42 AM, Eggert, Lars  wrote:

> Hi,
> 
> On 2014-8-17, at 18:10, Adam McDougall  wrote:
>> We were using +: type entries in the local password and group
>> tables and I believe we used an unmodified /etc/nsswitch.conf (excluding
>> cache lines while testing nscd):
> 
> I tried that setup too, and it doesn't seem to be caching any NIS lookups 
> either.
> 
> The current NIS server is 25ms away, which is a pain. I'm trying to get a 
> local slave set up, which will make the need for nscd go away, but it would 
> sure be nice if it worked in the meantime.
> 
>> At our site, we never had enough load to outright require nscd on
>> FreeBSD, although there were some areas where caching had a usability
>> benefit.
> 
> Load is not an issue, latency is (see above).

I know that this a bit late but have you ever considered Hesiod? it uses 
DNS/txt.
we have been using it since the days when BSDi had no NIS support and haven’t
seen a ypserver not responding since :-)

danny

___
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: FreeBSD Quarterly Status Report - Second Quarter 2014

[Daniel Braniss]

On Jul 26, 2014, at 5:46 AM, Cy Schubert  wrote:

> In message <20140725211249.ga3...@brick.home>, Edward Tomasz 
> =?utf-8?Q?Napiera=
> C5=82a?= writes:
>> On 0725T1019, Cy Schubert wrote:
>>> In message <20140724183353.gl1...@hub.freebsd.org>, Glen Barber writes:
 New Automounter
 
   Contact: Edward Tomasz Napieral/a 
 
   Deficiencies in the current automounter, amd(8), are a recurring
   problem reported by many FreeBSD users. A new automounter is being
   developed to address these concerns.
 
   The automounter is a cleanroom implementation of functionality
   available in most other Unix systems, using proper kernel support
   implemented via an autofs filesystem. The automounter supports a
   standard map format, and will integrate with the Lightweight Directory
   Access Protocol (LDAP) service.
>>> 
>>> Will it also integrate with NIS (as SunOS and Solaris do)? FreeBSD's amd 
>>> currently integrates with NIS as well.
>> 

and  hesiod?
i can help with the testing
danny

>> It's just a matter of testing, apart from a trivial shell script.
>> Would you be able to help me with this?
>> 
> 
> 
> Sure! Just point me in the direction of the patches.
> 
> 
> -- 
> Cheers,
> Cy Schubert 
> FreeBSD UNIX: Web:  http://www.FreeBSD.org
> 
>   The need of the many outweighs the greed of the few.
> 
> 
> ___
> freebsd-sta...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-stable
> To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

___
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: keyboard break to debugger broken?

[Daniel Braniss]

On Jul 5, 2014, at 1:33 PM, John-Mark Gurney  wrote:

> Peter Jeremy wrote this message on Fri, Jul 04, 2014 at 21:27 +1000:
>> On 2014-Jul-04 02:28:48 -0700, John-Mark Gurney  wrote:
>>> So, I recently tried to break into the debugger w/ the various key
>>> sequences that I know about, and none of them worked... I've tried
>>> CTRL-ESC, ALT-ESC, CTRL-ALT-ESC, CTRL-PRTSCR, ALT-PRTSCR and
>>> CTRL-ALT-PRTSCR, and many other different ones...   I've verified that
>>> I can sysctl debug.kdb.enter=1 to enter the debugger, and the
>>> CTRL-ALT-PAUSE works to suspend the machine, and CTRL-ALT-DEL works
>>> to reboot...
>>> 
>>> Does anyone know if this works?
>> 
>> It works for me on 10.0.  Do you have debug.kdb.break_to_debugger=1
>> and hw.syscons.kbd_debug=1 (if you're using syscons)?
> 
> Turns out I didn't... and you didn't need to...  emaste helped me
> the other night discover this..  Apparently rwatson changed this and
> the docs never got updated...  I saw BREAK_TO_DEBUGGER, bug it was
> documented as being *serial* only, not syscons...
> 
> I've updated NOTES and added an entry for defaults/loader.conf, but
> more docs need to be updated that BREAK_TO_DEBUGGER or the tunable
> or sysctl needs to be set before if works..
> 

I don’t know about 10/11 but 9.3 (and probably late 9.2) introduced console_port
which silently overrides the hint.uart.n.flags=0x10 to set which serial port is
the ‘console’, in my case I have several platforms (mainly sunfire’s from sun) 
that only
have uart1 available.
somehow, i have the feeling that getting the serial console (needed to run 
serial-over-lab) to
work is getting more in the region of magic than technology.
please, some of us really need the serial console to work so that we can rescue 
servers when
all else fails.

thanks,
danny


> -- 
>  John-Mark Gurney Voice: +1 415 225 5579
> 
> "All that I will do, has been done, All that I have, has not."
> ___
> 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"

___
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: files disappearing from ls on NFS

[Daniel Braniss]

> Hartmut Brandt wrote:
> > On Fri, 3 May 2013, Daniel Braniss wrote:
> > 
> > DB>I don't know about current, but on 9.1-stable, the nfsstat -m only
> > works
> > DB>for root! nfsstat can be run by anybody.
> > 
> > Same for current. It silently prints nothing. Took me some time
> > to figure out I should try as root...
> > 
> Yea, I suppose it should either be opened up to non-root (see previous post)
> or "only works as root" should be documented.
> 
I have no strong opinios either, though security by obscurity was never my 
favorit.
It should at least have said 'permition denied'.

cheers,
danny

> rick
> 
> > harti


___
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: files disappearing from ls on NFS

[Daniel Braniss]

> Hartmut Brandt wrote:
> > Hi,
> > 
> > I've updated one of my -current machines this week (previous update
> > was in
> > february). Now I see a strange effect (it seems only on NFS mounts):
> > ls or
> > even echo * will list only some files (strange enough the first files
> > from
> > the normal, alphabetically ordered list). If I change something in the
> > directory (delete a file or create a new one) for some time the
> > complete
> > listing will appear but after sime time (seconds to a minute or so)
> > again
> > only part of the files is listed.
> > 
> > A ktrace on ls /usr/src/lib/libc/gen shows that getdirentries is
> > called
> > only once (returning 4096). For a full listing getdirentries is called
> > 5
> > times with the last returning 0.
> > 
> > I can still open files that are not listed if I know their name,
> > though.
> > 
> > The NFS server is a Windows 2008 server with an OpenText NFS Server
> > which
> > works without problems to all the other FreeBSD machines.
> > 
> > So what could that be?
> > 
> Someone else reported missing files returned via "ls" recently, when
> they used a small readdirsize (below 8K). I haven't yet had a change to try
> and reproduce it or do any snooping around.
> 
> There haven't been any recent changes to readdir in the NFS client,
> except a trivial one that adds a check for vnode type being VDIR,
> so I don't see that it can be a recent NFS change.
> 
> If you can increase the readdirsize, try that to see if it avoids
> the problem. "nfsstat -m" shows you what the mount options end up
> being after doing the mount. The server might be limiting the readdirsize
> to 4K, so you should check, even if you specify a large value for
> the mount.

I don't know about current, but on 9.1-stable, the nfsstat -m only works
for root! nfsstat can be run by anybody.

> 
> rick
> 
> > Regards,
> > harti
> > ___
> > 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"
> ___
> 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"
> 


___
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: mounting root from NFS via ROOTDEVNAME

[Daniel Braniss]

> On Jan 31, 2013, at 12:53, Andre Oppermann 
>  wrote:
> > The interface doesn't have a name during loader stage.  The kernel
> > finds the interface to use based on the MAC address.  You should
> > set boot.netif.hwaddr as well in the kernel environment.
> 
> Done, no change. Here is what's in my loader environment:
> 
> boot.netif.netmask   255.255.255.0
> boot.netif.gateway   10.11.12.13
> boot.nfsroot.server  10.11.12.13
> boot.nfsroot.path/usr/home/elars/dst
> boot.netif.ip10.11.12.15
> boot.netif.name  em4
> boot.netif.hwaddrxx:xx:xx:xx:xx:xx
> vfs.root.mountfrom   nfs:10.11.12.13:/usr/home/elars/dst
> 
> And here is what I see during boot:
> 
> Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []...
> mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ...
> Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19.
> 
> Lars

a shot in the dark, but is /usr/home/elars/dst properly exported?

danny



___
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: [HEADSUP] zfs root pool mounting

[Daniel Braniss]

> 
> Recently some changes were made to how a root pool is opened for root 
> filesystem
> mounting.  Previously the root pool had to be present in zpool.cache.  Now it 
> is
> automatically discovered by probing available GEOM providers.
> The new scheme is believed to be more flexible.  For example, it allows to 
> prepare
> a new root pool at one system, then export it and then boot from it on a new
> system without doing any extra/magical steps with zpool.cache.  It could also 
> be
> convenient after zpool split and in some other situations.
> 
> The change was introduced via multiple commits, the latest relevant revision 
> in
> head is r243502.  The changes are partially MFC-ed, the remaining parts are
> scheduled to be MFC-ed soon.
> 
> I have received a report that the change caused a problem with booting on at 
> least
> one system.  The problem has been identified as an issue in local environment 
> and
> has been fixed.  Please read on to see if you might be affected when you 
> upgrade,
> so that you can avoid any unnecessary surprises.
> 
> You might be affected if you ever had a pool named the same as your current 
> root
> pool.  And you still have any disks connected to your system that belonged to 
> that
> pool (in whole or via some partitions).  And that pool was never properly
> destroyed using zpool destroy, but merely abandoned (its disks
> re-purposed/re-partitioned/reused).
> 
> If all of the above are true, then I recommend that you run 'zdb -l ' 
> for
> all suspect disks and their partitions (or just all disks and partitions).  If
> this command reports at least one valid ZFS label for a disk or a partition 
> that
> do not belong to any current pool, then the problem may affect you.
> 
> The best course is to remove the offending labels.
> 
> If you are affected, please follow up to this email.

GREATE
in a diskless environment, /boot is read only, and the zpool.cache issue
has been bothering me ever since, there was no way (and I tried) to re route it.

thanks,
danny



___
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: compiler info in kernel identification string

[Daniel Braniss]

> 
> This is starting to turn into a bikeshed, but anyway...
> 
> on 16/11/2012 12:00 Daniel Braniss said the following:
> > the question as to what compiler was used to compile the kernel is a bit of 
> > an
> > oxymoron, since the kernel is made up of many different modules, which get 
> > compiled
> > either by different compilers, or different compiler flags.
> 
> The canonical way to compile a kernel is to use buildkernel and compile 
> modules

this does not guarantee uniformity, just look at the output it produces and 
you will see
different compilers/assemblers/scripts/flags

> along with the kernel.  Other configurations are supported too, of course.
> 

> > since the compiler does 'sign' the modules it compiles (and clang 
> > will/should
> > do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
> > file(1) could be modified to provide it, or config -x (8) ...
> 
> The key word in your note about clang is 'soon' as in 'not yet'.
Dimitry wrote that he will handle it :-)

> 
> Besides, when I see a bug report with a dmesg *I* want to immediately know 
> what
> compiler was used there.
today it's clang vs. gcc -- transition time --, but again it's only part of 
the story,
and soon it will only be noise.

> 
> > IMHO, the only meaningfull information added to uname was the svn/git(and 
> > hopefully hg) rev. version.
> 
> 
> -- 
> 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: compiler info in kernel identification string

[Daniel Braniss]

> on 16/11/2012 11:20 Erik Cederstrand said the following:
> > Den 16/11/2012 kl. 08.34 skrev Andriy Gapon :
> > 
> >> on 16/11/2012 01:09 Dimitry Andric said the following:
> >>> And as I remarked in another reply, now that I have thought about it a 
> >>> bit, I would much rather see this information moved to a sysctl or dmesg 
> >>> line, than in uname.  With the happy side effect that no existing uname 
> >>> parsers would be confused!
> >> 
> >> I would still like to have at least compiler's "base name" or type or
> >> something in uname.
> > 
> > This has been brought up before, but what about putting all this in a
> > separate file, e.g. /etc/buildinfo?
> 
> There is a chance this file could be out of sync with kernel.
> 
> > At least I'd like this to be configurable. I'm trying to get FreeBSD code in
> > a shape where it can optionally produce deterministic binaries from two
> 
> This is a very good goal.  I also would like to see it achieved.
> 
> > different builds (i.e. comparable with md5) as long as the binaries are
> > functionally equivalent, and "irrelevant" info like compiler version,
> 
> I agree about the following items, but not about compilers / compiler 
> versions.
> Different compilers can (and do) produce different binaries already (and
> sometimes bugs).
> While, indeed, time of compilation should not affect the binaries (unless the
> phase of the Moon plays a role).
> 
> > hostname, username, timestamp, absolute path etc. are a nuisance if they
> > can't be turned off with -fno-ident, -frandom-seed, -DSTRIP_FBSDID, ar -D 
> > and
> > the like.
> 

the question as to what compiler was used to compile the kernel is a bit of an
oxymoron, since the kernel is made up of many different modules, which get 
compiled
either by different compilers, or different compiler flags.

since the compiler does 'sign' the modules it compiles (and clang will/should
do it soon: http://llvm.org/bugs/show_bug.cgi?id=7292) some tool like
file(1) could be modified to provide it, or config -x (8) ...

IMHO, the only meaningfull information added to uname was the svn/git(and 
hopefully hg) rev. version.

as usual, my 3c,
danny



___
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: compiler info in kernel identification string

[Daniel Braniss]

> Hello,
> 
> avg@ suggested to include compiler version in the kernel so that it's
> present in uname (and one can easly tell what was used to compile it).
> 
> Here is my attempt:
> http://people.freebsd.org/~mjg/patches/newvers-compiler.diff
> 
> Basically adds compiler name and version/revision after revision of
> system sources.
> 
> Sample output from dirty git sources:
> gcc:
> FreeBSD 10.0-CURRENT #7 r242962=264d569-dirty(gcc-4.2.1-20070831): Wed
> Nov 14 00:11:51 CET 2012
> 
> clang:
> FreeBSD 10.0-CURRENT #8 r242962=264d569-dirty(clang-r162107): Wed Nov 14
> 00:12:26 CET 2012
> 
> Sample output from svn with gcc:
> FreeBSD 10.0-CURRENT #1 r243006:243007M(gcc-4.2.1-20070831): Wed Nov 14
> 00:41:23 CET 2012
> 
> I have no strong opinions on format, I just want this information easly
> accessible.
> 
> Comments?

in the old days (I'm talking before C :-) I remmeber one compiler
putting such info in the code it produced, I wonder if that's the case
with gcc/clang, and if so it would be nice if file(1) could show it.
my 3c,
danny



___
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: PORTS_MODULES

[Daniel Braniss]

> Howdy,
> 
> This is an FYI to let people know about a really nice feature for those
> that have ports installed which include kernel modules. You can place a
> list in /etc/src.conf like this:
> 
> PORTS_MODULES=  emulators/virtualbox-ose-kmod sysutils/fusefs-kmod
> x11/nvidia-driver
> 
> which will cause those modules to be built and installed with all the
> proper matching stuff at the same time as buildkernel and installkernel.
> 
> This feature has existed for a while, but has had "issues." Thanks to a
> team effort it's a lot more robust now, and ready for prime time (in
> HEAD, and the -STABLE branches for now, soon to be in 9.1-RELEASE).
> 
> Enjoy,
> 
> Doug

nice!
does it also work when cross-compiling? ie, using an amd64-freebsd-8.3 kernel
to compile for i386-freebsd-8.2

thanks,
danny


___
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: NICs not in GENERIC

[Daniel Braniss]

> On Tue, Feb 21, 2012 at 03:56:56PM +0100, Alexander Leidinger wrote:
> > Hi,
> > 
> > is there a specific reason that the following NICs are not (or shall  
> > not be) in GENERIC (at least on i386)?
> 
> No specific reason for these two:
> 
> >  - if_cxgb
> >  - if_cxgbe
> 
> But I do prefer to load them as modules (and as late as possible --
> after sysctl.conf has been processed and any nmbclusters, nmbjumboXX
> settings have taken affect).
> 
> Other than root over NFS, is there any reason to have NIC drivers in
> GENERIC?

even with root over NFS (aka diskless/dataless) you can load the nic module via
loader.conf.

> 
> Regards,
> Navdeep
> ___
> 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"
> 


___
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: Announcing Emulex 10G Ethernet NIC driver availability

[Daniel Braniss]

> On Tue, Feb 7, 2012 at 10:39 PM, Matthew Jacob  wrote:
> > Any plans for iscsi, fcoe?
> >
> >> Hi All,
> >>
> >>
> >>
> >> Please find the 10Gb Ethernet NIC driver for Emulex OneConnect
> >> (BladeEngine) and Lancer family of network adapters at
> 
> Yes, Emulex is working on a native FC/FCoE driver (initiator and/or
> target) that should be ready for wider testing in the next 3-4 months.
> Note this driver only supports the more recent devices such as the
> 10GbE FCoE CNA and 16G FC HBA (i.e. LPe1600x).

any plans for iSCSI?



___
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: Data corruption over NFS in -current

[Daniel Braniss]

> 
> --+QahgC5+KEYLbs62
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> 
> Stefan Bethke wrote on Wed, Jan 11, 2012 at 07:14:44PM +0100: 
> > Am 11.01.2012 um 17:57 schrieb Martin Cracauer:
> > 
> > > I'm sorry for the unspecific bug report but I thought a heads-up is
> > > better than none.
> > > 
> > > $ uname -a
> > > FreeBSD wings.cons.org 10.0-CURRENT FreeBSD 10.0-CURRENT #2: Wed Dec
> > > 28 12:19:21 EST 2011
> > > craca...@wings.cons.org:/usr/src/sys/amd64/compile/WINGS  amd64
> > 
> > I'm sure Rick will want to know which NFS version, which client code 
> > (default new code I'm assuming) and which mount options...
> 
> It's all default both in fstab and as reported by mount(8).
> 
> This is a diskless PXE boot but the mount affected (usr) is not the
> root filesystem, so this should come in via fstab.
> 
> BTW, my /usr/ports is another mount so the corruption is cross-mount
> (garbage from /usr/ports entering /usr).
> 
> Appending nfsstat output.
> 
> I am re-running things contiguously to see how reproducible this is.
> This machine was recently updated from a -current almost a year old,
> so it's its first time with the new NFS client code.
> 
> Martin
I've seen problems, but they were always related to programs running out of 
resources and not reporting it correctly - in dataless specialy if running
out of memory and there is no swap available.
btw, most of my servers are dataless (they boot via PXE but have local
swap, var, etc)

hth,
danny


> 
> > > I see filesystem corruption on NFS filesystems here.  I am running a
> > > heavy shellscript that is noodling around with ascii files assembling
> > > them with awk and whatnot.  Some actions are concurrent with up to 21
> > > forks doing full-CPU load scripting.  This machine is a K8 with a
> > > total of 8 cores, diskless NFS and memory filesystem for /tmp.
> > > 
> > > I observe two problems:
> > > - for no reason whatsoever, some files change from my 
> > >  (user/group) cracauer/wheel to root/cracauer
> > > - the same files will later be corrupted.  The beginning of the file
> > >  is normal but then it has what looks like parts of /usr/ports,
> > >  including our CVS files and binary junk, mostly zeros
> > > 
> > > I did do some ports building lately but not at the same time that this
> > > problem manifested itself.  I speculate some ports blocks were still
> > > resident in the filesystem buffer cache.
> > > 
> > > Server is Linux.
> > > 
> > > Martin
> > > -- 
> > > %%%
> > > Martin Cracauerhttp://www.cons.org/cracauer/
> > > ___
> > > 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"
> > 
> > -- 
> > Stefan BethkeFon +49 151 14070811
> > 
> > 
> > 
> 
> -- 
> %%%
> Martin Cracauerhttp://www.cons.org/cracauer/
> 
> --+QahgC5+KEYLbs62
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: attachment; filename=l
> 
> Client Info:
> Rpc Counts:
>   Getattr   SetattrLookup  Readlink  Read WriteCreate
> Remove
>  94392942513117   3637266  2577  40227237   2824593333832
> 304567
>Rename  Link   Symlink Mkdir Rmdir   Readdir  RdirPlus
> Access
> 32522  5121  4856 20363 13954179035 0   
> 3534382
> MknodFsstatFsinfo  PathConfCommit
> 5  21127240 3  2999521782
> Rpc Info:
>  TimedOut   Invalid X Replies   Retries  Requests
> 0 0 0 0 167678419
> Cache Info:
> Attr HitsMisses Lkup HitsMisses BioR HitsMisses BioW Hits
> Misses
> 1933340911  73265447 1123380719   3636242  90975094450509   4917135   
> 2824593
> BioRLHitsMisses BioD HitsMisses DirE HitsMisses Accs Hits
> Misses
>  54732346  2577599049142917352394 0 733726346   
> 3534382
> 
> Server Info:
>   Getattr   SetattrLookup  Readlink  Read WriteCreate
> Remove
> 0 0 0 0 0 0 0 > 0
>Rename  Link   Symlink Mkdir Rmdir   Readdir  RdirPlus
> Access
> 0 0 0 0 0 0 0 > 0
> MknodFsstatFsinfo  PathConfCommit
> 0 0 0 0 0
> Server Ret-Failed
> 0
> Server Faults
> 0
> Server Cache Stats:
>Inprog  Idem  Non-idemMisses
> 0 0 0 0
> Server Write Gathering:
>  WriteOps  WriteRPC   Opsaved
> 0 0 0
> 
> --+QahgC5+KEYLbs62
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7b

Re: rc.d script to load kernel modules

[Daniel Braniss]

> On 6/12/11 11:20 PM, Daniel Braniss wrote:
> >> On 6/12/2011 1:56 AM, Jason Hellenthal wrote:
> >>
> >>> Cutting modules out of the kernel in general does help speed up booting
> >>> but loading those same modules later in the boot process will just lead
> >>> you back to the same boot time.
> >> Loading modules via loader.conf is many times slower than doing it from
> >> disk after the system is partially booted. (As in, 2-3 seconds per
> >> module vs. nearly instantaneous for all 6.)
> >>
> >> I didn't offer my list as an example of what to do, I offered it as a
> >> syntax example. I would of course expect people to use appropriate
> >> discretion to load things in loader.conf that are necessary for boot.
> >> (Of course, the fact that people can easily get this wrong is a strike
> >> against the technique.)
> >>
> >> There is no point in having an _enable for this script because if the
> >> kld_list is empty, nothing happens.
> >>
> > Doug's solution is what we have been using for a very long time!
> >
> > the loader.conf solution is not practical when it's shared among many
> > hosts -like here where most of the hosts are dataless-, so, moving the not
> > essential ones to rc.conf was the obvious solution.
> 
> what would be REALLY cool would be the ability to make loader.conf 
> have some sort of conditional
> clauses..
> 
> e.g. if MAC== 01:02:03:04:05:06
>blah
in case of diskless, this is solved by having a private (per host/per 
network/etc)
rc.conf.

in case you use dhcp/pxeboot, you can concatenate several rc.confs to get
one tailored.

danny


___
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: rc.d script to load kernel modules

[Daniel Braniss]

> On 6/12/2011 1:56 AM, Jason Hellenthal wrote:
> 
> > Cutting modules out of the kernel in general does help speed up booting
> > but loading those same modules later in the boot process will just lead
> > you back to the same boot time.
> 
> Loading modules via loader.conf is many times slower than doing it from 
> disk after the system is partially booted. (As in, 2-3 seconds per 
> module vs. nearly instantaneous for all 6.)
> 
> I didn't offer my list as an example of what to do, I offered it as a 
> syntax example. I would of course expect people to use appropriate 
> discretion to load things in loader.conf that are necessary for boot. 
> (Of course, the fact that people can easily get this wrong is a strike 
> against the technique.)
> 
> There is no point in having an _enable for this script because if the 
> kld_list is empty, nothing happens.
> 
Doug's solution is what we have been using for a very long time!

the loader.conf solution is not practical when it's shared among many
hosts -like here where most of the hosts are dataless-, so, moving the not
essential ones to rc.conf was the obvious solution.

my .5

danny



___
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: Switch from legacy ata(4) to CAM-based ATA

[Daniel Braniss]

> Daniel Braniss wrote:
> >> Bruce Cran wrote:
> >>> On Wed, 20 Apr 2011 12:57:47 +0300
> >>> Alexander Motin  wrote:
> >>>
> >>>> If somebody has any problems with new ATA stack, please repeat your
> >>>> tests with latest HEAD code and contact me if problem is still there.
> >>>> Next three weeks before BSDCan I am going to dedicate to fixing
> >>>> possibly remaining issues.
> >>> I've not checked recently with -current, but at least on the
> >>> latest 8-stable there's a problem with using ATA_CAM on Xen: during boot
> >>> there's a pause for a minute after which "run_interrupt_driven_hooks:
> >>> still waiting after 60 seconds for xpt_config" is displayed.
> >> Verbose dmesg from the fresh system would be appreciated.
> >>
> > I have a similar problem, but it's under 8.2-stable:
should have been:
s/8.2-stable/real hardware/

> This should fix your problem:
> http://svn.freebsd.org/changeset/base/220920
> 

indeed, it worked!
it would be interested to know what's at the other end of this chip.
thanks,
danny


___
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: Switch from legacy ata(4) to CAM-based ATA

[Daniel Braniss]

> Bruce Cran wrote:
> > On Wed, 20 Apr 2011 12:57:47 +0300
> > Alexander Motin  wrote:
> > 
> >> If somebody has any problems with new ATA stack, please repeat your
> >> tests with latest HEAD code and contact me if problem is still there.
> >> Next three weeks before BSDCan I am going to dedicate to fixing
> >> possibly remaining issues.
> > 
> > I've not checked recently with -current, but at least on the
> > latest 8-stable there's a problem with using ATA_CAM on Xen: during boot
> > there's a pause for a minute after which "run_interrupt_driven_hooks:
> > still waiting after 60 seconds for xpt_config" is displayed.
> 
> Verbose dmesg from the fresh system would be appreciated.
> 
I have a similar problem, but it's under 8.2-stable:
...
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 8.2-STABLE #43 r4876: Fri Mar 25 12:00:48 IST 2011
danny@rnd:/home/obj/rnd/r+d/stable/8/sys/HUJI amd64
Preloaded elf kernel "/boot/kernel/kernel" at 0x80f08000.
Preloaded elf obj module "/boot/kernel/geom_stripe.ko" at 0x80f081a8.
Preloaded elf obj module "/boot/kernel/ahci.ko" at 0x80f087d8.
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 2261016004 Hz
CPU: Intel(R) Xeon(R) CPU   E5507  @ 2.27GHz (2261.02-MHz K8-class CPU)
  Origin = "GenuineIntel"  Id = 0x106a5  Family = 6  Model = 1a  Stepping = 5
  
Features=0xbfebfbff
  AMD Features=0x28100800
  AMD Features2=0x1
  TSC: P-state invariant
real memory  = 25769803776 (24576 MB)
...
ums0:  on usbus3
ums0: 3 buttons and [Z] coordinates ID=0
ata2: p0: SATA connect time=0ms status=0113
ata2: p1: SATA connect timeout status=
ata2: reset tp1 mask=03 ostat0=00 ostat1=00
ata2: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata2: reset tp2 stat0=00 stat1=00 devices=0x3
(aprobe0:ata2:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata2:0:1:0): CAM status: Command timeout
(aprobe0:ata2:0:1:0): SIGNATURE: eb14
run_interrupt_driven_hooks: still waiting after 60 seconds for xpt_config
ata2: p0: SATA connect time=0ms status=0113
ata2: p1: SATA connect timeout status=
ata2: reset tp1 mask=03 ostat0=00 ostat1=00
ata2: stat0=0x00 err=0x01 lsb=0x14 msb=0xeb
ata2: stat1=0x00 err=0x01 lsb=0x14 msb=0xeb
ata2: reset tp2 stat0=00 stat1=00 devices=0x3
(aprobe0:ata2:0:1:0): ATAPI_IDENTIFY. ACB: a1 00 00 00 00 40 00 00 00 00 00 00
(aprobe0:ata2:0:1:0): CAM status: Command timeout
pass0 at ata2 bus 0 scbus0 target 0 lun 0
pass0:  Removable CD-ROM SCSI-0 device 
pass0: Serial Number e1F3456789KLMN4P
pass0: 150.000MB/s transfers (SATA 1.x, UDMA5, ATAPI 12bytes, PIO 8192bytes)
ATA PseudoRAID loaded
lapic22: CMCI unmasked
lapic0: CMCI unmasked
SMP: AP CPU #3 Launched!
lapic4: CMCI unmasked
lapic18: CMCI unmasked
...

cheers,
danny


___
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: Starting with svn commit r216333 current freezes

[Daniel Braniss]

> Hi!
> 
> With commit r216333 to pmap.c my PC (i386 32 bit) freezes within a few 
> seconds 
> when X (with nvidia-driver 256.53) starts. I already recompiled and 
> reinstalled the nvidia driver, but this didn't change anything. I also tried 
> the latest nvidia-driver 260.19.29 but without luck, too :-(.
> 
> By chance I saw a panic message "vm_page_unwire: page 0x... wire count is 
> zero", but no crash dump was generated.
> 
> Any clues?
> 
are you running amd (am-utils)?

danny

> Thanks,
> Christian.
> ___
> 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"
> 


___
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: tmpfs out of space (ZFS related?)

[Daniel Braniss]

> On (21/11/2010 22:22), Ivan Voras wrote:
> > I got a curious error today while starting PostgreSQL, complaining about 
> > "out of space" errno while creating lock file on /tmp.
> > 
> > /tmp on this machine is mounted as tmpfs and indeed, here is the statistic:
> > 
> > biggie:/# df -i
> > Filesystem1M-blocks  Used  Avail Capacity iused ifree %iused 
> > Mounted on
> > /dev/mfid0s1a  9912  5193   392657%  306079   1012831   23%   /
> > devfs 0 0  0   100%   0 0  100%   /dev
> > fdescfs   0 0  0   100%   4 110920% 
> > /dev/fd
> > tmpfs 0 0  0   100%   9 0  100%   /tmp
> > tank 376044 0 376044 0%   4 7701383470%   /tank
> > tank/ports   376658   614 376044 0%  145919 7701383470% 
> > /usr/ports
> > tank/mysql   37607329 376044 0% 102 7701383470% 
> > /var/db/mysql
> > tank/pgdata90400469 24425 376044 6%1047 7701383470% 
> > /tank/pgdata90
> > 
> > On the other hand, "top" reports this:
> > 
> > last pid: 79667;  load averages:  0.08,  0.68,  0.77up 1+09:12:13 
> > 00:11:33
> > 44 processes:  1 running, 43 sleeping
> > CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
> > Mem: 13M Active, 46M Inact, 15G Wired, 232K Cache, 1458M Buf, 8358M Free
> > Swap: 1024M Total, 1024M Free
> > 
> > Note the "8358M free" report.
> That's probably integer overflow, could you try specifying max
> size as mount option. There was a series of integer overflows in tmpfs.
> Used and available are 0 in df output. On my system I have:
> % df
> Filesystem SizeUsed   Avail Capacity  Mounted on
> tmpfs  4.3G4.0K4.3G 0%/usr/obj/ports
> 
> Also note, that tmpfs does somewhat weired thing on constantly
> recalculating available space based on free memory/swap (not sure if
> specifying max size would fix it).
> 
> Did you try double copy elimination patch by k...@?
> http://lists.freebsd.org/pipermail/freebsd-fs/2010-June/008786.html
> 
> It doesn't apply cleanly to current any more, but fixing it shouldn't be
> hard. The patch wouldn't fix this particular issue but looks very
> promising.
> 
> Thanks,
> Gleb
> 
> > The server has ZFS and was doing IO intensive database work on it; the 8 
> > GB free memory comes from PostgreSQL being restarted and freeing the 
> > memory (but failing to start again...).
> > 
> > Starting PostgreSQL gets me this message:
> > Nov 22 00:18:24 biggie postgres[79696]: [1-1] FATAL:  could not write 
> > lock file "/tmp/.s.PGSQL.5432.lock": No space left on device
> > 
> > This is 8-STABLE amd64.
> > 
> > Running "touch /tmp/abc" works, and creates a file. Running "echo abc > 
> > /tmp/abc" doesn't return an error but *doesn't write anything to the 
> > file*, just creates a directory entry.
> > 
> > The status doesn't change over time, i.e. "df" on tmpfs always shows "0 
> > free".

out of space is sometimes caused by out of inodes.
what does df -i say?
you can increase the # of inodes, see man mdmfs

my .5
danny


___
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: Move banner to games

[Daniel Braniss]

> In message <4cadc453.7010...@googlemail.com>, "army.of.root" writes:
> > On 10\10\02 18:48, Paul B Mahol wrote:
> > > On 10/2/10, Brandon Gooch  wrote:
> > >> On Sat, Oct 2, 2010 at 7:36 AM, Paul B Mahol  wrote:
> > >>> Hi,
> > >>>
> > >>> I see no point to have it in usr/bin.
> > >>
> > >> Cool! This is the first time I've heard of this program! How come the
> > >> folks at my university who manage the line printers have never let me
> > >> on to this?!
> > >>
> > >> Ahh -- wait a sec -- I'm beginning to see your point about the whole
> > >> "move it to games thing"...
> > >>
> > >> -Brandon aka "The Green Bar Bandit"
> > >>
> > >
> > > NetBSD and OpenBSD have this version in games and horizontal version
> > > of banner in usr/bin.
> > >
> > > I see no point to have this program(s) in base at all.
> > >
> > > I will just stop here.
> > 
> > Hi,
> > 
> > A horizontal version of banner could be nice for motd etc.
> > 
> > I like banner.
> > It makes me smile and think that FreeBSD is a cosy place to be.
> 
> It's been in the base for decades. People used it to print banners on 
> reports, before laser and  ink jet printers were around, when tractor feed 
> printers ruled. Banner was more than just a game. People used it for 
> production work. I suppose you could still use it for its intended purpose 
> today however with the graphical tools we have today it's a little archaic. 
> Having said that, it doesn't take up a lot of space and should probably 
> remain where it is.
> 
> BTW, I'm of the age where I did use it and tools like it (on the IBM 
> mainframe) for real work.

ah memories, I had the walls of my office covered with pi with some very long 
precision :-)

danny


___
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: Official request: Please make GNU grep the default

[Daniel Braniss]

> On Sat, 14 Aug 2010, Julian H. Stacey wrote:
> 
> >> why would you want to lock a file for reading anyways?
> >
> > Does current bsdgrep read lock by default ?
> > If so, it would be better off by default, enabled by an option.
> > 8.0-RELEASE man grep (gnu) does not mention locking.
> 
> bsdgrep in -current does lock via the call to fgetc().  That is why I 
> suggested using flockfile/getchar_unlocked+/funlockfile instead.  Other 
> unlocked functions would also be useful, i.e., feof_unlocked(). 
> Avoiding fgetc() does not completely solve the speed issue, yet it 
> certainly helps.
> 
> Just for reference:  older bsdgrep used fgetln().

let me rephrase the question:
why would you want to lock a file for reading anyways??

there is no real benefit that I can see in locking a file for searching
a pattern. On a single file the overhead is irrelevant, but for 'grep -r?'


cheers,
danny


___
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: Official request: Please make GNU grep the default

[Daniel Braniss]

>   This message is in MIME format.  The first part should be readable text,
>   while the remaining parts are likely unreadable without MIME-aware tools.
> 
> --56599777-398594934-1281714095=:35204
> Content-Type: TEXT/PLAIN; charset=US-ASCII; format=flowed
> 
> On Fri, 13 Aug 2010, Gabor Kovesdan wrote:
> 
> > Em 2010.08.13. 10:43, Doug Barton escreveu:
> >> My reason is simple, performance. While doing some portmaster work 
> >> recently I was regression testing some changes I made to the --index* 
> >> options and noticed that things were dramatically slower than the 
> >> last time I tested those features. Thinking that I had made a 
> >> programming mistake I dug into my code, and while the regexps that I 
> >> was using could be tuned for slightly better performance the problem 
> >> was not in my code.  I then installed textproc/gnugrep to compare, 
> >> and the differences were very dramatic using a highly pessimized test 
> >> case (finding a match on the last line of INDEX). The script I used 
> >> to test is at http://people.freebsd.org/~dougb/grep-time-trial.sh.txt 
> >> and a typical result was:
> >> 
> >> GNU grep
> >> Elapsed time: 2 seconds
> >> 
> >> BSD grep
> >> Elapsed time: 47 seconds
> >> 
> > Ok, I'll take care of this soon, and make GNU grep default, again with 
> > a knob to build BSD grep. I agree with you that we cannot allow such a 
> > big performance drawback but I my measures only showed significant 
> > differences for very big searches and I didn't imagine that it could 
> > add up to such a big diference. I'm sorry for the bad decision I took 
> > making it default.
> 
> This should trim some time off BSD grep.  It removes the lock/unlock for 
> each fgetc() by locking/unlocking the file once.  stdio can be slow.
> 
> You probably want to replace flockfile() with ftrylockfile() if threads 
> will be involved at some point (threading or making a libgrep that may 
> be used in a threaded process).

why would you want to lock a file for reading anyways?
BTW, back in the jurasic age, ATT/Bell had this poster: 
Reach out and GREP someone!
danny



___
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: read() on dirs - grep

[Daniel Braniss]

> Em 2010.08.09. 21:34, Gennady Proskurin escreveu:
> > I see misbehaviour of new bsd grep in freebsd on tmpfs when grepping dirs.
> > For example (on tmpfs /tmp):
> >
> > mkdir /tmp/qwe
> > grep something /tmp/qwe
> > (grep hangs)
> >
> Thank you for the report, I'm already aware of the issue and preparing a 
> fix for it.
> 
just in case this is the same but different :-)
if grep hits an NFS mounted dir it goes into a loop:
truss grep  -l '^# PROVIDE:' /cs/share/etc/rc.d/*
...
read(2,0x800c5e000,4096) ERR#21 'Is a directory'
...
cheers,
danny


___
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: [Need Help]isboot (iSCSI boot driver) version 0.2.1

[Daniel Braniss]

> iscsi initiator paniced over 4 dev, and the code has limitations of
> devices, it is hardcoded to 4
> 
> 9f2ae5be (scottl 2007-07-24 15:35:02 +  39) #define ISCSIDEV
> "iscsi"
> 9f2ae5be (scottl 2007-07-24 15:35:02 +  40)
> 9f2ae5be (scottl 2007-07-24 15:35:02 +  41) #define
> ISCSI_MAX_TARGETS  4 //64
> 9f2ae5be (scottl 2007-07-24 15:35:02 +  42)
> 9f2ae5be (scottl 2007-07-24 15:35:02 +  43) #define ISCSI_MAX_LUNS
>  4
> 
> when setting this to 64, than paniced the kernel
> 

get
ftp://ftp.cs.huji.ac.il/users/danny/freebsd/iscsi-2.2.4.tar.gz

but what does this have to to with the Subject:?

danny

> 
> On 7/4/10, Alexander Motin  wrote:
> > Daisuke Aoyama wrote:
>  Notes/Known Issues/Limitations:
>  FreeBSD can't use transfer length > 64KB.
> >>>
> >>> Since 8.0 FreeBSD can use any transfer lengths. 64K is a safety limit
> >>> for CAM SIMs that do not report maximum transfer size. If your driver
> >>> supports bigger transactions (and even if not), you should fill maxio
> >>> field in XPT_PATH_INQ response.
> >>
> >> I set maxio=1024*1024 in version 0.2.2. As a result, the request (each
> >> ccb)
> >> have 256 blocks (128KB). I don't know why it is 128KB.
> >
> > 128KB is a default MAXPHYS value. You may rise it in your kernel if you
> > want. I am successfully using 1MB MAXPHYS now.


___
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: Use of boot0cfg to set boot slice broke between r209459 and r209502

[Daniel Braniss]

> 
> --qZLFzaLf2KECwqmh
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Sat, Jun 26, 2010 at 12:10:57PM +0300, Daniel Braniss wrote:
> > ...
> > what do you see when you type boot0cfg -v ...?
> > gpart show?
> > then try=20
> > gpart set -a active -i n aacd0
> > n will probably be 5.
> >=20
> > bottom line, the MBR is NOT being updated by boot0cfg
> 
> OK; here's what I see -- note that the /S1/usr/sbin/boot0cfg executable
> is the one I built yesterday without the 2 lines from r209469:
> 
> freebeast(9.0-C)[2] uname -a
> FreeBSD freebeast.catwhisker.org 9.0-CURRENT FreeBSD 9.0-CURRENT #200 r2095=
> 22: Fri Jun 25 06:11:00 PDT 2010 r...@freebeast.catwhisker.org:/usr/obj=
> /usr/src/sys/GENERIC  i386
> freebeast(9.0-C)[3] sudo boot0cfg -v aacd0; echo $?
> Password:
> #   flag start chs   type   end chs   offset size
> 1   0x00  0:  1: 1   0xa5651:254:63   63 10474317
> 2   0x00652:  0: 1   0xa5   1023:254:63 10474380 10474380
> 3   0x00   1023:255:63   0xa5   1023:254:63 20948760 10474380
> 4   0x80   1023:255:63   0xa5   1023:254:63 31423140 40194630
> 
> version=3D1.0  drive=3D0x80  mask=3D0xf  ticks=3D182  bell=3D  (0x7)
> options=3Dpacket,update,nosetdrv
> default_selection=3DF4 (Slice 4)
> 0
> freebeast(9.0-C)[4] sudo boot0cfg -v -s 2 aacd0 ; echo $?
> boot0cfg: write_mbr: /dev/aacd0: Operation not permitted
> 1
> freebeast(9.0-C)[5] sudo boot0cfg -v aacd0 ; echo $?
> #   flag start chs   type   end chs   offset size
> 1   0x00  0:  1: 1   0xa5651:254:63   63 10474317
> 2   0x00652:  0: 1   0xa5   1023:254:63 10474380 10474380
> 3   0x00   1023:255:63   0xa5   1023:254:63 20948760 10474380
> 4   0x80   1023:255:63   0xa5   1023:254:63 31423140 40194630
> 
> version=3D1.0  drive=3D0x80  mask=3D0xf  ticks=3D182  bell=3D  (0x7)
> options=3Dpacket,update,nosetdrv
> default_selection=3DF4 (Slice 4)
> 0
> freebeast(9.0-C)[6] sudo /S1/usr/sbin/boot0cfg -v -s 2 aacd0 ; echo $?
> #   flag start chs   type   end chs   offset size
> 1   0x00  0:  1: 1   0xa5651:254:63   63 10474317
> 2   0x00652:  0: 1   0xa5   1023:254:63 10474380 10474380
> 3   0x00   1023:255:63   0xa5   1023:254:63 20948760 10474380
> 4   0x80   1023:255:63   0xa5   1023:254:63 31423140 40194630
> 
> version=3D1.0  drive=3D0x80  mask=3D0xf  ticks=3D182  bell=3D  (0x7)
> options=3Dpacket,update,nosetdrv
> default_selection=3DF2 (Slice 2)
> 0
> freebeast(9.0-C)[7] sudo boot0cfg -v aacd0 ; echo $?
> #   flag start chs   type   end chs   offset size
> 1   0x00  0:  1: 1   0xa5651:254:63   63 10474317
> 2   0x00652:  0: 1   0xa5   1023:254:63 10474380 10474380
> 3   0x00   1023:255:63   0xa5   1023:254:63 20948760 10474380
> 4   0x80   1023:255:63   0xa5   1023:254:63 31423140 40194630
> 
> version=3D1.0  drive=3D0x80  mask=3D0xf  ticks=3D182  bell=3D  (0x7)
> options=3Dpacket,update,nosetdrv
> default_selection=3DF2 (Slice 2)
> 0
> freebeast(9.0-C)[8] sudo gpart show
> =3D>  63  71619471  aacd0  MBR  (34G)
> 63  10474317  1  freebsd  (5.0G)
>   10474380  10474380  2  freebsd  (5.0G)
>   20948760  10474380  3  freebsd  (5.0G)
>   31423140  40194630  4  freebsd  [active]  (19G)
>   71617770  1764 - free -  (882K)
> 
> =3D>   63  143306919  aacd1  MBR  (68G)
>  63  143299737  1  freebsd  [active]  (68G)
>   143299800   7182 - free -  (3.5M)
> 
> =3D>   0  10474317  aacd0s1  BSD  (5.0G)
>  0   30720001  freebsd-ufs  (1.5G)
>3072000   74023174  freebsd-ufs  (3.5G)
> 
> =3D>   0  10474380  aacd0s2  BSD  (5.0G)
>  0   30720001  freebsd-ufs  (1.5G)
>3072000   74023804  freebsd-ufs  (3.5G)
> 
> =3D>   0  10474380  aacd0s3  BSD  (5.0G)
>  0   30720001  freebsd-ufs  (1.5G)
>3072000   74023804  freebsd-ufs  (3.5G)
> 
> =3D>   0  40194630  aacd0s4  BSD  (19G)
>  0   30720001  freebsd-ufs  (1.5G)
>3072000  209715202  freebsd-swap  (10G)
>   24043520   74014724  freebsd-ufs  (3.5G)
>   31444992   87496386  freebsd-ufs  (4.2G)
> 
> =3D>0  143299737  aacd1s1  BSD  (68G)
>   0   209715202  freebsd-swap  (10G)
>20971520   671088644  freebsd-ufs  (32G)
>8

Re: Use of boot0cfg to set boot slice broke between r209459 and r209502

[Daniel Braniss]

> 
> --jr/gb2Ce1GM9KKZD
> Content-Type: text/plain; charset=us-ascii
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
> 
> On Fri, Jun 25, 2010 at 08:37:36AM -0400, John Baldwin wrote:
> > On Friday 25 June 2010 7:40:11 am David Wolfskill wrote:
> > > Well, one one of my machines -- I realize that there are some
> > > machines for which it's been problematic for a while.  And all of
> > > the machines I'm using run FreeBSD/i386.
> >=20
> > 209469 perhaps?
> 
> Apparently so.
> 
> Here's what I did to test the above assertion:
> 
> * Booted the build machine from slice 4 (usual "head" slice); cloned
>   that slice to slice 1; booted from slice 1.
> 
> * In a "head" src working directory, I issued
> 
>   svn diff -c209469
> 
>   and saw that r209469 merely added 2 lines to usr.sbin/boot0cfg/boot0cfg.c.
> 
> * On the build machine's src working directory, I edited
>   usr.sbin/boot0cfg/boot0cfg.c to remove the lines in question.
> 
> * Then (as root), I made /usr/src/usr.sbin/boot0cfg/ my current working
>   directory and issued:
> 
>   make && make install
> 
> * I then issued
> 
>   boot0cfg -s 4 aacd0 && shutdown -r now
> 
>   then watched the serial console.
> 
> * I noticed that the default boot slice -- which had been 1 -- was now
>   4.
> 
> * For grins, I then booted slice 4 (head) in single-user mode, mounted
>   the file systems, then invoked the boot0cfg executable from slice 1 to
>   switch the default to slice 2, then issued "halt -p".  I waited a bit,
>   then powered the machine back up (WoL can be handy!) noted it was
>   booting from slice 2, brought it up in single-user mode, then issued
>   "halt -p" to reduce its power consumption and heat & nouse generation.
> 
> All that said, it looks as if r209469 merely noticed an existing error
> condition and tried to do something arguably sensible with it, rather
> than merely ignore it.  So it would seem that there's a more fundamental
> issue at stake, here

what do you see when you type boot0cfg -v ...?
gpart show?
then try 
gpart set -a active -i n aacd0
n will probably be 5.

bottom line, the MBR is NOT being updated by boot0cfg

danny


___
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Daniel Braniss]

> On 21.04.2010 10:01, pluknet wrote:
> > Hmm.. That's strange to hear.
> > We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64).
> > All runs flawlessly.
> >   I'll try to boot it from head today if that matters.
> 
> It was about 1.5 hour ago when i entered "autoboot" in loader prompt.
> It still show slowly rotated dash line at end of
> /boot/kernel/kernel text=x |

I've seen this happen when there were problems with the serial port, either
missing or miss-configured.

HTH,
danny



___
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: [RFC] Rewriting sade(8)

[Daniel Braniss]

> 09.04.10, 11:20, "Garrett Cooper" :
> >  Ok. Or maybe since `we're here' sade needs to be populating
> >  $DESTDIR/etc/fstab, not sysinstall ? 
> 
> I'm also looking for answer to this question. It seems that all basic 
> operations
> with partitions are already implemented. And I think about next steps.
> 
> Also I think I should make a dialog for writing bootcode. And there are a 
> bunch of
> different bootstrap code which can be used with different schemes. So if 
> anyone 
> can share own experience I'll be grateful.
> 
> MBR:
> /boot/mbr - standart boot record (is it needed? Is it not the same which 
> gpart creates?).
> /boot/boot0 - boot0 boot manager.
> /boot/boot0sio - boot0 boot manager with redirected output ot com1.

correct me if I'm wrong, is MBR the only one that can be used to change the 
boot partition
via menu? and also via serial? BTW, you said you would look into boot0cfg :-)

> 
> GPT:
> /boot/pmbr - protective mbr
> /boot/gptboot - bootstrap code for booting from GPT, should be installed to 
> freebsd-boot
> partition.
> /boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be 
> installed to 
> freebsd-boot partition.
> 
> /boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this 
> bootcode doesn't have
> a correct way (e.g `gpart bootcode ...`) to be writed.
> 
> What about VTOC8, PC98, APM?
> 
> -- 
> WBR, Andrey V. Elsukov
> ___
> 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"
> 


___
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"