Re: build of main broken? (ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_...' failed: symbol not defined)

2024-05-24 Thread Matteo Riondato 



> On May 24, 2024, at 10:54 AM, Dimitry Andric  wrote:
> 
> On 24 May 2024, at 15:19, Matteo Riondato  wrote:
>> 
>> I’m trying to build 59aa64914aeb1b20d4fc39ead2ee159a1e5b from 
>> main-62adeb92df, and got the error below.
>> 
>> I cannot immediately trace it back to any recent commit, so I’m a bit 
>> surprised by it.
>> 
>> Any hint?
>> 
>> --
>>>>> stage 4.2: building libraries
>> --
>> cd /usr/src;  time env MACHINE_ARCH=amd64  MACHINE=amd64  
>> CPUTYPE=skylake-avx512 BUILD_TOOLS_META=.NOMETA CC="/usr/local/bin/ccache cc 
>> -target x86_64-unknown-freebsd15.0 
>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
>> -target x86_64-unknown-freebsd15.0 
>> --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target 
>> x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
>> -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" 
>> LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  
>> SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
>> PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
>>   SYSROOT=/usr/obj/usr/src/amd64.amd64/tmp make  -f Makefile.inc1  
>> BWPHASE=libraries  DESTDIR=/usr/obj/usr/src/amd64.amd64/tmp -DNO_FSCHG 
>> MK_HTML=no -DNO_LINT MK_MAN=no  MK_PROFILE=no MK_TESTS=no 
>> MK_TESTS_SUPPORT=no  libraries
>> cd /usr/src;  make -f Makefile.inc1 _prereq_libs;  make -f Makefile.inc1 
>> _startup_libs;  make -f Makefile.inc1 _prebuild_libs 
>> -DLIBCRYPTO_WITHOUT_SUBDIRS;  make -f Makefile.inc1 _generic_libs
>> Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_installlinks
>> Building /usr/obj/usr/src/amd64.amd64/lib/libssp_nonshared/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_INCSINS
>> installing DIRS FILESDIR
>> install -U  -d -m 0755 -o root  -g wheel  
>> /usr/obj/usr/src/amd64.amd64/tmp/usr/lib
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_Scrt1.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crt1.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_gcrt1.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbegin.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginS.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginT.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtend.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtendS.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crti.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtn.o
>> Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_libinstall
>> Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_INCSINS
>> Building /usr/obj/usr/src/amd64.amd64/lib/libc/libc.so.7
>> building shared library libc.so.7
>> ld: error: version script assignment of 'FBSD_1.0' to symbol 
>> 'xdr_domainname' failed: symbol not defined
>> ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_keydat' 
>> failed: symbol not defined
> 
> In lib/libc/rpc/Symbol.map there is:
> 
>/* From yp_xdr.c (generated by rpcgen - include/rpcsvc/yp.x) */
>xdr_domainname;
>xdr_keydat;
> 
> so maybe the rpcgen step went wrong somehow? Do you have WITHOUT_NIS enabled?

Yes, I do have WITHOUT_NIS=y in src.conf

Thanks,
Matteo

build of main broken? (ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_...' failed: symbol not defined)

2024-05-24 Thread Matteo Riondato 
Hi All,

I’m trying to build 59aa64914aeb1b20d4fc39ead2ee159a1e5b from 
main-62adeb92df, and got the error below.

I cannot immediately trace it back to any recent commit, so I’m a bit surprised 
by it.

Any hint?

--
>>> stage 4.2: building libraries
--
cd /usr/src;  time env MACHINE_ARCH=amd64  MACHINE=amd64  
CPUTYPE=skylake-avx512 BUILD_TOOLS_META=.NOMETA CC="/usr/local/bin/ccache cc 
-target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin" CXX="/usr/local/bin/ccache c++  
-target x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  CPP="cpp -target 
x86_64-unknown-freebsd15.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp 
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin"  AS="as" AR="ar" ELFCTL="elfctl" 
LD="ld"  LLVM_LINK="" NM=nm OBJCOPY="objcopy"  RANLIB=ranlib STRINGS=  
SIZE="size" STRIPBIN="strip"  INSTALL="install -U"  
PATH=/usr/obj/usr/src/amd64.amd64/tmp/bin:/usr/obj/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin
  SYSROOT=/usr/obj/usr/src/amd64.amd64/tmp make  -f Makefile.inc1  
BWPHASE=libraries  DESTDIR=/usr/obj/usr/src/amd64.amd64/tmp -DNO_FSCHG 
MK_HTML=no -DNO_LINT MK_MAN=no  MK_PROFILE=no MK_TESTS=no MK_TESTS_SUPPORT=no  
libraries
cd /usr/src;  make -f Makefile.inc1 _prereq_libs;  make -f Makefile.inc1 
_startup_libs;  make -f Makefile.inc1 _prebuild_libs 
-DLIBCRYPTO_WITHOUT_SUBDIRS;  make -f Makefile.inc1 _generic_libs
Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libcompiler_rt/_installlinks
Building /usr/obj/usr/src/amd64.amd64/lib/libssp_nonshared/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libgcc_eh/_INCSINS
installing DIRS FILESDIR
install -U  -d -m 0755 -o root  -g wheel  
/usr/obj/usr/src/amd64.amd64/tmp/usr/lib
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_Scrt1.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crt1.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_gcrt1.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbegin.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginS.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtbeginT.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtend.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtendS.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crti.o
Building /usr/obj/usr/src/amd64.amd64/lib/csu/amd64/_FILESINS_crtn.o
Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_libinstall
Building /usr/obj/usr/src/amd64.amd64/lib/libsys/_INCSINS
Building /usr/obj/usr/src/amd64.amd64/lib/libc/libc.so.7
building shared library libc.so.7
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_domainname' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_keydat' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_mapname' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_peername' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_valdat' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_ypbind_binding' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypbind_resp' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_ypbind_resptype' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_ypbind_setdom' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypmap_parms' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypmaplist' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_yppush_status' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 
'xdr_yppushresp_xfr' failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_key' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_nokey' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol 'xdr_ypreq_xfr' 
failed: symbol not defined
ld: error: version script assignment of 'FBSD_1.0' to symbol

Re: ns8250: UART FCR is broken

2022-10-29 Thread Matteo Riondato 

On 2022-10-28 at 17:49 EDT, Colin Percival  wrote:

On Mon, 24 Oct 2022 at 22:11, void  wrote: 

this started appearing in dmesg

ns8250: UART FCR is broken
ns8250: UART FCR is broken
For the list: While I was correct that bhyve didn't emulate FCR_XMT_RST, 
this warning was actually caused by a bug in my earlier commit.  It should 
be fixed now:


I still see it on bare metal.

Thanks,
Matteo


signature.asc
Description: PGP signature

Re: ns8250: UART FCR is broken

2022-10-27 Thread Matteo Riondato 

On 2022-10-26 at 17:15 EDT, Colin Percival  wrote:


On 10/26/22 13:48, Ed Maste wrote:

On Mon, 24 Oct 2022 at 22:11, void  wrote:

this started appearing in dmesg

ns8250: UART FCR is broken
ns8250: UART FCR is broken


This message was added as part of Colin's work to support FreeBSD in 
the Firecracker VMM 
https://cgit.freebsd.org/src/commit/?id=c4b68e7e53bb352be3fa16995b99764c03097e66


In this case it indicates that bhyve has the same bug/missing 
functionality as Firecracker -- it doesn't implement the FCR_XMT_RST 
or FCR_RCV_RST bits. You can safely ignore the message, and it will 
disappear once someone adds the required support to bhyve. We should 
probably also have the kernel emit the message only once. I've CC'd 
Colin for comment.


Indeed, looking at usr.sbin/bhyve/uart_emul.c it looks like FCR_XMT_RST is 
not emulated.  This is different from Firecracker, which doesn't emulate 
either anything from the FCR and where I was seeing the receive side not 
being flushed, but I'm glad my warning was able to flag a bug. :-)


If "void" is comfortable with kernel hacking, it would be great to 
confirm >that the warning is indeed coming from the transmit side not 
being flushed; a printf("drain = %d\n", drain); would be sufficient.


And yes, only emitting this warning once per device (or once per boot?) 
would probably be good.


I got the same message on real hardware, no virtualization involved as 
either host or guest. Is that expected at all?


Relevant lines from /var/run/dmesg.boot:

ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart0: <16550 or compatible> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
uart0: console (115200,n,8,1)
ns8250: UART FCR is broken
ns8250: UART FCR is broken
uart1: <16550 or compatible> port 0x2f8-0x2ff irq 3 on acpi0
ns8250: UART FCR is broken

Thanks,
Matteo


signature.asc
Description: PGP signature

Re: nvme INVALID_FIELD in dmesg.boot

2022-06-12 Thread Matteo Riondato 

On 2022-05-25 at 11:49 EDT, Warner Losh  wrote:


On Wed, May 25, 2022 at 9:39 AM Matteo Riondato  wrote:

On 2022-05-25 at 11:29 EDT, Warner Losh  wrote: 
> 
>SET FEATURES (opcode 9) feature 0xb is indeed async event 
>configuration. 
>0x31f is: 
>SMART WARNING for available spares (0x1) 
>SMART warning for temperature (0x2) 
>SMART WARNING for device reliability (0x4) 
>SMART WARNING for being read only (0x8) 
>SMART WARNING for volatile memory backup (0x10) 
>Namespace attribute change events (0x100) 
>Firmware activation events (0x200) 
> 
>I wonder which one of those it doesn't like. My reading of the standard 
>suggests that those should always be supported for a 1.2 and later 
>drive... Thought maybe with the possible exception of the volatile 
>memory backup, so let me do some digging here... 
> 
>We can get the last two items from OAES field of the controller 
>identificaiton data. This is bytes 95:92, which if I'm counting right 
>is the last word on the 040: line in the nvmecontrol identify -x nvmeX 
>command: 
> 
>040: 4e474e4b 30303150 000cca07 0023 00010200 005b8d80 0030d400 
>0100


>--^

On my system:

040: 31564456 30373130 5cd2e400 0500 00010200 001e8480 002dc6c0 
0200




Yea, 0x200 and we send 0x300, so maybe that's the cause of the message


With the patch you sent, the message is gone from dmesg. Thank you.
I didn't check (because I don't know how), but I assume that everything 
else stayed the same.


If, as you said above, these features should be supported per ithe 
standard, but aren't, perhaps it would be worth printing a warning 
(maybe under verbose boot)? But maybe it is too much hassle.


Thanks anyway, and perhaps you may commit the patch you sent me.

Thanks,
Matteo


signature.asc
Description: PGP signature

Re: nvme INVALID_FIELD in dmesg.boot

2022-05-25 Thread Matteo Riondato 

On 2022-05-25 at 11:29 EDT, Warner Losh  wrote:


SET FEATURES (opcode 9) feature 0xb is indeed async event 
configuration.

0x31f is:
SMART WARNING for available spares (0x1)
SMART warning for temperature (0x2)
SMART WARNING for device reliability (0x4)
SMART WARNING for being read only (0x8)
SMART WARNING for volatile memory backup (0x10)
Namespace attribute change events (0x100)
Firmware activation events (0x200)

I wonder which one of those it doesn't like. My reading of the standard 
suggests that those should always be supported for a 1.2 and later 
drive... Thought maybe with the possible exception of the volatile 
memory backup, so let me do some digging here...


We can get the last two items from OAES field of the controller 
identificaiton data. This is bytes 95:92, which if I'm counting right 
is the last word on the 040: line in the nvmecontrol identify -x nvmeX 
command:


040: 4e474e4b 30303150 000cca07 0023 00010200 005b8d80 0030d400 
0100

--^


On my system:

040: 31564456 30373130 5cd2e400 0500 00010200 001e8480 002dc6c0 
0200


(same for all nvmeX, as far as I can tell)

It looks like we don't currently test these bits before we add the last 
two (we do it unconditionally for >= 1.2, and maybe we should check 
these bits >= 1.2).


Would you be able to test a fix for this?


Yes, I would be happy to, but I cannot do it for a couple of weeks 
(running simulations for a deadline).


Thanks,
Matteo


signature.asc
Description: PGP signature

Re: nvme INVALID_FIELD in dmesg.boot

2022-05-25 Thread Matteo Riondato 


> On May 25, 2022, at 9:58 AM, Alexander Motin  wrote:
> 
> On 25.05.2022 08:25, Matteo Riondato wrote:
>> My dmesg.boot contains the following entries containing "INVALID_FIELD" 
>> about nvme (I use nda(4) for my nvme disks, with hw.nvme.use_nvd=0 in 
>> loader.conf):
>> trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
>> nvme0:  mem 0xb861-0xb8613fff irq 40 at device 0.0 
>> numa-domain 0 on pci7
>> nvme1:  mem 0xb851-0xb8513fff irq 47 at device 0.0 
>> numa-domain 0 on pci8
>> nvme2:  mem 0xc5e1-0xc5e13fff irq 48 at device 0.0 
>> numa-domain 0 on pci10
>> nvme3:  mem 0xc5d1-0xc5d13fff irq 55 at device 0.0 
>> numa-domain 0 on pci11
>> nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b cdw11:031f
>> nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b cdw11:031f
>> nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b cdw11:031f
>> nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b cdw11:031f
>> nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
>> nda0 at nvme0 bus 0 scbus16 target 0 lun 1
>> nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> nda1 at nvme1 bus 0 scbus17 target 0 lun 1
>> nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> nda2 at nvme2 bus 0 scbus18 target 0 lun 1
>> nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> nda3 at nvme3 bus 0 scbus19 target 0 lun 1
>> nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
>> The disks seem to work fine, from what I can tell.
>> Are the "INVALID_FIELD" messages harmless, or can they be avoided with some 
>> tuning, or maybe with some patch?
> 
> Those messages mean that driver tried to enable certain types of asynchronous 
> events, but probably the hardware does not support some of those.  If you 
> wish to experiment we could try to mask some of the bits in 
> nvme_ctrlr_configure_aer() function to find out which one exactly, but for 
> discontinued drives 4-5 years old it might not have too much sense.  It 
> should not be critical unless you either overheat them, or somehow else they 
> fail and wish to report it.

Thank you, Alexander.

One question though: the messages report that the driver tried to set (?) cdw10 
and cdw11, but the INVALID_FIELD is about cdw0 (sorry, I have no idea what 
these “cwd” mean).  Is that expected? Unrelated?

(The disks are Intel DC P4510, I don’t know how long they’ve been around)

Thanks,
Matteo

nvme INVALID_FIELD in dmesg.boot

2022-05-25 Thread Matteo Riondato 

Dear list,

My dmesg.boot contains the following entries containing "INVALID_FIELD" 
about nvme (I use nda(4) for my nvme disks, with hw.nvme.use_nvd=0 in 
loader.conf):


trismegistus ~ % grep -e 'nvme[0-9]\?' /var/run/dmesg.boot
nvme0:  mem 0xb861-0xb8613fff irq 40 at device 0.0 
numa-domain 0 on pci7
nvme1:  mem 0xb851-0xb8513fff irq 47 at device 0.0 
numa-domain 0 on pci8
nvme2:  mem 0xc5e1-0xc5e13fff irq 48 at device 0.0 
numa-domain 0 on pci10
nvme3:  mem 0xc5d1-0xc5d13fff irq 55 at device 0.0 
numa-domain 0 on pci11
nvme0: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b 
cdw11:031f

nvme0: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme1: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b 
cdw11:031f

nvme1: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme2: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b 
cdw11:031f

nvme2: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nvme3: SET FEATURES (09) sqid:0 cid:15 nsid:0 cdw10:000b 
cdw11:031f

nvme3: INVALID_FIELD (00/02) sqid:0 cid:15 cdw0:0
nda0 at nvme0 bus 0 scbus16 target 0 lun 1
nda0: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda1 at nvme1 bus 0 scbus17 target 0 lun 1
nda1: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda2 at nvme2 bus 0 scbus18 target 0 lun 1
nda2: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link
nda3 at nvme3 bus 0 scbus19 target 0 lun 1
nda3: nvme version 1.2 x4 (max x4) lanes PCIe Gen3 (max Gen3) link

The disks seem to work fine, from what I can tell.

Are the "INVALID_FIELD" messages harmless, or can they be avoided with 
some tuning, or maybe with some patch?


Thanks,
Matteo


signature.asc
Description: PGP signature

Re: build with WITHOUT_GPL_DTC=y broken?

2017-02-13 Thread Matteo Riondato 

> On Feb 13, 2017, at 3:57 PM, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 13 Feb 2017, at 20:27, Matteo Riondato <mat...@freebsd.org> wrote:
>> 
>>> On Feb 13, 2017, at 1:58 PM, Dimitry Andric <d...@freebsd.org> wrote:
>>> On 13 Feb 2017, at 16:53, Matteo Riondato <mat...@freebsd.org> wrote:
>>>> 
>>>> When I build world with WITHOUT_GPL_DTC=y in src.conf (complete file after 
>>>> the error) I get the following error in stage 1.2: bootstrap tools. This 
>>>> is not a recent breakage, I’ve experienced it for a while.
>>>> 
>>>> ===> usr.bin/dtc (obj,all,install)
>>>> /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc
>>>> echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a 
>>>> >> .depend
>>>> echo dtc: /usr/lib/libc++.a >> .depend
>>>> c++  -O2 -pipe -DNDEBUG -MD -MF.depend.dtc.o -MTdtc.o -Qunused-arguments 
>>>> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-rtti 
>>>> -fno-exceptions  -Wno-c++11-extensions -c /usr/src/usr.bin/dtc/dtc.cc -o 
>>>> dtc.o
>>>> c++  -O2 -pipe -DNDEBUG -MD -MF.depend.input_buffer.o -MTinput_buffer.o 
>>>> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 
>>>> -fno-rtti -fno-exceptions  -Wno-c++11-extensions -c 
>>>> /usr/src/usr.bin/dtc/input_buffer.cc -o input_buffer.o
>>>> /usr/src/usr.bin/dtc/input_buffer.cc:547:53: error: type 'dtc::(anonymous 
>>>> namespace)::expression' is not a direct or virtual base of 
>>>> 'binary_operator<Precedence, Op>'
>>>> binary_operator(source_location l, const char *) : expression(l) {}
>>>>^~
>>> 
>>> Which FreeBSD version are you running on the host?  I've just tried
>>> building head/usr.bin/dtc on 12-CURRENT, 11-STABLE and 10-STABLE, but it
>>> all works just fine for me.
>> 
>> Very interesting. I’m using 12.0-CURRENT #2 r313159.
>> 
>> I even did two 'make cleandir' in /usr/src and removed /usr/obj/ , and still 
>> it does not compile.
> 
> I see now, this is because you are using WITHOUT_ASSERT_DEBUG.  This
> adds -DNDEBUG to CFLAGS, and apparently you are the first person to hit
> this NDEBUG-only code. :)
> 
> I committed a fix in r313709.

Thank you!

Matteo



signature.asc
Description: Message signed with OpenPGP

Re: build with WITHOUT_GPL_DTC=y broken?

2017-02-13 Thread Matteo Riondato 

> On Feb 13, 2017, at 1:58 PM, Dimitry Andric <d...@freebsd.org> wrote:
> 
> On 13 Feb 2017, at 16:53, Matteo Riondato <mat...@freebsd.org> wrote:
>> 
>> When I build world with WITHOUT_GPL_DTC=y in src.conf (complete file after 
>> the error) I get the following error in stage 1.2: bootstrap tools. This is 
>> not a recent breakage, I’ve experienced it for a while.
>> 
>> ===> usr.bin/dtc (obj,all,install)
>> /usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc
>> echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> 
>> .depend
>> echo dtc: /usr/lib/libc++.a >> .depend
>> c++  -O2 -pipe -DNDEBUG -MD -MF.depend.dtc.o -MTdtc.o -Qunused-arguments 
>> -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-rtti 
>> -fno-exceptions  -Wno-c++11-extensions  -c /usr/src/usr.bin/dtc/dtc.cc -o 
>> dtc.o
>> c++  -O2 -pipe -DNDEBUG -MD -MF.depend.input_buffer.o -MTinput_buffer.o 
>> -Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 
>> -fno-rtti -fno-exceptions  -Wno-c++11-extensions  -c 
>> /usr/src/usr.bin/dtc/input_buffer.cc -o input_buffer.o
>> /usr/src/usr.bin/dtc/input_buffer.cc:547:53: error: type 'dtc::(anonymous 
>> namespace)::expression' is not a direct or virtual base of 
>> 'binary_operator<Precedence, Op>'
>>   binary_operator(source_location l, const char *) : expression(l) {}
>>  ^~
> 
> Which FreeBSD version are you running on the host?  I've just tried
> building head/usr.bin/dtc on 12-CURRENT, 11-STABLE and 10-STABLE, but it
> all works just fine for me.

Very interesting. I’m using 12.0-CURRENT #2 r313159.

I even did two 'make cleandir' in /usr/src and removed /usr/obj/ , and still it 
does not compile.

Matteo



signature.asc
Description: Message signed with OpenPGP

build with WITHOUT_GPL_DTC=y broken?

2017-02-13 Thread Matteo Riondato 
When I build world with WITHOUT_GPL_DTC=y in src.conf (complete file after the 
error) I get the following error in stage 1.2: bootstrap tools. This is not a 
recent breakage, I’ve experienced it for a while.

===> usr.bin/dtc (obj,all,install)
/usr/obj/usr/src/tmp/usr/src/usr.bin/dtc created for /usr/src/usr.bin/dtc
echo dtc: /usr/lib/libc.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a >> 
.depend
echo dtc: /usr/lib/libc++.a >> .depend
c++  -O2 -pipe -DNDEBUG -MD -MF.depend.dtc.o -MTdtc.o -Qunused-arguments 
-I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 -fno-rtti -fno-exceptions  
-Wno-c++11-extensions  -c /usr/src/usr.bin/dtc/dtc.cc -o dtc.o
c++  -O2 -pipe -DNDEBUG -MD -MF.depend.input_buffer.o -MTinput_buffer.o 
-Qunused-arguments -I/usr/obj/usr/src/tmp/legacy/usr/include -std=c++11 
-fno-rtti -fno-exceptions  -Wno-c++11-extensions  -c 
/usr/src/usr.bin/dtc/input_buffer.cc -o input_buffer.o
/usr/src/usr.bin/dtc/input_buffer.cc:547:53: error: type 'dtc::(anonymous 
namespace)::expression' is not a direct or virtual base of 
'binary_operator'
binary_operator(source_location l, const char *) : expression(l) {}
   ^~
/usr/src/usr.bin/dtc/input_buffer.cc:653:8: error: using declaration refers 
into 'binary_operator<5, modulus >::', which is not a base 
class of 'divmod'
using binary_operator<5, T>::binary_operator;
  ^~~
/usr/src/usr.bin/dtc/input_buffer.cc:687:15: note: in instantiation of template 
class 'dtc::(anonymous namespace)::divmod' requested here
expr = new divmod(l, "/");
   ^
/usr/src/usr.bin/dtc/input_buffer.cc:654:8: error: using declaration refers 
into 'binary_operator_base::', which is not a base class of 
'divmod'
using binary_operator_base::result;
  ^~
/usr/src/usr.bin/dtc/input_buffer.cc:655:22: error: only virtual member 
functions can be marked 'override'
result operator()() override
^~~~
/usr/src/usr.bin/dtc/input_buffer.cc:653:8: error: using declaration refers 
into 'binary_operator<5, divides >::', which is not a base 
class of 'divmod'
using binary_operator<5, T>::binary_operator;
  ^~~
/usr/src/usr.bin/dtc/input_buffer.cc:693:15: note: in instantiation of template 
class 'dtc::(anonymous namespace)::divmod' requested here
expr = new divmod(l, "/");
   ^
/usr/src/usr.bin/dtc/input_buffer.cc:654:8: error: using declaration refers 
into 'binary_operator_base::', which is not a base class of 
'divmod'
using binary_operator_base::result;
  ^~
/usr/src/usr.bin/dtc/input_buffer.cc:655:22: error: only virtual member 
functions can be marked 'override'
result operator()() override
^~~~
/usr/src/usr.bin/dtc/input_buffer.cc:1201:78: error: use of undeclared 
identifier 'errno'
fprintf(stderr, "Unable to open file '%s'.  %s\n", 
path.c_str(), strerror(errno));

  ^
8 errors generated.
*** Error code 1

Stop.
make[3]: stopped in /usr/src/usr.bin/dtc
*** Error code 1

Stop.
make[2]: stopped in /usr/src
*** Error code 1

Stop.
make[1]: stopped in /usr/src
*** Error code 1

Stop.
make: stopped in /usr/src



### /etc/src.conf

WITH_BSD_GREP=y
WITHOUT_AMD=y
WITHOUT_APM=y
WITHOUT_ASSERT_DEBUG=y
WITHOUT_ATM=y
WITHOUT_AUDIT=y
WITHOUT_AUTOFS=y
WITHOUT_BHYVE=y
WITHOUT_BLACKLIST=y
WITHOUT_BLUETOOTH=y
WITHOUT_BOOTPARAMD=y
WITHOUT_BOOTPD=y
WITHOUT_BSNMP=y
WITHOUT_CAPSICUM=y
WITHOUT_CASPER=y
WITHOUT_CDDL=y
WITHOUT_CUSE=y
WITHOUT_DEBUG_FILES=y
WITHOUT_EE=y
WITHOUT_EXAMPLES=y
WITHOUT_FLOPPY=y
WITHOUT_FREEBSD_UPDATE=y
WITHOUT_GAMES=y
WITHOUT_GPL_DTC=y
WITHOUT_CTM=y
WITHOUT_HESIOD=y
WITHOUT_HAST=y
WITHOUT_HTML=y
WITHOUT_HYPERV=y
WITHOUT_IPFILTER=y
WITHOUT_IPFW=y
WITHOUT_ISCSI=y
WITHOUT_KERBEROS=y
WITHOUT_LIB32=y
WITHOUT_NDIS=y
WITHOUT_NIS=y
WITHOUT_PC_SYSINSTALL=y
WITHOUT_PPP=y
WITHOUT_PROFILE=y
WITHOUT_QUOTAS=y
WITHOUT_RBOOTD=y
WITHOUT_RCMDS=y
WITHOUT_ROUTED=y
WITHOUT_SHARED_DOCS=y
WITH_SORT_THREADS=y
WITHOUT_SVNLITE=y
WITHOUT_SYSINSTALL=y
WITHOUT_SYSCONS=y
WITHOUT_TALK=y
WITHOUT_TCP_WRAPPERS=y
WITHOUT_TELNET=y
WITHOUT_TESTS=y
WITHOUT_TFTP=y
WITHOUT_TIMED=y
WITHOUT_WIRELESS=y
WITHOUT_WPA_SUPPLICANT_EAPOL=y
WITHOUT_ZFS=y

No WITH_META_MODE in /etc/src-env.conf

Matteo



signature.asc
Description: Message signed with OpenPGP

Re: Signal 12 on make update (or any target in /usrc/src)

2016-08-10 Thread Matteo Riondato 

> On Aug 10, 2016, at 10:41 AM, Konstantin Belousov <kostik...@gmail.com> wrote:
> On Wed, Aug 10, 2016 at 10:33:23AM -0400, Matteo Riondato wrote:
>> Hi all,
>> 
>> I recently upgraded from a late June (pre 11-branch, as far as I can tell) 
>> revision to r303771.
>> 
>> Now, running ???make update??? (or buildworld, ???) in /usr/src fails with a 
>> signal 12:
>> 
>> matteo@triton:/usr/src$ sudo make update
>> Password:
>> *** Signal 12
> 
> You did not updated, I think.  You, most likely, inly updated the kernel,
> but left the old userspace in place, at least libc.

That would be surprising but it may have happened, as I don’t remember without 
doubts to have run installworld :/

> Signal 12 is SIGSYS, which means that the program tries to use a syscall
> not implemented by the kernel.  My guess is that your kernel lacks option
> COMPAT_FREEBSD10, and the failing syscall is pipe(2).

Indeed I do not have COMPAT_FREEBSD10, because I believed my previous world 
revision was >302092, as noted by the entry about pipe(2) in UPDATING.

Any suggestion on how to fix this?
Boot the old kernel, add COMPAT_FREEBSD10 to kernel config, and rebuild/install 
world and kernel perhaps?

Thanks for the help!

Matteo



signature.asc
Description: Message signed with OpenPGP using GPGMail

Signal 12 on make update (or any target in /usrc/src)

2016-08-10 Thread Matteo Riondato 
Hi all,

I recently upgraded from a late June (pre 11-branch, as far as I can tell) 
revision to r303771.

Now, running “make update” (or buildworld, …) in /usr/src fails with a signal 
12:

matteo@triton:/usr/src$ sudo make update
Password:
*** Signal 12

Stop.
make: stopped in /usr/src
.ERROR_TARGET='update'
.ERROR_META_FILE=''
.MAKE.LEVEL='0'
MAKEFILE=''
.MAKE.MODE='normal'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src'
.TARGETS='update'
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MAKEOBJDIRPREFIX='/usr/obj'
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20160606'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src

Installing ports using “make install” works.

Relevant (?) section of src.conf:
WITH_CCACHE_BUILD=y
WITH_SYSTEM_COMPILER=y

src-env.conf:
WITH_META_MODE=yes

make.conf:
KERNCONF=TRITON
CPUTYPE?=k8-sse3
SVN_UPDATE=y
COPTFLAGS=-O2 -pipe
MALLOC_PRODUCTION=y

Any hints?

Thanks,
Matteo



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: 11.0 -r300944 build attempted WITH_META_MODE failed [amd64 targeting powerpc64 via devel/powerpc64-gcc use]

2016-05-30 Thread Matteo Riondato 

> On May 30, 2016, at 11:29 AM, Bryan Drewery  wrote:
> 
> I should have mentioned that to enable META_MODE after not having it on
> you should do a 'make cleanworld' first.

This should probably be mentioned in src.conf(5) then.

Best,
Matteo



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: if_tun failed to register

2003-11-04 Thread Matteo Riondato 
Il Mar, 2003-11-04 alle 14:17, Antoine Jacoutot ha scritto:
 Max Laier wrote:
   AJ 
   AJ module_register: module if_tun already exists!
   AJ Module if_tun failed to register: 17
   AJ can't re-use a leaf (if_tun_debug)!
   AJ 
  
  AJ Is there a kernel option I missed ? I already have device tun in
  AJ my kernel config file.
  
  This might be due to missing/incomplete mergemaster after
  installworld? Try to remove your rc.d related stuff from etc before
  running mergemaster -i. The scripts should not try to kldload
  if_tun if you allready have tun interfaces (built in).
 
 Well, it did not change anything :(
 What is really strange is that tun is compiled in the kernel, but the 
 module is started anyway ???

I had the same problem last year and solved it by removing
device tun 
from the kernel configuration file.
Best regards
-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

Re: 10/23 cvsup buildworld failure

2003-10-24 Thread Matteo Riondato 
Il Ven, 2003-10-24 alle 17:47, Michael L. Squires ha scritto:
  Tinderbox
   /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/lib/libfetch/common.c:60: 
 error: initializer element is not constant
  
  Under 5.1-CURRENT or i386 cvsuped on 10/23 I get the same failure, with
  the additional error message
  
  /usr/src/lib/libfetch/common.c:58: error:  'EAINONAME' undeclared here (not in a 
 function)
  
  Other error messages are similar or the same.
 
  I have re-cvsup'd and am trying again.

You cvsup'd on at a bad moment, because ume@ correct this error at
2003/10/23 20:49:38 PDT with revision 1.29 of netdb.h

Regards
-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

Re: cannot build kernel

2003-10-19 Thread Matteo Riondato 
Il Dom, 2003-10-05 alle 10:03, Matt Douhan ha scritto:
 cvsup this morning 5th oct 12.05 PM
 
 I get the following error during buildkernel
 
 
 cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline 
 -Wcast-qual  -fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/src/
 sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/
 src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL 
 -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding 
 -Werror  /usr/src/sys/dev/usb/usb.c
 /usr/src/sys/dev/usb/usb.c: In function `usbioctl':
 /usr/src/sys/dev/usb/usb.c:555: warning: assignment from incompatible pointer 
 type

No problem here with revision 1.93 of usb.c
cvsup this morning 2003.10.05 10.35am (west Europe time)
Regards
-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: More ULE bugs fixed.

2003-10-17 Thread Matteo Riondato 
Il Mer, 2003-10-15 alle 09:51, Jeff Roberson ha scritto:
 I fixed two bugs that were exposed due to more of the kernel running
 outside of Giant.  ULE had some issues with priority propagation that
 stopped it from working very well.
 
 Things should be much improved. 

On my Athlon XP 2000+ the situation is much better. No mouse jerkiness 
whatever the load of the sistem is. The system respond better in any situation.
I'm using libc_r, so no problem with any Gnome app caused (probably) by KSE.
Best Regards.
-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

ata problem with 13/10/2003 current

2003-10-14 Thread Matteo Riondato 
After having update my -CURRENT box to yesterday afternoon (Central
Europe Time) sources, I can't get it to boot. It stops probing ata1:
GEOM: create disk ad0 dp=0xc4536a70
ad0: 57259MB MAXTOR 6L060J3 [116336/16/63] at ata0-master UDMA133
GEOM: create disk ad1 dp=0xc4915a70
ad1: 38172MB QUANTUM FIREBALLP AS40.0 [77557/16/63] at ata0-slave \
UDMA100 
ata1: resetting devices ..
acd0: FAILURE - SETFEATURES status=51 READY,DSC,ERROR error=4ABORTED
done
acd0: FAILURE - SETFEATURES device lockup-removed

And it stops here.

On ata1 there are a Liteon CD-ReWriter 48x12x48x (acd0)
and a LG DVD-ROM Drive DRD-8160B (acd1)

I never had problem with ATAng before, so it is probably related to a
recent commit.

Best Regards

--
Rionda aka Matteo Riondato
GUFI Staff Member (http://www.gufi.org)


___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ata problem with 13/10/2003 current

2003-10-14 Thread Matteo Riondato 
Il Mar, 2003-10-14 alle 15:09, Soren Schmidt ha scritto:
 It seems Matteo Riondato wrote:
  
  I never had problem with ATAng before, so it is probably related to a
  recent commit.
 
 Could you try this patch please:I

 Index: ata-queue.c
 ===

I cannot patch my system:
kaiser# cd /usr/src/sys/dev/ata/
kaiser# patch  /home/rionda/ata-patch.patch 
Hmm...  Looks like a unified diff to me...
The text leading up to this was:
--
|Index: ata-queue.c
|===
|RCS file: /home/ncvs/src/sys/dev/ata/ata-queue.c,v
|retrieving revision 1.8
|diff -u -r1.8 ata-queue.c
|--- ata-queue.c 12 Oct 2003 12:38:03 -  1.8
|+++ ata-queue.c 13 Oct 2003 13:05:01 -
--
Patching file ata-queue.c using Plan A...
Hunk #1 failed at 315.
1 out of 1 hunks failed--saving rejects to ata-queue.c.rej
done
kaiser#

 -Søren

Regards
-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ata problem with 13/10/2003 current

2003-10-14 Thread Matteo Riondato 
Il Mar, 2003-10-14 alle 15:09, Soren Schmidt ha scritto:
 It seems Matteo Riondato wrote:
  After having update my -CURRENT box to yesterday afternoon (Central
  Europe Time) sources, I can't get it to boot. It stops probing ata1:
  GEOM: create disk ad0 dp=0xc4536a70
  
  I never had problem with ATAng before, so it is probably related to a
  recent commit.
 
 Could you try this patch please:
 
 Index: ata-queue.c
 =

It works perfectly and solves my problem.
Thanks.
Do you plan to commit it?
Best Regards

-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Sched_Ule

2003-10-10 Thread Matteo Riondato 
Il Ven, 2003-10-10 alle 04:54, Jonathan E Fosburgh ha scritto:
 On Thursday 09 October 2003 08:16 pm, Evan Dower wrote:
  How many of the people experiencing SCHED_ULE related problems (primarily
  lagging) are also using nvidia-driver? I know I am, and I'm pretty sure
  Arjan is. Could there be a connection?
 
 I switched back to the XFree86 nv driver earlier today and still have trouble.  
 moused is running and it is  a PS/2 mouse.

Same situation here.

-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Status of SCHED_ULE?

2003-09-28 Thread Matteo Riondato 
Il Dom, 2003-09-28 alle 15:45, Arjan van Leeuwen ha scritto:

  Ahh I tell you the other difference. I had a USB mouse when I tried ULE
  with 5.1-release and it stuttered. It's just a ps2 one on the current
  kernel where it's not stuttering.
 
  Matt.
 
 I have a PS/2 mouse, I run -CURRENT from 2 days ago, and I experience the 
 stuttering too.
 
 It happens when compiling stuff, when loading complicated pages in Mozilla 
 Firebird, and when logging out of GNOME 2.4 (the 'background fade' animation 
 brings my Athlon XP 2000+ to its knees when I use SCHED_ULE).


Same problem here, with a PS/2 Mouse on my Athlon XP 2000+, usign
Firebird, Ximian Evolution and others applications with SCHED_ULE.

-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata

Re: howto: LiveCD FBSD question

2003-08-14 Thread Matteo Riondato 
Il Gio, 2003-08-14 alle 01:09, Usher Abraham ha scritto:
 Does anyone have a howto on how to create a custom LiveCD (FreeBSD)
 CDROM in English?

http://www.freesbie.org/?section=doc-en

Best Regards

-- 
Rionda aka Matteo Riondato
G.U.F.I Staff Member (http://www.gufi.org)
BSD-FAQ-it Main Developer (http://www.gufi.org/~rionda)
GPG key at: http://www.riondabsd.net/riondagpg.asc
Sent from: kaiser.sig11.org running FreeBSD-5.1-CURRENT


signature.asc
Description: Questa parte del messaggio =?ISO-8859-1?Q?=E8?= firmata