Re: Slow iSCSI discovery on boot halting the boot process.

[Arrigo Marchiori via freebsd-stable]

Hello,

On Fri, Apr 30, 2021 at 10:29:33AM +0200, Andrea Brancatelli via freebsd-stable 
wrote:

> Hello,  
> 
> I'm having an annoying problem with FreeBSD 12.2-RELEASE-p6, iscsid,
> geom multiparty, a Dell MD3200i and fstab. 
> 
> Long story short, iSCSI login/connection/whatever is slower than the
> boot process and the machine always get stuck with "cannot find
> /san_storage (/dev/multipath/...) please enter /bin/sh location"  

Did you try putting in /boot/loader.conf:
kern.cam.boot_delay=1

It should wait for 10 seconds before attempting to mount the root
partition.

This solves the issue for me on certain embedded systems, and when
trying to boot from cheap USB pen drives.

I hope this helps.

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

Re: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable

[Arrigo Marchiori via freebsd-stable]

Dear All,

On Tue, Mar 02, 2021 at 10:55:15AM +0200, Andriy Gapon wrote:

> On 02/03/2021 09:50, Arrigo Marchiori via freebsd-stable wrote:
> > Dear All,
> > 
> > On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via 
> > freebsd-stable wrote:
> > 
> >> Hello Helge, and thank you for replying again.
> >>
> >> On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote:
> >>
> >>> Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 
> >>> +0100 (CET):
> >>>> On the memstick, the root filesystem is mounted read-only.  I
> >>>> apologize, I should have told it explicitly.  The ``invalid'' attempt
> >>>> is to mount it read-write (no mode is indicated on the command line).
> >>>
> >>> Try to make it r/w mounted (which I suspect you are attempting to
> >>> achieve):
> >>>
> >>> mount -uw /
> >>
> >> Ok, I will try this.
> >>
> >> But just for the record: I am not try to achieve anything.  I gave the
> >> ``invalid'' mount command by mistake (I wanted to mount a partition
> >> from another disk and wrote "da0" instead of "da1") and I saw that the
> >> system became unstable. I thought that this should not happen and I
> >> reported it here.
> > 
> > I have two updates.
> > 
> >  1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2.
> > bsdlabel(8) output (copied by hand):
> > # /dev/da0s2:
> > 8 partitions:
> > #   size offsetfstype[fsize  bsize bps/cpg]
> >   a: 1491200 164.2BSD 0  0 0
> >   c: 1491216  0unused 0  0 # "raw" part, don't 
> > edit
> > 
> >  2- if I mount the partition rw, then the mount command _always_ fails
> >  with error "operation not permitted" and the system _always_ remains
> >  stable. This is independent from mounting from /dev/ufs/label or
> >  /dev/da0s2a.
> > 
> > Therefore I can change the description of this problem report as:
> > 
> > 8<8<8<8<8<8<8<-
> > 
> > When a BSD partition is mounted _read_only_ to / (suppose
> > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I
> > receive a ``strange'' error message, and from that moment the mounted
> > filesystem becomes unreadable.
> > 
> >  - If the partition is mounted from /dev/ufs/label, then mount(8)
> > reports "Operation not permitted" and the system remains stable.
> > This is the expected behavior IMHO.
> > 
> >  - If the partition is mounted read_write, from any special device,
> >then mount(8) reports:
> >  - "Operation not permitted" if I try to mount the slice rw,
> >  - the same strange error message if I try to mount the slice ro,
> >and the system remains stable.
> > 
> >  - The "strange error message" is "invalid argument" on 11.4-STABLE.
> > 
> > 8<8<8<8<8<8<8<-
> > 
> > Now to the question: is this worth a PR? Was it already reported?  Or
> > is it just something that ``should not happen'' because root should be
> > allowed to shoot themselves in the foot?
> > 
> > Thank you in advance and best regards,
> 
> I think that this is worth a PR.

Just reported:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=254005

> I think that even when mounting read-only the underlying GEOM object should be
> marked for exclusive use.
> I vaguely recall that UFS has some quirk in this respect to allow for
> modifications by fsck.  That is supposed to be limited to the root filesystem.
> Maybe it should further be limited to certain boot stages to prevent
> foot-shooting after a system is fully booted.

Thank you and best regards,
-- 
Arrigo

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

Re: Trying do mount a slice containing a r/o mounted partition makes the filesystem unreadable

[Arrigo Marchiori via freebsd-stable]

Dear All,

On Sat, Feb 27, 2021 at 04:34:52PM +0100, Arrigo Marchiori via freebsd-stable 
wrote:

> Hello Helge, and thank you for replying again.
> 
> On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote:
> 
> > Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 
> > +0100 (CET):
> > > On the memstick, the root filesystem is mounted read-only.  I
> > > apologize, I should have told it explicitly.  The ``invalid'' attempt
> > > is to mount it read-write (no mode is indicated on the command line).
> > 
> > Try to make it r/w mounted (which I suspect you are attempting to
> > achieve):
> > 
> > mount -uw /
> 
> Ok, I will try this.
> 
> But just for the record: I am not try to achieve anything.  I gave the
> ``invalid'' mount command by mistake (I wanted to mount a partition
> from another disk and wrote "da0" instead of "da1") and I saw that the
> system became unstable. I thought that this should not happen and I
> reported it here.

I have two updates.

 1- the da0s2a slice starts 16 (blocks?) after the beginning of da0s2.
bsdlabel(8) output (copied by hand):
# /dev/da0s2:
8 partitions:
#   size offsetfstype[fsize  bsize bps/cpg]
  a: 1491200 164.2BSD 0  0 0
  c: 1491216  0unused 0  0 # "raw" part, don't edit

 2- if I mount the partition rw, then the mount command _always_ fails
 with error "operation not permitted" and the system _always_ remains
 stable. This is independent from mounting from /dev/ufs/label or
 /dev/da0s2a.

Therefore I can change the description of this problem report as:

8<8<8<8<8<8<8<-

When a BSD partition is mounted _read_only_ to / (suppose
/dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I
receive a ``strange'' error message, and from that moment the mounted
filesystem becomes unreadable.

 - If the partition is mounted from /dev/ufs/label, then mount(8)
reports "Operation not permitted" and the system remains stable.
This is the expected behavior IMHO.

 - If the partition is mounted read_write, from any special device,
   then mount(8) reports:
 - "Operation not permitted" if I try to mount the slice rw,
 - the same strange error message if I try to mount the slice ro,
   and the system remains stable.

 - The "strange error message" is "invalid argument" on 11.4-STABLE.

8<8<8<8<8<8<8<-

Now to the question: is this worth a PR? Was it already reported?  Or
is it just something that ``should not happen'' because root should be
allowed to shoot themselves in the foot?

Thank you in advance and best regards,
-- 
Arrigo

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

Re: Trying do mount a slice containing a mounted partition makes the filesystem unreadable

[Arrigo Marchiori via freebsd-stable]

Hello Helge, and thank you for replying again.

On Sat, Feb 27, 2021 at 03:43:52PM +0100, Helge Oldach wrote:

> Arrigo Marchiori via freebsd-stable wrote on Sat, 27 Feb 2021 14:00:24 +0100 
> (CET):
> > On the memstick, the root filesystem is mounted read-only.  I
> > apologize, I should have told it explicitly.  The ``invalid'' attempt
> > is to mount it read-write (no mode is indicated on the command line).
> 
> Try to make it r/w mounted (which I suspect you are attempting to
> achieve):
> 
> mount -uw /

Ok, I will try this.

But just for the record: I am not try to achieve anything.  I gave the
``invalid'' mount command by mistake (I wanted to mount a partition
from another disk and wrote "da0" instead of "da1") and I saw that the
system became unstable. I thought that this should not happen and I
reported it here.

Best regards,
-- 
Arrigo

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

Re: Trying do mount a slice containing a mounted partition makes the filesystem unreadable

[Arrigo Marchiori via freebsd-stable]

Hello Helge, Kevin, and thank you for replying.

On Sat, Feb 27, 2021 at 09:21:39AM +0100, Helge Oldach wrote:

> Kevin P. Neal wrote on Sat, 27 Feb 2021 03:04:35 +0100 (CET):
> > On Fri, Feb 26, 2021 at 06:25:05PM +0100, Helge Oldach wrote:
> > > Arrigo Marchiori via freebsd-stable wrote on Fri, 26 Feb 2021 17:02:35 
> > > +0100 (CET):
> > > > Description: when a BSD partition is mounted to / (suppose
> > > > /dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I
> > > > receive a ``strange'' error message, and from that moment the mounted
> > > > filesystem becomes unreadable.
> > > 
> > > Actually you are mounting the same location on disk twice under
> > > different file systems which is a bad idea.
> > > 
> > > For example:
> > > 
> > > # gpart show -p ada0s2
> > > =>0  250064341   ada0s2  BSD  (119G)
> > >   0  241172480  ada0s2a  freebsd-ufs  (115G)
> > >   2411724808891861  ada0s2b  freebsd-swap  (4.2G)
> > > 
> > > Note the "0" offset for both ada0s2 and ada0s2a. When you mount, both
> > > "look" like a proper, distinct UFS but actually it's the same location
> > > on disk so UFS will get confused if you have both mounted rw. It should
> > > go well however if only one is mounted rw and the other(s) ro.

I believe that the memstick images may not organized as you pointed
out.  The standard behavior of mkimg(1) is to leave a small gap
between the beginning of the slice and the beginning of the first
partition.  But I will be able to confirm on Monday, when I will be
back to the office.

> > Wait, really? It seems like the ro mount wouldn't see any blocks (or other
> > unit of data) cached by the rw mount. So the ro mount would see an
> > inconsistent filesystem and I personally would expect a crash or other
> > misbehavior.
> 
> Of course the ro "view" will show inconistencies. That's actually what
> one asks for if doing such bad things as mounting volumes twice. However
> it shouldn't crash as the rw mount of / maintains consistency.

On the memstick, the root filesystem is mounted read-only.  I
apologize, I should have told it explicitly.  The ``invalid'' attempt
is to mount it read-write (no mode is indicated on the command line).

I did not try the mount command in read-only mode. I can try this on
Monday as well.

IMHO it is important to note that everything works as expected when
the partition is mounted from /dev/ufs/label: the mount attempt is
not permitted and nothing else happens.

Even if mounting an already-mounted partition is an invalid action, I
do not think that it should render a system unstable. 

I understand that ``the root user should be allowed to do anything'',
even shoot themselves in the foot. But on the other hand, there are
features such as kern.geom.debugflags that explicitly avoid it.

I hope I could explain myself clearly.

Best regards,
-- 
Arrigo

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

Trying do mount a slice containing a mounted partition makes the filesystem unreadable

[Arrigo Marchiori via freebsd-stable]

Dear All,

I think I found a bug that is similar to an already reported one, but
I am not sure.

Description: when a BSD partition is mounted to / (suppose
/dev/da0s2a), if I try to mount its containing slice (/dev/da0s2) I
receive a ``strange'' error message, and from that moment the mounted
filesystem becomes unreadable.

This problem appears:
 - on a memstick built from 11.4-STABLE r369279,
 - on the ``official'' 12.2-RELEASE memstick,
both tested on amd64.

Fun fact: the problem does _not_ appear if the already-mounted
filesystem is mounted from /dev/ufs/label instead of /dev/da0s2a.

Steps to reproduce on 12.2-RELEASE
==

 1- download the official memstick image for 12.2-RELEASE-amd64 and
 flash it into a USB pen drive

 2- edit /boot/loader.conf on the memstick adding the following lines
 (needed to boot successfully on my test system):
kern.vty=sc
kern.cam.boot_delay=1
kern.cam.scsi_delay=1

 3- edit /etc/fstab on the memstick and change the root device from
 /dev/ufs/FreeBSD_Install to /dev/da0s2a

 4- boot the memstick and open a shell

 5- # mount /dev/da0s2 /mnt
mount: /dev/da0s2: No such file or directory <--- strange message!

 6- the filesystem is now unreadable! For example, trying to run some
binaries not yet in the cache:
# man
/usr/bin/man: Device not configured

If I try to reboot, the console is flooded by:

> vm_fault: pager read error, pid 1 (init)

This problem also appears on a memstick built from 11.4-STABLE
r369279. The error messages are different, but the outcome is the
same.

Expected behavior
=

If the root partition is mounted from /dev/ufs/label (i.e. you skip
step 3 above) the culprit mount command (step 5 above) gives the
following error message:

> mount: /dev/da0s2: Operation not permitted

and the system remains healty and stable.

Am I seeing PR 222948:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222948 or is it
something else?

Thank you in advance and best regards,
-- 
Arrigo

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

Re: Kernel modules and updates (problems with graphics/drm-stable-kmod)

[Arrigo Marchiori via freebsd-stable]

Hello Niclas,

On Mon, Oct 29, 2018 at 01:19:18PM +0100, Niclas Zeising wrote:

> On 10/29/18 12:23 PM, Arrigo Marchiori via freebsd-stable wrote:
> > Dear All,
> > 
> > I am encountering a strange problem with port graphics/drm-stable-kmod.
> > My system is a 11.2-STABLE amd64 with GENERIC kernel.
> > 
> > I upgrade the base system every week or two from source.  My
> > /etc/make.conf lists graphics/drm-stable-kmod in PORTS_MODULES, in
> > order to have it recompiled with every kernel.
> > 
> > When I install the new kernel, run mergemaster and reboot, however,
> > Xorg is unable to drive the video card: something goes wrong with DRM
> > and he tty belonging to Xorg remains black. The other tty's work
> > well.
> > 
> > I tracked down the problem to the file /boot/kernel/radeonkms.ko
> >   ^^
> > If I delete that file and reboot, Xorg works fine.
> > 
> > My question is: why is that file there? The port
> > graphics/drm-stable-kmod installs its module in
> > /boot/modules/radeonkms.ko but the other version from /boot/kernel/
> >^^^   ^^
> > seems to be loaded instead, and therefore Xorg does not work.
> > 
> > Is this a bug of either installkernel, or the port? Or am I doing
> > anything wrong?
> > 
> > Thank you in advance,
> > 
> 
> Hi!
> /boot/kernel/radeonkms.ko is part of the old drm driver that is in base 
> on 11.2 and 12.  In order to load the module from drm-stable-kmod you 
> need to specify the whole path, /boot/modules/radeonkms.ko when loading 
> the module.
> Regards

Thank you for your reply.

I should have read more carefully the pkg-message from
graphics/drm-stable-kmod !

Best regards,
-- 
rigo

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

Kernel modules and updates (problems with graphics/drm-stable-kmod)

[Arrigo Marchiori via freebsd-stable]

Dear All,

I am encountering a strange problem with port graphics/drm-stable-kmod.
My system is a 11.2-STABLE amd64 with GENERIC kernel.

I upgrade the base system every week or two from source.  My
/etc/make.conf lists graphics/drm-stable-kmod in PORTS_MODULES, in
order to have it recompiled with every kernel.

When I install the new kernel, run mergemaster and reboot, however,
Xorg is unable to drive the video card: something goes wrong with DRM
and he tty belonging to Xorg remains black. The other tty's work
well.

I tracked down the problem to the file /boot/kernel/radeonkms.ko
 ^^
If I delete that file and reboot, Xorg works fine.

My question is: why is that file there? The port
graphics/drm-stable-kmod installs its module in
/boot/modules/radeonkms.ko but the other version from /boot/kernel/
  ^^^   ^^
seems to be loaded instead, and therefore Xorg does not work.

Is this a bug of either installkernel, or the port? Or am I doing
anything wrong?

Thank you in advance,
-- 
rigo

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

Re: D-Link DGE530T issue

[Arrigo Marchiori via freebsd-stable]

Hello,

On Fri, Nov 17, 2017 at 03:12:58PM +0300, Mike Black wrote:

> Hello
> 
> VPD is
> none0@pci0:5:1:0:   class=0x02 card=0x4b011086 chip=0x4b011086
> rev=0x11 hdr=0x00
> vendor = 'J. Bond Computer Systems'

IMHO this is either a joke, or a reference to a company in California
that seems to have not produced much for 10 years (I just googled its
name).

I would speculate it is a sort of inside joke from D-Link engineers,
for a chip intended for development, that was inadvertently mounted on
a board for resale.

This would explain the other strange bits.

> subclass   = ethernet
> bar   [10] = type Memory, range 32, base 0xfebec000, size 16384, enabled
> bar   [14] = type I/O Port, range 32, base 0xee00, size 512, enabled
> cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D3
> cap 03[50] = VPD
> VPD ident  = 'DGD-530T Ghgabht Ethernet @dapte'
> 
> But I see... it says some DGD-530T... Do not know why, because it's
> DGE-530T for sure.
> 
> So you're saying this it hardware degradation?
> I will try to find some windows host and plug it in there to check it.
> 
> 2017-11-17 13:19 GMT+03:00 YongHyeon PYUN :
> 
> > On Fri, Nov 17, 2017 at 09:55:03AM +0300, Mike Black wrote:
> > > Hello. I looked into svn code for 8.3R and 11.1R and there seems no
> > changes
> > > in descriptors/identifiers. So I think that NIC is being wrongly
> > identified
> > > during startup process - it is being recognized with a wrong PCI VID. How
> > > can this be checked or fixed?
> > > I use a loadable kernel module after a startup, so there is no useful
> > > messages during boot process.
> > >
> >
> > It seems it's single bit error but if it's dying there would no way
> > to get fixed.  Given that pciconf(8) says VPD capability, try to
> > read it(i.e. pciconf -lcbvV).  Generally VPD contains a readable
> > product string so you may be able to know whether there are other
> > errors.  If vendor ID is the only corrupted one, you can simply
> > patch the device ID in the driver.
> >
> > > 15 нояб. 2017 г. 11:00 PM пользователь "Mike Black" 
> > > написал:
> > >
> > > > Hello
> > > >
> > > > I've got old PCI NIC D-Link DGE530T Rev 11 with SysKonnect chip on it.
> > > > Years ago it worked in FreeBSD 8/9 Stable with if_sk driver.
> > > >
> > > > Now I'm runnig
> > > > 11.1-STABLE FreeBSD 11.1-STABLE #1 r323214: Sat Nov 11 19:06:20 MSK
> > 2017
> > > >amd_miek@diablo.miekoff.local:/usr/obj/usr/src/sys/DIABLO64  amd64
> > > > 1101502 1101502
> > > >
> > > > But recently I plugged this card back and it's not being recognized by
> > a
> > > > driver.
> > > >
> > > > pciconf says that is
> > > > none0@pci0:5:1:0:   class=0x02 card=0x4b011086 chip=0x4b011086
> > > > rev=0x11 hdr=0x00
> > > > vendor = 'J. Bond Computer Systems'
> > > > class  = network
> > > > subclass   = ethernet
> > > > bar   [10] = type Memory, range 32, base 0xfebec000, size 16384,
> > > > enabled
> > > > bar   [14] = type I/O Port, range 32, base 0xee00, size 512,
> > enabled
> > > > cap 01[48] = powerspec 2  supports D0 D1 D2 D3  current D3
> > > > cap 03[50] = VPD
> > > >
> > > > According /usr/share/misc/pci_vendors this D-link should have 4b011186
> > not
> > > > 4b011086.
> > > > I looked into driver code  (if_sk) and it expects 1186 card also.
> > > > I googled about this issue but found no one similar in a recent years
> > > > So I'd like to know what's wrong - some changes in driver in a recent
> > > > years or smth going wrong while OS detecting this NIC. But that's
> > > > confusing, because this exact NIC worked years ago...
> > > >
> > > > --
> > > > amd_miek
> > > > Think different.
> > > > Just superior.
> >
> 
> 
> 
> -- 
> amd_miek
> Think different.
> Just superior.

-- 
rigo

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

Re: dd is returning different content using same inputs

[Arrigo Marchiori via freebsd-stable]

Hello,

On Thu, Jun 08, 2017 at 05:15:15PM +0800, Christopher Hall wrote:

> Hello Dewayne,
> 
> On Thu, 8 Jun 2017 18:10:11 +1000, Dewayne Geraghty
>  wrote:
> 
> > I'm attempting to skip the first three bytes of a file and then pull
> > the header out of message. Please note the file size varies between
> > 105 and 54 bytes, even though the input file and everything else
> > remains constant, on
> > 
> > FreeBSD hathor 11.1-PRERELEASE FreeBSD 11.1-PRERELEASE #0 r319562M:
> > Mon Jun  5 03:13:08 AEST 2017
> > root@hathor:/110007/D/K8/hqdev-amd64-smp-vga amd64 1100514 1100514
> > 
> > # rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384
> > count=1 of=encheader ; ls -lrth  encheader
> > 0+1 records in
> > 0+1 records out
> > 105 bytes transferred in 0.26 secs (4071661 bytes/sec)
> > -rw-r--r--  1 root  wheel   105B Jun  8 16:35 encheader
> > # rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384
> > count=1 of=encheader ; ls -lrth  encheader
> > 0+1 records in
> > 0+1 records out
> > 67 bytes transferred in 0.26 secs (2554912 bytes/sec)
> > -rw-r--r--  1 root  wheel67B Jun  8 16:35 encheader
> > # rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384
> > count=1 of=encheader ; ls -lrth  encheader
> > 0+1 records in
> > 0+1 records out
> > 68 bytes transferred in 0.24 secs (2867263 bytes/sec)
> > -rw-r--r--  1 root  wheel68B Jun  8 16:35 encheader
> > # rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384
> > count=1 of=encheader ; ls -lrth  encheader
> > 0+1 records in
> > 0+1 records out
> > 54 bytes transferred in 0.25 secs (2167717 bytes/sec)
> > -rw-r--r--  1 root  wheel54B Jun  8 16:35 encheader
> > # rm encheader;dd if=/tmp/tLbdoJ/encmessage bs=1 skip=3 | dd bs=384
> > count=1 of=encheader ; ls -lrth  encheader
> > 0+1 records in
> > 0+1 records out
> > 91 bytes transferred in 0.24 secs (3751494 bytes/sec)
> > -rw-r--r--  1 root  wheel91B Jun  8 16:35 encheader
> > 
> > I used this around May 8th (from a OS and ports rebuild on 4th May)
> > and was performing some final testing on an 11.1 Prerelease built on
> > Jun 5.
> > 
> It works similarly on TrueOS (FreeBSD 12) I suspect it is because you
> block sizes are different on the input and output dd commands.
> I would think that the output block size (obs) on 1st dd needs to be
> specified the same input block size on receiving dd to make it work
> correctly.

I also agree; the ``funny'' behavior is probably given by the pipe and
the different block sizes.

The manual page of dd(1) says about the bs parameter:

[...]
> bs=n Set both input and output block size to n bytes, superseding the
>  ibs and obs operands.  If no conversion values other than
>  noerror, notrunc or sync are specified, then each input block is
>  copied to the output as a single block without any aggregation
>  of short blocks.

The second dd seems to receive non-deterministic amounts of data from
the first, and due to the bs parameter, it does not wait until 384
bytes are received, but it outputs its partial block immediately and
then quits.

> > This works correctly so perhaps I'm not using dd correctly?
> > dd if=/tmp/tLbdoJ/encmessage skip=1 bs=3  | dd bs=1 count=384
> > of=encheader ; hd encheader|head -n1; ls -l encheader

If I understood correctly, you could issue a single command:

$ dd if=inputfile bs=1 skip=3 count=384 of=outputfile

I hope this helps.
-- 
rigo

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

Re: moxa uport 1110 RS232 USB to serial support?

[Arrigo Marchiori via freebsd-stable]

Hello,

I am resending this reply message to the freebsd-usb@ and
freebsd-stable@ mailing list, because it bounced back to me after one
day.

On Thu, Nov 17, 2016 at 10:08:44AM +0100, Marko Cupać wrote:

> Hi,
> 
> is it possible to use Moxa Uport 1110 USB to serial adapter on FreeBSD
> 11.0?
> http://www.moxa.com/product/uport_1110.htm

I am afraid that the short answer is «no».

For what I could find on-line:

 - the Moxa UPort 1110 driver for Linux is the same as the Texas
   Instruments TUSB3410
   (source: 
https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/commit/drivers/usb/serial?id=b923c6c62981cec5e2d2187fd700c2fc4386fc45)

 - the port comms/uticom was a driver for the TUSB3410, but it was
   deprecated, and removed three years ago.
   FreeBSD forum thread: https://forums.freebsd.org/threads/18151/
   Port information: http://www.freshports.org/comms/uticom
   SourceForge page: https://sourceforge.net/projects/uticom/

I hope this helps.
-- 
rigo

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

Re: boot0cfg on does not set default selection on gmirror device

[Arrigo Marchiori via freebsd-stable]

Hello all,

On Fri, Oct 21, 2016 at 08:41:33AM -0600, Warner Losh wrote:

> On Fri, Oct 21, 2016 at 5:39 AM, Patrick M. Hausen  wrote:
> > Hi, all,
> >
> > we are repeatedly bitten by the following misbehaviour of boot0cfg:
> >
> > root@hd45:/usr/local # boot0cfg -s 1 mirror/m0
> > root@hd45:/usr/local # boot0cfg -v mirror/m0
> > #   flag start chs   type   end chs   offset size
> > 1   0x80  1:  0: 1   0xa5   1022:254:6316065 16418430
> > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
> > 3   0x00   1021:  0: 1   0xa5768:254:63 32852925   1920667140
> >
> > version=1.0  drive=0x80  mask=0xf  ticks=182  bell=  (0x7)
> > options=packet,update,nosetdrv
> > default_selection=F2 (Slice 2)
> >
> > So, while it should have set the default to slice 1, it simply didn't.
> >
> > gpart on the other hand works as expected:
> >
> > root@hd45:/usr/local # gpart set -a active -i 1 mirror/m0
> > active set on mirror/m0s1
> > root@hd45:/usr/local # gpart show mirror/m0
> > =>63  1953525104  mirror/m0  MBR  (932G)
> >   63   16002 - free -  (7.8M)
> >1606516418430  1  freebsd  [active]  (7.8G)
> > 1643449516418430  2  freebsd  (7.8G)
> > 32852925  1920667140  3  freebsd  (916G)
> >   19535200655102 - free -  (2.5M)
> >
> > But the "active" flag alone is not enough to convince boot0 to actually 
> > boot that partition.
> >
> > Additional info:
> >
> > root@hd45:/usr/local # uname -a
> > FreeBSD hd45.hosting.punkt.de 10.3-RELEASE-p10 FreeBSD 10.3-RELEASE-p10 #0 
> > r306942: Mon Oct 10 10:29:14 UTC 2016 
> > root@:/usr/obj/nanobsd.hosting/usr/src/sys/GENERIC  amd64
> > root@hd45:/usr/local # gmirror status
> >  NameStatus  Components
> > mirror/m0  COMPLETE  ada0 (ACTIVE)
> >  ada1 (ACTIVE)
> >
> >
> > The only way to actually switch the boot0 default selection is:
> >
> > root@hd45:/usr/local # sysctl kern.geom.debugflags=16
> > kern.geom.debugflags: 0 -> 16
> > root@hd45:/usr/local # boot0cfg -s 1 ada0
> > root@hd45:/usr/local # boot0cfg -s 1 ada1
> > root@hd45:/usr/local # boot0cfg -v mirror/m0
> > #   flag start chs   type   end chs   offset size
> > 1   0x80  1:  0: 1   0xa5   1022:254:6316065 16418430
> > 2   0x00   1023:  0: 1   0xa5   1020:254:63 16434495 16418430
> > 3   0x00   1021:  0: 1   0xa5768:254:63 32852925   1920667140
> >
> > version=1.0  drive=0x80  mask=0xf  ticks=182  bell=  (0x7)
> > options=packet,update,nosetdrv
> > default_selection=F1 (Slice 1)
> >
> >
> > Any hints what's going on, here? Obviously it is possible to manipulate
> > the MBR of a gmirror device - as gpart proves. The boot0cfg pops up
> > since FreeBSD 8 when we started using a mirrored NanoBSD setup.
> 
> Any chance you can migrate to using gpart? Is boot0cfg still
> referenced in NanoBSD somewhere?

Ahem... For what it's worth... I cannot help not pointing this old PR
out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186030

Best regards,
-- 
rigo

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

Re: Problems with piped tar

[Arrigo Marchiori via freebsd-stable]

Hello,

On Tue, Aug 23, 2016 at 09:35:12AM +0200, Gerhard Schmidt wrote:

> Am 23.08.2016 um 09:18 schrieb Daniel Braniss:
> > 
> >> On 23 Aug 2016, at 10:06, Gerhard Schmidt  wrote:
> >>
> >> Hi,
> >>
> >> i'm quite often use tar to copy files using
> >>
> >> tar cf - /some/dir | (cd /dest/dir; tar xvvf - )
> > the ‘new’ way:
> > tar cf - /some/dir | tar xvvd - -C /dest/dir
> > which of course does not explain way your version hangs, but this one is 
> > cleaner, and btw, don’t
> > include /.
> 
> that's very strange. It's working, but doesn't solve another related
> problem. When i pipe the tar thru nc a have the same problem as my
> version. And it's no difference if there is a tar c an the receiving end
> of nc or just a '> file.tar'

Maybe you are not invoking nc(1) with the -N option?

From the manual page:

 -N  shutdown(2) the network socket after EOF on the input.  Some
 servers require this to finish their work.

I hope this helps.

Regards,
-- 
rigo

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

Re: svn - but smaller?

[Arrigo Marchiori]

On Tue, Jan 29, 2013 at 11:48:31AM -0500, Isaac (.ike) Levy wrote:

[...]
 John, All,
 
 Just a quick announce re. svnup utility is really exciting/important work-
 
 I wanted to give a shout that I re-focued my shell based c[v]sup
 workalike, and I'm gunnin' for a basically functional utility this
 weekend sometime.
 The folks managing ctm(1) deltas on the distribution servers, have
 kicked in some help to make this happen on the server side.
 
 Just to be clear: I'm not trying to compete or confuse- the svnup
 work is terribly important to me- but I (and some colleagues) need a
 workalike *asap*. 

Downloading sources from a SVN repository can already be done using
tools in base, but at the expense of a terrible inefficiency.

The FreeBSD SVN repositories are also accessible via http. The served
pages are _very_ easy to parse, as you can see from the
attachment. MD5 sums and all SVN properties are available through
WebDAV requests (not handled by the script).

I tried the attached script to download
http://svn.freebsd.org/base/stable/9/ In 27 minutes it downloaded 67
megabytes, corresponding to 42 KByte/sec, through an ADSL link capable
of roughly 400 KByte/sec. Then I stopped it.

IMHO this should demonstrate that the problem is not only having a
SVN workalike, but a fast and efficient one. 
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: svn - but smaller?

[Arrigo Marchiori]

On Wed, Jan 30, 2013 at 01:47:52PM +0100, Arrigo Marchiori wrote:

[...]
 The FreeBSD SVN repositories are also accessible via http. The served
 pages are _very_ easy to parse, as you can see from the
 attachment. 

The attachment was stripped by mailman...  You can download it from my
homepage:
http://rigo.altervista.org/tools/index.php#svn_http_downloader

-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Svnsup architecture

[Arrigo Marchiori]

Disclaimer: I am trying to go inside the technicalities of the SVN
protocol. I am not sure whether this sub-thread should belong to this
list or to another; I am open to suggestions on this topic.

On Fri, Jan 25, 2013 at 07:40:45PM -0600, John Mehr wrote:

 On Fri, 25 Jan 2013 13:42:19 +0100 Arrigo Marchiori ard...@yahoo.it wrote:
  On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy 
  
  1- svnsup-distill: takes a revision from svn and creates 
  a text file (called a delta) that represents it. It seems to be 
  almost complete.
 
  To answer one of John Mehr's problems: MD5 sums are calculated by
  svnsup-distill and included in the deltas. The client only needs
  to check them against the local files.
 
 Hello,
 
 I've been looking for a way to get the details of a 
 complete revision in one step, but I haven't had any luck 
 yet. This would solve the one aspect I'm most worried 
 about: with 5+ files and 5500+ directories in my local 
 copy of /usr/src, I'd hate to have my code end up 
 inadvertently causing a denial of service on the 
 repositories with a flood of tiny requests...

After investigating more in depth the SVN protocol, if I understood
correctly, your problem cannot be solved. Or, at least, the server is
not supposed to help us.

The SVN client, in fact, seems to save a copy of the whole working
copy inside the .svn directory.

Whether a file was changed or not, it is an information that the
_client_ knows, before it contacts the server.

A svn update command sends to the server the start and end
revisions (the latter in the svn-update message, the first in the
set-path message).  Merging the information from the server (delta's)
with the working copy is the client's job.

To summarize, any svn-like downloader should at least know:
 1- the current revision of the working copy;
 2- the checksums of all the files in the repository, at the current
revision. 

The official SVN client does more than point 2: it stores the whole
content of each file; this allows the svn diff and svn revert
commands to work off-line. 

Best regards,
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Svnsup architecture [was: Re: svn - but smaller?]

[Arrigo Marchiori]

On Thu, Jan 24, 2013 at 12:57:17AM -0800, 'Jeremy Chadwick' wrote:

[...]
 Also, just as a footnote point to readers: please do not bring up
 svnsup.  Until it's stated by some official FreeBSD person that
 {committers} are actively working on this and bringing it into the base
 system so people can get src/ports without installing
 ports/devel/subversion, it's not pragmatic to mention it as a
 *solution*.

I take the chance of this thread to tell my understanding of the
svnsup project and how and why it should answer our concerns.

I am not a FreeBSD official person, but I hope I still can bring a
bit of useful information.

Disclaimer: I only had a small e-mail exchange with des, who is the
author of svnsup. 90% of this message are my opinions; the other 10%
is copy'n paste from des' emails. I am currently trying to contribute
to the software; my opinions are made after studying parts of the
current source code.

The current svnsup design is composed of:

 1- svnsup-distill: takes a revision from svn and creates a text file
(called a delta) that represents it. It seems to be almost
complete.

 2- svnsup-apply: takes a delta generated by svnsup-distill and applies
it to an existing source tree. It's currently a work in progress.

 3- a server-side application that runs svnsup-distill and distributes
the deltas (still to be developed).

 4- a client-side application that fetches new deltas and runs
svnsup-apply. New trees are bootstrapped from other sources,
e.g.  weekly tarballs (still to be developed).

The FreeBSD base system could only contain applications 2 and
4. Neither of them depends on any SVN-related library: deltas are
simple text files.

Efficiency, if I understood correctly, was one of the key features of
cvsup. This is why svnsup only transfers deltas.

To answer one of John Mehr's problems: MD5 sums are calculated by
svnsup-distill and included in the deltas. The client only needs to
check them against the local files.

I think that svnsup still needs a lot of work before becoming
usable. But some of the fundamental parts are there, and the projects
can count on at least two developers. :-)
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Page fault panic in scioctl and console-kit-daemon

[Arrigo Marchiori]

Hello,

On Fri, Mar 13, 2009 at 01:24:57PM +0100, Arrigo Marchiori wrote:

 On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote:
[...]
  Any other fix ?
 
 It seems to me that no package has been depending on consolekit, since
 a couple of days. At least, portupgrade is not showing any more stale
 dependencies when I try to portupgrade -aR without having
 consolekit installed. So I'm living happily without it. :-)

I answer to myself: after upgrading to hal-0.5.11_21 consolekit is
required again. This problem has returned. :-(
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Re: Page fault panic in scioctl and console-kit-daemon

[Arrigo Marchiori]

On Mon, Mar 09, 2009 at 12:15:15PM +0100, spara wrote:

 Hello,
 I'm experiencing the same 
 (http://www.mail-archive.com/freebsd-stable@freebsd.org/msg101997.html) 
 after updating to last hald in 6.4-STABLE.
 Anyone tried to fix it with the Kostik Belousov patch as in 
 http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html 
 ?

You mean the patch attached to this message:
http://lists.freebsd.org/pipermail/freebsd-current/2008-February/083586.html
? If so, I didn't try because the message says committed to all
branches. But I can try, if it's necessary...

 Any other fix ?

It seems to me that no package has been depending on consolekit, since
a couple of days. At least, portupgrade is not showing any more stale
dependencies when I try to portupgrade -aR without having
consolekit installed. So I'm living happily without it. :-)
-- 
rigo

http://rigo.altervista.org
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org

Page fault panic in scioctl and console-kit-daemon

[Arrigo Marchiori]

Hello everybody,

I'm reporting a problem that looks _very_ similar to one reported on
freebsd-current@ last year, by Pawel Worach:
http://lists.freebsd.org/pipermail/freebsd-current/2008-January/082581.html

My system is a 6.4-STABLE, with up-to-date /usr/src and /usr/ports:

$ uname -a
FreeBSD diavoletto 6.4-STABLE FreeBSD 6.4-STABLE #19: Mon Feb 16 12:01:24 CET
2009 r...@diavoletto:/usr/obj/usr/src/sys/GENERIC  i386

In /etc/rc.conf I have the following lines:
 dbus_enable=YES
 hald_enable=YES

Every time dbus is started, if consolekit-0.3.0 is installed then a
page fault occurs just after the login screen is shown. If I make
deinstall the port in single-user-mode, then the system boots and
works fine.

If I boot with consolekit uninstalled, then install it and restart
dbus, I get a panic.

I'm reporting here the same information that Pawel Worach reported
last year for his problem. Please tell me if I can provide any more
information; this is my very first problem report here!

8888888-
Script started on Fri Feb 20 12:47:10 2009
# cd /usr/obj/usr/src/sys/GENERIC
# kgdb kernel.debug /var/crash/vmcore.0
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB.  Type show warranty for details.
This GDB was configured as i386-marcel-freebsd...

Unread portion of the kernel message buffer:


Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x4
fault code  = supervisor read, page not present
instruction pointer = 0x20:0xc09dfaef
stack pointer   = 0x28:0xe85a8bf8
frame pointer   = 0x28:0xe85a8c40
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 14500 (console-kit-daemon)
trap number = 12
panic: page fault
Uptime: 30m41s
Dumping 1471 MB (2 chunks)
  chunk 0: 1MB (155 pages) ... ok
  chunk 1: 1471MB (376496 pages) (CTRL-C to abort)  1455 1439 1423 1407 (CTRL-C 
to abort)  1391 1375 1359 1343 1327 1311 1295 1279 1263 1247 1231 1215 1199 
1183 1167 1151 1135 1119 1103 1087 1071 1055 1039 1023 1007 991 975 959 943 927 
911 895 879 863 847 831 815 799 783 767 751 735 719 703 687 671 655 639 623 607 
591 575 559 543 527 511 495 479 463 447 431 415 399 383 367 351 335 319 303 287 
271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15

Reading symbols from /boot/kernel/linux.ko...done.
Loaded symbols for /boot/kernel/linux.ko
Reading symbols from /boot/kernel/snd_hda.ko...done.
Loaded symbols for /boot/kernel/snd_hda.ko
Reading symbols from /boot/kernel/sound.ko...done.
Loaded symbols for /boot/kernel/sound.ko
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /usr/local/modules/fuse.ko...done.
Loaded symbols for /usr/local/modules/fuse.ko
Reading symbols from /boot/kernel/green_saver.ko...done.
Loaded symbols for /boot/kernel/green_saver.ko
#0  doadump () at pcpu.h:165
165 __asm __volatile(movl %%fs:0,%0 : =r (td));
(kgdb) backtrace
#0  doadump () at pcpu.h:165
#1  0xc072b274 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
#2  0xc072b5a6 in panic (fmt=0xc0a66e6f %s)
at /usr/src/sys/kern/kern_shutdown.c:566
#3  0xc0a02f2c in trap_fatal (frame=0xe85a8bb8, eva=0)
at /usr/src/sys/i386/i386/trap.c:838
#4  0xc0a02c32 in trap_pfault (frame=0xe85a8bb8, usermode=0, eva=4)
at /usr/src/sys/i386/i386/trap.c:745
#5  0xc0a027e2 in trap (frame=
  {tf_fs = 8, tf_es = 40, tf_ds = 40, tf_edi = 9, tf_esi = -977926144, 
tf_ebp = -396719040, tf_isp = -396719132, tf_ebx = -1061927328, tf_edx = 
-978051584, tf_ecx = 2000, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = 
-1063388433, tf_cs = 32, tf_eflags = 66182, tf_esp = -978051584, tf_ss = 
-977926144})
at /usr/src/sys/i386/i386/trap.c:435
#6  0xc09ec99a in calltrap () at /usr/src/sys/i386/i386/exception.s:139
#7  0xc09dfaef in scioctl (dev=0xc5b63200, cmd=9, data=0xe85a8cbc \n, 
flag=1, td=0xc6416900) at /usr/src/sys/dev/syscons/syscons.c:1060
#8  0xc06f489c in giant_ioctl (dev=0xc5b63200, cmd=0, data=0x0, fflag=0, 
td=0x0) at /usr/src/sys/kern/kern_conf.c:330
#9  0xc06c8f19 in devfs_ioctl_f (fp=0xc60fdc60, com=537163270, 
data=0xe85a8cbc, cred=0xc7845280, td=0xc6416900)
at /usr/src/sys/fs/devfs/devfs_vnops.c:480
#10 0xc0755007 in ioctl (td=0xc6416900, uap=0xe85a8d04) at file.h:265
#11 0xc0a03302 in syscall (frame=
---Type return to continue, or q return to quit---
  {tf_fs = 59, tf_es = 59, tf_ds = 59, tf_edi = 10, tf_esi = 134714152, 
tf_ebp = -1081716952, tf_isp = -396718748, tf_ebx = 134627884, tf_edx = 
135049216, tf_ecx