Pokala, Ravi | 28 May 03:47 2015

Quick question re: dual-booting

Hi folks,

For doing some apples-to-apples comparisons on a piece of hardware, we
want to be able to easily flip back and forth between FreeBSD (10.1,
amd64, traditional non-UEFI bootstrap w/ GPT) and Linux. To minimize the
chance of an installer going wrong and nuking something, we're installing
one drive, installing FreeBSD on it, then swapping in another drive and
installing Linux on it. Then we'll install both drives, and let the
bootloader control which one gets booted.

The question is: how do we tell the bootloader which OS to boot? If we can
do it using loader, great! If we have to use something like grub, that's
fine too. But either way, I need some guidance.

Thoughts?

Thanks,

Ravi

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Adrian Chadd | 26 May 23:58 2015
Picon

Re: Performance issues with Intel Fortville (XL710/ixl(4))

hi!

Try enabling RSS and PCBGROUPS on -HEAD. The ixl driver should work.

(I haven't tested it though; I've had other things going on here.)

-adrian

On 21 May 2015 at 15:20, Lakshmi Narasimhan Sundararajan
<lakshmi.n <at> msystechnologies.com> wrote:
> Hi FreeBSD Team!
>
> We seem to have found a problem to Tx performance.
>
> We found that the tx handling is spread on all CPUs causing probably cache trashing resulting in poor performance.
>
> But once we used cpuset to bind interrupt thread and iperf process to the same CPU, performance was close to
line rate. I used userland cpuset command to perform this manually. I want this constrained in the kernel
config/code through some tunables, and I am seeking your help/pointers in that regard.
>
>
> My followup questions are as follows.
>
> a) How are Tx interrupts steered from the NIC to the CPU on the transmit path? Would tx_complete# interrupt
for packets transmitted from CPU#x, be serviced on the same CPU? If not, how to get this binding done?
>
>
> b) I would like to use a pool of CPUs dedicated to service NIC interrupts. Especially on the transmit path, I
would want the tx_interrupts to be handled on the same CPU on which request was submitted. How to get this done?
>
(Continue reading)

Julian Elischer | 26 May 16:21 2015
Picon

non standard (standard?) timezones.

I'm trying to reproduce an existing system
(but get it more up to date)
In the existing timezone db on hte machine there are
the following additional timezones htat were I think at
some time symlinks to the real ones, but have over the
years (probably with the help of our friend 'cp') been
turned into real files.

I'm wondering if anyone has any idea of where these came from..
(I suspect some linux distro).
I will probably end up spending a few hours working out the correct 
symlinks to make for each
(e.g. Australia/West -> Australia/Perth )
but if anyone knows of such a list already somewhere that'd be nice..

/usr/share/zoneinfo/Jamaica
/usr/share/zoneinfo/Kwajalein
/usr/share/zoneinfo/Israel
/usr/share/zoneinfo/Africa/Timbuktu
/usr/share/zoneinfo/Africa/Asmera
/usr/share/zoneinfo/Pacific/Samoa
/usr/share/zoneinfo/Pacific/Yap
/usr/share/zoneinfo/Libya
/usr/share/zoneinfo/Iceland
/usr/share/zoneinfo/Mexico/BajaNorte
/usr/share/zoneinfo/Mexico/BajaSur
/usr/share/zoneinfo/Mexico/General
/usr/share/zoneinfo/Europe/Belfast
/usr/share/zoneinfo/Europe/Tiraspol
/usr/share/zoneinfo/Canada/Eastern
(Continue reading)

rank1seeker | 26 May 12:31 2015
Picon

dumpfs incorrectly displays ufsid

I've reported this at REL 8.2, long ago at May 2011
    https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=156908

Now at 10.1-RELEASE-p10 #0 r282952   i386

This happens, ONLY when first chars are 0 (zeros) in second pair of 8
chars, in which case dumpfs, ommits them.
I.e; For:
    /dev/ufsid/3b9aca0000000001

# dumpfs ada0s1h | head -2
magic   19540119 (UFS2) time    Sun Sep  9 03:46:40 2001
superblock location     65536   id      [ 3b9aca00 1 ]

Problem is in '[ 3b9aca00 1 ]'

Domagoj
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Daniel Braniss | 25 May 16:41 2015
Picon
Picon

pwm for raspberry pi?

reposting to hackers …
Hi,
Now that I’m rapping up my spi/rfid driver (available on demand :-),
I would like to use the pwm interface to power on/off a door lock, but
have no idea how to go around it, so any clues would be very welcomed.

cheers,
	danny

_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"
Pratik Singhal | 25 May 15:46 2015
Picon

Convert virtual address to physical address

I need to convert a kernel virtual address to physical address. To do that,
as far as I know, we have 2 macros :-

vtophys :- In sys/arm/include/pmap.h
VTOP :- In sys/boot/i386/libi386/amd64_tramp.S

Since, I am working on arm kernel with ARM_NEW_PMAP option, I am using
vtophys macro by including the pmap.h file.

Now, if I compile the kernel after including the pmap.h file, I am getting
the error :-

error: field has incomplete type 'struct pmap_statistics'
        struct pmap_statistics  pm_stats;       /* pmap statictics */
                                ^
./machine/pmap-v6.h:127:9: note: forward declaration of 'struct
pmap_statistics'
        struct pmap_statistics  pm_stats;       /* pmap statictics */

How, should I resolve this error ? Or is there some other way to convert
virtual address to physical address for arm kernel ?
_______________________________________________
freebsd-hackers <at> freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscribe <at> freebsd.org"

Eric McCorkle | 23 May 23:45 2015
Picon

EFI ZFS loader successful load and boot

My work on ZFS support for EFI has now progressed to the point where I
have successfully loaded and booted a kernel.  The patch I have attached
includes modifications to both boot1 and loader.  The modified
loader.efi can be loaded and run by boot1 or an appropriately-configured
GRUB (I've tested with both).

The code is not ready for integration; however, it is at this point
ready for testing.  The following need to be done, IMO, before it can be
considered for integration:

* boot1 completely ignores partition type GUIDs and probes everything.
A notable effect of this are the "Not ufs" messages that show up.

* There is some commented-out code for looking at command-line arguments
in loader.  It turns out I didn't need to do that.

* I (ab)use the EFI pool allocator in a malloc-like fashion, allocating
single objects in boot1.  This might be OK, but someone with more EFI
knowledge should probably comment as to whether or not it is.

* A future refactoring project that might be useful would be to add a
payload field to the end of struct devdesc, similar to what is done with
struct sockaddr.  That way, extended devdesc structures (like
zfs_devdesc) could be handled in the same way that struct sockaddr_in,
etc are.  If you look at my code, there are a couple of places where I
explicitly check for ZFS, and have separate branches that create
zfs_devdesc's

Please apply and test my patch with both UFS and ZFS filesystems.

(Continue reading)

Neffi | 21 May 20:42 2015
Picon

Botched NCQ on SSD - cannot disable?

I was discussing this issue in freenode/#freebsd and I was recommended to
shoot an email to you fellows about it.

I've got an Samsung 840 EVO SSD (model MZ-7TE250BW), which uses Samsung's
own controller from what I can gather. I had issues of mass data corruption
when used under Linux, and several programs crashing unexpectedly when used
under FreeBSD. I've gone through 2 drives under warranty with the same
issue before customer service suggested to disable drive queuing.

After some research it seems as though this drive (and several other common
SSDs) report that they support NCQ, but in fact are botched and will have
all sorts of problems with NCQ enabled ranging from poor performance, to
I/O stalls to data corruption.

Sure enough the logs on Linux spit out something along the lines of:

> ata1: exception Emask 0x0 SAct 0xf SErr 0x0 action 0x10 frozen
> ata1.00: failed command: READ FPDMA QUEUED

This happens several times when used on Linux, in the few hours leading up
to total filesystem corruption.

The recommendation in the Linux world is to disable NCQ on these drives,
for which there is an easy boot-time tunable for it. This fixes the issue.
No more data corruption.

There doesn't seem to be a tunable for this anywhere on FreeBSD.
camcontrol(8) mentions setting the tags used, but only between some
hardcoded limits, with a default of 2 -- not sufficient to disable NCQ on
the drive. It looks like presently the only option is to manually patch the
(Continue reading)

Daniel Braniss | 21 May 08:41 2015
Picon
Picon

OF_getprop weirdness - raspberry pi

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]: 0x03000000
		data[1]: 0x06000000
(Continue reading)

Slawa Olhovchenkov | 20 May 20:10 2015
Picon

FreeBSD Boot Environments

I am try to use Boot Environments and have some misundertanding.
As I see beadm manage only zroot/ROOT. But base upgrade touch not only
/{boot,etc,bin,lib,libexec,rescue,sbin} but also /usr and from time to
time /var. And don't touch (at most) /root.

What correct way to use Boot Environments?
Rename zfs datasets as:

From			To
zroot/usr		zroot/ROOT/default/usr
zroot/usr/home		zroot/home

create

zroot/root

leave (rename after moving zroot/usr)

zroot/usr/ports
zroot/usr/src
zroot/usr/local

Or somehow else?

How prepare upgrades for such install?

Create model setup, witch similar enviroment
zfs snap modelroot <at> N
do install{world,kernel} DESTDIR=/modelroot
do mergemaster -I -U -D /modelroot
(Continue reading)

Sean Bruno | 19 May 18:23 2015

Trying to use clang/head and XCC


Following the External Tool Chain instructions on the wiki seem to not
work:
https://wiki.freebsd.org/ExternalToolchain

I've gotten about this far:
https://people.freebsd.org/~sbruno/clang_head_build_log.txt

Two items of note.
 -- The bootstrap bits *completely* ignore XCC and build with the host
cc/c++
 -- No documentation of what CFLAGS are required to build and ignore
warnings.

Anyone out there have success doing this?

sean

Gmane