Re: Trying to read linux-lvm on 11.0-RC2 using geom, bhyve, fail.

[Andrey V. Elsukov]

On 15.09.2016 08:10, Zaphod Beeblebrox wrote:
> After this fail, I decided I didn't really _need_ to run linux here and I
> discovered 'geom_linux_lvm.ko' ... cool.  But fail, too.  Doesn't emit any
> messages.  I even enabled the debug messages for it.
> 
> The linux disk is partitioned thusly:
> 
> =>63  1953525105  ada1  MBR  (932G)
>   631985- free -  (993K)
> 2048  1953523120 1  linux-data  [active]  (932G)

Probably it isn't LVM or some modern version, which isn't supported by
module. With enable kern.geom.linux_lvm.debug=1 module will complain
only if it will find magic string "LABELONE" in the metadata.
You can check what is stored in the metadata with the following command:
# dd if=/dev/ada1s1 count=1 | hexdump -vC

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Kevin Lo]

On Sun, Oct 02, 2016 at 10:15:49AM -0700, Adrian Chadd wrote:
> 
> hi,

Hi Adrian,

> can you turn on debugging? Do you see RX frames?

No Rx frames.  The log is pretty much the same one I sent on the list:
https://lists.freebsd.org/pipermail/freebsd-wireless/2016-September/007093.html

> -a

Thanks,
Kevin

> On 1 October 2016 at 08:09, Kevin Lo  wrote:
> > Strange, rtwn(4) stops working.  I tried to scan for the available network,
> > but it just returns empty results.
> >
> > On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote:
> >>
> >> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo :
> >>
> >> Few more questions:
> >> 1) does it work with h/w encryption support? (enabled by default)
> >> (if 'yes' - I will remove 'hardware crypto enabled' warning).
> >> 2) is there rate control support? (wlandebug -i wlan0 rate ; then transmit
> >> something - if it works then AMRR will print it's current status
> >> periodically)
> >> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n)
> >> (see r92ce_adj_devcaps() in sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c).
> >>
> >> > It works for me, thanks :)
> >> >
> >> > Kevin
> >> >
> >> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
> >> >>
> >> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo
> >> >> :
> >> >>
> >> >> Thanks for the log file,
> >> >>
> >> >> Tx 'device timeouts' should be fixed in
> >> >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
> >> >> (currently I'm reviewing PCI-specific code to see if there are any
> >> >> additional
> >> >> issues - e.g., there are no Rx events in the log file).
> >> >>
> >> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
> >> >> >>
> >> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo
> >> >> >> :
> >> >> >>
> >> >> >> Hi,
> >> >> >>
> >> >> >> So, the driver was fully tested. Thanks!
> >> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
> >> >> >> the problem is?
> >> >> >
> >> >> > Sure.  Here you go
> >> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
> >> >> >
> >> >> > Thanks,
> >> >> > Kevin
> >> >> >
> >> >> >> > Hi Andriy,
> >> >> >> >
> >> >> >> > First of all, THANK YOU!  You're doing amazing work!
> >> >> >> > Second, I've done some testing on the following devices,
> >> >> downloading
> >> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
> >> >> >> > ftp.freebsd.org:
> >> >> >> >
> >> >> >> > - ASUS USB-N10 NANO (RTL8188CUS):
> >> >> >> >   rtwn0:  >> >> addr
> >> >> >> > 3> on usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
> >> >> >> >
> >> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU):
> >> >> >> >   rtwn0:  on
> >> >> >> > usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
> >> >> >> >
> >> >> >> > - D-Link DWA-131 (RTL8192CU):
> >> >> >> >   rtwn0:  >> >> addr
> >> >> >> > 3> on usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
> >> >> >> >
> >> >> >> > - TP-Link Archer T4U (RTL8812AU):
> >> >> >> >   rtwn0:  on
> >> >> >> > usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
> >> >> >> >
> >> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU):
> >> >> >> >   rtwn0: <802.11n WLAN Adapter> on usbus0
> >> >> >> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
> >> >> >> >
> >> >> >> > - RTL8188CE mini pcie:
> >> >> >> >   rtwn0:  port 0xd000-0xd0ff mem
> >> >> >> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1
> >> >> >> >   rtwn0: r92ce_attach: warning: hardware crypto enabled
> >> >> >> >   rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
> >> >> >> >
> >> >> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't work:
> >> >> >> >
> >> >> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used
> >> >> >> > rtwn0: device timeout
> >> >> >> >
> >> >> >> >   Kevin
> >> >> >> >
> >> >> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
> >> >> >> >>
> >> >> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
> >> >> >> >> :
> >> >> >> >>
> >> >> >> >> Now it resides on https://github.com/s3erios/freebsd-rtwn
> >> >> (integrated
> >> >> >> >> into src tree, so it can be built with 'make buildkernel' / 'make
> >> >> >> >> buildworld').
> >> >> >> >>
> >> >> >> >> This the last stage; once all reported issues will be resolved,
> >> >> I'm
> >> >> >> >> going to merge it into HEAD.
> >> >> >> >>
> >> >> >> >> > Hi everyone,
> >> >> >> >> >
> >> >> >> >> > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were
> >> >> >> merged
> >> >> >> >> > into a
> >> >> >> >> > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the
> >> >> >> code is
> >> >> >> >> > available on https://github.com/s3erios/rtwn repository. Among
> >> >> >> >> bugfixes /
> >> >> >> >> > code deduplication, there some new features too:
> >> >> >> >> >
> >> >> >> >> > 1) 

Re: ZFS - Abyssal slow on copying

[O. Hartmann]

Am Sun, 2 Oct 2016 15:30:41 -0400
Allan Jude  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
> >   
> 

Hello Jude.

Thank you for your answer.

> 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.

All right, that confirms my fear - I had dedup on for a while when 
experimenting ... 

> 
> If the drive is making that much noise, have you considered that the
> drive might be failing?

The drive seems all right, I think it's the reading/writing of many small 
blocks at once
when copying from that specific ZFS partition containing the nanbsd 
installation with
dedup on once. The noise is "classical", but unusual in that specific task when 
supposed
not to do so many read/writes. But, anyway, it is an optimistic guess and 
somehow also
wishful thinking ;-) I will take a drive failure also in consideration - I 
hopefully have
backups.

Kind reagrds,

Oliver
> 


pgp_gNfrfYvX1.pgp
Description: OpenPGP digital signature

Re: ZFS - Abyssal slow on copying

[Allan Jude]

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?

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

ZFS - Abyssal slow on copying

[O. Hartmann]

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


pgpJnApNKJBY8.pgp
Description: OpenPGP digital signature

Re: urtwn(4) / rtwn(4) drivers are merged - call for review / testing

[Adrian Chadd]

hi,

can you turn on debugging? Do you see RX frames?


-a


On 1 October 2016 at 08:09, Kevin Lo  wrote:
> Strange, rtwn(4) stops working.  I tried to scan for the available network,
> but it just returns empty results.
>
> On Fri, Sep 23, 2016 at 02:44:13PM +0300, Andriy Voskoboinyk wrote:
>>
>> Fri, 23 Sep 2016 10:18:30 +0300 було написано Kevin Lo :
>>
>> Few more questions:
>> 1) does it work with h/w encryption support? (enabled by default)
>> (if 'yes' - I will remove 'hardware crypto enabled' warning).
>> 2) is there rate control support? (wlandebug -i wlan0 rate ; then transmit
>> something - if it works then AMRR will print it's current status
>> periodically)
>> 3) can you test some disabled capabilities? (ad-hoc/AP modes, 11n)
>> (see r92ce_adj_devcaps() in sys/dev/rtwn/rtl8192c/pci/r92ce_attach.c).
>>
>> > It works for me, thanks :)
>> >
>> > Kevin
>> >
>> > On Fri, Sep 23, 2016 at 09:08:15AM +0300, Andriy Voskoboinyk wrote:
>> >>
>> >> Fri, 23 Sep 2016 04:58:40 +0300 було написано Kevin Lo
>> >> :
>> >>
>> >> Thanks for the log file,
>> >>
>> >> Tx 'device timeouts' should be fixed in
>> >> https://github.com/s3erios/rtwn/commit/f78d51b6ed8590e3aeb65fbf616aa767034a89f5
>> >> (currently I'm reviewing PCI-specific code to see if there are any
>> >> additional
>> >> issues - e.g., there are no Rx events in the log file).
>> >>
>> >> > On Thu, Sep 22, 2016 at 01:54:21PM +0300, Andriy Voskoboinyk wrote:
>> >> >>
>> >> >> Thu, 22 Sep 2016 12:24:42 +0300 було написано Kevin Lo
>> >> >> :
>> >> >>
>> >> >> Hi,
>> >> >>
>> >> >> So, the driver was fully tested. Thanks!
>> >> >> Can you set dev.rtwn.0.debug=0x829f for RTL8188CE to see how big
>> >> >> the problem is?
>> >> >
>> >> > Sure.  Here you go
>> >> https://people.freebsd.org/~kevlo/rtl8188ce-debug.txt
>> >> >
>> >> > Thanks,
>> >> > Kevin
>> >> >
>> >> >> > Hi Andriy,
>> >> >> >
>> >> >> > First of all, THANK YOU!  You're doing amazing work!
>> >> >> > Second, I've done some testing on the following devices,
>> >> downloading
>> >> >> > FreeBSD-12.0-CURRENT-amd64-20160809-r303880-disc1.iso from
>> >> >> > ftp.freebsd.org:
>> >> >> >
>> >> >> > - ASUS USB-N10 NANO (RTL8188CUS):
>> >> >> >   rtwn0: > >> addr
>> >> >> > 3> on usbus0
>> >> >> >   rtwn0: MAC/BB RTL8188CUS, RF 6052 1T1R
>> >> >> >
>> >> >> > - TP-Link TL-WN725N v2 (RTL8188EU):
>> >> >> >   rtwn0:  on
>> >> >> > usbus0
>> >> >> >   rtwn0: MAC/BB RTL8188EU, RF 6052 1T1R
>> >> >> >
>> >> >> > - D-Link DWA-131 (RTL8192CU):
>> >> >> >   rtwn0: > >> addr
>> >> >> > 3> on usbus0
>> >> >> >   rtwn0: MAC/BB RTL8192CU, RF 6052 2T2R
>> >> >> >
>> >> >> > - TP-Link Archer T4U (RTL8812AU):
>> >> >> >   rtwn0:  on
>> >> >> > usbus0
>> >> >> >   rtwn0: MAC/BB RTL8812AU, RF 6052 2T2R
>> >> >> >
>> >> >> > - D-Link DWA-171 rev A1 (RTL8821AU):
>> >> >> >   rtwn0: <802.11n WLAN Adapter> on usbus0
>> >> >> >   rtwn0: MAC/BB RTL8821AU, RF 6052 1T1R
>> >> >> >
>> >> >> > - RTL8188CE mini pcie:
>> >> >> >   rtwn0:  port 0xd000-0xd0ff mem
>> >> >> > 0x9080-0x90803fff irq 17 at device 0.0 on pci1
>> >> >> >   rtwn0: r92ce_attach: warning: hardware crypto enabled
>> >> >> >   rtwn0: MAC/BB RTL8188CE, RF 6052 1T1R
>> >> >> >
>> >> >> > All seems to be ok, except RTL8188CE PCIe adapter doesn't work:
>> >> >> >
>> >> >> > rtwn0: r92ce_post_init: warning: net80211 ratectl is used
>> >> >> > rtwn0: device timeout
>> >> >> >
>> >> >> >   Kevin
>> >> >> >
>> >> >> > On Mon, Sep 19, 2016 at 04:26:38PM +0300, Andriy Voskoboinyk wrote:
>> >> >> >>
>> >> >> >> Thu, 01 Sep 2016 19:29:03 +0300 було написано Andriy Voskoboinyk
>> >> >> >> :
>> >> >> >>
>> >> >> >> Now it resides on https://github.com/s3erios/freebsd-rtwn
>> >> (integrated
>> >> >> >> into src tree, so it can be built with 'make buildkernel' / 'make
>> >> >> >> buildworld').
>> >> >> >>
>> >> >> >> This the last stage; once all reported issues will be resolved,
>> >> I'm
>> >> >> >> going to merge it into HEAD.
>> >> >> >>
>> >> >> >> > Hi everyone,
>> >> >> >> >
>> >> >> >> > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were
>> >> >> merged
>> >> >> >> > into a
>> >> >> >> > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the
>> >> >> code is
>> >> >> >> > available on https://github.com/s3erios/rtwn repository. Among
>> >> >> >> bugfixes /
>> >> >> >> > code deduplication, there some new features too:
>> >> >> >> >
>> >> >> >> > 1) multi-vap support (one any wireless interface + one STA
>> >> >> interface +
>> >> >> >> > any number of monitor mode interfaces).
>> >> >> >> > 2) few new sysctls:
>> >> >> >> >   * dev.rtwn.#.crypto - controls how to use hardware crypto
>> >> >> >> acceleration
>> >> >> >> >   * dev.rtwn.#.ratectl_selected
>> >> >> >> >   * dev.rtwn.#.ratectl - selects current 'rate control'
>> >> algorithm
>> >> >> >> > (currently only 'none' and 'net80211' are supported; RTL8192CE
>> >> >> needs
>> >> >> >> > 

Mime issue on -current

[Poul-Henning Kamp]

I just updated to current from source, and found that evince did
claimed all .pdf files were "application/octet".

The solution, after some digging around is to run

/usr/local/bin/update-mime-database /usr/local/share/mime

Which is something I pressume some port used to do, but for some
reasons didn't do this time...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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"