Re: FreeBSD Core Team Response to Controversial Social Media Posts

[v]

On Sun, May 12, 2019, at 7:50 PM, Sulev-Madis Silber wrote:
> On Friday, May 10, 2019, FreeBSD Core Team Secretary <
> core-secret...@freebsd.org> wrote:
> > The FreeBSD Core Team is aware of recent controversial statements made
> > on social media by a FreeBSD developer.  We, along with the Code of
> > Conduct review committee, are investigating the matter and will decide
> > what action to take.  Both the Core Team and the FreeBSD Foundation
> > would like to make it clear that views shared by individuals represent
> > neither the Project nor the Foundation.
> >
> > --
> > FreeBSD Core Team
> >
> 
> 
> is this a political party?! i thought it was developer team of certain
> specific area server operating system?
> 
> first, i would like to know if this is a joke? because it must be! then, if
> it's not, what has said and by who?
 

FreeBSD Core Team and the FreeBSD Foundation can claim injury to reputation. We 
are waiting to see if they claim injury. 

“Tort: a wrongful act, other than breach of contract, that results in injury to 
another party’s person, property, dignity, or reputation, and which is 
recognized by statue or common law as a legitimate basis for liability.” (2014, 
July 30). Retrieved from https://www.youtube.com/watch?v=jQ6smN3lcnY

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

Re: FreeBSD Core Team Response to Controversial Social Media Posts

[v]

Igor et al,

Instead of debating definitions of hate speech, free speech, and trying to 
discover intent, I suggest we focus on right relationships.

https://www.youtube.com/watch?v=A14THPoc4-4

Vester



On Fri, May 17, 2019, at 12:08 AM, Igor Mozolevsky wrote:
> On Sun, 12 May 2019 at 18:28, Igor Mozolevsky wrote:
> > On Friday, 10 May 2019, FreeBSD Core Team Secretary 
> >  wrote:
> >
> > > The FreeBSD Core Team is aware of recent controversial statements made
> > > on social media by a FreeBSD developer.  We, along with the Code of
> > > Conduct review committee, are investigating the matter and will decide
> > > what action to take.
> >
> > 
> >
> > > --
> > > FreeBSD Core Team
> >
> > This seems to be a wanton  violation of Article 19 of the Universal 
> > Declaration of Human Rights [1].
> >
> > 1. https://www.un.org/en/universal-declaration-human-rights/
> 
> 
> More applicable if you think that UN declarations don't apply to you:-
>  https://www.supremecourt.gov/opinions/16pdf/15-1293_1o13.pdf
> 
> 
> -- 
> Igor M.
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>https://www.youtube.com/watch?v=A14THPoc4-4
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Problems with hda

[Justin V.]

On Thu, 4 Nov 2010, Doug Barton wrote:


On 11/04/10 11:46, Garrett Cooper wrote:

Can you try with 7.x to see if there's a similar problem? I ask
this because similar symptoms might exist with snd_emu10kx as another
person and I have hashed over in another thread.


Yes, but not right away. :)  What am I looking for when I do?


Doug

--

Nothin' ever doesn't change, but nothin' changes much.
-- OK Go

Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price.  :)  http://SupersetSolutions.com/

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




I have the same soundcard I believe..

You loaded the driver??

I built mine into the kernal:

[...@yeaguy ~]$ grep -i hda /usr/src/sys/i386/conf/HBCA
device  snd_hda


[...@yeaguy ~]$ cat /var/run/dmesg.boot | grep hd
hdac0:  mem 
0xdffdc000-0xdffd irq 16 at device 27.0 on pci0

hdac0: HDA Driver Revision: 20100226_0142
hdac0: [ITHREAD]
hdac0: HDA Codec #2: Sigmatel STAC9227X
pcm0:  at cad 2 nid 1 on hdac0
pcm1:  at cad 2 nid 1 on hdac0


Did you try playing with the MIXER??

i use rexima .. console based mixer, easy to use.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

usb issues

[justin v]

Hi,

Any advice on how to deal with this USB trouble.. ?


This is scrolling through messages..  and when i plug in my USB device,  
ANY, it is not recognized, when normally it is...




exit
[...@yeaguy ~]$ tail -f /var/log/messages
Dec 21 22:13:11 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:11 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:13 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:13 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:15 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:15 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:16 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:16 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:18 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:18 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:20 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:20 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3



Dec 21 22:13:21 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:21 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:23 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:23 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:24 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:24 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:26 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:26 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3
Dec 21 22:13:27 yeaguy kernel: uhub_reattach_port: port 3 reset failed,  
error=USB_ERR_TIMEOUT
Dec 21 22:13:27 yeaguy kernel: uhub_reattach_port: device problem  
(USB_ERR_TIMEOUT), disabling port 3




--
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: usb issues

[Justin V.]

On Wed, 22 Dec 2010, Hans Petter Selasky wrote:


On Wednesday 22 December 2010 07:15:53 justin v wrote:

Hi,

Any advice on how to deal with this USB trouble.. ?


This is scrolling through messages..  and when i plug in my USB device,
ANY, it is not recognized, when normally it is...



What version of FreeBSD are you using?

Have you tried using an external USB HUB?

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




Im on 8.1.

Everything on this box has been pretty solid expect USB and WIFI...

Ive tried an external connector, not a hub.. the extension that came with 
my keyboard and mouse..

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

Re: usb issues

[Justin V.]

On Thu, 23 Dec 2010, Hans Petter Selasky wrote:


On Wednesday 22 December 2010 21:31:19 Kim Culhan wrote:

On Wed, December 22, 2010 3:00 am, Hans Petter Selasky wrote:

On Wednesday 22 December 2010 07:15:53 justin v wrote:

Hi,

Any advice on how to deal with this USB trouble.. ?


This is scrolling through messages..  and when i plug in my USB device,
ANY, it is not recognized, when normally it is...


What version of FreeBSD are you using?

Have you tried using an external USB HUB?


Seeing this on 8.2-BETA1:

kernel: uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling
port 4

Also seeing some problems with hostapd and rum device at startup, could
this be related?


Could you try to apply this patch?

http://svn.freebsd.org/changeset/base/216249

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





Hi,

Thanks for the suggestion.. Do I simply replace the file??


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

Re: usb issues

[Justin V.]

On Thu, 23 Dec 2010, Hans Petter Selasky wrote:


On Thursday 23 December 2010 21:59:13 Justin V. wrote:

On Thu, 23 Dec 2010, Hans Petter Selasky wrote:

On Wednesday 22 December 2010 21:31:19 Kim Culhan wrote:

On Wed, December 22, 2010 3:00 am, Hans Petter Selasky wrote:

On Wednesday 22 December 2010 07:15:53 justin v wrote:

Hi,

Any advice on how to deal with this USB trouble.. ?


This is scrolling through messages..  and when i plug in my USB
device, ANY, it is not recognized, when normally it is...


What version of FreeBSD are you using?

Have you tried using an external USB HUB?


Seeing this on 8.2-BETA1:

kernel: uhub_reattach_port: device problem (USB_ERR_TIMEOUT), disabling
port 4

Also seeing some problems with hostapd and rum device at startup, could
this be related?


Could you try to apply this patch?

http://svn.freebsd.org/changeset/base/216249

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


Hi,

Thanks for the suggestion.. Do I simply replace the file??


No, just apply the patch by hand.

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




Im not familiar with patching I guess.. any tips?
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD EFI projects

[Greg V]

On Mon, Sep 17, 2018 at 11:09 PM, Konstantin Belousov 
 wrote:

That said, making only the loader->kernel transition from EFI 32bit to
64bit kernel should be not too hard, and even significantly simpler 
than

to make 32bit EFI load 32bit kernel. amd64 kernels already aware that
there might be no BIOS and they do not try to make vm86 calls into 
real

code, and only read memory map from the loader metadata etc.

Besides old Macs, this should also benefit newer Intel embedded-like
boards.


Hi,

I can confirm that the kernel already worked fine when booted from 
32-bit EFI.


I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 
:)


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

Re: FreeBSD EFI projects

[Greg V]

On 09/18, Rebecca Cran wrote:

On 9/18/18 4:11 AM, Greg V wrote:



I can confirm that the kernel already worked fine when booted from
32-bit EFI.

I booted an old Mac into HardenedBSD using a 32-bit-EFI build of GRUB2 :)



Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
FreeBSD boots fine, but 64-bit needs work.


Yes, of course it was 64-bit.

I don't think I ever downloaded the 32-bit one...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD EFI projects

[Greg V]

On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes 
 wrote:

 On 9/18/18 4:11 AM, Greg V wrote:

 >
 > I can confirm that the kernel already worked fine when booted from
 > 32-bit EFI.
 >
 > I booted an old Mac into HardenedBSD using a 32-bit-EFI build of 
GRUB2 :)



 Was that a 64-bit version of FreeBSD? My understanding is the 32-bit
 FreeBSD boots fine, but 64-bit needs work.


You would be hard pressed to find a system with a 64 bit CPU that
could run 64 bit FreeBSD that had a 32 bit EFI implementation.


Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the 
2007 model's firmware flashed, but I don't think that impacts FreeBSD).


And probably just the 2007 model as well :)

Also, IIRC there were some Intel Atom tablets with 32-bit EFI.

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

Re: FreeBSD EFI projects

[Greg V]

On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes 
 wrote:

 On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
  wrote:
 >>  On 9/18/18 4:11 AM, Greg V wrote:
 >>
 >>  >
 >>  > I can confirm that the kernel already worked fine when booted 
from

 >>  > 32-bit EFI.
 >>  >
 >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI build 
of

 >> GRUB2 :)
 >>
 >>
 >>  Was that a 64-bit version of FreeBSD? My understanding is the 
32-bit

 >>  FreeBSD boots fine, but 64-bit needs work.
 >
 > You would be hard pressed to find a system with a 64 bit CPU that
 > could run 64 bit FreeBSD that had a 32 bit EFI implementation.

 Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and the
 2007 model's firmware flashed, but I don't think that impacts 
FreeBSD).


Yes, that is one of the catagories of rare, a EFI-32 bit system that
was originally shipped with a 32 bit only CPU, that later got upgraded
in the field with a 64 bit CPU, that still runs a EFI-32 bios.
Are you sure the 2007 firmware is EFI32?  I would of thought
since they upgraded the base system to a 64 bit CPU they would
of shipped it with a EFI-64 bios.


The EFI firmware is technically 64 bit… but it only boots 32-bit 
binaries.


https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html

'Furthermore, it appears that although subsequently released MacBook, 
MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped with 
"Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked these 
"consumer-targeted" Macs from booting in 64-bit mode. iMac and MacBook 
Pro models released in 2007 with 64-bit EFIs seem to have been blocked 
as well.'



 And probably just the 2007 model as well :)

 Also, IIRC there were some Intel Atom tablets with 32-bit EFI.


Atom N2xx and Z5xx series Atom models cannot run x86-64


Atom Z3740 — "Instruction Set: 64-bit"
https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz

The tablet in question: ASUS VivoTab Note 8 (M80TA)
https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/

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

Re: FreeBSD EFI projects

[Greg V]

On Wed, Sep 19, 2018 at 6:31 PM, Rodney W. Grimes 
 wrote:

 On Wed, Sep 19, 2018 at 6:06 PM, Rodney W. Grimes
  wrote:
 >>  On Wed, Sep 19, 2018 at 5:34 PM, Rodney W. Grimes
 >>   wrote:
 >>  >>  On 9/18/18 4:11 AM, Greg V wrote:
 >>  >>
 >>  >>  >
 >>  >>  > I can confirm that the kernel already worked fine when 
booted

 >> from
 >>  >>  > 32-bit EFI.
 >>  >>  >
 >>  >>  > I booted an old Mac into HardenedBSD using a 32-bit-EFI 
build

 >> of
 >>  >> GRUB2 :)
 >>  >>
 >>  >>
 >>  >>  Was that a 64-bit version of FreeBSD? My understanding is 
the

 >> 32-bit
 >>  >>  FreeBSD boots fine, but 64-bit needs work.
 >>  >
 >>  > You would be hard pressed to find a system with a 64 bit CPU 
that

 >>  > could run 64 bit FreeBSD that had a 32 bit EFI implementation.
 >>
 >>  Mac mini 2006 with a Core2Duo instead of the stock CoreDuo (and 
the

 >>  2007 model's firmware flashed, but I don't think that impacts
 >> FreeBSD).
 >
 > Yes, that is one of the catagories of rare, a EFI-32 bit system 
that
 > was originally shipped with a 32 bit only CPU, that later got 
upgraded

 > in the field with a 64 bit CPU, that still runs a EFI-32 bios.
 > Are you sure the 2007 firmware is EFI32?  I would of thought
 > since they upgraded the base system to a 64 bit CPU they would
 > of shipped it with a EFI-64 bios.

 The EFI firmware is technically 64 bit? but it only boots 32-bit
 binaries.

 
https://everymac.com/mac-answers/snow-leopard-mac-os-x-faq/mac-os-x-snow-leopard-64-bit-macs-64-bit-efi-boot-in-64-bit-mode.html
 'Furthermore, it appears that although subsequently released 
MacBook,
 MacBook Air, and pre-"Mid-2010" Mac mini models all are equipped 
with
 "Core 2 Duo" 64-bit processors and 64-bit EFIs, Apple has blocked 
these
 "consumer-targeted" Macs from booting in 64-bit mode. iMac and 
MacBook
 Pro models released in 2007 with 64-bit EFIs seem to have been 
blocked

 as well.'


That is not EFI32, so that is not a test case for how FreeBSD boots
on EFI32 systems.  That is a restriction apple artificially placed
in the implementation.


Yeah, maybe not the best test case, but probably the most common one.
What matters to users is that a 32-bit loader (bootia32.efi) is 
required, whether artificially or not.



 >>  And probably just the 2007 model as well :)
 >>
 >>  Also, IIRC there were some Intel Atom tablets with 32-bit EFI.
 >
 > Atom N2xx and Z5xx series Atom models cannot run x86-64

 Atom Z3740 ? "Instruction Set: 64-bit"
 
https://ark.intel.com/products/76759/Intel-Atom-Processor-Z3740-2M-Cache-up-to-1_86-GHz


The above does not say Atom Z3xxx.  If you find a Atom
N2xx or Z5xx based system it most certainly has a EFI32.



 The tablet in question: ASUS VivoTab Note 8 (M80TA)
 https://www.asus.com/us/Tablets/ASUS_VivoTab_Note_8_M80TA/


I can not find enough detail to know for certain that tablet
actually has which version of EFI.
You are saying it has EFI32?  And if so based on what information?


Heard from someone that it only took 32-bit efi binaries.

Other Z3xxx users report the same:
https://askubuntu.com/questions/775498/ubuntu-on-32-bit-uefi-only-based-tablet-pc



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

Re: FreeBSD EFI projects

[Greg V]

On Thu, Sep 20, 2018 at 12:24 AM, Rebecca Cran  
wrote:

On 9/19/18 3:53 AM, Greg V wrote:



Yes, of course it was 64-bit.

I don't think I ever downloaded the 32-bit one...



And are you sure it was booted via EFI and not the BIOS emulation CSM 
(Compatibility Support Module)? I'm fairly sure we _don't_ support 
booting a 64-bit kernel from 32-bit EFI yet.


Well, I said I built a 32-bit-EFI version of GRUB 2, and told *that* to 
boot 64-bit FreeBSD kernel :)


Our loader.efi wasn't used.

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

Re: Good motherboard for Ryzen (first-gen)

[Greg V]

On Sat, Sep 22, 2018 at 5:53 AM, Eric van Gyzen  
wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released 
errata for the second-gen yet (as far as I know...I would love to be 
wrong).


IIRC the weird freeze/segfault bugs were only in the early batches of 
1st gen. If you get 2nd gen, you're *definitely* getting a stable chip. 
My R7 1700 is from Aug 2017, never had any issues. So a 1st gen bought 
today should be fine too of course, unless *somehow* you get very very 
very old stock.


I would like to be a cool kid with a Threadripper, but I can't 
justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 
cores.  :)
Yeah, yeah. Good discounts on 1st gen Threadripper can be found these 
days though… but still there's board cost + RAM cost (you have to 
fill up 4 memory channels on TR if you want performance to not suck).


Ideally, I want an Intel NIC, ECC memory support, and a 3-year 
warranty.


For ECC, you can google board name + ecc ram. You can often find 
reports on forums/subreddits/whatever.


Since you care about warranty, you probably don't care about 
overclocking, so do not watch the following videos: B450 boards — 
https://youtu.be/yWAwOH-egFs X470 — https://youtu.be/L8T2gzIkw78 :)


But still, good power delivery is important for an 8-core even at stock 
settings, so avoid the latest ASUS TUF board, and super cheap boards in 
general.


I have an MSI X370 SLI PLUS. The firmware is good, RGB lighting support 
is good (most important thing! lol. controllable under FreeBSD with 
https://github.com/nagisa/msi-rgb), the VRM is okay but not super great 
(8-core @ 1.39V 3.95GHz → ~100 ℃ without any direct airflow over 
the VRM heatsink). NIC is Realtek, recognized by re(4), I never tried 
it (I use a Mellanox card). Audio is Realtek, works fine 99% of the 
time (very occasionally sound stops working, sysctl 
dev.hdac.0.polling=1 brings it back). There is a pin header for the SPI 
flash chip  to recover a failed firmware update (I actually did this 
once :D), but the pins are tiny (2mm instead of the usual 2.54).


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

Re: best linux emulation for 12-current

[Greg V]

On Thu, Oct 4, 2018 at 7:31 PM, tech-lists  wrote:

Hi,

Which is the better package for linux emulation on 12-alpha8 - c6 or 
c7? Or something else?


Emulation is for boinc_client to take linux work


c7 is newer, of course it's better, c6 is very old stuff. But you can 
also just extract any Linux distro (that's not *too* new — Ubuntu 
16.04 cloud image works) into a directory and chroot into it.


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

Re: linux-c7 and opengl apps?

[Greg V]

On Wed, Oct 3, 2018 at 12:36 PM, Johannes Lundberg  
wrote:

Hi

Have anyone successfully run opengl apps with linux-c7?

Linux opengl apps works great with linux-c6 on gpu < kabylake but
linux-c6-dri does not include support for kabylake gpus.
Linux glxinfo in c7 show support for hardware rendering on kabylake 
but any

attempt to run an opengl app results in application seg fault or other
crash (I believe this is also the case with skylake gpus on linux-c7).


On AMD Polaris: everything used to work in an ubuntu 16.04 chroot 
(currently having "can't open display :0" with that, probably 
forgetting something).


Trying Unigine Heaven with c7, segfaults right now. glxinfo shows 
everything correctly though.



Is there any way to run gdb on linux apps/core dumps?


There was a BSDCan talk that mentioned some gdb solutions:

https://www.youtube.com/watch?v=9N3NrPeCJpk
https://www.bsdcan.org/2018/schedule/attachments/473_linuxulator-notes-bsdcan2018.txt

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

Re: linux-c7 and opengl apps?

[Greg V]

On Fri, Oct 5, 2018 at 11:21 PM, Theron  wrote:

% /compat/linux/opt/VirtualGL/bin/glxinfo | grep OpenGL
libGL error: MESA-LOADER: failed to retrieve device information


Do you have linsysfs mounted?

Try reading /compat/linux/sys/class/drm/card0/device/uevent.

Mesa won't retrieve device information without linsysfs.
I wrote the linsysfs patch that exposed the info there so that recent 
Mesa would work :)

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=222375
(Wow, that was a year ago… interesting note from there: you might 
need to set LIBGL_DRI3_DISABLE=1 for Linux apps)


Also, what's with the "/opt/VirtualGL"? Are you using mesa from 
linux-c7 or something… weird?


This problem has existed forever.  I am not sure it is actually a 
fault in Linux emulation, as these very same symptoms ("failed to 
retrieve device information" message, console freeze) existed back in 
FreeBSDDesktop/freebsd-base-graphics days when attempting to run 
purely FreeBSD OpenGL apps.  At the time the workaround was a patch 
to Mesa's GPU detection; the underlying kernel problem wasn't 
addressed.


There was a somewhat related issue (but not the same one, FreeBSD and 
Linux versions of mesa/libdrm use different mechanisms to get device 
info).
Mostly affected Wayland-EGL clients — they would try to access 
/dev/dri/card408 instead of /dev/dri/card0, fail to get info and fall 
back to software rendering.
I fixed it a while ago: 
https://gitlab.freedesktop.org/mesa/mesa/commit/db8519a369261cdedda50852facc45616d4eba28


But I never saw console freezes when Mesa couldn't properly detect the 
GPU o_0


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

Re: Problem compiling rust

[Greg V]

On Sat, Oct 6, 2018 at 3:26 PM, Filippo Moretti  
wrote:
  extracting 
cargo-0.29.0-x86_64-unknown-freebsd/cargo/share/doc/cargo/README.md  
extracting cargo-0.29.0-x86_64-unknown-freebsd/cargo/manifest.in  
extracting 
cargo-0.29.0-x86_64-unknown-freebsd/cargo/etc/bash_completion.d/cargo 
 extracting cargo-0.29.0-x86_64-unknown-freebsd/cargo/bin/cargo  
extracting 
cargo-0.29.0-x86_64-unknown-freebsd/cargo/share/zsh/site-functions/_cargorunning: 
/usr/ports/lang/rust/work/rustc-1.29.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo 
build --manifest-path 
/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/Cargo.toml 
--frozenTraceback (most recent call last):  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/x.py", line 20, in 
bootstrap.main()  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 843, in mainbootstrap(help_triggered)  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 819, in bootstrapbuild.build_bootstrap()  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 646, in build_bootstraprun(args, env=env, 
verbose=self.verbose)  File 
"/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/bootstrap.py", 
line 148, in runraise RuntimeError(err)RuntimeError: failed to 
run: 
/usr/ports/lang/rust/work/rustc-1.29.1-src/build/x86_64-unknown-freebsd/stage0/bin/cargo 
build --manifest-path 
/usr/ports/lang/rust/work/rustc-1.29.1-src/src/bootstrap/Cargo.toml 
--frozen*** Error code 1

Stop.make[1]: stopped in /usr/ports/lang/rust*** Error code 1
Stop.make: stopped in /usr/ports/lang/rust[root@sting 
/usr/ports/lang/rust]# I always had this problem trying to compiling 
rust (amd64 alpha3),as I only need it to compile firefox I wonder if 
it is possible to disable its building.Thanks Filippo


You don't need to compile Rust from source to compile Firefox.
You can just 'pkg install rust' to get Rust from a binary package.

BTW, this error message doesn't say much, but if cargo fails, you might 
be out of memory.


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

Re: Good motherboard for Ryzen (first-gen)

[Greg V]

On Thu, Oct 11, 2018 at 11:40 PM, Eric van Gyzen  
wrote:

On 9/21/18 9:53 PM, Eric van Gyzen wrote:
I would like to build a Ryzen desktop.  Can anyone recommend a good 
motherboard?


I'm planning on a first-gen, because the second-gen has similar 
stability problems as the first-gen had, and AMD hasn't released 
errata for the second-gen yet (as far as I know...I would love to 
be wrong).


I would like to be a cool kid with a Threadripper, but I can't 
justify the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 
cores.  :)


Ideally, I want an Intel NIC, ECC memory support, and a 3-year 
warranty.


Thanks for all the responses.  They were very helpful.  Here is what 
I ended up building:


Mobo:  ASUS Prime X470-Pro
CPU:   Ryzen 7 2700X 3.7GHz 8-Core
RAM:   Corsair Vengeance LPX 2 x 16GB DDR4-2666 PC4-21300 C16
Video: ASUS GeForce GTX 1060 6GB
Disk:  Samsung 970 EVO 500GB TLC NAND M.2 2280 PCIe NVMe 3.0 x4
PSU:   EVGA SuperNOVA G3 750 Watt 80 Plus Gold ATX
Fan:   Cooler Master Hyper 212 EVO Universal CPU Cooler

It's running FreeBSD head.  BIOS version is 4018 (2018-07-12).  So 
far, it has been perfectly stable.  No crashes, no lockups.  It has 
been my work-from-home desktop for just over a week now.  I'm 
overclocking the memory a little, but nothing else.  The NIC works.  
The sound works, though I've only tested the rear analog output.  The 
video card works with the nvidia-driver, currently 390.87.  It's 
driving two 2560x1440 monitors over HDMI.


The only problem so far:  I can't get NUMA enabled.  I've set Memory 
Interleave to "off", but the BIOS still doesn't generate an ACPI SRAT 
table.  I'm still working on this.


You won't ever get NUMA enabled.

Because Ryzen 7 2700X is not a NUMA processor! :)

Only Threadripper and EPYC are.

Desktop Ryzen has a "slightly NUMA-like" thing going on, it's 
recognized as 'cache groups' in the line:
FreeBSD/SMP: 1 package(s) x 2 cache groups x 4 core(s) x 2 hardware 
threads


But it's not actual NUMA.

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

Re: Current status of Ryzen (non-)support

[Greg V]

On Sun, Oct 21, 2018 at 7:09 PM, Hannes Hauswedell 
 wrote:

Hi everyone,

I wanted to ask what the current status of Ryzen support is and/or
whether any new changes are planned.

My situation:
* second generation Ryzen: 2600X
* running -CURRENT
* I have done the things described here:
https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
* no full system freezes, but under load, e.g. building with 12 
threads,

programs start to segfault.
* memtest86 ran through without issues
* on a Linux dual boot I haven't had any issues

Is this a known problem? Anythings I can do about it? I thought the
Ryzen problem were only supposed to happen with first generation 
CPUs...


First gen (R7 1700) here, overclocked to 3.9GHz, also running CURRENT 
— never had any unexpected segfaults, even when building with 16 
threads.


The only bug is that the bottom (chipset) PCIe slot breaks when an NVMe 
SSD is installed / chipset USB3 ports don't work:

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231923

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

Re: Graphics open-source-friendliness, AMD Ryzen vs. Intel

[Greg V]

On Sun, Nov 11, 2018 at 3:42 PM, Thomas Mueller  
wrote:
I may need to buy parts for a new computer because of malfunctions on 
current motherboard and CPU (Intel Sandy Bridge dating to May 2011).


Question is whether I am better off, regarding 
open-source-friendliness of graphics chips for running Xorg, with AMD 
Ryzen or the newer Intel chipsets.  I know to avoid NVIDIA.


Both are great for open source friendliness in general.

Onboard Vega GPUs on the Ryzen APUs should work fine on FreeBSD with 
kms-drm 4.16.


If you're looking for high performance though, don't get an APU, get an 
8-core (R7 2700X/2700/1700X/1700) and a discrete GPU (Radeon RX 
550/560/570/580 depending on how much you care about graphics 
performance).


I am inclined to run FreeBSD-current and build Xorg from FreeBSD 
ports.


When I boot into UEFI setup, I see the CPU temperature is or quickly 
goes to 97 C and stays there.


I tried replacing the thermal paste and installing a new case fan to 
replace one that had quit, but CPU temperature still shows and stays 
at 97 C.


Now I have a replacement Arctic Cooler heatsink and fan on order to 
replace the original Intel heatsink and fan whose connectors were 
damaged in taking out and struggling to get back in.


Currently, I boot into UEFI Setup, but after a couple minutes, the 
computer powers off and then tries to power back on, then off again a 
few seconds later, until I end the loop by turning off the power 
supply switch.  I can guess CPU overheating.


Yeah, a new CPU cooler should help.

I could transplant the current hard drive (Seagate NAS 4 TB) to get a 
quicker start software-wise.


An SSD might provide a quicker start too ;)

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

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Greg V]

On Tue, Nov 13, 2018 at 8:59 PM, Daniel Eischen  
wrote:

Greetings,

I'm trying to track down a couple of things.  amdtemp doesn't
report any temperature sensors, and acpi seems to have some
errors.  Not sure if they are related.

These are the ACPI-related warnings and errors during boot.

   Firmware Warning (ACPI): Optional FADT field Pm2ControlBlock has 
valid Length but zero Address: 0x/0x1 
(20181031/tbfadt-796)


I see this one on my R7 1700 / X370 system, seems harmless.


   acpi0:  on motherboard
   Firmware Error (ACPI): Failure creating [\134_SB.SMIC], 
AE_ALREADY_EXISTS (20181031/dswload2-477)
   ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog 
(20181031/psobject-372)
   Firmware Error (ACPI): Failure creating [\134_SB.SMIB], 
AE_ALREADY_EXISTS (20181031/dsfield-803)


Looks like people see these on Linux:

https://forum.manjaro.org/t/unstable-behaviour-not-always-completely-booting/55823/5

Are you on the latest firmware ("BIOS") revision for your board?

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

Re: emac g4 1.25 GHz retail model won't boot FreeBSD 12 at all.

[Greg V]

On Mon, Nov 12, 2018 at 11:54 PM, Alex McKeever 
 wrote:
The CD or DVD show up fine in the device selection screen, but it 
won’t even boot the disc. What changed from 11.2 to 12.0 in regards 
to PowerPC Macs that are 32 bit?


I've been able to boot various 12-CURRENT builds on my iBook G4 just 
fine.


What exactly do you mean by "won't even boot"? Do you see the loader 
prompt when selecting the disc?


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

Re: Switching fb backend back to default

[Greg V]

On Sun, Mar 17, 2019 at 3:07 PM, Johannes Lundberg  
wrote:

Hi

I'm working on making i915kms unload properly. I've come to what I 
think

is the last issue. The drm driver unloads ok, the "efifb" backend is
restored (according to logs) and vt_efifb_init() is being called but 
the

screen (laptop built in display) stays black. The system seems
operational otherwise. If I load i915kms again in this state I get 
back

a visible (i915kms) framebuffer.

Did we ever have this working so it's known to work?


Recently on the linux kernel mailing list:

http://lkml.iu.edu/hypermail/linux/kernel/1903.1/01162.html

> Of course, once native drivers like i915 or radeon take over, such a 
framebuffer is toast... [6]


> [6] 
linux/drivers/gpu/drm/i915/i915_drv.c::i915_kick_out_firmware_fb()

> linux/drivers/gpu/drm/radeon/radeon_drv.c::radeon_pci_probe()

So it seems like efifb is not supposed to work after a driver has been 
loaded at least once.



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

Re: Danish FreeBSD Developer hates jews collectively

[Greg V]

On May 9, 2019 10:16:35 PM GMT+03:00, Enji Cooper  wrote:
>
>> On May 9, 2019, at 11:03 AM, ossobser...@redchan.it wrote:
>
>This is the only reply I’m going to give to this thread that seems like
>obvious troll bait.

Oh yeah, if you see anything mentioning "GPL revocation", it's most likely the 
work of That Guy:

https://redd.it/b8wwhk https://redd.it/antkt3

Looks like low-effort spamming of Reddit was so unsatisfying that he went back 
to high-effort trolling.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD Core Team Response to Controversial Social Media Posts

[Greg V]

On Sun, May 12, 2019 at 03:16, Miroslav Lachman <000.f...@quip.cz> 
wrote:

FreeBSD Core Team Secretary wrote on 2019/05/10 03:24:
The FreeBSD Core Team is aware of recent controversial statements 
made

on social media by a FreeBSD developer.  We, along with the Code of
Conduct review committee, are investigating the matter and will 
decide

what action to take.  Both the Core Team and the FreeBSD Foundation
would like to make it clear that views shared by individuals 
represent

neither the Project nor the Foundation.



This is incredibly stupid and I am really sad to read things like 
this in the mailinglist of my favourite operating system (again).
What will be next? Checking if developers do not smoke weed, drink 
alcohol or have sex without condom?


https://yourlogicalfallacyis.com/slippery-slope

Speaking freely does not mean you are entitled to having your speech 
published by any forum or mailing list. Having rules and enforcing them 
is good, every project has the right to enforce their rules in their 
spaces.


The only problem here is that the "report" was posted by a known troll, 
so hopefully the outcome of the investigation is


a) nothing, and

b) mail from known anonymous email domains no longer gets accepted into 
mailing lists.



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

Re: Enabling synaptics and elantech touchpads by default

[Greg V]

On June 3, 2019 11:31:21 PM GMT+03:00, Niclas Zeising  
wrote:
>Hi!
>I've created a reveiew, https://reviews.freebsd.org/D20507, to enable 
>synaptics and elantech touchpads by default.
>
>Today, these tunables needs to be set on boot for users to get full use
>
>of their touchpads, even when using X.  By enabling this, things like 
>two finger scroll will work in X by default, meaning we get a more user
>
>friendly appearance.
>
>Is there any reason not to do this?

Probably buggy hardware, as usual?

But the ONLY system I ever saw a problem on is the ASUS Eee PC 900 (where 
elantech support breaks all mouse movement). Which is an extremely irrelevant 
joke of a machine. I only booted it for the nostalgia/laughs/dmesgd.nycbug 
posts.

Definitely +1 to enabling by default. Reducing the amount of tunables required 
for modern desktop use is very good.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485

[Greg V]

On July 20, 2019 1:54:47 AM GMT+03:00, Evilham  wrote:

> it even suspends and resumes back to X

Wow, that's great news! Desktop Ryzen+Vega doesn't (not that I need suspend 
very much on desktop haha)

>- xbacklight doesn't work, neither does intel-backlight because 
>  it's AMD

Since it's a Thinkpad, do the brightness keys work anyway? Does acpi_ibm work?

>Serious issue:
>I was just debugging this right now, more infos with a proper bug 
>report will come, but I think the system encounters a deadlock 
>sometimes with the drm-kmod / amdgpu which results in a kernel 
>panic.

If you're on the packaged drm-kmod v4.16, it's amazing that Raven GPU works at 
all. You should try drm-v5.0 from git.

>kld_list="amdgpu"

It even works when loaded this early? Interesting. Do you also not have the EFI 
framebuffer conflict? i.e. without disabling vt.syscons, everything just works 
reliably?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: "amdgpu and radeonkms are known to fail with EFI Boot"

[Greg V]

On August 24, 2019 10:15:22 AM GMT+03:00, "Clay Daniels Jr." 
 wrote:
>From the kmod ports, dated 20190814
>
>
>/usr/ports/graphics/drm-current-kmod/pkg-descr
>
>"amdgpu and radeonkms are known to fail with EFI Boot"
>
>
>/usr/ports/graphics/drm-current-kmod/pkg-message
>
>"some positive reports if EFI is not enabled"
>
>
>Any practical suggestions on getting drm-current-kmod to work on an AMD
>machine, including how to NOT enable EFI? I did not see that option on
>the
>install menu.

"Not enabling" EFI means booting the installer in legacy more (CSM). Installer 
images are universal, so you'd have to instruct the firmware to ignore the EFI 
loader on there. Deleting the EFI partition might work I guess. rEFInd can 
force CSM boot a USB drive.

I do not recommend this. Instead, there is a workaround for the EFI framebuffer 
conflict. If you have it (i.e. amdgpu fails to load, or hangs when starting 
GUI), boot with hw.syscons.disable=1. You won't see anything on the screen 
after the boot loader and before loading the driver :) but that's not a big 
deal when the driver autoloads successfully.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Firefox – GtkFileChooserNative – file selection dialogues

[Greg V]

On September 19, 2019 8:02:35 PM GMT+03:00, Graham Perrin 
 wrote:
>Firefox does not use xdg-desktop-portal for file selection dialogs
>
>
> > This patch makes Firefox's GTK3 platform support use
> > GtkFileChooserNative when available. GtkFileChooserNative
> > transparently uses the desktop portals interface, which
> > enables Firefox to use native Qt file dialogs on KDE, or
> > sandboxed file dialogs in Flatpak.
>
>– RESOLVED FIXED, mozilla64
>
>Can I benefit from this patch on FreeBSD?
>
>(What am I missing?)

The dbus portal implementation itself, most likely.

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

Re: AMD Secure Encrypted Virtualization - FreeBSD Status?

[Greg V]

Hey everyone,

On October 5, 2019 4:49:39 AM GMT+03:00, "Clay Daniels Jr." 
 wrote:
>Grarpamp,Tomasz, and all:
>
>https://wiki.freebsd.org/SecureBoot
>A work in progress.

please keep in mind that the wiki is, as usual, very outdated. You can see that 
the last edit on this page was in 2017.

A lot more work has been happening e.g. https://reviews.freebsd.org/D19093 
https://reviews.freebsd.org/D20952 etc.

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

Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[N V]

21.12.2011, 04:28, "O. Hartmann" :
> On 12/21/11 00:29, Jeremy Chadwick wrote:
>
>>  On Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote:
>>>  On 12/20/11 22:45, Samuel J. Greear wrote:
  http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved

  PostgreSQL tests, see the linked PDF for #'s on FreeBSD, DragonFly, Linux
  and Solaris. Steps to reproduce these benchmarks provided.

  Sam

  On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky 
 wrote:
>  Interestingly, while people seem to be (arguably rightly) focused on
>  criticising Phoronix's benchmarking, nobody has offered an alternative
>  benchmark; and while (again, arguably rightly) it is important to
>  benchmark real world performance, equally, nobody has offered any
>  numbers in relation to, for example, HTTP or SMTP, or any other "real
>  world"-application torture tests done on the aforementioned two
>  platforms... IMO, this just goes to show that "doing is hard" and
>  "criticising is much easier" (yes, I am aware of the irony involved in
>  making this statement, but someone has to!)
>
>  Cheers,
>  Igor M :-)
>  ___
>  freebsd-current@freebsd.org mailing list
>  http://lists.freebsd.org/mailman/listinfo/freebsd-current
>  To unsubscribe, send any mail to 
> "freebsd-current-unsubscr...@freebsd.org"
>>>  Thanks for those numbers.
>>>  Impressive how Matthew Dillon's project jumps forward now. And it is
>>>  still impressive to see that the picture is still in the right place
>>>  when it comes to a comparison to Linux.
>>>  Also, OpenIndiana shows an impressive performance.
>>  Preface to my long post below:
>>
>>  The things being discussed here are benchmarks, as in "how much work
>>  can you get out of Thing".  This is VERY DIFFERENT from testing
>>  interactivity in a scheduler, which is more of a test that says "when
>>  Thing X is executed while heavier-Thing Y is also being executed, how
>>  much interaction is lost in Thing X".
>>
>>  The reason people notice this when using Xorg is because it's visual,
>>  in an environment where responsiveness is absolutely mandatory above all
>>  else.  Nobody is going to put up with a system where during a buildworld
>>  they go to move a window or click a mouse button or type a key and find
>>  that the window doesn't move, the mouse click is lost, or the key typed
>>  has gone into the bit bucket -- or, that those things are SEVERELY
>>  delayed, to the point where interactivity is crap.
>
> I whitnessed sticky, jumpy and non-responsive-for seconds FreeBSD
> servers (serving homes, NFS/SAMBA and PostgreSQL database (small)).
> Those "seconds" where enough to cut a ssh line. Not funny. Network
> traffic droped significantly. X/Desktop makes the problem visible,
> indeed. But not seeing it does not mean it isn't there.
> This might be the reason why FreeBSD is so much behind when it comes to X?
>

Well... Are you talking about FreeBSD being laggy with the X and other GUI 
staff? Well, am I so lucky to have great responsiveness and interactivity here 
in X with the FreeBSD? The interactiveness was one the reasons I've switched my 
desktop from Windows to *nix (specifically FreeBSD).

>>  I just want to make that clear to folks.  This immense thread has been


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

Re: 9.0-CURRENT r220692 && cc1: internal compiler error: Segmentation fault: 11

[N V]

Hello.

Don't know is this related.

I've got rather fresh 9.0-CURRENT (checked out few days ago) built with clang. 
And I use clang as the system compiler, but ruby fails to build with clang. So 
I've tried gcc. But with gcc I've got this:

..
configure:3211: checking whether the C compiler works
configure:3233: cc -I/usr/include -O2 -pipe -march=native -fno-strict-aliasing 
-I/usr/include   -rpath=/usr/lib:/usr/local/lib -pthread conft
est.c -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread >&5
Segmentation fault (core dumped)
configure:3237: $? = 139
configure:3275: result: no
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| /* end confdefs.h.  */
| 
| int
| main ()
| {
| 
|   ;
|   return 0;
| }
configure:3280: error: in 
`/mnt/portworkdir/usr/ports/lang/ruby18/work/ruby-1.8.7-p302':
configure:3283: error: C compiler cannot create executables
..

As far as I remeber, all was ok when I had base gcc build by gcc not clang. But 
this could be unrelated.

Regards.


26.04.2011, 12:04, "Matthias Apitz" :
> Hello,
>
> I'm trying to compile /usr/ports/mail/evolution-exchange/ and the gcc
> crashes with:
>
> [root@vm-9Current /usr/ports/mail/evolution-exchange]#  LANG=C make
> ===>  Building for evolution-exchange-2.32.1_1
> gmake  all-recursive
> gmake[1]: Entering directory
> `/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1'
> Making all in server
> gmake[2]: Entering directory
> `/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1/server'
> Making all in xntlm
> gmake[3]: Entering directory
> `/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1/server/xntlm'
>   CC libxntlm_la-xntlm.lo
> cc1: internal compiler error: Segmentation fault: 11
>
> Some notes about this:
> - the system runs in a VMworkstation 7.x
> - it has already compliled kernel, userland and ~1000 ports without any
>   crash, i.e. it is *not* the typical hardware related crash;
> - the above mentioned version evolution-exchange-2.32.1_1 is a fake, in
>   real it is compiling the original evolution-exchange-2.32.3 sources;
> - it is fully reproduceable
>
> What next?
> (David, should it be posted to evolut...@gnome.org as well?)
>
> matthias
>
> --
> Matthias Apitz
> t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
> e ; - w http://www.unixarea.de/
> ___
> freebsd-current@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD-9.0-BETA1-i386-bootonly

[N V]

Hi.

Tried to use FreeBSD-9.0-BETA1-i386-bootonly.iso in VirtualBox to test. 
Installation stops after trying to fetch files from ftp. Attached screenshot is 
informative, I think. Seems to use i386/ twice for some reason.

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

mlx4 weird error "Failed to map EQ context memory" after update

[Greg V]

Hi. I've upgraded CURRENT from December 19 
(https://github.com/freebsd/freebsd/commit/fd53ccf393f4f8ac1948e97eca108) 
to today 
(https://github.com/freebsd/freebsd/commit/391a83c86bb91ae3840cf37b7de478f42cc97e2a) 
and my Mellanox ConnectX-2 network card stopped working:


mlx4_core0:  mem 0xfe10-0xfe1f,0xf080-0xf0ff 
irq 32 at device 0.0 on pci7

mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017)
mlx4_core: Initializing mlx4_core
mlx4_core0: command 0xffa failed: fw status = 0x1
mlx4_core0: Failed to map EQ context memory, aborting
device_attach: mlx4_core0 attach returned 12


Loading the OLD mlx4.ko and mlx4en.ko on the NEW kernel actually does 
work fine!


Reverting all mlx4 changes between then and now (no big changes, mostly 
just the 1 << 31 thing from D13858) and rebuilding the mlx4 module with 
CC=clang50 does not help.


What happened?!

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

Re: mlx4 weird error "Failed to map EQ context memory" after update

[Greg V]

On 01/19/2018 12:54, Hans Petter Selasky wrote:

On 01/18/18 14:11, Greg V wrote:
Hi. I've upgraded CURRENT from December 19 
(https://github.com/freebsd/freebsd/commit/fd53ccf393f4f8ac1948e97eca108) 
to today 
(https://github.com/freebsd/freebsd/commit/391a83c86bb91ae3840cf37b7de478f42cc97e2a) 
and my Mellanox ConnectX-2 network card stopped working:


mlx4_core0:  mem 
0xfe10-0xfe1f,0xf080-0xf0ff irq 32 at device 0.0 on pci7

mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017)
mlx4_core: Initializing mlx4_core
mlx4_core0: command 0xffa failed: fw status = 0x1
mlx4_core0: Failed to map EQ context memory, aborting
device_attach: mlx4_core0 attach returned 12


Loading the OLD mlx4.ko and mlx4en.ko on the NEW kernel actually does 
work fine!


Reverting all mlx4 changes between then and now (no big changes, 
mostly just the 1 << 31 thing from D13858) and rebuilding the mlx4 
module with CC=clang50 does not help.


What happened?!


Hi,

Can you do:

objdump -Dx /boot/kernel/mlx4.ko > mlx4.ko.txt
objdump -Dx /boot/kernel/mlx4en.ko > mlx4en.ko.txt

And diff the text result between working and non-working ko's.
That results in 180883 lines (9.2 megabytes) of diff for mlx4.ko. The 
CC=clang50 one is only a bit better at 7.6 MB :(
Can you also make sure that /boot/modules does not contain anything 
*mlx4* ?

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

Re: Broadcom 802.11ac WDI SDIO Adapter (Version 1.605.1.0) not configured

[Greg V]

On 01/24/2018 02:03, KIRIYAMA Kazuhiko wrote:

HI,

Broadcom 802.11ac WDI SDIO Adapter works in Windows but does
not recognaized in my machne[1]. Actually both ifconfig and
pciconf show nothing wifi drives found:

Hi.

SDIO support is not there yet.

Some development is going on:
https://wiki.freebsd.org/SDIO?action=AttachFile&do=view&target=sdio_bsdcam.pdf

But seems like it's quite far from actually working with Wi-Fi cards.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: mlx4 weird error "Failed to map EQ context memory" after update

[Greg V]

On 01/20/2018 12:18, Hans Petter Selasky wrote:

On 01/20/18 00:17, Greg V via freebsd-net wrote:


On 01/19/2018 12:54, Hans Petter Selasky wrote:

On 01/18/18 14:11, Greg V wrote:
Hi. I've upgraded CURRENT from December 19 
(https://github.com/freebsd/freebsd/commit/fd53ccf393f4f8ac1948e97eca108) 
to today 
(https://github.com/freebsd/freebsd/commit/391a83c86bb91ae3840cf37b7de478f42cc97e2a) 
and my Mellanox ConnectX-2 network card stopped working:


mlx4_core0:  mem 
0xfe10-0xfe1f,0xf080-0xf0ff irq 32 at device 0.0 on 
pci7

mlx4_core: Mellanox ConnectX core driver v3.4.1 (October 2017)
mlx4_core: Initializing mlx4_core
mlx4_core0: command 0xffa failed: fw status = 0x1
mlx4_core0: Failed to map EQ context memory, aborting
device_attach: mlx4_core0 attach returned 12


Loading the OLD mlx4.ko and mlx4en.ko on the NEW kernel actually 
does work fine!


Reverting all mlx4 changes between then and now (no big changes, 
mostly just the 1 << 31 thing from D13858) and rebuilding the mlx4 
module with CC=clang50 does not help.


What happened?!

Upgraded CURRENT again today, the problem went away :)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Compilation failure of the kernel for drm-next

[Greg V]

On 2/27/2018 5:03 AM, Pete Wright wrote:



On 02/26/2018 17:17, Mylan Connolly wrote:

Hello all,

I'm not sure if this is the best place to send this, but it looks 
like the issue tracker in Github is a bit dead.


there may not be much traffic on it recently, but people are def still 
actively working on the repository and will see when new issues are 
reported.


as of now your best to to use or test out the drm-next bits is to run 
a recent 12-CURRENT with no patches applied.  then you can build the 
port or package via the ports tree under graphics/drm-next-kmod.  it 
currently runs on my end under 12-CURRENT and 11-STABLE.

Yeah, and the issue tracker for drm-next-kmod is

https://github.com/FreeBSDDesktop/kms-drm/issues

NOT https://github.com/FreeBSDDesktop/freebsd-base-graphics/issues
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: zfskern{txg_thread_enter} thread using 100% or more CPU

[Greg V]

On Wed, Apr 25, 2018 at 2:30 AM, Steve Wills  wrote:

Hi,

Recently on multiple systems running CURRENT, I've been seeing the 
system become unresponsive. Leaving top(1) running has lead me to 
notice that when this happens, the system is still responding to ping 
and top over ssh is still working, but no new processes can start and 
switching to other tasks doesn't work. In top, I do see pid 17, 
[zfskern{txg_thread_enter}] monopolizing both CPU usage and disk IO. 
Any ideas how to troubleshoot this? It doesn't appear to be a 
hardware issue.

Hi,

Do you have something writing to a gzip compressed dataset? You can use 
the vfssnoop DTrace script from 
https://forums.freebsd.org/threads/sharing-of-dtrace-scripts.32855/#post-181816 
to see who's writing what.


I don't remember if it was exactly txg_thread_enter or whatever, but 
both CPU and disk sounds a lot like heavily compressed writes.


In my case, the Epiphany browser was downloading a large malware 
database to ~/.config/epiphany/gsb-threats.db :D

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

Re: Elantech Touchpad Woes - Support for Elantech touchpads over i2c/SMBus still possibly missing

[Greg V]

On Sat, Jun 2, 2018 at 3:14 AM, Albert  wrote:

Hi all,


I'd like to start out by saying that I'm a newcomer to FreeBSD, but 
I've been running Linux for years now and I'm still having a few 
issues transitioning. Despite that. I've been having a blast setting 
things up for myself, and I'm hopeful I can get this resolved soon 
enough.


I'm trying to get FreeBSD running on my laptop, an "Acer Chromebook 
14" (EDGAR), and although I've managed to overcome most of the 
problems I've faced along the way (needing to upgrade to a UEFI, 
misnamed wireless modules, video drivers not working on RELEASE nor 
STABLE), I just can't seem to get the touchpad on this thing to work.


For reference, EDGAR is an Intel Celeron N3160 SoC. Pretty much the 
only thing in it that isn't Intel are the case, the keyboard, the 
webcam and the touchpad. On Linux, the touchpad appears in _/proc_ as

[...]
and it can be seen from _lsmod_ as *elan_i2c*. The source for the 
corresponding driver can be found here: Google ChromeOS Git. 



Now on FreeBSD, it's as though it didn't even exist. Without applying 
any of the changes I've tried to get it working, here's the (verbose) 
output to _dmesg_ on FreeBSD: (vdmesg-nochanges 
). 
With the knowledge I have so far, this is to be expected, as it seems 
FreeBSD requires the *ig4* module to work with *i2c* devices. Loading 
it at boot does seem to make the buses visible, but the touchpad 
still doesn't appear (or not properly, I don't know all these codes): 
(vdmesg-ig4 
). 
The obvious solution is to enable support for elantech devices with 
_hw.psm.elantech_support_, but nada: (vdmesg-elantech 
). 
The only difference is _sysctl_ shows that option is enabled. Aside 
from that, it seems I'm not the only one who's had this sort of issue 
before, so support has been worked on and is claimed to be working. 
Loading the recommended cyapa and chromebook_platform modules at boot 
does not fix this issue: (vdmesg-chromebook 
). 
The reason appears, at least to me, to be that the cyapa driver isn't 
a proper elan driver. These are /different/ devices.


I'm determined to get this working /somehow/, so any help would be 
appreciated. It feels like there's a solution here somewhere and I'm 
either too dumb to find it or it's just not there quite yet. If it's 
the latter, I'm willing to put some work into porting the right 
driver with a little guidance. (I have plenty of experience with C 
but none of this driver stuff.)


Hi! hw.psm.elantech_support is not the solution. hw.psm... psm means 
PS/2 Mouse. This is for PS/2 Elantech touchpads.


cyapa is indeed not the right driver either. The "cy" is for Cypress. 
That's the touchpad found in e.g. the Acer C720.


So there's no support for your touchpad right now.

OpenBSD has HID over i2c support: https://man.openbsd.org/imt -- you 
could try porting that...


Also, should be possible to add i2c support to webcamd I guess, that 
would get the Linux driver running in userspace.

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

Re: dmesg output I don't understand

[Greg V]

On Wed, Aug 22, 2018 at 7:20 PM, Per Gunnarsson 
 wrote:

Hello!

What do these lines in my dmesg mean?

I am on amd64.

/usr/src Revision: 338177

/usr/ports Revision: 43

P.S

I got Fatal trap 12 with this revision after installing several fusefs
modules from ports.

After removing fuse from my loader.conf, things booted again.

Regards,

Per Gunnarsson

lock order reversal:
 1st 0xfee82d80 bufwait (bufwait) @ 
/usr/src/sys/kern/vfs_bio.c:3916

 2nd 0xf80005787000 dirhash (dirhash) @
/usr/src/sys/ufs/ufs/ufs_dirhash.c:289


Hi,

this is debugging output you're seeing because your kernel is built 
with the WITNESS option.

(e.g. the default GENERIC kernel in -CURRENT)

lock order reversal is a very common message, you can ignore it.

Switch to GENERIC-NODEBUG to get rid of the messages and get a 
performance boost (these safety checks impact syscall performance)


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

cannot build 12.1-RELEASE on latest current-snapshot

[h v]

Dear List,

buildworld for 12.1-RELEASE fails on recent current.. in stage 3: cross
tools (see below)

Did i miss  newer Options/ Parameters (i checked UPDATING without
relevant changes)

i'm also not attemting a cross build, simply compiling on amd64 for amd64.

--- C U T ---

--
>>> stage 3: cross tools
--
cd /usr/src/12.1; INSTALL="sh /usr/src/12.1/tools/install.sh" 
TOOLS_PREFIX=/usr/obj/usr/src/12.1/amd64.amd64/tmp 
PATH=/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
 
WORLDTMP=/usr/obj/usr/src/12.1/amd64.amd64/tmp  MAKEFLAGS="-m
/usr/src/12.1/tools/build/mk  -m /usr/src/12.1/share/mk" make  -f
Makefile.inc1  DESTDIR= 
OBJTOP='/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools' 
OBJROOT='${OBJTOP}/'  MAKEOBJDIRPREFIX=  BOOTSTRAPPING=1300084 
BWPHASE=cross-tools  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes MK_MAN=no 
-DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no
MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no
MK_RETPOLINE=no MK_TESTS=no  MK_INCLUDES=yes MK_LLVM_TARGET_ALL=no 
TARGET=amd64 TARGET_ARCH=amd64  MK_GDB=no MK_TESTS=no cross-tools
===> lib/clang (obj,all,install)
===> lib/clang/libllvm (all)
[Creating objdir
/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools/lib/clang/libllvm...]
make[4]: "/usr/src/12.1/lib/clang/libllvm/Makefile" line 18: Please
enable at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM,
MK_LLVM_TARGET_BPF, MK_LLVM_TARGET_MIPS,  MK_LLVM_TARGET_POWERPC,
MK_LLVM_TARGET_RISCV, MK_LLVM_TARGET_SPARC,  or MK_LLVM_TARGET_X86
*** Error code 1

Stop.
make[3]: stopped in /usr/src/12.1/lib/clang
*** Error code 1

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

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

Stop.
make: stopped in /usr/src/12.1

---C U  T ---


Best

Henry



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

Re: cannot build 12.1-RELEASE on latest current-snapshot

[h v]

Hi,

--- C U T ---

On 20.03.20 18:20, Warner Losh wrote:
>
>
> On Fri, Mar 20, 2020, 11:12 AM Dimitry Andric  <mailto:d...@freebsd.org>> wrote:
>
> On 20 Mar 2020, at 10:55, h v  <mailto:henry.v...@gmail.com>> wrote:
> >
> > buildworld for 12.1-RELEASE fails on recent current.. in stage
> 3: cross
> > tools (see below)
> >
> > Did i miss  newer Options/ Parameters (i checked UPDATING without
> > relevant changes)
> >
> > i'm also not attemting a cross build, simply compiling on amd64
> for amd64.
> >
> > --- C U T ---
> >
> > --
> >>>> stage 3: cross tools
> > --
> > cd /usr/src/12.1; INSTALL="sh /usr/src/12.1/tools/install.sh"
> > TOOLS_PREFIX=/usr/obj/usr/src/12.1/amd64.amd64/tmp
> >
> 
> PATH=/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/12.1/amd64.amd64/tmp/legacy/bin:/sbin:/bin:/usr/sbin:/usr/bin
> > WORLDTMP=/usr/obj/usr/src/12.1/amd64.amd64/tmp  MAKEFLAGS="-m
> > /usr/src/12.1/tools/build/mk  -m /usr/src/12.1/share/mk" make  -f
> > Makefile.inc1  DESTDIR=
> > OBJTOP='/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools'
> > OBJROOT='${OBJTOP}/'  MAKEOBJDIRPREFIX=  BOOTSTRAPPING=1300084
> > BWPHASE=cross-tools  SSP_CFLAGS=  MK_HTML=no NO_LINT=yes MK_MAN=no
> > -DNO_PIC MK_PROFILE=no -DNO_SHARED  -DNO_CPU_CFLAGS MK_WARNS=no
> > MK_CTF=no  MK_CLANG_EXTRAS=no MK_CLANG_FULL=no  MK_LLDB=no
> > MK_RETPOLINE=no MK_TESTS=no  MK_INCLUDES=yes MK_LLVM_TARGET_ALL=no
> > TARGET=amd64 TARGET_ARCH=amd64  MK_GDB=no MK_TESTS=no cross-tools
> > ===> lib/clang (obj,all,install)
> > ===> lib/clang/libllvm (all)
> > [Creating objdir
> >
> /usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools/lib/clang/libllvm...]
> > make[4]: "/usr/src/12.1/lib/clang/libllvm/Makefile" line 18: Please
> > enable at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM,
> > MK_LLVM_TARGET_BPF, MK_LLVM_TARGET_MIPS,  MK_LLVM_TARGET_POWERPC,
> > MK_LLVM_TARGET_RISCV, MK_LLVM_TARGET_SPARC,  or MK_LLVM_TARGET_X86
> > *** Error code 1
>
> Looks like you have MK_LLVM_TARGET_ALL=no in your src.conf? Try
> removing
> it.  Can you also post your make.conf and src.conf?
>
>
>
> No. This was an error I committed. Update and try again. I had one too
> many changes in the tree I pushed this morning. 
>
> Warner


Unfortunately not.. im now @13.0-CURRENT r359179 - still bailing out
(after make cleanworld for src=12.1-RELEASE-p3) -

btw. 12-STABLE can be compiled , as well as 11.3 and 11-STABLE (this is
a build machine;-)

it's only 12.1-RELEASE (trying to compile -p3)

Normally i compile with  -j 8 and WITH_META_MODE=yes, now compiling
manually without them..


Regarding /etc/{src,src-env,make}.conf - not using any of these on this
tests atm.


---C U T---

--- cross-tools ---
===> lib/clang (obj,all,install)
--- all_subdir_lib/clang/libllvm ---
===> lib/clang/libllvm (all)
[Creating objdir
/usr/obj/usr/src/12.1/amd64.amd64/tmp/obj-tools/lib/clang/libllvm...]
make[4]: "/usr/src/12.1/lib/clang/libllvm/Makefile" line 18: Please
enable at least one of: MK_LLVM_TARGET_AARCH64, MK_LLVM_TARGET_ARM,
MK_LLVM_TARGET_BPF, MK_LLVM_TARGET_MIPS,  MK_LLVM_TARGET_POWERPC,
MK_LLVM_TARGET_RISCV, MK_LLVM_TARGET_SPARC,  or MK_LLVM_TARGET_X86
*** [all_subdir_lib/clang/libllvm] Error code 1

make[3]: stopped in /usr/src/12.1/lib/clang


---C U T ---

any other ideas ?

Best

Henry



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

Re: cannot build 12.1-RELEASE on latest current-snapshot

[h v]

Hi,

> On 20.03.20 18:20, Warner Losh wrote:
>>
>> ...
>> No. This was an error I committed. Update and try again. I had one
>> too many changes in the tree I pushed this morning. 
>>
>> Warner
>
>
> Unfortunately not.. im now @13.0-CURRENT r359179 - still bailing out
> (after make cleanworld for src=12.1-RELEASE-p3) -
>
> Normally i compile with  -j 8 and WITH_META_MODE=yes, now compiling
> manually without them..
>
> ...
>
for the sake of completeness.. compiling w/out -j 8 and  META_MODE
didn't help, of course.

so compiling 12.1-RELEASE(-p3) on 13-CURRENT still broken .. clang10 issue ?

Best

Henry




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

Re: cannot build 12.1-RELEASE on latest current-snapshot

[h v]

Hi again,

On 21.03.20 21:52, Dimitry Andric wrote:
>> ...
> It needs a merge of r355588 ("Fix WITHOUT_CLANG build"), actually.  For
> some reason, the logic in 12.1-R's version of src.opts.mk does not work
> correctly.  I tried setting MK_SYSTEM_COMPILER=no, but even that does
> not work as it should.  If you can, I would use 12-STABLE instead.
>
> -Dimitry

I applied r355588 and now and it proceeds further but bails out again
shortly thereafter:

--- C U T ---

...

Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/yp_xdr.o
--- pkru.o ---
/usr/src/12.1/lib/libc/x86/sys/pkru.c:74: warning: 'ifunc' attribute
directive ignored
/usr/src/12.1/lib/libc/x86/sys/pkru.c:109: warning: 'ifunc' attribute
directive ignored
--- getcontextx.o ---
/usr/src/12.1/lib/libc/x86/gen/getcontextx.c:64: warning: 'ifunc'
attribute directive ignored
/usr/src/12.1/lib/libc/x86/gen/getcontextx.c:103: warning: 'ifunc'
attribute directive ignored
Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/yplib.o
--- __vdso_gettc.o ---
/usr/src/12.1/lib/libc/x86/sys/__vdso_gettc.c:75: warning: 'ifunc'
attribute directive ignored
/usr/src/12.1/lib/libc/x86/sys/__vdso_gettc.c:75: warning: 'rdtsc_mb'
used but never defined
Building /usr/obj/usr/src/12.1/amd64.amd64/lib/libc/subr_capability.o
--- pkru.o ---
{standard input}: Assembler messages:
{standard input}:39: Error: no such instruction: `rdpkru'
{standard input}:60: Error: no such instruction: `wrpkru'
{standard input}:171: Error: no such instruction: `rdpkru'
*** [pkru.o] Error code 1

make[4]: stopped in /usr/src/12.1/lib/libc
.ERROR_TARGET='pkru.o'
.ERROR_META_FILE='/usr/obj/usr/src/12.1/amd64.amd64/lib/libc/pkru.o.meta'
--- C U T ---

this looks even more serious to me.. are the other patches to apply ?

Best

Henry



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

immediate panic after nvidia load

[h v]

Hi,

recent current (faf24c828d5-c254344(main)): macmini3,1 panics after
loading nvidia (nvidia-driver-340-340.108_2)


--  cat /var/crash/info.2 


Dump header from device: /dev/ada0p3
  Architecture: amd64
  Architecture Version: 2
  Dump Length: 330252288
  Blocksize: 512
  Compression: none
  Dumptime: 2020-11-09 17:23:30 +0100
  Hostname: macmini
  Magic: FreeBSD Kernel Dump
  Version String: FreeBSD 13.0-CURRENT #8 faf24c828d5-c254344(main): Mon
Nov  9 15:32:08 CET 2020
    root@del:/usr/obj/usr/src/13/amd64.amd64/sys/MODULAR
  Panic String: malloc_init: type nvidia with unsupported version 877983977
  Dump Parity: 2100487787
  Bounds: 2
  Dump Status: good

--- CU T ---

How to proceed ?

Kind Regards

Henry

-- 
--
OpenPGP Fngerprint: E3F7 8EAF 1ED7 CFFD 9A07 E859 1BED 39D9 B0C8 6AF4
All other Infos removed for Privacy.



OpenPGP_signature
Description: OpenPGP digital signature

Re: immediate panic after nvidia load

[h v]

Hi,

On 10.11.20 13:13, David Wolfskill wrote:
> On Tue, Nov 10, 2020 at 01:09:14PM +0100, h v wrote:
>> Hi,
>>
>> recent current (faf24c828d5-c254344(main)): macmini3,1 panics after
>> loading nvidia (nvidia-driver-340-340.108_2)
>>  
>>
>> How to proceed ?
>>
>> Kind Regards
>>
>> Henry
>> 
> When you built the kernel, did you also rebuild the nvidia-driver kernel
> module(s)?
>
> If not, you do need to do that.
>
> And easy way to do it (and ensure that it is done henceforth) is to
> append:
>
> PORTS_MODULES+=x11/nvidia-driver
>
> to /etc/src.conf before you do your next kernel build.

usually i build kernel(s) on a fast machine and install them as packages
, but

packaging (make packges) them doesn't work unfortunately:

...

===> Ports module x11/nvidia-driver-340 (install)
cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver-340; env  -u CC  -u CXX  -u
CPP  -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR  MAKEFLAGS="-D
NO_ROOT -D NO_ROOT .MAKE.LEVEL.ENV=MAKELEVEL
DESTDIR=/usr/obj/usr/src/13/amd64.amd64/kernelstage/kernel KERNEL=kernel
MK_META_MODE=no PKG_VERSION=13.0.s20201110130740 TARGET=amd64
TARGET_ARCH=amd64"  SYSDIR=/usr/src/13/sys 
PATH=/usr/obj/usr/src/13/amd64.amd64/tmp/bin:/usr/obj/usr/src/13/amd64.amd64/tmp/usr/sbin:/usr/obj/usr/src/13/amd64.amd64/tmp/usr/bin:/usr/obj/usr/src/13/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/usr/src/13/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/usr/src/13/amd64.amd64/tmp/legacy/bin:/usr/obj/usr/src/13/amd64.amd64/tmp/legacy/usr/libexec::/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/bin:/usr/local/sbin
 
SRC_BASE=/usr/src/13  OSVERSION=1300113  WRKDIRPREFIX=/tmp make -B
deinstall reinstall
===>  Creating some important subdirectories
===> /tmp subdirectory has been successfully created
===> /dev subdirectory has been successfully created
===>  Starting chrooted make in
/usr/obj/usr/src/13/amd64.amd64/kernelstage/kernel...
chroot: /bin/sh: No such file or directory
===>  Chrooted make in
/usr/obj/usr/src/13/amd64.amd64/kernelstage/kernel failed
===>  Cleaning up...
*** Error code 1

Stop.
make[9]: stopped in /usr/ports/x11/nvidia-driver-340
*** Error code 1

Stop.
make[8]: stopped in /usr/obj/usr/src/13/amd64.amd64/sys/MODULAR
*** Error code 1


Is there a solution, despite not using packages ?

Best

Henry

-- 
--
OpenPGP Fngerprint: E3F7 8EAF 1ED7 CFFD 9A07 E859 1BED 39D9 B0C8 6AF4
All other Infos removed for Privacy.



OpenPGP_signature
Description: OpenPGP digital signature

Re: immediate panic after nvidia load

[h v]

On 10.11.20 14:58, David Wolfskill wrote:
> On Tue, Nov 10, 2020 at 02:37:53PM +0100, h v wrote:
>> Hi,
>> ... 
>>>> recent current (faf24c828d5-c254344(main)): macmini3,1 panics after
>>>> loading nvidia (nvidia-driver-340-340.108_2)
>>>>  
>>>>
>>>> How to proceed ?
>>>>
>>>> Kind Regards
>>>>
>>>> Henry
>>>> 
>>> When you built the kernel, did you also rebuild the nvidia-driver kernel
>>> module(s)?
>> ...
>>> append:
>>>
>>> PORTS_MODULES+=x11/nvidia-driver
>>>
>>> to /etc/src.conf before you do your next kernel build.
>> usually i build kernel(s) on a fast machine and install them as packages
>> , but
>>
>> packaging (make packges) them doesn't work unfortunately:
>>
>> ...
>>
>> ===> Ports module x11/nvidia-driver-340 (install)
>> cd ${PORTSDIR:-/usr/ports}/x11/nvidia-driver-340; env  -u CC  -u CXX  -u
>> CPP  -u MAKESYSPATH  -u MK_AUTO_OBJ  -u MAKEOBJDIR  MAKEFLAGS="-D
>> NO_ROOT -D NO_ROOT .MAKE.LEVEL.ENV=MAKELEVEL
>> ...
>> ===>  Starting chrooted make in
>> /usr/obj/usr/src/13/amd64.amd64/kernelstage/kernel...
>> chroot: /bin/sh: No such file or directory
>> ===>  Chrooted make in
>> /usr/obj/usr/src/13/amd64.amd64/kernelstage/kernel failed
>> ===>  Cleaning up...
>> *** Error code 1
>>
>> Stop.
>> make[9]: stopped in /usr/ports/x11/nvidia-driver-340
>> *** Error code 1
>>
>> Stop.
>> make[8]: stopped in /usr/obj/usr/src/13/amd64.amd64/sys/MODULAR
>> *** Error code 1
>>
>>
>> Is there a solution, despite not using packages ?
>>
>> Best
>>
>> Henry
> What I do on my laptop is build FreeBSD from source, with he directive
> in /etc/src.conf so the x11/nvidia0driver kmod is rebuilt during "make
> buildkernel" (and installed during "make installkernel").
>
> That's simple and easy, and it works (at least, for me -- and has done,
> for years).
>
> If you wish to build the kernel on a different machine, I believe you
> will need to be a bit more creative to ensure that the kernel and the
> port/package are kept in sync.
>
> A way that *might* work:
>
> * On the build machine, update FreeBSD sources and ports to some desired
>   point.
> * Build FreeBSD.
> * Build (e.g., using poudriere) all of the packages you want to use,
>   ensuring that the FreeBSD sources that poudriere uses are copies of what
>   was used to build FreeBSD (so everything stays in sync).
> * Install everything (probably the packages from ports first, as any
>   kmods won't actually be effective until hey're loaded).
> * Reboot from the newly-installed FreeBSD.
>
> Caveats: I don't do that.  The above is just a somewhat-educated guess;
> it has not been tested at all.  Building all the packages using
> poudriere is likely to take a significant amount of time.

This is more or less what i'm doing.. but never had it rebuild the
driver for a long - until now.

i always had the impression the freebsd generated pckages worked, same
for the bwn-firmware-kmod the macmini needs.

But it's solved: i added  nvidia-driver to the list of poudriere
packages to build and it works again.

Thanks.

Henry

-- 
--
OpenPGP Fngerprint: E3F7 8EAF 1ED7 CFFD 9A07 E859 1BED 39D9 B0C8 6AF4
All other Infos removed for Privacy.



OpenPGP_signature
Description: OpenPGP digital signature

Re: Current kernel build broken with linuxkpi?

[Greg V]

On Thu, Jan 14, 2021 at 08:05, Robert Huff  wrote:


"Houston ... we have a problem."
Scenario: Chicken, meet egg?
I am trying to upgrade a system running:

FreeBSD 13.0-CURRENT #0 r365372: Sun Sep  6 10:51:26 EDT 2020 amd64

Per this discussion, I cannot compile the kernel because
drm-current-kmod is out-of-date.
When I try to upgrade drm-current-kmod (r561457) I get:

===>  drm-current-kmod-5.4.62.g20210113 not supported on older 
CURRENT, no

kernel support.
*** Error code 1

Stop.
make: stopped in /usr/ports/graphics/drm-current-kmod

Huh?
What is my path forward? (That does not involve reinstalling the
OS.)


Either

upgrade the kernel without the drm PORTS_ whatever thing → upgrade 
drm-current-kmod → add back the PORTS_thing if you really want it → 
upgrade kernel again


or

remove the IGNORE line in the port's Makefile → upgrade 
drm-current-kmod → upgrade the kernel.


You have discovered precisely why this (building kmods from ports when 
building the kernel itself) is not a very good feature :)



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

Re: Current kernel build broken with linuxkpi?

[Greg V]

On Thu, Jan 14, 2021 at 08:36, Robert Huff  wrote:


Hello:


   > I am trying to upgrade a system running:
   >
   > FreeBSD 13.0-CURRENT #0 r365372: Sun Sep  6 10:51:26 EDT 2020 
amd64

   >
   > Per this discussion, I cannot compile the kernel because
   > drm-current-kmod is out-of-date.
   > When I try to upgrade drm-current-kmod (r561457) I get:
   >
   > ===>  drm-current-kmod-5.4.62.g20210113 not supported on older
   > CURRENT, no
   > kernel support.
   > *** Error code 1
   >
   > Stop.
   > make: stopped in /usr/ports/graphics/drm-current-kmod
   >
   > Huh?
   > 	What is my path forward? (That does not involve reinstalling 
the

   > OS.)

   Either

   upgrade the kernel without the drm PORTS_ whatever thing h
   upgrade drm-current-kmod h add back the PORTS_thing if you
   really want it upgrade kernel again


If I understand things correctly: things in the PORTS_MODULES
list are upgraded _after_ the kernel is completely rebuilt.
I am hitting this _during_ the rebuild.


I'm not sure if they will be upgraded after it's installed..

also, did you upgrade the world?
The version stuff that ports checks comes from /usr/include.


So the question becomes: _will_ removing the IGNORE line work?


Why wouldn't it?


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

Re: Name of touchpad changed in latest rev

[Greg V]

On Mon, Jan 18, 2021 at 08:01, Malcolm Matalka  
wrote:

I just installed the below revision, and looks like the name the mouse
shows up as has changed.  Not sure if this is intended or not.  What 
was

"SynPS/2 Synaptics TouchPad" and now it is "DELL07E6:00 06CB:76AF
TouchPad".


Congratulations, you are now using the touchpad over I2C instead of 
PS/2 :)
The iichid code has finally landed in current so we have much better 
HID support now.



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

Re: panic in drm or vt or deadlock on mutex or ...

[Greg V]

On Mon, Feb 8, 2021 at 04:53, Alastair Hogge  wrote:

On 2021-02-04 17:50, Emmanuel Vadot wrote:

[...]


  Only happens with drm when you do what ?


Boot to multi-user; login (getty):
$ doas kldload /boot/modules/amdgpu.ko
$ sysctl
[panic]

..is a guaranteed way to panic my system.



https://github.com/freebsd/drm-kmod/issues/15 → 
https://github.com/freebsd/drm-kmod/pull/37 ?



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

Re: FYI for aarch64 main [14] running a mid March version: I ended up with [usb{usbus2}] stuck at (near) 100% cpu

[Greg V]

On May 14, 2021 5:59:48 AM UTC, Mark Millard via freebsd-current 
 wrote:
>The [usb{usbus2}] process eventually got stuck-busy, no
>more I/O:
>
>
>The system was a MACCHIATObin Double Shot.

I've noticed USB issues on the mcbin too.
In my experience uaudio was the most likely thing to freeze: sometimes when 
playing audio the whole USB stack would hang, IIRC only unplugging and 
reconnecting the hub would let USB I/O continue.

Looks like the XHCI hardware might not be fully stable here?? but I do wonder 
if we could possibly lack some recovery mechanisms for this situation that 
other OSes have.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Buildworld error: [_cleanworldtmp] Error code 6

[h v]

On 31.10.24 13:50, Renato Botelho wrote:
I do incremental builds using META_MODE on this system every ~ 2 weeks 
and today I got an error when I tried to build world.  I considered to 
just clean /usr/obj and move on but decided to report it here first 
for the case anyone is interested.


For me,  it was sufficient to rm -rf $OBJTOP/tmp  manually before 
buildworld.. omitting  -j XX when doing buildworld. also seems to help, 
but slows down the build considerably.


Timing issue ?

Regards

Henry



current system is running main-n273133-419249c1cac

make[1]: "/usr/src/Makefile.inc1" line 364: SYSTEM_COMPILER: libclang 
will be built for bootstrapping a cross-compiler.
make[1]: "/usr/src/Makefile.inc1" line 369: SYSTEM_LINKER: libclang 
will be built for bootstrapping a cross-linker.

--
>>> World build started on Thu Oct 31 09:45:27 -03 2024
--
>>> Deleting stale files in build tree...
    0.60 real 0.46 user 0.73 sys
*** [_cleanworldtmp] Error code 6

make[1]: stopped making "buildworld" in /usr/src
.ERROR_TARGET='_cleanworldtmp'
.ERROR_META_FILE=''
.MAKE.LEVEL='1'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='buildworld'
CPUTYPE=''
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MACHINE_CPUARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20240711'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk 
/usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk 
/etc/src-env.conf
 /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk 
/usr/src/share/mk/local.sys.machine.mk /usr/src/share/mk/meta.
sys.mk /usr/src/share/mk/local.meta.sys.env.mk 
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk 
/etc/make.conf /
usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/src.tools.mk
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.endian.mk /u
sr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.compat.pre.mk /u
sr/src/Makefile.libcompat /usr/src/share/mk/bsd.compat.mk 
/usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.init.mk /usr/sr

c/share/mk/local.init.mk /usr/src/share/mk/src.init.mk'
.PATH='. /usr/src'
make[1]: 1 error

make[1]: stopped making "buildworld" in /usr/src
.ERROR_TARGET='_cleanworldtmp'
.ERROR_META_FILE=''
.MAKE.LEVEL='1'
MAKEFILE=''
.MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes'
_ERROR_CMD='.PHONY'
.CURDIR='/usr/src'
.MAKE='make'
.OBJDIR='/usr/obj/usr/src/amd64.amd64'
.TARGETS='buildworld'
CPUTYPE=''
DESTDIR=''
LD_LIBRARY_PATH=''
MACHINE='amd64'
MACHINE_ARCH='amd64'
MACHINE_CPUARCH='amd64'
MAKEOBJDIRPREFIX=''
MAKESYSPATH='/usr/src/share/mk'
MAKE_VERSION='20240711'
PATH='/sbin:/bin:/usr/sbin:/usr/bin'
SRCTOP='/usr/src'
OBJTOP='/usr/obj/usr/src/amd64.amd64'
.MAKE.MAKEFILES='/usr/src/share/mk/sys.mk 
/usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk 
/etc/src-env.conf
 /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk 
/usr/src/share/mk/local.sys.machine.mk /usr/src/share/mk/meta.
sys.mk /usr/src/share/mk/local.meta.sys.env.mk 
/usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk 
/etc/make.conf /
usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk 
/etc/src.conf /usr/src/Makefile.inc1 /usr/src/share/mk/src.tools.mk
/usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.opts.mk 
/usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/bsd.endian.mk /u
sr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk 
/usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.compat.pre.mk /u
sr/src/Makefile.libcompat /usr/src/share/mk/bsd.compat.mk 
/usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.init.mk /usr/sr

c/share/mk/local.init.mk /usr/src/share/mk/src.init.mk'
.PATH='. /usr/src'
--- buildworld ---

/etc/pccard_ether "improvement"

[Robert V. Baron]

I'm going to be using either a wavelanII (wi0) or a 3com (ep0)
on my laptop.  I'd like to have the rc.conf's specify how to 
configure each.  Then I'd like to have the one that is in the
machine to be configured.  In the current /etc/ether_pccard there
is $pccard_ifconfig which is used as args to ifconfig if 
$pccard_ifconfig is not NO.  But I need a different ifconfig for
each device.  So I'd like to propose fixing pccard_ether as:
--- /etc/pccard_ether.BAK   Mon Oct  4 10:38:32 1999
+++ /etc/pccard_ether   Mon Oct  4 11:09:18 1999
@@ -35,7 +35,14 @@
else
interface=$1
shift
-   ifconfig $interface $pccard_ifconfig $*
+   if [ "x$pccard_ifconfig" = "xYES" ] ; then
+   eval ifconfig_args=\$ifconfig_${interface}
+   if [ -n "${ifconfig_args}" ] ; then
+   ifconfig ${interface} ${ifconfig_args} $*
+   fi
+   else
+   ifconfig $interface $pccard_ifconfig $*
+   fi
fi
 fi
This way pccard devices are initialized just like other devices


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

sysinstall tweak

[Robert V. Baron]

Suppose I need to install on a bunch of machines.  What I'd do, is 
install once, get all the pieces/ports/customizations right and then
make a tarball of the system.  To install the next machine, I'd use
sysinstall to partition and label the new machine and then just nfs
mount the machine with the tarball, unroll it and just fix rc.conf as
necessary.  But when you go this way, there are no commands available
available at the holographic shell.  Could this be fixed by letting
the commands be linked/copied into the chroot env?
(As a workaround I just put a good copy of tar with the tarball in
nfs, and used that tar.)



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

subscribe

[Ruslan V. Sulakov]

subscribe



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Dell laptop cardbus problem

[Vladimir V. Egorin]

25687935, end = 27696059, size 2008125 : OK
pccbb0: card inserted: event=0x, state=3820
pccbb0: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
pccbb0: pccbb_power: CARD_VCC_3V and CARD_VPP_VCC [11]
found-> vendor=0x115d, dev=0x0003, revid=0x03
class=02-00-00, hdrtype=0x00, mfdev=1
cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords)
lattimer=0xa8 (5040 ns), mingnt=0x14 (5000 ns), maxlat=0x28 (1 ns)
intpin=a, irq=0
TUPLE: LINKTARGET [3]: 43 49 53
Product version: 5.0
Product name: Xircom | CardBus Ethernet 10/100 + Modem 56 | CBEM56G | 1.03 | 
TUPLE: Unknown(0x88) [4]: b8 d5 98 00
TUPLE: Unknown(0x8a) [12]: 39 30 30 33 57 47 39 38 44 35 42 38
TUPLE: Unknown(0x8b) [4]: 01 00 00 00
Manufacturer ID: 0501030181
TUPLE: DATE [4]: d7 72 4a 29
Functions: Network Adaptor, Multi-Functioned
Function Extension: 04060010a498d5b8
Function Extension: 0102
Function Extension: 0280969800
Function Extension: 0200e1f505
Function Extension: 0301
Function Extension: 0303
Function Extension: 0501
TUPLE: DEVICE_OC [4]: 02 4f 02 ff
cardbus0: Opening BAR: type=IO, bar=10, len=0080
cardbus0: Opening BAR: type=MEM, bar=14, len=0080
cardbus0: Opening BAR: type=MEM, bar=18, len=0100
cardbus0: Invalid BAR number: 27(06)
TUPLE: CONFIG_CB [7]: 03 02 03 01 00 00 ff
TUPLE: CFTABLE_ENTRY_CB [8]: 41 b0 b0 bc 8e 0e fb 04
TUPLE: CFTABLE_ENTRY_CB [9]: 02 b8 02 b0 bc 8e 1c fb 04
TUPLE: NO_LINK [0]:
CIS reading done
cardbus0: Non-prefetchable memory at 4400-4400017f
cardbus0: Non-prefetchable memory rid=18 at 4400-44ff (100)
cardbus0: Non-prefetchable memory rid=14 at 44000100-4400017f (80)
cardbus0: IO port at 1000-107f
cardbus0: IO port rid=10 at 1000-107f
dc0:  port 0x1000-0x107f mem 
0x4400-0x44ff,0x44000100-0x4400017f irq 11 at device 0.0 on cardbus0
dc0: Ethernet address: 4a:29:21:02:06:00
miibus0:  on dc0
tdkphy0:  on miibus0
tdkphy0: OUI 0x00c039, model 0x0014, rev. 11
tdkphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
bpf: dc0 attached
found-> vendor=0x115d, dev=0x0103, revid=0x03
class=07-00-02, hdrtype=0x00, mfdev=1
cmdreg=0x, statreg=0x0210, cachelnsz=0 (dwords)
lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns)
intpin=a, irq=0
TUPLE: LINKTARGET [3]: 43 49 53
Product version: 5.0
Product name: Xircom | CardBus Ethernet 10/100 + Modem 56 | CBEM56G | 1.03 | 
TUPLE: Unknown(0x88) [4]: b8 d5 98 00
TUPLE: Unknown(0x8a) [12]: 00 00 00 00 00 00 00 00 00 00 00 00
TUPLE: Unknown(0x8b) [4]: 01 00 00 00
Manufacturer ID: 0501001081
TUPLE: DATE [4]: d7 72 4a 29
Functions: Serial Port, Multi-Functioned
Function Extension: 00020f5c
Function Extension: 0206003f1c03030f070001b5
Function Extension: 1306000b000200b5
TUPLE: DEVICE_OC [4]: 02 4f 02 ff
cardbus0: Opening BAR: type=IO, bar=10, len=0002
cardbus0: Opening BAR: type=MEM, bar=14, len=0002
cardbus0: Opening BAR: type=MEM, bar=18, len=0100
cardbus0: Invalid BAR number: 27(06)
TUPLE: CONFIG_CB [7]: 03 02 f3 00 00 00 ff
TUPLE: CFTABLE_ENTRY_CB [9]: 41 b8 02 b0 bc 8e 0e fb 04
TUPLE: CFTABLE_ENTRY_CB [8]: 02 b0 b0 bc 8e 0e fb 04
TUPLE: NO_LINK [0]:
CIS reading done
cardbus0: Non-prefetchable memory at 44000200-44000301
cardbus0: Non-prefetchable memory rid=18 at 44000200-440002ff (100)
cardbus0: Non-prefetchable memory rid=14 at 44000300-44000301 (2)
cardbus0: IO port at 1080-1081
cardbus0: IO port rid=10 at 1080-1081
sio4: irq maps: 0x201 0x201 0x201 0x201
sio4: probe failed test(s): 0 1 2 4 6 7 9
sio4: irq maps: 0x201 0x201 0x201 0x201
sio4: probe failed test(s): 0 1 2 4 6 7 9
cardbus0:  (vendor=0x115d, dev=0x0103) at 0.1 irq 11
start_init: trying /sbin/init
cardbus1: detach_card: no card to detach!
pccbb1: pccbb_power: CARD_VCC_0V and CARD_VPP_0V [44]
link_elf: symbol pfil_add_hook undefined
 cstsevent occures, 0x3868
splash: image decoder found: green_saver
Linux ELF exec handler installed




#
# NEWCARD -- efforts at porting newconfig pccard/cardbus code to newbus
#
# This is a new implementation of pccard and cardbus support.  It works
# for many folks right now.  Some folks still have issues.  The support
# around the edges isn't as complete as the previous pccard system.
#
# For more information on this file, please read the handbook section on
# Kernel Configuration Files:
#
#http://www.FreeBSD.org/handbook/kernelconfig-config.html
#
# The handbook is also available locally in /usr/share/doc/handbook
# if you've installed the doc distribution, otherwise always see the
# FreeBSD World Wide Web server (http://www.FreeBSD.org/) for the
# latest information.
#
# An exhaustive list of options and more detailed explanations of the
# device lines is also present in the NOTES configuration file. If you are
# in doubt as to the purpose or necessity of a line, check first in NOTES.
#
# $FreeBSD: src/sys/i386/conf/NEWCARD,v 1.50 2001/08/06 16:04:39 nate Exp $

machine i386
cpu I686_CPU
ident   NEWCARD
maxusers128

#To statically compil

Re: Dell laptop cardbus problem

[Vladimir V. Egorin]

On Sat, Sep 15, 2001 at 11:03:25PM +0200, Georg-W. Koltermann wrote:
> At Sat, 15 Sep 2001 14:43:38 -0500,
> Vladimir V. Egorin <[EMAIL PROTECTED]> wrote:
> > 
> > I have a Dell Latitude CPx with a Xircom RealPort
> > CardBus Ethernet 10/100+Modem 56 card.  The card used
> > to work on an Aug 1, 2001 -CURRENT. I've cvsup'ed and
> > built the system yesterday (sep 15) and cannot make the card
> > work anymore.   Any ideas what might be wrong?  I am attaching 
> > dmesg and  kernel config (NEWCARD).   I have the following
> > in sio.c:
> > 
> > static struct pci_ids pci_ids[] = {
> > { 0x0103115d, "Xircom Cardbus modem", 0x10 },
> > { 0x, NULL, 0 }
> > };
> > 
> > [...]
> >
> > sio3: configured irq 9 not in bitmap of probed irqs 0
> > sio3: irq maps: 0x201 0x201 0x201 0x201
> > sio3: probe failed test(s): 0 1 2 4 6 7 9
> > sio3 failed to probe at port 0x2e8-0x2ef irq 9 on isa0
> 
> I remember the probe failure.  My card needed to be re-initialized to
> 8 bit CFCR.  I'm attaching my current patch which I'm using on an
> early August -current.
> 
> Warner, how about committing this patch?

Thank you very much for the advice.
I had an equivalent "fix" in sio.c (was calling sioprobe() twice in
sio_pci_probe() ), this worked on Aug 1 -CURRENT, but not anymore.
I've also tried applying your patch, unfortunately with no success.
I guess I'll just downgrade back to Aug 1 source.Warner, I'll be
happy to upgrade and test if needed whenever you have a chance to get
back to this.

-- 
Vladimir

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Request for CDR/CDRW drives working status

[Alexey V. Neyman]

Hello, Soren!

>Drive model/version (from dmesg and possibly  from the label on the drive).
I've sent you info about
acd0:  CD-RW drive
(PR: 25840), I think it was complete enogh for poll? :)

Best regards,
Alexey.



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Supported ATAPI cdr/cdrw drives

[Alexey V. Neyman]

Good day!

On Mon, 28 May 2001, Søren Schmidt wrote:

>As promised I've made up a list of reports I've received so far go to
>http://freebsd.dk/ and follow the link.
>
>I also have a patch for the Yamaha's (yamaha-cdr.p1) which also
>can be found via the above URL. Let me know if that make things
>work...

yamaha-cdr.p1 is mode 0600, there is yamaha-cdr.p2, but it does not apply
cleanly (FreeBSD srv2.any 4.3-STABLE, cvsupped about 7-8 Jun).

I tried to apply it manually, and everything was ok. The disk was written
and closed successfully. Thank you.

When MFC'ing, close my PR 25960 :)

-- 
---+---
Is that not what living is for?| Regards, Alexey V. Neyman
   | mailto: [EMAIL PROTECTED]
( Pkunk, SC2 )-+---



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: status of bridge code

[Vitaly V. Belekhov]

On Wed, 24 Jan 2001, Julian Elischer wrote:

 ...

> > my dc cards.  No problems so far - as long as I don't use DUMMYNET with it.
> > I really wish I could use DUMMYNET as I need to put bandwidth limits on a
> > few of the computers on my network.

 ...

> Rate limitting is one thing that isn't there yet. If we pulled our fingers out,
> I guess we would have ripped the dummynet rate limmiter out of where it is
> and placed it into a netgraph node where it would be generally useful
> instead of being hardcoded into one (sometimes useful) localtion in the 
> netoworking stacks.
> 
> there is a rate limitter based on netgraph available from:
> http://www.riss-telecom.ru/~vitaly/
> 
> but I have not tried it.
> 
> I need to look at it again as I believe it has improved and 
> may be generally useful.
> When I looked at it last it was a bit alpha.
> It probably needs rewriting for the new netgraph API in -current.

 Current state of this project:
 Grade: production, working on more than 40 hosts from June 2000,
city-wide ISP network
 OS version:3-STABLE from 8 January 2000 - this version currently used
in our production routers/hosts
 Capabilities:  guaranteed low bandwidth, maximum bandwidth, priority can be
set for queue, traffic classification and bandwidth management
realized by separate netgraph nodes.

 Since I currently have high workload, I dont have time to port it to 4.x or
 5-CURRENT...
 Conclusion: volunteer required for this work... and I can consult him/her.

-- 
Vitaly Belekhov
System architect,
AB-Telecom, Novosibirsk



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Can not boot after r203503. Unable to open /dev/ada(1/2)p3 for writing

[Andrey V . Elsukov]

26.02.10, 14:47, "Paul Wootton" :
>  I have an unusual problem. Last night I tried updating from my old-ish 
>  kernel/world to an up to date version. I had been using 202500-ish 
>  successfully. I can build and install the newer world and kernel fine, 
>  but when I reboot I get the following
>  
>  Trying to mount root from zfs:raid250/root
>  ZFS WARNING: Unable to open /dev/ada1p3 for writing (error=1). ZFS 
>  WARNING: Unable to open /dev/ada2p3 for writing (error=1). ROOT MOUNT ERROR.
>  If you have invalid mount options, reboot, and first try the following 
>  from the loader prompt:
>  set vfs.root.mountfrom.options=rw
>  and then remove the invalid options from /etc/fstab
>  loader variables:
>  vfs.root.mountfrom=zfs:raid250/root
>  vfs.root.mountfrom.options=rw

I had the same problem recently. I have ZFS-only 9.0-CURRENT-amd64.
First time when i had this problem was after I added linux_load="YES" in
/boot/loader.conf. :-) 
It was only change i made. So, i rebooted again and unload linux from 
boot prompt. And system boots fine. I tried again with linux.ko and it failed to
boot. After that i synced source tree and rebuild kernel. And after that it 
failed
to boot with and without linux. :-)
So, after that i booted from another disk and only thing that i did was:
# zpool import -R /mnt z
# gpart modify -l ZFS -i 3 ad4 (previous label was "zfs")
After that i can boot with and without linux.ko again. And I can't reproduce 
this bug again.

-- 
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

buildkernel broken

[Sergey V. Dyatko]

Hi, 
I'm trying to build kernel (update from  204272 to 205122) and
got following error:

===> drm/i915 (all)
cc -O2 -pipe -fno-strict-aliasing -Werror -D_KERNEL -DKLD_MODULE
-nostdinc   -DHAVE_KERNEL_OPTION_HEADERS
-include /usr/obj/usr/src/sys/b450/opt_global.h -I. -I@
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100
--param large-function-growth=1000 -fno-common -g
-fno-omit-frame-pointer -I/usr/obj/usr/src/sys/b450 -mcmodel=kernel
-mno-red-zone  -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx
-mno-3dnow  -msoft-float -fno-asynchronous-unwind-tables -ffreestanding
-fstack-protector -std=iso9899:1999 -fstack-protector -Wall
-Wredundant-decls -Wnested-externs -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  -Wundef
-Wno-pointer-sign -fformat-extensions
-c /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c 
/usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:
In function
'i915_dma_cleanup': 
/usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159:
error: 'DEV' undeclared (first use in this
function) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159:
error: (Each undeclared identifier is reported only
once /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:159:
error: for each function it appears
in.) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In
function
'i915_set_status_page': 
/usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:807:
error: 'DEV' undeclared (first use in this
function) /usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c: In
function
'i915_driver_load': 
/usr/src/sys/modules/drm/i915/../../../dev/drm/i915_dma.c:847:
error: 'DEV' undeclared (first use in this function) *** Error code 1

Stop in /usr/src/sys/modules/drm/i915.
*** Error code 1

Stop in /usr/src/sys/modules/drm.
*** Error code 1

Stop in /usr/src/sys/modules.
*** Error code 1

Stop in /usr/obj/usr/src/sys/b450.
*** Error code 1

Stop in /usr/src.
*** Error code 1

Stop in /usr/src.


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

Re: Results of BIND RFC

[Andrey V. Elsukov]

On 02.04.2010 9:24, Stanislav Sedov wrote:

While it certainly might make sense to drop BIND out of the base, I'm not
sure dropping bind tools as well from it is the best decision.  How hard
it will be to continue maintaining bind tools inside the base (so the
critical ones like dig and nslookup still will be available), while moving
the rest of it (the server itself and supporting tools) to the port?


Hi, All.

I'm agree with Stas. If it is not so hard to maintain "bind-tools" in the base,
It is very useful to still having them in base system.

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

[RFC] Rewriting sade(8)

[Andrey V . Elsukov]

Hi, All.

Some days ago i begun rewriting sade(8) to libgeom(3). Just for fun :-)
Today i have progress and you can see some screenshoots here:
http://butcher.heavennet.ru/sade/

What is done:
1. It's fully rewritten, but yes, i reuse some code from old sade.
2. I wrote small framework "customdlg" for creating custom dialogs (not yet 
fully finished, but works).
3. Now sade use libgeom for searching providers and it can use:
{"DISK","disk device"},
{"MD",  "memory backed virtual disk"},
{"ZFS::ZVOL",   "ZFS volume"},
{"MIRROR",  "GEOM based mirror (RAID1)"},
{"STRIPE",  "GEOM based stripe (RAID0)"},
{"RAID3",   "GEOM based RAID3 array"},
{"CONCAT",  "GEOM based concatenated disk"},
{"ELI", "GEOM based encrypted disk"},
{"JOURNAL", "GEOM based journalled disk"},
{"MULTIPATH",   "GEOM based disk with multiple path"}
4. Access to partitions based on geom_part.so library. I made some changes in 
geom_part.c and
sent it to Marcel, but currently didn't receive answer. Any way if these 
changes is not acceptable
i can rewrite it for using libgeom(3) only.
5. Undo/Commit features are based on internal implementation of geom class 
PART. I found there
two bugs:
http://lists.freebsd.org/pipermail/freebsd-geom/2010-April/004018.html
http://lists.freebsd.org/pipermail/freebsd-bugs/2010-April/039390.html
6. All "device" related code can be placed in shared library and in future can 
be reused in another
frontend...
7. New Partition Editor:
* partitions list now scrollable;
* all operations based on geom_part.so and similar to gpart(8);
* opening partition editor on empty provider opens new "Selech Partitioning 
Scheme" dialog
and create selected scheme;
* new add slice dialog;
* deleting slice from empty table destroys scheme;

Todo:
1. Refine customdlg.
2. Waiting for fixes in geom_part_mbr, geom_part and geom_part.so.
3. "Set Type and Label" dialog.
4. Better wording needed for messages and help. My english is bad :(
--
Missing functions:
Creating filesystem and save them into /etc/fstab.

What new can be added:
1. Creating ZFS pools and datasets.
2. Creating GEOM-based raids.

Any comments are welcome.
-- 
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Rewriting sade(8)

[Andrey V. Elsukov]

On 07.04.2010 21:49, Randi Harper wrote:

Wow. This is awesome. patches? :D


:)
I'm not ready yet to publish code. I planned to announce this RFC
a bit later, when code will be finished. But Konstantin (kib@) suggested
do it before finishing.


I've been working on moving sysinstall from libdisk to libgeom, but
unfortunately it's a bit more complicated (redoing the way we detect
devices while I'm at it). I've done a lot of the heavy lifting code,
but I haven't even started on the GUI parts yet. I'd love to see how
someone else tackled doing this. I'm particularly interested in #5&
#7. :)


Initially i wanted to only modify current sade's code to move it from
libdisk to libgeom. But after several attempts i decided that it will be
easier to rewrite it :)


Generally, we try to keep sysinstall's disk tools and sade in sync, so
I would like to work with you on this and see what we can come up
with. I'm not entirely sure if #2 is a viable option since we already
have functions in sysinstall that handle generating dialog boxes with
libdialog, but if it's an improvement on what's existing, bring it on.


Yes, I looked at this code in sysinstall and in libdialog. Also I looked
to another console UI libs. The main problem of using external libraries
is that not so easy import them into base system.

libdialog have several problemls too, imho.
1. Custom dialogs based on ComposeObj are ugly :)
2. It supports *only* single-byte characters. Initially I wanted to
write code with message catalogs support. But after several tests
I leaved this idea. Also it seems there is no catgets analog for
wide characters.

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Rewriting sade(8)

[Andrey V. Elsukov]

On 08.04.2010 10:27, Bruce Cran wrote:

That's a shame. As long as the source isn't available it's of little interest
to me.

For anyone who wants to see the bits of code I've got so far, I've created a
Google Code project at http://code.google.com/p/gcpart/ . I'm currently trying
to figure out how to get the partitioning scheme out of the XML tree, which is
why there's no geom code there yet.  As soon as I do so, I'll start checking
in my effort at the new partitioning application.


I just thinking about future of my project. It seems there are several people
who worked on the same before. And I have not finished yet only few things from
initially planned. After that i can remove any unused code, write some comments
and publish it somewhere in perforce.
Also at this time code depends on changes which i made in geom_part.so and which
are not yet commited into base system.
After code review there can be several ways to go. And I have an interest which 
way
will be for me :)

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Rewriting sade(8)

[Andrey V. Elsukov]

On 08.04.2010 11:27, Randi Harper wrote:

It's great that you want to work on this, but there are other people
working in the same area, so keeping your code to yourself for too
long makes it very likely that it will never get used.


Ok. I put the code here:
http://butcher.heavennet.ru/sade/sade-20100408.tgz

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Rewriting sade(8)

[Andrey V. Elsukov]

On 08.04.2010 14:15, Alexander Leidinger wrote:

We don't grant non-committers access to the Subversion repo.


Ooops... seems I misremembered his status. Somehow I associate him with
something FreeBSD related. Andrey, did you participate in a GSoC?


No, I'm not fit for GSoC.


My suggestion is to add a "sysinstall mode" to sade where it operates
under certain (minor) constraints and reports what it did in a format
that sysinstall can parse, so sysinstall can just fork-exec sade instead
of duplicating the code.


I like this idea. Any way i'll try to finish my work myself.

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Re: [RFC] Rewriting sade(8)

[Andrey V . Elsukov]

09.04.10, 11:20, "Garrett Cooper" :
>  Ok. Or maybe since `we're here' sade needs to be populating
>  $DESTDIR/etc/fstab, not sysinstall ? 

I'm also looking for answer to this question. It seems that all basic operations
with partitions are already implemented. And I think about next steps.

Also I think I should make a dialog for writing bootcode. And there are a bunch 
of
different bootstrap code which can be used with different schemes. So if anyone 
can share own experience I'll be grateful.

MBR:
/boot/mbr - standart boot record (is it needed? Is it not the same which gpart 
creates?).
/boot/boot0 - boot0 boot manager.
/boot/boot0sio - boot0 boot manager with redirected output ot com1.

GPT:
/boot/pmbr - protective mbr
/boot/gptboot - bootstrap code for booting from GPT, should be installed to 
freebsd-boot
partition.
/boot/gptzfsboot - bootstrap code for booting from GPT and ZFS, should be 
installed to 
freebsd-boot partition.

/boot/zfsboot - bootstrap code for booting from ZFS from MBR, it seems this 
bootcode doesn't have
a correct way (e.g `gpart bootcode ...`) to be writed.

What about VTOC8, PC98, APM?

-- 
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: ipfw bug on i386

[Andrey V. Elsukov]

On 12.04.2010 10:07, Hizel Ildar wrote:

Hey! I'm fix this bug :D

patch:

foo# diff -ruN main.c~ main.c
--- main.c~ 2010-03-04 19:54:56.0 +0300
+++ main.c  2010-04-12 09:37:21.0 +0400
@@ -553,7 +553,7 @@
 }

 while (fgets(buf, BUFSIZ, f)) { /* read commands */
-   char linename[10];
+   char linename[11];
 char *args[2];

 lineno++;


Can you test your it with 100k lines? :)
I think it can be fixed with something similar to:

-   sprintf(linename, "Line %d", lineno);
+   snprintf(linename, sizeof(linename), "Line %d", lineno);

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Rewriting sade(8)

[Andrey V. Elsukov]

On 14.04.2010 13:28, Daniel Braniss wrote:

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


At this thime I implemented writing bootstrap code only for MBR and GPT schemes.
For MBR scheme user can select one from "Standart MBR" and "Boot Manager".
For GPT scheme user can select ZFS-aware gptzfsboot and gptboot.

Currently I'm working on File Systems Editor. But here are lot of work.

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Andrey V. Elsukov]

On 21.04.2010 2:44, Maxim Sobolev wrote:

Maxim Sobolev wrote:

Maybe try adding

hint.atkbdc.0.disabled="1"
hint.atkbd.0.disabled="1"


Actually it helped, thank you very much! The problem was that I have had
my hints compiled into the kernel itself.


Hi, Maxim.

I tried to boot 9.0-CURRENT amd64 snapshot on IBM x3650 M2 and seems have the
same problem, i set hints from loader prompt, but this didn't help.
Can you explain what you did to boot FreeBSD faster?

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server

[Andrey V. Elsukov]

On 21.04.2010 10:01, pluknet wrote:

Hmm.. That's strange to hear.
We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64).
All runs flawlessly.
  I'll try to boot it from head today if that matters.


It was about 1.5 hour ago when i entered "autoboot" in loader prompt.
It still show slowly rotated dash line at end of
/boot/kernel/kernel text=x |

--
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Re: Switchover to CAM ATA?

[Andrey V . Elsukov]

22.04.10, 11:17, "Adam Vande More":

>  I think sade(and by further discussion sysinstall) is now getting some
>  attention and now supports geom devices, zfs, etc at least in one person's
>  testbed.  I know that's it's been tried before but there are actually
>  screenshots from it.
>  
>  http://lists.freebsd.org/pipermail/freebsd-current/2010-April/016418.html

Yes, I have plans to add support of simple GEOM-based RAID management
in sade.

-- 
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: KVA/KVM shortages

[Robert V. Baron]

Mike Smith  writes:

> I just committed a tweak that allows you to say:
> 
>   set kern.vm.kmem.size=
> 
> at the loader prompt or in /boot/loader.rc to override the default 
> VM_KMEM_SIZE value.
> 
> If anyone has any more of these tunables that can easily be enhanced 
> like this, please let me know.
> 
How about all the parameters that are assigned in param.c?  Why not
make them all tweakable in the loader.rc, rather than having to patch
the kernel.

Actually, thinking about this a little more ...
The loader knows where all symbols are in memory.  Why not a general
mechanism to let you reassign the value of any "variable" used in
the kernel or in a module.  I presume that the loader allocates bss
for the kernel and each module as it loads it.  So I presume I can
assign a value to a variable that would ordinarily take on a 0
value, too.

To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

3.0-STABLE and 4.0-CURRENT snapshots

[Roman V. Palagin]

Hello!

Where I can find snapshot for -stable & -current? I've tried
current.freebsd.org, but 'cd /pub/FreeBSD' says 'Permission denied'.
And there is nothing at
ftp://ftp.freebsd.org/pub/FreeBSD/release/snapshots/i386 

  -----
   Roman V. Palagin  |  RVP1-6BONE | Just because you're paranoid
   Network Administrator |  RP40-RIPE  | doesn't mean they AREN'T after you


To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Problems with nfsstat and dynamic OID

[Roman V. Palagin]

Hello! Five minutes ago I type 'nfsstat' and got:

nfsstat: sysctl: No such file or directory

I take a look at the source and that's what I found:
Nfsstat gets statistic via sysctl(3). name[0]=CTL_VFS, name[2]=NFS_NFSSTATS, 
but name[1] has a value of vfc.vfc_typenum, returned by getvfsbyname(3).
And it is very bad, 'cause vfc_typenum contains fs type number assigned
by kernel, not sysctl OID! As we can see in nfs_vfsops.c NFS sysctl node
declared with OID_AUTO (on my system it becomes 119, not 4 as returned by
getvfsbyname).

Operating system is 4.0-CURRENT as of 1999/02/20. What you think?

p.s. Sorry for bad English :(

  -----
   Roman V. Palagin  |  RVP1-6BONE | Just because you're paranoid
   Network Administrator |  RP40-RIPE  | doesn't mean they AREN'T after you



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Re: Problems with nfsstat and dynamic OID

[Roman V. Palagin]

On Sun, 21 Feb 1999, Doug Rabson wrote:

> 
> Oh.  Thats nasty.  I don't want to allocate special oids for 'privileged'
> nodes.  I think the userland code should use sysctlbyname() instead.
> This patch seems to fix it for me:
Works for me too. This problem exists not only in -current, i believe.
Should all sysctl be replaced by sysctlbyname? I just grep sysctl in `find
/usr/src/usr.bin *.c` and got many lines. Just start checking...
 
> 
> Index: nfsstat.c
> ===
> RCS file: /home/ncvs/src/usr.bin/nfsstat/nfsstat.c,v
> retrieving revision 1.12
> diff -u -r1.12 nfsstat.c
> --- nfsstat.c 1998/10/25 10:59:44 1.12
> +++ nfsstat.c 1999/02/21 11:47:08
> @@ -162,16 +162,9 @@
>   err(1, "kvm_read");
>   }
>   } else {
> - int name[3];
>   size_t buflen = sizeof *stp;
> - struct vfsconf vfc;
>  
> - if (getvfsbyname("nfs", &vfc) < 0)
> - err(1, "getvfsbyname: NFS not compiled into kernel");
> - name[0] = CTL_VFS;
> - name[1] = vfc.vfc_typenum;
> - name[2] = NFS_NFSSTATS;
> - if (sysctl(name, 3, stp, &buflen, (void *)0, (size_t)0) < 0) {
> + if (sysctlbyname("vfs.nfs.nfsstats", stp, &buflen, (void *)0, 
> (size_t)0) < 0) {
>   err(1, "sysctl");
>   }
>   }
> 
> --
> Doug Rabson   Mail:  d...@nlsystems.com
> Nonlinear Systems Ltd.Phone: +44 181 442 9037
> 
> 
> 
> 
> To Unsubscribe: send mail to majord...@freebsd.org
> with "unsubscribe freebsd-current" in the body of the message
> 

  -
   Roman V. Palagin   | Friday, monday, what's the difference.
   System Administrator   | (C) Jordan K. Hubbard



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

[no subject]

[Inna V. Dotsenko]

subscribe



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

[no subject]

[Inna V. Dotsenko]

auth c92316af subscribe freebsd-current bl...@quadrus.ru



To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

Status of 'tee' firewall action

[Roman V. Palagin]

Hello!

What the status of 'tee' action? Anybody working on it?

  -
   Roman V. Palagin | RVP1-6BONE, RP40-RIPE| Network Administrator   
  -




To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-current" in the body of the message

ONE HUNDRED MiLLioN E-MAiL AddREssES *NEW CD* $99

[plglDaniel V McCaul]

You want email addresses; we've got lots of fresh ones.
Face it, there's no way you're going to extract 400 million email addresses
with some flimsy email extractor program you downloaded from the web.
You're lucky if you can extract 2 million in a year! 

Our email addresses are even targeted in 34 different categories to help you 
reach only the market you want.

No need to buy any more directories from the web. We've bought almost all of
them for you, cleaned them up including removal of duplicates and flamers, 
and compiled them into a 4 disk volume for only $139.00

Now you can send emails to millions of people worldwide. Imagine if only
a small number out of even 1 million emails sent responded to your email. 
Don't you think you'd make something out of that?

No need to worry if our email addresses will work with your mailing program.
We already thought of that and made sure to save all files as text files. Text files
are the most universal types of files so they will import easily. Also, there's no
limit to how many times you can use our email addresses.

Still have more specific questions? We're here to help. You can contact us by email
At [EMAIL PROTECTED]  make sure to put "ENQUIRY" in the subject line

Want to order? Follow the instructions below:

[] I want to order online

Please complete ONLY section A & B of the order form below and either fax or email it 
back to us. If you're faxing it, send it to 1-6 30-604-1030 or 1-44 3-659-0730

[] I want to order by Credit Card

Please complete section A , B & C  of the order form below. For your security, DO NOT 
email anything with your credit card number on it. Please fax your order form to 
1-63 0-604-10 30 or 1-4 43-659-07 30

[] I want to order by Paypal

Please complete section A , B & D of the order form below. You can email or fax the 
order form back to us for processing. Return by fax to 1-630-604-1 030 or 1-443-6 
59-0730

\

SECTION A  - Products & Shipping (prices are in US$)

BULK DIRECTORIES:

[] Email Marketing CD with 100 million Addresses $69.00
[] 200 Million Email Addresses on 2 CD's $79.00 
[] 1.5 Million USA Business Fax Numbers $49.00 
[] PACKAGE "A" - ALL DIRECTORIES ABOVE (3 CDs) $99.00 

[] Email Gold CD FRESHLY EXTRACTED 100 Million Addresses $99.00
[] 7 Million Chinese Email Addresses $99.00 
[] PACKAGE "B" + PACKAGE "A"- All directories above (4 CDs) $139.00

SPECIALTY DIRECTORIES:

[] 1 Million Email Addresses from French speaking countries $69
[] 1 Million Email Addresses from Spanish speaking countries $69
[] 1 Million U.K. only email addresses $69

SHIPPING & HANDLING OPTIONS (YOU MUST SELECT ONE): 

[] $7 Regular Mail (2 - 4 weeks)
[] $15 Priority Mail (1 - 2 weeks) 
[] $30 Fedex (overnight) For US & Canada Only - Other countries extra, please enquire 
by phone or email


TOTAL:_ US$

/

SECTION B - Personal Information

Full Name:

Company Name:

Tel: ( __) ___-__

Email Address:__  


Shipping Addresss:___Zip/Postal:___

City:___ State/Province:

Country:

\

SECTION C - Credit Card Information

Card Number:

Expiration Date:/CVV2 code (last 3 digits on reverse):__

Type of card :   [] Visa   [] Mastercard[] American Express

Exact name on card:___

Billing Address:Zip/Postal___

City:State/Province:___

Country:


Cardholder Signature:__

I hereby authorize F.T. Internat ion al to bill my credit card for the items ordered 
on this form. I understand that all sales are final and further agree not to dispute 
this charge.

\

SECTION D - Paypal Information

Email Address associated with Paypal:

Note: After receiving this order form, we will send a payment request to the address 
above.

/

if_alc trouble

[Sergey V. Dyatko]

Hi all,
I have strange problem:

NIC:
a...@pci0:2:0:0:class=0x02 card=0x38a317aa chip=0x10621969
rev=0xc0 hdr=0x00 vendor = 'Attansic (Now owned by Atheros)'
device = 'Atheros AR8132 PCI-E Fast Ethernet Controller
(AR8132)' class  = network
subclass   = ethernet

% uname -a
FreeBSD laptop.minsk.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #8 r209973:
Tue Jul 13 10:17:08 EEST 2010
r...@laptop.minsk.domain:/usr/obj/usr/src/sys/b450  i386

I'm using if_alc as a kernel module, when I boot with plugged in
cable all works fine, but when I booting with unplugged
cable - network doesn't work.

I'm trying kenv hw.alc.msi_disable=1 and kldload if_alc..
from messages: 

Aug 13 09:06:12 laptop kernel: alc0:  port 0x3000-0x307f mem 0x9610-0x9613 ir q 16 at
Ethernet> device 0.0 on pci2
Aug 13 09:06:12 laptop kernel: alc0: 15872 Tx FIFO, 15360 Rx FIFO
Aug 13 09:06:12 laptop kernel: miibus0:  on alc0
Aug 13 09:06:12 laptop kernel: atphy0:  PHY
0 on miibus0 Aug 13 09:06:12 laptop kernel: atphy0:  10baseT,
10baseT-FDX, 100baseTX, 100baseTX-FDX, auto Aug 13 09:06:12 laptop
kernel: alc0: Ethernet address: 00:1f:16:2e:fa:49 Aug 13 09:06:12
laptop kernel: alc0: [FILTER] Aug 13 09:06:12 laptop kernel: alc0: link
state changed to DOWN Aug 13 09:06:15 laptop kernel: alc0: link state
changed to UP Aug 13 09:06:15 laptop kernel: alc0: DMA write error! --
resetting Aug 13 09:06:15 laptop kernel: alc0: link state changed to
DOWN Aug 13 09:06:16 laptop kernel: alc0: promiscuous mode enabled
Aug 13 09:06:17 laptop kernel: alc0: link state changed to UP
Aug 13 09:06:18 laptop kernel: alc0: DMA write error! -- resetting
Aug 13 09:06:18 laptop kernel: alc0: link state changed to DOWN
Aug 13 09:06:20 laptop kernel: alc0: link state changed to UP
Aug 13 09:06:21 laptop kernel: alc0: DMA write error! -- resetting


how to repeat: 
1) boot with unplugged cable (if_alc_load="YES" on loader.conf)
2) plug-in cable
3) dhclient alc0
4) tcpdump -ni alc0 -vvv -> http://tiger.ipfw.ru/files/tcpdump.txt
5) reboot with plugged cable..
6) dhclient alc0

[ti...@laptop]~%ifconfig alc0 
alc0: flags=8843 metric 0 mtu
1500
options=c3198
ether 00:1f:16:2e:fa:49 inet 192.168.9.150 netmask 0xff00 broadcast
192.168.9.255 media: Ethernet autoselect (100baseTX )
status: active

now I can unplug cable, unload if_alc, load it again, plug cable -- all
works fine..

Thanks in advance

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

Performance AMD Phenom II X6 1090T

[Vladislav V. Prodan]

Is there anyone using AMD Phenom II X6 1090T?
What can you say about it's performance?
Have you any tasks that use all 6-cores?
Does it balance workload between all 6 cores properly?
I am interested how it will work specifically under 8.1-RELEASE and
9.0-CURRENT.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ndisgen is broken (bsdgrep)

[Sergey V. Dyatko]

Hi, 

[ti...@laptop]~%which egrep
/usr/bin/egrep
[ti...@laptop]~%egrep --version
egrep (BSD grep) 2.5.1-FreeBSD

[ti...@laptop]~% fetch
http://tiger.ipfw.ru/files/rt3090_ndiswrapper.tar.gz
[ti...@laptop]~% tar xf rt3090_ndiswrapper.tar.gz
[ti...@laptop]~%cd rt3090_ndiswrapper/
[ti...@laptop]~/temp/rt3090_ndiswrapper%ndisgen rt2860.inf rt2860.sys

==
-- Windows(r) driver converter
---
==

INF file validation

I don't recognize this file format. It may not be a valid .INF
file.

Press enter to try again, or ^C to quit. 

with gnugrep all works fine...

[ti...@laptop]~%uname -a
FreeBSD laptop.minsk.domain 9.0-CURRENT FreeBSD 9.0-CURRENT #9
r211484M: Thu Aug 19 12:31:20 EEST 2010
r...@laptop.minsk.domain:/usr/obj/usr/src/sys/b450  i386

on another box (HEAD, amd64 r210780) same error

Thanks in advance

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

Re: 3 different ral(4) pcmcia card (same chip) give the same error

[Sergey V. Dyatko]

On Wed, 13 Oct 2010 14:46:17 +0100
Anton Shterenlikht  wrote:

> Is damien@ still active in ral(4) development?
> I'm posting here in case he's not.
> 
> many thanks
> anton
> 

As far I know damien@ leave Project long time ago, not so far I ask
him for RT3090 support. Hi didn't reply, even on !...@freebsd.org email,
but according to obsd commit logs hi still working on wifi

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

Re: [zfs] Mounting from (...) failed with error 19

[Andrey V. Elsukov]

On 19.10.2010 3:50, Xin LI wrote:
> With latest kernel I got:
> 
>   Mounting from (...) failed with error 19
> 
> On boot.  The system is using pure ZFS setup.  It seems that 19 means
> ENODEV but according to the dmesg the device do exist.

Yes, i have the same problem.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: [zfs] Mounting from (...) failed with error 19

[Andrey V. Elsukov]

On 19.10.2010 09:03, Andrey V. Elsukov wrote:
>>  Mounting from (...) failed with error 19
>>
>> On boot.  The system is using pure ZFS setup.  It seems that 19 means
>> ENODEV but according to the dmesg the device do exist.
> 
> Yes, i have the same problem.

I fixed it with attached patch.

-- 
WBR, Andrey V. Elsukov
Index: vfs_mountroot.c
===
--- vfs_mountroot.c (revision 214058)
+++ vfs_mountroot.c (working copy)
@@ -713,7 +713,8 @@
goto out;
}
 
-   if (dev[0] != '\0' && !parse_mount_dev_present(dev)) {
+   if (strcmp(fs, "zfs") && dev[0] != '\0' &&
+   !parse_mount_dev_present(dev)) {
printf("mountroot: waiting for device %s ...\n", dev);
delay = hz / 10;
timeout = root_mount_timeout * hz;


signature.asc
Description: OpenPGP digital signature

Re: [zfs] Mounting from (...) failed with error 19

[Andrey V. Elsukov]

On 19.10.2010 19:43, Marcel Moolenaar wrote:
>> Yes, i have the same problem.
> 
> Can you both boot verbose and send me the output.
> Also, please boot with -a and show me the console
> output, as well as the output of the '?' command.

It is ZFS-only system and I have this line in /boot/loader.conf:
vfs.root.mountfrom="zfs:zroot"

With "boot -a -v -s" I got the same result that with "boot -s -v"
but when I enter zfs:zroot in mountroot prompt it printed:

Trying to mount root from zfs:zroot []...
mountroot: waiting for device zroot ...
Mounting from zfs:zroot failed with error 19.
Trying to mount root from zfs:zroot []...
mountroot: waiting for device zroot ...
Mounting from zfs:zroot failed with error 19.
panic: mountroot: unable to (re-)mount root.

So, it seems that waiting for device when we are booting from zfs
is not necessary..

-- 
WBR, Andrey V. Elsukov
Copyright (c) 1992-2010 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #8 r214013: Wed Oct 20 00:06:20 MSD 2010
root@:/usr/obj/usr/src/sys/BTR i386
Table 'FACP' at 0x7f7a0200
Table 'APIC' at 0x7f7a0390
Table 'MCFG' at 0x7f7a03f0
Table 'OEMB' at 0x7f7ae040
Table 'HPET' at 0x7f7a5900
Table 'SSDT' at 0x7f7aeb80
ACPI: No SRAT table found
Preloaded elf kernel "/boot/kernel/kernel" at 0x83d7c000.
Preloaded elf module "/boot/kernel/zfs.ko" at 0x83d7c198.
Preloaded elf module "/boot/kernel/opensolaris.ko" at 0x83d7c240.
Preloaded elf module "/boot/kernel/linux.ko" at 0x83d7c2f0.
Preloaded elf module "/boot/kernel/snd_hda.ko" at 0x83d7c39c.
Preloaded elf module "/boot/kernel/sound.ko" at 0x83d7c448.
Preloaded elf module "/boot/kernel/coretemp.ko" at 0x83d7c4f4.
Preloaded elf module "/boot/kernel/acpi_video.ko" at 0x83d7c5a4.
Preloaded /boot/zfs/zpool.cache "/boot/zfs/zpool.cache" at 0x83d7c654.
Preloaded elf module "/boot/kernel/drm.ko" at 0x83d7c6ac.
Preloaded elf module "/boot/kernel/i915.ko" at 0x83d7c754.
Preloaded elf module "/boot/kernel/acpi_asus.ko" at 0x83d7c800.
Preloaded elf module "/boot/modules/video4bsd.ko" at 0x83d7c8b0.
Preloaded elf module "/boot/kernel/usb.ko" at 0x83d7c960.
Preloaded elf module "/boot/kernel/usb_quirk.ko" at 0x83d7ca08.
Preloaded elf module "/boot/kernel/ehci.ko" at 0x83d7cab8.
Preloaded elf module "/boot/kernel/umass.ko" at 0x83d7cb64.
Calibrating TSC clock ... TSC clock: 1596041208 Hz
CPU: Intel(R) Atom(TM) CPU N270   @ 1.60GHz (1596.04-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x106c2  Family = 6  Model = 1c  Stepping = 2
  
Features=0xbfe9fbff
  Features2=0x40c39d
  AMD Features=0x10
  AMD Features2=0x1
  TSC: P-state invariant

1st-level instruction cache: 32 KB, 8-way set associative, 64 byte line size
L2 cache: 512 kbytes, 16-way associative, 64 bytes/line
real memory  = 2147483648 (2048 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x0010 - 0x003f, 3145728 bytes (768 pages)
0x01026000 - 0x7d36, 2083823616 bytes (508746 pages)
avail memory = 2079625216 (1983 MB)
Table 'FACP' at 0x7f7a0200
Table 'APIC' at 0x7f7a0390
APIC: Found table at 0x7f7a0390
MP Configuration Table version 1.4 found at 0x830f1160
APIC: Using the MADT enumerator.
MADT: Found CPU APIC ID 0 ACPI ID 1: enabled
SMP: Added CPU 0 (AP)
MADT: Found CPU APIC ID 1 ACPI ID 2: enabled
SMP: Added CPU 1 (AP)
Event timer "LAPIC" quality 400
ACPI APIC Table: 
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads
 cpu0 (BSP): APIC ID:  0
 cpu1 (AP/HT): APIC ID:  1
APIC: CPU 0 has ACPI ID 1
APIC: CPU 1 has ACPI ID 2
bios32: Found BIOS32 Service Directory header at 0x830f
bios32: Entry = 0xf0010 (830f0010)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0x31
pnpbios: Found PnP BIOS data at 0x830f88b0
pnpbios: Entry = f:996a  Rev = 1.0
Other BIOS signatures found:
ULE: setup cpu 0
ULE: setup cpu 1
ACPI: RSDP 0xfb9e0 00014 (v00 ACPIAM)
ACPI: RSDT 0x7f7a 0003C (v01 A_M_I_ OEMRSDT  03000903 MSFT 0097)
ACPI: FACP 0x7f7a0200 00084 (v02 A_M_I_ OEMFACP  03000903 MSFT 0097)
ACPI: DSDT 0x7f7a05b0 05342 (v01  A1028 A1028000  INTL 20051117)
ACPI: FACS 0x7f7ae000 00040
ACPI: APIC 0x7f7a0390 0005C (v01 A_M_I_ OEMAPIC  03000903 MSFT 0097)
ACPI: MCFG 0x7f7a03f0 0003C (v01 A_M_I_ OEMMCFG  03000903 MSFT 0097)
ACPI: OEMB 0x7f7ae040 00061 (v01 A_M_I_ AMI_OEM  03000903 MSFT 0097)
ACPI: HPET 0x7f7a5900 00038 (v01 A_M_I_ OEMHPET  03000903 MSFT 0097)

Re: [zfs] Mounting from (...) failed with error 19

[Andrey V. Elsukov]

On 20.10.2010 2:33, Marcel Moolenaar wrote:
>> What about the attached patch?  I'm going to give it a swirl soon.  The
>> difference is that it tests whether dev begins with /dev/.
> 
> Interesting. I've been thinking about this too, but isn't
> exactly fool-proof. When devfs is the root file system,
> you can use "ufs:da0s1a" to refer to the device special
> file. It seems inconsistent to have "ufs:da0s1" fail when
> ufs:/dev/da0s1" works (a real scenario with USB based mass
> storage devices -- root mount is unheld as soon as umass
> is created, but before daX exists for it).
> 
> This patch at least covers the problem cases with a single
> strstr(), and we may get away with the inconsistency given
> above by documenting it properly.
> 
> Andrey: any thoughts?

Currently usage information in parse_dir_ask() says that device should
be specified with "/dev/". But conf0 does not use "/dev/". Also,  Marcel,
do you have any plans write some documentation with examples about using
of new features?

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: [zfs] Mounting from (...) failed with error 19

[Andrey V. Elsukov]

On 20.10.2010 10:50, KOT MATPOCKuH wrote:
> Hello!
> 
>> I fixed it with attached patch.
> Omg... Why You are using strcmp, but not strncmp(fs, "zfs", strlen("zfs"))?

:)

Just because it is not first access to the fs variable in this function.
And it is already checked with strcmp.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: panic after entering blank line at mountroot prompt

[Andrey V. Elsukov]

On 30.10.2010 12:48, Bruce Cran wrote:
> mountroot code though because instead of another line, I got a panic: 
> "failed to (re-)mount root". Should the mountroot parser be failing if
> it doesn't find a valid root to mount on the first line?

Yes. This is default config for CURRENT.

-- 
WBR, Andrey V. Elsukov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Error 1: gpart create -s GPT ad0

[Andrey V. Elsukov]

On 12.11.2010 21:47, Ivan Klymenko wrote:
> http://img80.imageshack.us/i/qemu.png/
> Think all options for gpart are correct - what can there be a problem?

This was temporary regression and it is fixed now in r215118.
In any case it is harmless.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: Error 1: gpart create -s GPT ad0

[Andrey V. Elsukov]

On 12.11.2010 21:47, Ivan Klymenko wrote:
> I use the alternate installer pc-sysinstall based on FreeBSD
> 9.0-CURRENT r215176

Hmm, are you sure that your kernel is based on r215176?

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: Error 1: gpart create -s GPT ad0

[Andrey V. Elsukov]

On 13.11.2010 10:34, Ivan Klymenko wrote:
>> Hmm, are you sure that your kernel is based on r215176?
>>
> 
> no doubt! :)

Do you use custom ISO image? Can you mount it and show
output of command:
# ident /mnt/boot/kernel/kernel.symbols | grep g_part.c

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: Error 1: gpart create -s GPT ad0

[Andrey V. Elsukov]

On 13.11.2010 11:25, Ivan Klymenko wrote:
> Once mounted iso image of my drive to /mnt
> ident error: /mnt/boot/kernel/kernel.symbols: No such file or directory
> because this file (kernel.symbols) is really not in the iso image...

So, I can not reproduce this error. And I still think that you use older
revision and you should rebuild your ISO image with fresh sources.

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature

Re: Error 1: gpart create -s GPT ad0

[Andrey V. Elsukov]

On 13.11.2010 11:40, Ivan Klymenko wrote:
>> So, I can not reproduce this error. And I still think that you use
>> older revision and you should rebuild your ISO image with fresh
>> sources.
>>
> 
> well ...
> but it will take a little time ...

Just a note - as you may see from tinderbox's emails at the moment
building of fresh current is broken :)

-- 
WBR, Andrey V. Elsukov



signature.asc
Description: OpenPGP digital signature