Re: [head tinderbox] failure on amd64/amd64

[Doug Barton]

On 9/10/2010 12:54 AM, Mike Tancsa wrote:

At 06:57 PM 9/9/2010, Doug Barton wrote:


Normally they are pointed to a local mirror here at Sentex. However,
that server was having hardware problems which I think we have isolated
and resolved now. I will repoint this tinderbox to the local site again.


The best way to handle this would be to have messages about csup
failing to be directed only to those who are actually able to fix the
problem. Assuming that the cvsup server is always going to work is
contrary to both history and good system administration practices. :)


Perhaps as an interim measure a local procmail rule to filter out cvsup
failures from going to the list ?


That's a particularly unhelpful response. Not only is it borderline
rude to attempt to shift the responsibility for this to the users,
it's a violation of the robustness principle.


I meant "local procmail rule" as in local to the tinderboxes so that des
and myself and others who admin the boxes only get such messages. I
didnt want to make such changes without des' approval and was waiting
for his input...


In that case I apologize for the misunderstanding. I've used procmail 
for many years on the receiving end but was not aware of the ability to 
use it in the manner you suggested.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: [head tinderbox] failure on amd64/amd64

[Doug Barton]

On 9/10/2010 11:22 AM, Mike Tancsa wrote:

At 02:02 PM 9/10/2010, Doug Barton wrote:


In that case I apologize for the misunderstanding. I've used procmail
for many years on the receiving end but was not aware of the ability
to use it in the manner you suggested.


Have the tinderbox send just one email to a local account, then use
procmailrc to figure out where to send copies.


Ah, well, see? That's even more creative than I was giving you credit 
for. :)



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: DHCP server in base

[Doug Barton]

On 9/10/2010 9:54 AM, David DEMELIER wrote:

2010/9/10 Matthew Jacob:

  I think not. You are given the opportunity to install prebuilt packages at
install time, and with a modest amount of effort can install prebuilt
packages afterwards.

IMO, such as it is, there should be *less* in the base system than there
currently is and more in ports.


I agree with Matt on this one, although that shouldn't be a surprise 
since I'm on record saying it often. :)



In this case there are some parts in base/ that could live in ports/
instead of the base directory such as hostapd(8), maybe nobody want to
make a usable wireless access point?


Unfortunately arguing to include something new in the base because 
something else that you don't agree with is already there is not a valid 
method. The bar is a lot higher for adding things than keeping things 
(for better or worse).



And what about bind too?


As I've said many times, I'm ready to have it out when there is 
consensus to do so. The usual discussion goes like this:


1. Get BIND out of the base!
2. If we remove it, the command line tools (dig, host, nslookup) go with it.
3. Oh, well, we like those, so keep them, but get rid of the rest!
4. BIND is library based, so 90% of the work to make the command line 
tools is building the libs, after which building the server and its 
accessories is trivial work.

5. Oh, well, then make knobs to disable the server!
6. That's already done.
7. Oh, well, never mind then *mumble mumble*

However, all that is likely to change at some point in the future (as 
in, years from now) when BIND 10 becomes the only and/or most viable 
option since it requires a lot of stuff that we are unlikely to ever 
import into the base (like boost, python, etc.). So there is hope for 
you anti-BIND folks yet! :)



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: DHCP server in base

[Doug Barton]

On 9/10/2010 1:48 PM, Aleksandr Rybalko wrote:


Hi,

another argument about hostapd :) if have access point we must have
way to assign IP for AP clients.


To start with, your assumption is wrong. DHCPd is not *actually* a 
requirement, although I admit that practically it is.



Last spring I made firmware based on FreeBSD for router with only 4MB
NOR flash (D-Link DIR-320).


In this category (micro-miniaturization) you're already in the 
"significant customization needed" area, which means that general 
arguments about "the base" don't apply.



Since this device is router I must be
able to serve DHCP. And current implementation of dhcpclient, that we
have, is same isc-dhcp, and I replace system dhcpclient with ports
one+dhcpd but with small patch that put basic dhcp utils onto
libdhcp.so.


Your argument is creative and well thought out, but I personally don't 
find it persuasive. Counter arguments that come immediately to mind are:
1. The DHCP server is not going to benefit any but a small minority of 
FreeBSD users.
2. The software is already available in the ports tree, and adding a 
port/package of it really is not an overwhelming burden.


More generally, the main reason I want to keep more stuff out of the 
base, and remove some of the stuff that's in there now, is that it makes 
maintenance difficult across FreeBSD branches. We have a general policy 
that if we have a major version N of something in a release branch that 
we don't upgrade that major version without a really good reason to 
avoid POLA surprises for our users. Once again using BIND as an example, 
this has led to a really old and past-EOL version of BIND in FreeBSD 6 
which I've only gotten away with because anyone doing serious DNS work 
nowadays has to upgrade to at least 9.6 anyway. But it's an ugly 
situation, and I don't want to repeat it.


The problems get worse and/or more complex with the more 3rd party stuff 
you start including in the base. In part because of the product 
lifecycle issues that are similar to BIND's, but also due to the 
possibility of licensing issues (such as with gcc and/or other GPL 
software) and other more esoteric factors.


Even with home-grown stuff like our pkg_* tools we have problems because 
when we want to introduce new features (or deprecate old ones) there is 
currently a _minimum_ 3-year cycle we have to follow in order to make 
sure that the new feature is/is not available on all supported versions 
of FreeBSD. That's the main motivation behind my continuing to repeat 
the suggestion to move those tools specifically into the ports tree so 
that we can better support innovation in our ports/packages system.


In my view what we've needed to do for a long time now is to seriously 
strip down the notion of what "the base" should be to those items that 
are needed to work together for a specific API/ABI/AKI release, and move 
everything else into the ports tree. (Obviously there would be some 
exemptions made for really basic/vital stuff like ls, etc.) We can do 
this in a way that finds a middle ground between the linux model where 
literally everything is a package and the traditional BSD model of 
providing a "complete system," which is hardly ever true since I've 
never been involved with any FreeBSD system administration where there 
were absolutely no ports/packages installed at all.


Such a system could also be streamlined by creating a ports virtual 
category (something like "system") the packages for which could be 
included in the install media as long as we are judicious about what 
goes in there. Things like wpa_supplicant, dhclient, DNS tools, etc. 
could all be in that category, and all we'd have to do to make that work 
is to very slightly expand the list of questions that sysinstall already 
asks.


So this is a much longer version of my previous response which hopefully 
gives you more background about why it's a bad idea to add *any* more 
3rd party stuff to the base.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: DHCP server in base

[Doug Barton]

On 9/15/2010 7:25 AM, M. Warner Losh wrote:


Yea.  I agree too.  Just because BIND was EOLd in 6 isn't a great
argument against dhcp server.


That rather clearly was not the only element of my argument, and not 
only is it disingenuous for you to indicate that it was, I don't 
appreciate you doing so.



Most of the code is there anyway, and it isn't evolving as fast as BIND.


That is actually a more rational argument, even if I don't agree with 
it. FWIW, part of the reason that I don't agree with it is that at some 
point, hopefully in the near future, we will want to include the DHCPv6 
client in the mix somewhere; and when we do the code base is not going 
to be as stable as we have enjoyed so far with the v4 dhclient.



It would be very convenient to have this particular thing in the base,
and we shouldn't be too dogmatic about never having any new 3rd party
things in the base.  After all, we just added more compression
utilities to the base, and nobody said a peep.


I actually thought that change was rather silly, but it was clear that 
there was so much critical mass in favor of it that there was no point 
in stating a dissenting opinion. As part of the project's leadership you 
should be careful not to mistake silence for agreement, or worse, support.



This is analogous: we
have good opportunity to integrate into the system, and users benefit
from that integration.


Given your perspective of wanting more of a complete system in the base 
I can certainly see how you would be supportive of this change. My 
intent was to make the argument in a general way that this is the wrong 
direction to go, and that users would benefit *more* from a robust 
modularized system. The fact that the v4 DHCPd might accidentally be a 
good candidate for including in the base today doesn't mean that doing 
so is the right strategy for the long term.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: Multiple hpet messages during boot

[Doug Barton]

On 9/16/2010 5:28 AM, John Baldwin wrote:

On Wednesday, September 15, 2010 2:32:33 am Joel Dahl wrote:

I noticed this during boot (HEAD from yesterday):

hpet0: [FILTER]
hpet0: [FILTER]
hpet0: [FILTER]
hpet0: [FILTER]
hpet0: [FILTER]
hpet0: [FILTER]
hpet0: [FILTER]
hpet0: [FILTER]

Is it really necessary to print this 8 times?


I'd actually like to remove the interrupt messages that say '[FILTER]' or
'[GIANT]', etc.  I think in general they only add clutter.


+1

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: letting glabel recognise a media change

[Doug Barton]

On 9/29/2010 3:28 PM, Matthew Jacob wrote:

On 9/29/2010 2:45 PM, Andriy Gapon wrote:

on 30/09/2010 00:12 Alexander Best said the following:

hi there,

i wanted to ask if it would be possible to asjust glabel so that e.g.
inserting
a new media into a dvd-drive gets recognised and glabel displays the
lablel
right away.

Yes, of course, as soon as we have in kernel a programmatic way to
know that
media as changed.
We don't have one right now...



What announcement API would you like to add?

If something like that was in place, I assure you that things would
start to use it very quickly.


To what extent is HAL relevant here? I was sort of ambivalent about 
using it in FreeBSD, but my recent experimentation with ubuntu is 
starting to change my mind.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: letting glabel recognise a media change

[Doug Barton]

On 9/30/2010 2:29 PM, Dimitry Andric wrote:

On 2010-09-30 23:07, Doug Barton wrote:

To what extent is HAL relevant here? I was sort of ambivalent about
using it in FreeBSD, but my recent experimentation with ubuntu is
starting to change my mind.


Please read this first: https://wiki.ubuntu.com/Halsectomy :)


Right, especially the bits about moving the functionality into the kernel.


Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: letting glabel recognise a media change

[Doug Barton]

On 9/30/2010 2:34 PM, Doug Barton wrote:

On 9/30/2010 2:29 PM, Dimitry Andric wrote:

On 2010-09-30 23:07, Doug Barton wrote:

To what extent is HAL relevant here? I was sort of ambivalent about
using it in FreeBSD, but my recent experimentation with ubuntu is
starting to change my mind.


Please read this first: https://wiki.ubuntu.com/Halsectomy :)


Right, especially the bits about moving the functionality into the kernel.


Sorry, I'm being too terse. What I'm saying is that we have an existing 
"notifications" model that third party apps already know how to deal 
with. If we're considering developing a notifications model of our own 
then we are well served by looking at the work that has gone before 
(without violating copyright issues, yadda yadda).



hth,

Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: letting glabel recognise a media change

[Doug Barton]

On 9/30/2010 3:20 PM, Garrett Cooper wrote:

 The problem is that the current system proposed for Device Kit is
based on file system notification. I know we can do this with kqueues
to some degree, but we do some of our best work via sysctls, and using
other methods of attack, so it would be nice if these were
`abstracted' out into generic events with OS specific callback
handlers.


I'm not a kernel developer so I'm not going to tell anyone _how_ to 
implement the internals of this idea. My point is that if we're going to 
implement something that the API should be compatible so that all of the 
client software that already works with HAL doesn't have to be 
rewritten, patched, or abandoned.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: Setting up IPv6 in /etc/rc.conf

[Doug Barton]

On 10/15/2010 11:04 AM, Mark Murray wrote:

Hi

IPv6 gurus: what are the CURRENT /etc/rc.conf incantations to do the
following (which works):

$ ifconfig gif0 create
$ ifconfig gif0 tunnel 192.168.0.2 11.22.33.44
$ ifconfig gif0 inet6 2001:::::2 2001:::::1 prefixlen 
128
$ route -n add -inet6 default 2001:::::1
$ ifconfig gif0 up

... when my non-working setup in /etc/rc.conf contains

gif_interfaces="gif0"
gifconfig_gif0="192.168.0.2 11.22.33.44"
gifconfig_gif0_ipv6="2001:::::2 2001:::::1 prefixlen 
128"
ipv6_defaultrouter="-inet6 default 2001:::::1"

... which used to work. The bit that fails is the bit where gif0 gets
its tunnel IPv6 addresses.  I've tried both gifconfig_gif0_ipv6="..."
and ifconfig_gif0_ipv6="...". The IPv6 endmpoints never make it onto
gif0.

This used to work, but setting up IPv6 in CURRENT is a moving
target, and I can't find a working example any more. I've looked in
/etc/defaults/rc.conf, but the gifN examples there are all devoid of any
IPv6 examples.


Sorry for your frustration. Hiroki has taken over the IPv6 configuration 
responsibility, so hopefully he can help get you on the right path.



Doug

--

Breadth of IT experience, and|   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |  -- OK Go
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"

Is nvidia-driver 256.53 expected to work on -current?

[Doug Barton]

Y'all will probably recall that I had a lot of problems with the 
nvidia-driver, and video generally (esp. flash) on i386 -current. Well I 
haven't had any problems recently because I haven't been using FreeBSD. 
:)  But I have things I need to catch up on, so here's what I did:


1. Bought a new hard drive, and installed a snapshot of amd64 -current 
(this was actually done a while ago).
2. Yesterday I started configuring stuff, updated my source and ports 
trees, rebuilt the world, customized the kernel, etc.
3. With a newly up to date system I built the latest version of the 
nvidia-driver port, and started using it.


My experience with it has been exactly the same as older versions of the 
port on previous versions of i386 -current. Sometimes it runs fine for a 
while, but when I exit the window manager (openbox) the system hangs and 
I never get back to the command prompt. (I'm using startx to try and 
minimize the number of variables.) Sometimes it will work fine for an 
hour, maybe two, then the whole thing just hangs. All the stuff is 
displayed on the screen, but the mouse won't move, I can't zap X, or 
even switch to the console. I have to power off. This is particularly 
frustrating because I haven't even loaded flash (or for that matter 
firefox) yet.


Windows and linux (ubuntu, with the nvidia driver) work great on this 
same hardware, so I'm pretty thoroughly convinced that the problem is 
with freebsd/current somewhere. In addition to the -current partition I 
also installed amd64 8.1-RELEASE so I'll give that a go next, but I 
wanted to ask here first if anyone else was having problems on -current.



Doug

--

Breadth of IT experience, and|   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |  -- OK Go
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"

Re: Is nvidia-driver 256.53 expected to work on -current?

[Doug Barton]

On 10/17/2010 4:49 PM, Rob Farmer wrote:

I am running 256.53 on amd64 current (r213747). I don't use anything
linux (the module isn't loaded) and built the driver with all options
off except ACPI_PM. My custom kernel does not have "device agp".


Hmm. I had all the options off except linux. I'll try with your 
combination and see if that improves things.



Thanks,

Doug

--

Breadth of IT experience, and|   Nothin' ever doesn't change,
depth of knowledge in the DNS.   |   but nothin' changes much.
Yours for the right price.  :)   |  -- OK Go
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"

Re: Is nvidia-driver 256.53 expected to work on -current?

[Doug Barton]

On Sun, 17 Oct 2010, Garrett Cooper wrote:


On Sun, Oct 17, 2010 at 6:16 PM, Doug Barton  wrote:

On 10/17/2010 4:49 PM, Rob Farmer wrote:


I am running 256.53 on amd64 current (r213747). I don't use anything
linux (the module isn't loaded) and built the driver with all options
off except ACPI_PM. My custom kernel does not have "device agp".


Hmm. I had all the options off except linux. I'll try with your combination
and see if that improves things.


   I've given up on linux emulation support since 256.3x as it was
the factor that was causing lockups on my two machines.


Thanks. I tried again without linux support, no change, it still froze 
up. I suppose I can try again tomorrow without any of the options 
selected.



Doug

--

Improve the effectiveness of your Internet presence with
a domain name makeover!http://SupersetSolutions.com/

Computers are useless. They can only give you answers.
-- Pablo Picasso

___
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] More meaningful information about ENOEXEC for kldload(8)

[Doug Barton]

On 10/25/2010 12:19, Xin LI wrote:

Here is a simple patch that adds more meaning messages when kldload hits
ENOEXEC.


+1 on anything that makes this (and related) error more clear. I know 
I've stumbled over it numerous times.



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"

Re: [RFC] More meaningful information about ENOEXEC for kldload(8)

[Doug Barton]

On 10/25/2010 13:33, Ivan Voras wrote:

(except if the message is changed to say "please look at the kernel
syslog messages to find out the real reason for this failure")


Thinking about Garrett's response as well, this may be the best way to 
go. At this point I'm also not concerned about waiting for an ideal 
solution. IMO an incremental change here would be most welcome.



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"

Re: [RFC] More meaningful information about ENOEXEC for kldload(8)

[Doug Barton]

On 10/25/2010 5:53 PM, Garrett Cooper wrote:

On Mon, Oct 25, 2010 at 2:15 PM, Doug Barton  wrote:

On 10/25/2010 13:33, Ivan Voras wrote:


(except if the message is changed to say "please look at the kernel
syslog messages to find out the real reason for this failure")


Thinking about Garrett's response as well, this may be the best way to go.


 Well.. I'm not saying the current output is the best, but I just
don't want to dig a deeper hole that will further confuse people, as
some users may get even more confused with additional details.


I don't think "You'll find more information in the logs" to be confusing.


At this point I'm also not concerned about waiting for an ideal solution.
IMO an incremental change here would be most welcome.


 Wouldn't noting this in the manpage be sufficient?


I think _also_ adding it to the man page would be appropriate. IMO this 
is an area where we have to try and think more like users, and less like 
developers.



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"

Problems with hda

[Doug Barton]

Howdy,

Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960, 
with the following device:


hdac0:  mem 
0xf7adc000-0xf7ad irq 16 at device 27.0 on pci0

hdac0: HDA Driver Revision: 20100226_0142
hdac0: HDA Codec #0: Analog Devices AD1984A
pcm0:  at cad 0 nid 1 on hdac0
pcm1:  at cad 0 nid 1 on hdac0

There's 2 problems. When I plug the headphones in there are sounds, 
sometimes a low-level sound like a tea kettle whistling, and sometimes a 
louder screeching sound. The other problem is that the front headphone 
jack doesn't work. The rear one works, but this is less than convenient. 
:)  Windows and ubuntu linux do not have either problem with the same 
hardware.



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"

Re: Problems with hda

[Doug Barton]

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"

Re: Problems with hda

[Doug Barton]

On 11/04/10 12:45, Alexander Motin wrote:

Doug Barton wrote:

Thanks to a generous FreeBSD user I have a shiny new Dell Optiplex 960,
with the following device:

hdac0:  mem
0xf7adc000-0xf7ad irq 16 at device 27.0 on pci0
hdac0: HDA Driver Revision: 20100226_0142
hdac0: HDA Codec #0: Analog Devices AD1984A
pcm0:  at cad 0 nid 1 on hdac0
pcm1:  at cad 0 nid 1 on hdac0

There's 2 problems. When I plug the headphones in there are sounds,
sometimes a low-level sound like a tea kettle whistling, and sometimes a
louder screeching sound.


Try to play with mixer. Especially with "speaker", if you have it. Some
unconnected CODEC inputs may receive random radio interference from
other system components.


Bang on! Setting speaker to 0:0 instantly removed the random sounds. I 
assumed it was RFI from something, but I was using the windowmaker mixer 
app previously and thought I had already adjusted everything to 0. Silly 
of me not to check the command line version, thanks for the reminder.



The other problem is that the front headphone
jack doesn't work. The rear one works, but this is less than convenient.
:)


Have you tried to playback via pcm1? It could go exactly there.


2 for 2! The magic is hw.snd.default_unit=1


Windows and ubuntu linux do not have either problem with the same
hardware.


Linux and Windows often have hardcoded drivers for specific hardware.
Our driver tries to be universal and honor standards, unluckily often
violated by BIOS makers.


So, same song, $N'th verse? :)


For more information about CODEC and it's configuration you need to get
verbose dmesg. Details are in snd_hda(4).


Thank you for your excellent help, I learned something today. :)


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"

Re: [head tinderbox] failure on i386/pc98

[Doug Barton]

As far as I can tell the current state of the code builds just fine, so 
I'm wondering what the current problem with the tinderbox is.


Doug


On 11/21/2010 15:51, FreeBSD Tinderbox wrote:

TB --- 2010-11-21 22:05:00 - tinderbox 2.6 running on freebsd-current.sentex.ca
TB --- 2010-11-21 22:05:00 - starting HEAD tinderbox run for i386/pc98
TB --- 2010-11-21 22:05:00 - cleaning the object tree
TB --- 2010-11-21 22:05:12 - cvsupping the source tree
TB --- 2010-11-21 22:05:12 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca 
/tinderbox/HEAD/i386/pc98/supfile
TB --- 2010-11-21 22:10:38 - building world
TB --- 2010-11-21 22:10:38 - MAKEOBJDIRPREFIX=/obj
TB --- 2010-11-21 22:10:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin
TB --- 2010-11-21 22:10:38 - TARGET=pc98
TB --- 2010-11-21 22:10:38 - TARGET_ARCH=i386
TB --- 2010-11-21 22:10:38 - TZ=UTC
TB --- 2010-11-21 22:10:38 - __MAKE_CONF=/dev/null
TB --- 2010-11-21 22:10:38 - cd /src
TB --- 2010-11-21 22:10:38 - /usr/bin/make -B buildworld

World build started on Sun Nov 21 22:10:40 UTC 2010
Rebuilding the temporary build tree
stage 1.1: legacy release compatibility shims
stage 1.2: bootstrap tools
stage 2.1: cleaning up the object tree
stage 2.2: rebuilding the object tree
stage 2.3: build tools
stage 3: cross tools
stage 4.1: building includes
stage 4.2: building libraries
stage 4.3: make dependencies
stage 4.4: building everything

[...]
/src/usr.bin/xargs/xargs.c: In function 'pids_init':
/src/usr.bin/xargs/xargs.c:629: warning: old-style function definition
/src/usr.bin/xargs/xargs.c: In function 'pids_empty':
/src/usr.bin/xargs/xargs.c:641: warning: old-style function definition
/src/usr.bin/xargs/xargs.c: In function 'pids_full':
/src/usr.bin/xargs/xargs.c:647: warning: old-style function definition
/src/usr.bin/xargs/xargs.c: In function 'findfreeslot':
/src/usr.bin/xargs/xargs.c:676: warning: old-style function definition
*** Error code 1

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

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

Stop in /src.
*** Error code 1

Stop in /src.
*** Error code 1

Stop in /src.
TB --- 2010-11-21 23:51:29 - WARNING: /usr/bin/make returned exit code  1
TB --- 2010-11-21 23:51:29 - ERROR: failed to build world
TB --- 2010-11-21 23:51:29 - 4782.57 user 846.90 system 6388.46 real


http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-pc98.full
___
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"





--

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"

Re: [head tinderbox] failure on i386/pc98

[Doug Barton]

On 11/22/2010 05:57, Dag-Erling Smørgrav wrote:

Doug Barton  writes:

As far as I can tell the current state of the code builds just fine,
so I'm wondering what the current problem with the tinderbox is.


No weasel words, please.


None intended. My post was sent what I felt was a sufficient time after 
the commit of the fix that I was genuinely curious, especially given the 
history of c[v]sup related problems on the tinderbox infrastructure.



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"

Should green_saver.ko shut off a laptop's backlight?

[Doug Barton]

My recollection is that green_saver should turn off an LCD backlight, 
but I just loaded it up on my laptop and it's not doing so. It does 
remove the text from the screen, but the backlight is still on (i.e., it 
is doing exactly what blank_saver does).


When running X DPMS works on that same laptop, so I know the hardware is 
capable. This is 9-current amd64 at r214025. Any suggestions are welcome.



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"

Re: Should green_saver.ko shut off a laptop's backlight?

[Doug Barton]

On 11/29/2010 07:09, John Baldwin wrote:

On Saturday, November 27, 2010 11:30:56 pm Adam Vande More wrote:

On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton  wrote:


My recollection is that green_saver should turn off an LCD backlight, but I
just loaded it up on my laptop and it's not doing so. It does remove the
text from the screen, but the backlight is still on (i.e., it is doing
exactly what blank_saver does).

When running X DPMS works on that same laptop, so I know the hardware is
capable. This is 9-current amd64 at r214025. Any suggestions are welcome.



It's never worked for me either and this has been around awhile.

http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat=


green_saver just ask's your video card's BIOS to shut the screen off.  If the
BIOS doesn't turn off the backlight, that is the BIOS's problem, not
something we can fix.


Ok, so does the attached seem reasonable?



--

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/

Index: splash.4
===
--- splash.4(revision 216062)
+++ splash.4(working copy)
@@ -26,7 +26,7 @@
 .\"
 .\" $FreeBSD$
 .\"
-.Dd April 7, 2010
+.Dd November 29, 2010
 .Dt SPLASH 4
 .Os
 .Sh NAME
@@ -114,7 +114,12 @@
 .It Pa fire_saver.ko
 A fire which becomes higher as load increases.
 .It Pa green_saver.ko
-If the monitor supports power saving mode, it will be turned off.
+The screen will be blanked, similar to
+.Pa blank_saver.ko .
+If the monitor and/or the video card's BIOS support it,
+the screen will also be powered off.
+The latter may not work with LCD monitors,
+or monitors connected to a Digital Visual Interface (DVI) port.
 .It Pa logo_saver.ko
 Animated graphical
 .Fx
___
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: Should green_saver.ko shut off a laptop's backlight?

[Doug Barton]

On 11/29/2010 13:14, John Baldwin wrote:

On Monday, November 29, 2010 4:10:02 pm Doug Barton wrote:

On 11/29/2010 07:09, John Baldwin wrote:

On Saturday, November 27, 2010 11:30:56 pm Adam Vande More wrote:

On Sat, Nov 27, 2010 at 6:39 PM, Doug Barton   wrote:


My recollection is that green_saver should turn off an LCD backlight, but I
just loaded it up on my laptop and it's not doing so. It does remove the
text from the screen, but the backlight is still on (i.e., it is doing
exactly what blank_saver does).

When running X DPMS works on that same laptop, so I know the hardware is
capable. This is 9-current amd64 at r214025. Any suggestions are welcome.



It's never worked for me either and this has been around awhile.

http://www.freebsd.org/cgi/query-pr.cgi?pr=114928&cat=


green_saver just ask's your video card's BIOS to shut the screen off.  If the
BIOS doesn't turn off the backlight, that is the BIOS's problem, not
something we can fix.


Ok, so does the attached seem reasonable?


I would say 'If the monitor and the video card's BIOS support it' because
both things have to be true for green_saver to work.  and/or implies that
only one has to be true.  I'm not sure the second paragraph is truly needed
since I've seen it work fine with LCD's on other laptops and other external
monitors as well.  I think simply adding the text about the video card's
BIOS is sufficient (and a definite improvement).


Ok, done in r216065, thanks. I will update the PR soon'ish.


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"

Re: Next ZFSv28 patchset ready for testing.

[Doug Barton]

On 12/15/2010 23:19, Pawel Jakub Dawidek wrote:

On Wed, Dec 15, 2010 at 10:15:00PM -0500, ben wilber wrote:

On Mon, Dec 13, 2010 at 10:45:56PM +0100, Pawel Jakub Dawidek wrote:

Hi.

The new patchset is ready for testing:


Running fine for 24 hours now under load with a ~50 disk v15 (not
upgraded) pool from -CURRENT.  Thanks!

Only strange thing is the rc script complains:

/etc/rc: DEBUG: run_rc_command: doit: zvol_start
unrecognized command 'volinit'
usage: zfs command args ...


Did you run mergemaster(8) after the upgrade? The patch includes change
to etc/rc.d/zvol to remove 'zfs volinit'/'zfs volfini' which are no
longer available.


By default mergemaster will only notice the change if the $FreeBSD id 
changes, which it generally would not for a patch. The -s option will 
deal with this, but it may be less work to just cp the file.



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"

Discussion about upgrading BIND in RELENG_7

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

For those interested in the topic I have opened a discussion about the
idea of upgrading BIND in RELENG_7 on freebsd-stable. You can find the
post here:
http://lists.freebsd.org/pipermail/freebsd-stable/2010-December/060640.html
If you have anything to contribute please follow up on that list.


Thanks,

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/

-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)

iQEcBAEBCAAGBQJNDEuMAAoJEFzGhvEaGryEJMgIAMDmYwcX9vLOd9nh+XnZk/7S
WJ2brZWl0BSG57J369rp3wQnQvFh9xMnUdUG2gnMnQOR/JwLKeBsQdcVfxhL6RgT
mzelwstEa+OzmS4+cj96jWZYwQN1jyT5jMJCrbdM7JKTTPZG5PhUJTYvy7w68qNm
lhzdBbyQnw5iVKv/tsCU7m1ioSa7Aq1fRgj7O5/GkBAfcXSrF31S66LxRPtcM5OP
Ebxk4ttmJxZx5HXbQkU8xMhluYGvUaVt2quUks7mqkJ83NR6wNyL5A7WiP5aRHoA
UWj5bfCiACnblRRL89d2jT858okQ/eeqUBMZ8DQLzlOSKB/FNJxj7iIL+6+evX0=
=22Q7
-END PGP SIGNATURE-
___
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"

boost libs error

[Doug Barton]

I'm getting the following with qbittorrent-23 which depends on 
libtorrent-rasterbar-15 after the latest boost lib update:


qbittorrent
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort trap: 6 (core dumped)

This is on amd64-current, r216834M

#0  0x000805a6c4ac in thr_kill () at thr_kill.S:3
3   RSYSCALL(thr_kill)
[New Thread 807807400 (LWP 101197/initial thread)]
(gdb) where
#0  0x000805a6c4ac in thr_kill () at thr_kill.S:3
#1  0x000805b04e8b in abort () at 
/home/svn/head/lib/libc/stdlib/abort.c:65

#2  0x00080552f0a4 in __gnu_cxx::__verbose_terminate_handler ()
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/vterminate.cc:98
#3  0x0008055335a3 in __cxxabiv1::__terminate (handler=Variable 
"handler" is not available.

)
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:43

#4  0x0008055335e3 in std::terminate ()
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_terminate.cc:53

#5  0x00080553354a in __cxa_throw (obj=Variable "obj" is not available.
)
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++/eh_throw.cc:76
#6  0x000805584a02 in std::__throw_runtime_error (__s=Variable "__s" 
is not available.

)
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexcept.cc:84
#7  0x000805583a8d in std::locale::facet::_S_create_c_locale 
(__cloc=Variable "__cloc" is not available.

)
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc:141

#8  0x00080550c24c in _Impl (this=0x80781a1c0,
__s=0x7fffec72 "en_US.UTF-8", __refs=Variable "__refs" is not 
available.

)
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/localename.cc:185
#9  0x00080550df59 in locale (this=0x800fefcd0, __s=Variable "__s" 
is not available.

)
at 
/home/svn/head/gnu/lib/libstdc++/../../../contrib/libstdc++/src/localename.cc:57
#10 0x000800ee3b86 in path_locale () at 
libs/filesystem/v3/src/path.cpp:763

#11 0x000800ee3d88 in boost::filesystem3::path::wchar_t_codecvt_facet ()
at libs/filesystem/v3/src/path.cpp:791
#12 0x000800ee47a6 in __static_initialization_and_destruction_0 (
__initialize_p=Variable "__initialize_p" is not available.
) at path.hpp:377
#13 0x000800ee9122 in __do_global_ctors_aux ()
   from /usr/local/lib/libboost_filesystem.so
#14 0x000800ed3fc6 in _init () from 
/usr/local/lib/libboost_filesystem.so

#15 0x000800b0c180 in list_fini () from /libexec/ld-elf.so.1
#16 0x0008009e2168 in objlist_call_init (list=Variable "list" is not 
available.

)
at /home/svn/head/libexec/rtld-elf/rtld.c:1801
#17 0x0008009e49b9 in _rtld (sp=0x7fffe8c8, 
exit_proc=0x7fffe8a0,

objp=0x7fffe8a8) at /home/svn/head/libexec/rtld-elf/rtld.c:523
#18 0x0008009de849 in .rtld_start ()
at /home/svn/head/libexec/rtld-elf/amd64/rtld_start.S:39
#19 0x in ?? ()

... and then similar for 766 frames.




--

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"

Re: boost libs error

[Doug Barton]

On 01/01/2011 13:40, Alexander Churanov wrote:

2011/1/1 Doug Barton:

I'm getting the following with qbittorrent-23 which depends on
libtorrent-rasterbar-15 after the latest boost lib update:

qbittorrent
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort trap: 6 (core dumped)


Doug, please, check whether you have are observing the issue ports/153561.


Yes, that's it precisely! I have my locale set to en_US.UTF-8, and 
adding the patch in that PR solved the problem for me. Let me know if 
you'd like me to commit it for you.



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"

Re: HEADS UP: Merge of binutils 2.17

[Doug Barton]

On 01/07/2011 12:57, Dimitry Andric wrote:


Please report any problems with either the base system, or ports that
come up as a result of this binutils update.


This is much appreciated work of course, but I'm wondering if you've 
requested an experimental ports run with the change? It would be good to 
know how much damage to expect before the change gets committed.



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"

Re: HEADS UP: Merge of binutils 2.17

[Doug Barton]

On 01/07/2011 13:29, Dimitry Andric wrote:

On 2011-01-07 22:22, Doug Barton wrote:

This is much appreciated work of course, but I'm wondering if you've
requested an experimental ports run with the change? It would be good to
know how much damage to expect before the change gets committed.


Yes, I submitted an exp-run request Nov 15, 2010:

http://www.freebsd.org/cgi/query-pr.cgi?pr=152268


Ah, well done then. :)


Unfortunately, there has been little or no interest.


Fair enough, that sounds to me like portmgr is volunteering to clean up 
the mess then.



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"

Re: HEADS UP: Merge of binutils 2.17

[Doug Barton]

On 01/07/2011 13:54, Ade Lovett wrote:


On Jan 07, 2011, at 15:41 , Doug Barton wrote:

On 01/07/2011 13:29, Dimitry Andric wrote:


Yes, I submitted an exp-run request Nov 15, 2010:
http://www.freebsd.org/cgi/query-pr.cgi?pr=152268 Unfortunately,
there has been little or no interest.


Fair enough, that sounds to me like portmgr is volunteering to
clean up the mess then.


Most likely it's low priority given all the other exp-runs that
affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a
bunch of other infrastructure stuff.  Not to mention the impending 7-
and 8- RELEASEs.


That may very well be the case, but if so then it's incumbent on portmgr 
to communicate that. If you check the audit trail you will find that 
they did not.



Then of course there's the issue (which is certainly getting better)
of finding a point in time along the -CURRENT path where the tree is
stable (sic) enough to get through a full ports run (which is one of
the bigger internal stress tests we have of the system).


IMO this is a total red herring, and has been for several years now. I 
run -current every day on my real-work system, and barring the 
occasional hiccup it's been buildable nearly every time I've tried.


The way I would approach the problem of building packages for -current 
is to pick a day to update the src tree, then do the following:


1. make buildworld && make kernel && reboot &&
2. make installworld && reboot &&
3. update ports tree &&
4. start building ports

That can all be automated, and at the point where any of it fails the 
system barks loudly and stops trying to proceed. This would of course 
require a human to be involved once a week or so with running 
mergemaster, and maybe the odd cleanup here or there, but most times 
that doesn't even have to happen in band. I suggest Wednesday as "the 
day" to update the source since there is usually a lot of activity on 
the weekend, and if something is broken on Wednesday it gives people a 
chance to respond during working hours.


The great thing about this is that if it fails, no harm no foul. Having 
some packages, even a week or so out of date is much better than what we 
have now.


Of course, there are other things that would go along with this ... 
finding and tagging the very few packages that actually deeply care 
about system internals being first on the "off the top of my head" list. 
But the current system of "don't do anything" just isn't cutting it.



IMO, the best approach would be to make sure it does the right thing
with 'make universe' (twice, naturally, the second time being when
all traces of the previous binutils has been purged from the building
system).  Once that's done, commit (please bump __FreeBSD_version as
part of this, in case ports OSVERSION hacks are eventually needed),
and then give the exp-run a whirl -- with all of the above, this
should be nicely after 7.4/8.2


If portmgr is unwilling/unable to do the exp-run before dim is ready to 
commit, then I'd say yes, that all sounds fine; especially bumping 
__FreeBSD_version.



hth,

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"

Package building for -current (Was: Re: HEADS UP: Merge of binutils 2.17)

[Doug Barton]

I'm happy to have a discussion about this topic either publicly, or 
privately, your choice. Since your message went to -current@, that's 
where my reply is headed. I've also cc'ed ports@ since the topic is 
relevant there too.


Meanwhile, I've snipped some of what you wrote to focus on the issues 
that I think are most relevant. I value and respect both your opinion 
and your experience in these issues, but I have some rather profound 
disagreements with your conclusions.



On 01/07/2011 21:48, Ade Lovett wrote:


On Jan 07, 2011, at 17:37 , Doug Barton wrote:

On 01/07/2011 13:54, Ade Lovett wrote:


Most likely it's low priority given all the other exp-runs that
affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and
a bunch of other infrastructure stuff.  Not to mention the
impending 7- and 8- RELEASEs.


Before I start on this, I would like a few things noted for the
record:

1.  I have set Reply-To to developers@ (this should be a major hint)
2.  I am not a current member of portmgr@ 3.  I requested, and
served, for a very short time, on the first portmgr



That may very well be the case, but if so then it's incumbent on
portmgr to communicate that. If you check the audit trail you will
find that they did not.


Horsecrap.  You are taking an individual PR history without reference
to the whole host of things that were also going on at the same time.
Like it or not, when it comes to ports, -STABLE wins over -CURRENT
every single time.


I disagree rather profoundly on this point. We have a 
tolerance/expectation of our leadership just plain not communicating 
with us that has gone way past unhealthy. It takes 30 seconds to respond 
to a PR and say "We can't get to this before the pending releases, here 
is a suggested course of action." That's a perfectly reasonable thing 
for a person to expect in response to a request. In addition to not 
responding just being plain rude, it fosters the attitude of "Why should 
I bother communicating with portmgr, they never respond anyway."


Not to mention the fact that occasionally the fact that portmgr doesn't 
like to communicate can sometimes create actual problems, such as when 
they removed the MD5 checksum stuff without warning, and therefore broke 
all the ports management and other tools that depended on them. I was 
glad of the action to finish the change, but the action came after 
months of no communication about it at all.



IMO this is a total red herring, and has been for several years
now. I run -current every day on my real-work system, and barring
the occasional hiccup it's been buildable nearly every time I've
tried.


Apologies for not being able to drive my email client appropriately.
The issue at hand is one of running -CURRENT.

There is a distinct, and fundamental difference between running
-CURRENT on a single system, as opposed to a cluster of systems that
are tightly interlinked.


Believe it or not, I understand that. I also get that sometimes running 
package building on -current stresses it in ways that cause it to break. 
That's a good thing. :)


My point is that YEARS of ignoring the problem is not acceptable, and 
needs to change. For a long time portmgr griped about not having enough 
systems for the build cluster. Now they have plenty of hardware 
available, but the problem is that the system is too pointy-hat centric. 
Apparently significant progress has been made in that area, but none of 
it seems to have trickled down to actually getting more packages built 
for more platforms better and faster.


I do, honestly, get that this is a hard problem. But if portmgr needs 
help, it needs to ask for it. It asked for and received more hardware, 
so clearly the foundation and the FreeBSD community at large is ready to 
step up to help. I think it's pretty obvious at this point that the 
gating factor is person-hours, so portmgr needs to be a lot more 
aggressive in developing new volunteers, asking for help with specific 
tasks, etc. etc. The fact that they are dealing with hard problems is no 
longer an acceptable excuse for years of failure to solve them.



Sadly, the only thing I can say to your 4-step procedure, and with
utmost politeness, is that your src-centric views are completely
missing the point.  "4. start building ports" is in fact a 20- or
30-step process to ensure no cross-contamination.


Once again, I get that bit too. Since we do, in fact, already have a 
package building cluster I was handwaving it because I was trying to 
address your red herring about "we can't find a version of -current we 
like so we can't even try." The essential points that I'm trying to 
communicate are:


1. Most of the time HEAD works pretty well nowadays
2. Very few ports care that deeply about the guts of the system they are 
running on



I look forward to your input and total solutions on how to ma

Re: boost libs error

[Doug Barton]

On 01/01/2011 13:40, Alexander Churanov wrote:

2011/1/1 Doug Barton:

I'm getting the following with qbittorrent-23 which depends on
libtorrent-rasterbar-15 after the latest boost lib update:

qbittorrent
terminate called after throwing an instance of 'std::runtime_error'
  what():  locale::facet::_S_create_c_locale name not valid
Abort trap: 6 (core dumped)


Doug, please, check whether you have are observing the issue ports/153561.

Alexander Churanov,
maintainer of devel/boost-*


I didn't see your reply to the PR, so I wasn't aware that you had 
approved the patches until I double-checked tonight. But the update is 
done now, thanks!



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"

Re: TCP resident expert?

[Doug Barton]

On 01/15/2011 07:31, William Allen Simpson wrote:

Who's the kernel expert on TCP around here?


freebsd-net@ is generally the relevant list. Good luck with your work.


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"

Re: BSDInstall: merging to HEAD

[Doug Barton]

On 01/20/2011 14:15, Chuck Swiger wrote:

On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
[ ... ]

Why does the installer use GPT partition by default? Do you know that GPT is 
not supported on every (even modern) computer ?


Sure.  Legacy PC/BIOS platforms can work with a hybrid GPT which includes the legacy or 
"protective" MBR used by pre-EFI systems; FreeBSD 7 and later, recent Linux, 
MacOS X 10.4 and later should be able to boot from disks with that hybrid format.

If you need to dual-boot into Windows, however, and your hardware doesn't 
provide EFI then you're likely stuck using MBR + PC/BIOS only.


We should not do anything by default that damages the ability to 
dual-boot windows (and by windows I really mean "xp or later" since 
we'll have xp around through 2014). If there are significant advantages 
to gpt as a default when possible then it will be necessary to ask the 
user some intelligent questions such as "Will this system be 
multi-booted?" and if yes, "Will ${lowest_common_denominator:-windows} 
be installed?"



hth,

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"

Re: BSDInstall: merging to HEAD

[Doug Barton]

On 01/20/2011 14:47, Nathan Whitehorn wrote:

On 01/20/11 16:44, Doug Barton wrote:

On 01/20/2011 14:15, Chuck Swiger wrote:

On Jan 20, 2011, at 1:37 PM, David Demelier wrote:
[ ... ]

Why does the installer use GPT partition by default? Do you know
that GPT is not supported on every (even modern) computer ?


Sure. Legacy PC/BIOS platforms can work with a hybrid GPT which
includes the legacy or "protective" MBR used by pre-EFI systems;
FreeBSD 7 and later, recent Linux, MacOS X 10.4 and later should be
able to boot from disks with that hybrid format.

If you need to dual-boot into Windows, however, and your hardware
doesn't provide EFI then you're likely stuck using MBR + PC/BIOS only.


We should not do anything by default that damages the ability to
dual-boot windows (and by windows I really mean "xp or later" since
we'll have xp around through 2014). If there are significant
advantages to gpt as a default when possible then it will be necessary
to ask the user some intelligent questions such as "Will this system
be multi-booted?" and if yes, "Will
${lowest_common_denominator:-windows} be installed?"


It does do exactly what you suggest. It only uses GPT by default if you
have a totally unformatted disk or indicate you intend to run only
FreeBSD on the machine. Otherwise, you get MBR+bsdlabel just like now.


That isn't exactly what I suggested. :)  Imagine the following scenario 
(which is what I used to do, until our fdisk started using wacky 
geometries):

1. Get new computer and/or new hard drive
2. Boot freebsd from installation/live media (aka, disc1)
3. Unceremoniously (and in some cases gleefully) delete all existing 
partition/slices

4. Slice the disk, and write out the changes with "regular" MBR
5. Boot windows, install into the first unused slice/partition

Now if by "indicate you intend to run only FreeBSD on the machine" above 
you mean that you already have questions built into the process that 
covers what I proposed above, then fine. My point is simply that running 
the installer on a blank (or newly blank'ed) disk is not by itself a 
sign that everything that will be installed understands gpt.



hth,

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"

Re: why panic(9) ?

[Doug Barton]

On 01/23/2011 15:00, David Demelier wrote:

In any case, when panic occurs, switching display to the tty can be
great. Why not a sysctl like kern.tty_on_panic? Because when you're
running X and a panic occurs not everybody understand what happens.


Putting the following in /etc/sysctl.conf can help:

debug.debugger_on_panic=0

The reason being that sometimes when you panic in X the system is 
attempting to drop to the debugger, but can't, which is why it hangs.



hth,

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"

Problem with a port after clang'ifying

[Doug Barton]

I followed the instructions at: 
http://wiki.freebsd.org/BuildingFreeBSDWithClang and everything went 
quite well. The system built fine, and runs fine for most of my ports. 
There is one minor one, misc/wmweather+ that crashes every time I start 
it. The trace looks like this:


#0  strcasecmp (s1=Variable "s1" is not available.
) at /home/svn/head/lib/libc/string/strcasecmp.c:48
48  while (tolower(*us1) == tolower(*us2++))
(gdb) bt
#0  strcasecmp (s1=Variable "s1" is not available.
) at /home/svn/head/lib/libc/string/strcasecmp.c:48
#1  0x000800988259 in CreateColors (display=0x802cf5000,
attributes=0x7fffd590, colors=0x802c4fd00, ncolors=5,
image_pixels=0x802cb75e0, mask_pixels=0x802cb7610,
mask_pixel_index=0x7fffcf4c, alloc_pixels=0x802cb7670,
nalloc_pixels=0x7fffcf48, used_pixels=0x802cb76a0,
nused_pixels=0x7fffcf44) at create.c:657
#2  0x000800989764 in xpmParseDataAndCreate (display=0x802cf5000,
data=0x7fffcfb0, image_return=0x7fffd498,
shapeimage_return=0x7fffd490, image=0x7fffd430,
info=0x7fffd3f0, attributes=0x7fffd590) at create.c:2127
#3  0x000800985403 in XpmCreateImageFromData (display=0x802cf5000,
data=0x61e4c0, image_return=0x7fffd498,
shapeimage_return=0x7fffd490, attributes=0x7fffd590)
at CrIFrDat.c:66
#4  0x000800985693 in XpmCreatePixmapFromData (display=0x802cf5000, 
d=169,

data=Variable "data" is not available.
) at CrPFrDat.c:60
#5  0x00412d66 in GetXPM (wmgen=0x7fffd580, 
pixmap_bytes=0x61e4c0)

at wmgeneral-x11.c:117
#6  0x00409e54 in init_font (i=0) at font.c:61
#7  0x00409f75 in DrawChar (x=32, y=29, c=Variable "c" is not 
available.

) at font.c:143
#8  0x0040a198 in DrawString (x=32, y=29, str=Variable "str" is 
not available.

) at font.c:72
#9  0x00406160 in DrawDisplay (force=Variable "force" is not 
available.

) at dock.c:457
#10 0x004077a0 in update_dock () at dock.c:229
#11 0x004124a7 in main (argc=1, argv=0x7fffd970)
at wmweather+.c:737

The ports were all compiled with gcc of course, recompiling (still with 
gcc) after clang'ifying didn't help.


Oddly enough, this is a very simple port, so far all my other complex 
ports (including things like firefox + flash, tbird, pidgin, etc.) are 
all working fine.



Suggestions welcome,

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"

Re: Problem with a port after clang'ifying

[Doug Barton]

A little more information. Using -O0 or -O1 in CFLAGS the resulting 
binary works. The default of -O2 crashes, with or without 
-fno-strict-aliasing.



hth,

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"

Re: Can't update CLang-based system

[Doug Barton]

On 02/27/2011 19:30, Tim Kientzle wrote:

I have a FreeBSD-CURRENT AMD64 system here that was last updated at r215029.

I'm trying to update it to r219079, but the build fails in lib/libz when it 
tries to compile gvmat64.S.  It looks like the Makefile here has a workaround 
for clang on AMD64, but it doesn't seem to actually be working in this case.


I have a different problem on r219092. Everything builds find, but 
"linking kernel.debug" hangs forever. It can't even be killed with ^C. 
My existing system is r218985M, which was built with clang. This is my 
first time trying to build a system with clang ON a system that was 
itself built with clang (if that makes sense).



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"

Re: mergemaster broken

[Doug Barton]

I'll take a look at this, thanks.

On Tue, 22 Jul 2003, Ruslan Ermilov wrote:

> On Sun, Jul 06, 2003 at 08:21:14PM -0700, Gregory Neil Shapiro wrote:
> > > > mergemaster -dv
> > >
> > > [snip]
> > >
> > > cd /usr/src/etc/sendmail; make distribution
> > > install -o root -g wheel -m 644  /usr/src/etc/sendmail/freebsd.mc freebsd.cf 
> > > /var/tmp/temproot.0707.11.55/etc/mail
> > > install: freebsd.cf: No such file or directory
> > > *** Error code 71
> >
> > Thanks, I just committed a fix for this.
> >
> Er,
>
> The correct fix would be to revert this change from sendmail/Makefile,
> and fix mergemaster(8) instead, as shown in the attached patch.  The
> "distribution" target of src/etc/Makefile is part of the standard
> "distribute" target, and as such it's just a specialized version of
> the "install" target that should not _build_ anything (and that was
> fixed in rev. 1.23).  To build things, one needs to call the "all"
> target, which the attached patch simply does.  It's just a pure
> coincidence that the "distribution" part of src/etc/Makefile does
> not need to build anything (in the object directory).
>
> Can you please test it and commit?
>
>
> Cheers,
>

-- 

This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

host/domain name verification, and valid top level domains (fwd)

[Doug Barton]

Folks,

One of the topics at the recent ICANN conference was the issue of
functionality for the new generic top level domains (gTLD's). Seven new
gTLD's were adopted by ICANN in November of 2000, but many users with
domains in those TLD's are still having problems using them.

One of the areas that is particularly relevant to us is the issue of web
forms, and other locations where user data like URL's or e-mail
addresses are verified and stored (especially C/C++ code that allocates
memory for names, etc.). In the past, all domain names ended in 2, 3, or
4 letter labels. However, now the list of valid gTLD's also contains one
with 6. The list of currently valid gTLD's is:

.aero, .biz, .com, .coop, .edu, .gov, .info, .int, .mil, .museum, .name,
.net, .org, and .pro

If you are responsible for code that deals with domain names in any way,
please run some tests to be sure that hostnames from all of these gTLD's
work with your code, and please fix anything that doesn't.

If you have any questions, please shoot them my way. If you are tempted
to reply to all, please trim your cc: list appropriately, and keep me in
there somewhere.

Hope this helps,

Doug


References:
http://www.iana.org/domain-names.htm
http://www.iana.org/cctld/cctld-whois.htm
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: atapicam panic at boot.

[Doug Barton]

On Tue, 26 Aug 2003, Kenneth Culver wrote:

> I think some people are already tracking this down related to the recent
> update of the ata drivers.

It would be nice if those people would post regarding their progress. A
lot of people depend on atapicam.

Doug

-- 

This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: buildworld failure

[Doug Barton]

On Fri, 29 Aug 2003, Sheldon Hearn wrote:

> Okay, you philosophize while the rest of us follow the advice of the
> folks who have a good understanding of gcc's optimizer. :-)

Not to be disagreeable, but the gcc developers seem to think that -O2
should "always" produce better code, and "never" produce errors. This is
straight from the mouth of the husband of one of my co-workers, who
works for redhat hacking gcc.

If you have a reproducable case where correct C code produces bad
objects, or fails to compile using -O2, the gcc folks want to hear about
it.

Doug

-- 

This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile

[Doug Barton]

Poul-Henning,

Please don't forget to update src/share/examples/etc/make.conf
accordingly.

All,

As a sometime-contributor to the "let's give people more options to
leave stuff out" cause, I fully support adding more knobs like this.
There is no harm to adding more knobs that work the same way as the
existing ones do, with or without a "grand plan." If we decide to embark
on something more complex, I'd like to see more discussion though.

Doug


On Fri, 29 Aug 2003, Poul-Henning Kamp wrote:

> phk 2003/08/29 03:35:01 PDT
>
>   FreeBSD src repository
>
>   Modified files:
> gnu/usr.bin  Makefile
> lib  Makefile
> sbin Makefile
> usr.bin  Makefile
> usr.sbin Makefile
>   Log:
>   Introduce more knobs to slim down FreeBSD userland
>
>   NO_TOOLCHAINskips Compilers and Binutils
>   NO_USB  skips USB stuff
>   NO_VINUMskips Vinum stuff
>   NO_ACPI skips ACPI stuff
>
>   Revision  ChangesPath
>   1.76  +6 -1  src/gnu/usr.bin/Makefile
>   1.171 +5 -1  src/lib/Makefile
>   1.127 +5 -2  src/sbin/Makefile
>   1.246 +17 -6 src/usr.bin/Makefile
>   1.270 +11 -4 src/usr.sbin/Makefile
>
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/gnu/usr.bin/Makefile.diff?&r1=1.75&r2=1.76&f=h
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/lib/Makefile.diff?&r1=1.170&r2=1.171&f=h
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/Makefile.diff?&r1=1.126&r2=1.127&f=h
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.bin/Makefile.diff?&r1=1.245&r2=1.246&f=h
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/usr.sbin/Makefile.diff?&r1=1.269&r2=1.270&f=h
>
>

-- 

This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: cvs commit: src/gnu/usr.bin Makefile src/lib Makefile src/sbinMakefile src/usr.bin Makefile src/usr.sbin Makefile

[Doug Barton]

On Sat, 30 Aug 2003, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Doug Barton writes:
> >Poul-Henning,
> >
> >Please don't forget to update src/share/examples/etc/make.conf
> >accordingly.
>
> Hmm, so this stuff is documented both in make.conf(5) and an examples
> file ?  Sounds like one place too many to me.

Well, there's "always" been an example make.conf file. In previous
incarnations it's lived in /etc, then /etc/defaults. I also agree with
the previous poster that it's useful to have such an example, and
mergemaster uses it for the -p option.

Doug

-- 

This .signature sanitized for your protection
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Build broken in sys/dev/pcic/i82365.c

[Doug Barton]

With latest sources:

cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/net/if.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/net/netisr.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/dev/fb/fb.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/dev/kbd/atkbd.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/dev/kbd/atkbdc.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/i386/i386/busdma_machdep.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/i386/i386/critical.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/i386/i386/identcpu.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -

pcic device causes kernel build failure

[Doug Barton]

I found my problem, when I got this new laptop two weeks ago I
UN-commented the pcic cardbus bridge "just in case." This worked fine up
till 8/27, my last build on that machine. Starting last night, with that
device in my kernel config, kernel build fails with the error below.
Commenting it again allows the kernel to build.

FYI,

Doug


cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/net/if.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/net/netisr.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/dev/fb/fb.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/dev/kbd/atkbd.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/dev/kbd/atkbdc.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/i386/i386/busdma_machdep.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing  
-mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror  
/usr/local/src/sys/i386/i386/critical.c
cc -c -O -fno-ident -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs 
-Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual  
-fformat-extensions -std=c99 -g -nostdinc -I-  -I. -I/usr/local/src/sys 
-I/usr/local/src/sys/contrib/dev/acpica -I/usr/local/src/sys/contrib/ipfilter 
-I/usr/local/src/sys/contrib/dev/ath -I/usr/local/src/sys/contrib/dev/ath/freebsd 
-D_KERNEL -include opt_global.h -fno-comm

Latest kernel requires CD in drive to boot

[Doug Barton]

I've cvsup'ed and built world/kernel from the latest sources to this
point, and on my desktop I have the problem that's been previously
discussed about not being able to boot without a disc in the CD-RW
that's on ata1-master. I've included an annotated verbose dmsesg below.

I have the following in loader.conf.local:
hw.ata.ata_dma="1"
hw.ata.wc="1"
hw.ata.tags="0"
hw.ata.atapi_dma="1"

This is with a fairly standard "GENERIC minus stuff I don't need" kernel
config, with atapicam still commented out. Let me know if there's
anything I can do to help.

Doug


 5.1-CURRENT-0830 #1: Sat Aug 30 16:01:06 PDT 2003
[EMAIL PROTECTED]:/usr/local/obj/current/usr/local/src/sys/MASTER-current
Preloaded elf kernel "/boot/kernel/kernel" at 0xc0643000.
Preloaded elf module "/boot/kernel/linux.ko" at 0xc06431d8.
Preloaded elf module "/boot/kernel/nvidia.ko" at 0xc0643284.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc0643330.
Calibrating clock(s) ... i8254 clock: 1193149 Hz
CLK_USE_I8254_CALIBRATION not specified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 601366074 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (601.37-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x673  Stepping = 3
  
Features=0x383f9ff
real memory  = 536858624 (511 MB)
Physical memory chunk(s):
0x1000 - 0x0009, 651264 bytes (159 pages)
0x0066a000 - 0x1f6d6fff, 520540160 bytes (127085 pages)
avail memory = 514650112 (490 MB)
bios32: Found BIOS32 Service Directory header at 0xc00f9d50
bios32: Entry = 0xf0520 (c00f0520)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0x720
pnpbios: Found PnP BIOS data at 0xc00fd1a0
pnpbios: Entry = f:d1d0  Rev = 1.0
pnpbios: OEM ID cd041
Other BIOS signatures found:
null: 
mem: 
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 03 00 01 00 01 01 00 00 00 22 00
00 01 00 04 17 04 07 01 00 01 1a 01 00 01 28 01
00 01 00 01 01 01 02 01 03 01 04 01 05 01 06 01
07 01 08 01 09 01 0a 01 0b 01 0c 01 0e 01 0f 01
VESA: 35 mode(s) found
VESA: v3.0, 65536k memory, flags:0x1, mode table:0xc03b9402 (122)
VESA: NVidia
VESA: NVidia Corporation NV17 () Board Chip Rev A2
random: 
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x80002358
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=71908086)
pcibios: BIOS version 2.10
Using $PIR table, 6 entries at 0xc00f0d10
PCI-Only Interrupts: none
Location  Bus Device Pin  Link  IRQs
slot 1  0   12A   0x60  3 4 5 7 9 10 11 12
slot 1  0   12B   0x61  3 4 5 7 9 10 11 12
slot 1  0   12C   0x62  3 4 5 7 9 10 11 12
slot 1  0   12D   0x63  3 4 5 7 9 10 11 12
slot 2  0   11A   0x61  3 4 5 7 9 10 11 12
slot 2  0   11B   0x62  3 4 5 7 9 10 11 12
slot 2  0   11C   0x63  3 4 5 7 9 10 11 12
slot 2  0   11D   0x60  3 4 5 7 9 10 11 12
slot 3  0   10A   0x62  3 4 5 7 9 10 11 12
slot 3  0   10B   0x63  3 4 5 7 9 10 11 12
slot 3  0   10C   0x60  3 4 5 7 9 10 11 12
slot 3  0   10D   0x61  3 4 5 7 9 10 11 12
slot 4  09A   0x63  3 4 5 7 9 10 11 12
slot 4  09B   0x60  3 4 5 7 9 10 11 12
slot 4  09C   0x61  3 4 5 7 9 10 11 12
slot 4  09D   0x62  3 4 5 7 9 10 11 12
embedded04A   0x60  3 4 5 7 9 10 11 12
embedded04B   0x61  3 4 5 7 9 10 11 12
embedded04C   0x62  3 4 5 7 9 10 11 12
embedded04D   0x63  3 4 5 7 9 10 11 12
embedded01A   0x60  3 4 5 7 9 10 11 12
embedded01B   0x61  3 4 5 7 9 10 11 12
embedded01C   0x62  3 4 5 7 9 10 11 12
embedded01D   0x63  3 4 5 7 9 10 11 12
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 4 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks BAD  min = 1, max = 6, width = 5
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 6, width = 4
ACPI timer looks BAD  min = 2, max = 16777214, width = 16777212
ACPI timer looks BAD  min = 1, max = 6, width = 5
ACPI timer looks BAD  min = 1, max = 7, width = 6
Timecounter "ACPI-safe" frequency 3579545 Hz quality 1000
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 4 func 3
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 4 func 3
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
acpi_cpu0:  on acpi0
acpi_button0:  on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
 initial configuration 
\\_SB_.LNKA irq  11: [  3  4  5  6  7  9 10 11 12 14 1

Re: automated clean up of /usr/lib because of /lib

[Doug Barton]

There was a discussion of this recently, and the conclusion was more or
less that doing this in an automated fashion is frought with danger,
since you don't know for sure what else besides system components the
user has put in the various directories.

I've been using the following combination of a bash function (that could
just as easily be its own script) and a script I call
after_installworld.

doinstall ()
{
cd /usr && [ -d include-old ] && /bin/rm -r include-old;
[ ! -e include-old ] && mv -i include include-old;
/bin/rm -r /usr/share/man;
cd /usr/src && touch installdate && make installworld
}


#!/bin/sh

PATH=/usr/bin:/bin
export PATH

for dir in /bin /lib /libexec /rescue /sbin \
/usr/bin /usr/games /usr/lib /usr/libdata /usr/libexec /usr/sbin ; do
for file in `find $dir \( -type f -o -type l \) -a \
! -newer /usr/src/installdate`; do
case "${file}" in
/usr/lib/compat/*|*/0ld/*|/usr/libdata/perl/*) ;;
*)  echo ''
ls -lao ${file}
read -p "  *** Move ${file} to ${file%/*}/0ld? [n] " M
case ${M} in
[yY]*)  mkdir -p ${file%/*}/0ld
chflags 0 ${file} &&
mv -i ${file} ${file%/*}/0ld/
;;
esac
;;
esac
done
done

exit 0


This combination keeps things squeaky clean for me.

HTH,

Doug

-- 

This .signature sanitized for your protection


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

Re: Kernel fails to compile

[Doug Barton]

On Mon, 1 Sep 2003, Martin Jessa wrote:

> Sources fetched an hour ago.
> Running make in /usr/src/sys/i386/compile/MYKERNEL :

Remove device pcic from your kernel config. My understanding is that
it's broken anyway, so you're not losing anything by removing it.

HTH,

Doug

-- 

This .signature sanitized for your protection

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

RE: ACPI problems with Compaq Evo N610c

[Doug Barton]

I got interested in this recently because I inherited one of these
laptops from work.

On Wed, 30 Jul 2003, Cagle, John (ISS-Houston) wrote:

> Which version of the N610C BIOS are you using?  (F.14 is the latest on
> the hp.com website.)  I know that the _OSI("Windows 2001") bug will be
> fixed in the F.15 release, but I don't think the _GL_ portion of your
> patch will be included.  Did you have to remove the Acquire & Release
> of _GL_ in order to get xbat to work?  (This is not a problem we see
> with Linux ACPI in 2.4.21, so I think that FreeBSD's ACPI stack needs
> updating.)

I just updated to F.15, and it does indeed fix the windows bit in the
output of 'acpidump -d'. However, even with Tony's recommendation of
removing the acquire/release of _GL in methods C12C and C12D, I still
can't get xbatt or wmbattery to run, even with the very latest -current
(which has had at least one acpi stack upgrade since 7/30). When I run
either command, it locks the box tight. If I ever get a cursor back, I
have to Ctrl-Alt-Backspace to get out of X, since I can't actually type
anything.

I have a feeling that my acpi table didn't actually get overridden
though, due to the following from dmesg:

ACPI: DSDT was overridden.
-0424: *** Error: UtAllocate: Could not allocate size 6e49202a
ACPI-0428: *** Error: Could not allocate table memory for [/*
 ] length 6e49202a
ACPI-0368: *** Error: Could not copy override ACPI table,
AE_NO_MEMORY

Also, the "before" and "after" acpidump's don't show anything different.
So, I'm curious if wmbatt is still working for Tony and Robert or not
with the latest -current.

The other problem I'm having is that doing 'sysctl -a', or just 'sysctl
hw.acpi' locks the system tight for a couple minutes, and never
completes. The last line that's printed to the screen is:

hw.acpi.thermal.tz1._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1

Any ideas on that one?

Thanks,

Doug


> > > /boot/loader.conf is now
> > >
> > > hw.pci.allow_unsupported_io_range=1
> > > acpi_dsdt_load="YES"
> > > acpi_dsdt_name="/boot/acpi_dsdt.aml


-- 

This .signature sanitized for your protection

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

Re: ACPI problems with Compaq Evo N610c

[Doug Barton]

On Mon, 1 Sep 2003, Robert [unknown-8bit] Blacquière wrote:

> I don't seem to have these problems. I use xbattbar without problem.

Argh. How recent is your -current? I compile regularly, and I was up to
date as of this afternoon.

> I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl

Thanks for the suggestion... I tried that one, but got the same error
about not enough memory to load the override file.

I attached a verbose dmesg, just in case someone wants to take a look.

Doug

-- 

This .signature sanitized for your protection
ified - using default frequency
Timecounter "i8254" frequency 1193182 Hz quality 0
Calibrating TSC clock ... TSC clock: 1794188892 Hz
CPU: Mobile Intel(R) Pentium(R) 4 - M CPU 1.80GHz (1794.19-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0xf27  Stepping = 7
  
Features=0xbfebf9ff
real memory  = 536674304 (511 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x00503000 - 0x1f6aafff, 521830400 bytes (127400 pages)
avail memory = 51598 (492 MB)
bios32: Found BIOS32 Service Directory header at 0xc00fa000
bios32: Entry = 0xf (c00f)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0x3a2
pnpbios: Found PnP BIOS data at 0xc00f4330
pnpbios: Entry = f:435e  Rev = 1.0
pnpbios: Event flag at f4356
pnpbios: OEM ID 4d00110e
Other BIOS signatures found:
null: 
random: 
mem: 
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 
00 01 ff 01 00 01 19 01 00 01 2f 01 00 01 34 01 
00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 
94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 
VESA: 60 mode(s) found
VESA: v2.0, 32704k memory, flags:0x1, mode table:0xc03f08e2 (122)
VESA: ATI MOBILITY RADEON 7500
VESA: ATI Technologies Inc. P7   01.00
ACPI: DSDT was overridden.
-0424: *** Error: UtAllocate: Could not allocate size 50204453
ACPI-0428: *** Error: Could not allocate table memory for [/*
R] length 50204453
ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=1a308086)
pcibios: BIOS version 2.10
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 1 dev 0 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 0 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 2 dev 6 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 2 dev 6 func 1
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 31 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
ACPI timer looks GOOD min = 4, max = 4, width = 0
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_cpu0:  port 0x530-0x537 on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_tz0:  port 0x530-0x537 on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_tz1:  port 0x530-0x537 on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
 initial configuration 
\\_SB_.C045.C0C2 irq   0: [  5 10 11] low,level,sharable 0.31.0
\\_SB_.C045.C0C1 irq  11: [  5 10 11] low,level,sharable 0.31.1
 before setting priority for links 
\\_SB_.C045.C0C2:
interrupts:  51011
penalty:   110   110   210
references: 1
priority:   0
 before fixup boot-disabled links -
\\_SB_.C045.C0C2:
interrupts:  51011
penalty:   110   110   210
references: 1
priority:   143
 after fixup boot-disabled links --
 arbitrated configuration -
\\_SB_.C045.C0C2 irq  10: [  5 10 11] low,level,sharable 0.31.0
\\_SB_.C045.C0C1 irq  11: [  5 10 11] low,level,sharable 0.31.1
pci0:  on pcib0
pci0: physical bus=0
map[10]: type 3, range 32, base 60

Re: /lib symlinks problem?

[Doug Barton]

On Mon, 1 Sep 2003, M. Warner Losh wrote:

> My tool is initially just a 'delete these files' tool, but now that I
> think about it, it wouldn't be hard to say also 'create these
> symlinks'.  The hard part here is generating the 'obsolete' lists.

I posted one approach to this today... touch a file right before you
start installworld, then consider anything not newer than that file a
candidate for disposal. There is currently something weird going on in
/usr/lib though... a lot of the files don't have newer dates, I haven't
tracked down why yet.

Also, I highly recommend NOT deleting the files, but moving them
somewhere. This makes it much easier to recover if you delete something
you shouldn't have.

Doug

-- 

This .signature sanitized for your protection

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

Re: /lib symlinks problem?

[Doug Barton]

On Mon, 1 Sep 2003, Ruslan Ermilov wrote:

> > I posted one approach to this today... touch a file right before you
> > start installworld, then consider anything not newer than that file a
> > candidate for disposal. There is currently something weird going on in
> > /usr/lib though... a lot of the files don't have newer dates, I haven't
> > tracked down why yet.
> >
> This is because static libraries are installed with -C.  The reasoning
> was like this:
>
> On Sat, Mar 30, 2002 at 02:15:56PM +0100, Dag-Erling Smorgrav wrote:
> > Ruslan Ermilov <[EMAIL PROTECTED]> writes:
> > > On Fri, Mar 22, 2002 at 12:28:17PM -0800, Dag-Erling Smorgrav wrote:
> > > >   Log:
> > > >   Install static and profiled libraries with -C.
> > > Um why, what's so special about them?
> >
> > They appear in dependency lists.  This was discussed on -arch.

Can you fill in a little more detail here? I really prefer the old
behavior, not using -C.

> This also will not work for anything that has not changed and is
> installed with -C, that is includes,

I posted my script to -current just today. I 'mv include include-old' to
handle this. I also blow away /usr/share/man, since creating it from
scratch is just as easy as trying to cleanse it.

> rtld-elf, and some parts of /sys/boot.

I haven't touched /boot yet, I'm not that brave. :) There are a couple
other things that my script doesn't handle just on the basis of "newer
than," but as a proof of concept it's quite functional.

Doug

-- 

This .signature sanitized for your protection

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

Re: /lib symlinks problem?

[Doug Barton]

On Mon, 1 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
>     Doug Barton <[EMAIL PROTECTED]> writes:
> : On Mon, 1 Sep 2003, M. Warner Losh wrote:
> :
> : > My tool is initially just a 'delete these files' tool, but now that I
> : > think about it, it wouldn't be hard to say also 'create these
> : > symlinks'.  The hard part here is generating the 'obsolete' lists.
> :
> : I posted one approach to this today... touch a file right before you
> : start installworld, then consider anything not newer than that file a
> : candidate for disposal. There is currently something weird going on in
> : /usr/lib though... a lot of the files don't have newer dates, I haven't
> : tracked down why yet.
>
> No.  That's not what I'm talking about.  That approach is crap,
> because installworld doesn't touch all files.

Please tell us how you really feel! :) I have never said that my
suggestion was a complete solution to the problem. But it does get you
pretty far down the road for any given instance of installworld, without
needing to maintain complicated databases of what files have been
installed by the system.

I would think that using my suggestion in directories where we _do_
touch every file (like *[s]bin) would make your task easier, but since I
haven't seen your WIP yet, I'll reserve further comment till I do.

> : Also, I highly recommend NOT deleting the files, but moving them
> : somewhere. This makes it much easier to recover if you delete something
> : you shouldn't have.
>
> I don't care the method of removal.  I care more about the list.  If
> you want to mv them them instead of rm, it isn't a big deal to change
> that detail.

Ok, consider this a request to do that then. As suggestions, I currently
use two different methods to deal with this. In the after_installworld
script I posted, I create an 0ld directory in the same directory as the
files I want to back up. I use zero as the first character so it always
sorts at the top for easy identification. For mergemaster's -P option, I
create /var/tmp/mergemaster/preserved-files-yymmdd-hhmmss, where the
time is the time that the run of mergemaster started. Both approaches
have merit. For binaries and libs my thinking was that leaving them on
the same file system will make it possible to recover if one of the
things you happened to mv turned out to be important during mount
time/boot time.

> The mv /usr/foo -> /usr/foo.old is too dangerous, and I think it is
> the wrong way to go.

Well, I started doing it for /usr/include and /usr/share/man personally
because nothing from either directory is needed for installworld, and I
know for a fact that I'm rigorous about not putting any foreign stuff in
there. I'm certainly not married to the idea of doing it that way.

As I've been saying all along, the stuff I've been posting is little
more than Proof of Concept work atm. My goal has been to defeat the
inertia surrounded by "we cannot make this work!" by demonstrating one
method that does work, albeit imperfectly. The fact that you're moving
farther down this road is music to my ears. :)

Doug

-- 

This .signature sanitized for your protection

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

Re: ACPI problems with Compaq Evo N610c

[Doug Barton]

On Mon, 1 Sep 2003, Terry Lambert wrote:

> Doug Barton wrote:
> > > I use this acpi_dsdt code: http://www.guldan.cistron.nl/acpi_dsdt.dsl
> >
> > Thanks for the suggestion... I tried that one, but got the same error
> > about not enough memory to load the override file.
> >
> > I attached a verbose dmesg, just in case someone wants to take a look.
>
> | ACPI: DSDT was overridden.
> | -0424: *** Error: UtAllocate: Could not allocate size 50204453
> | ACPI-0428: *** Error: Could not allocate table memory for [/*
> | R] length 50204453
> | ACPI-0368: *** Error: Could not copy override ACPI table, AE_NO_MEMORY
>
>
> I'm going to go out on a limb here and suggest that perhaps the
> problem is that the damn thing appears to be 50 Megabytes...

Well, you could have verified that easily enough for yourself by
downloading the file at that URL above. :)  It turns out that it's only
142k, which is another reason I think that something very odd is
happening.

Doug

-- 

This .signature sanitized for your protection

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

Re: bsd.lib.mk and bsd.own.mk ignore /etc/make.conf(INSTALL)

[Doug Barton]

On Mon, 1 Sep 2003, Ian Freislich wrote:

> Hi
>
> Any idea why '-C' is hard coded for bsd.lib.mk and bsd.own.mk?  I
> thought that the make.conf variable was there to allow or disallow
> this.  The following comes from bsd.lib.mk:

I'd also like to see this option be a knob, preferably defaulting to
without -C.

Doug

-- 

This .signature sanitized for your protection

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

Re: 5.2-RELEASE TODO -2

[Doug Barton]

On Mon, 1 Sep 2003, Nicole wrote:

>  It just drives me crazy when important things get broken and people
> act like..  What the big deal. I don't need it why should you?

You're certainly free to draw that conclusion, however you'd be
mistaken. There are times when adding new features means that things
change. That's life in a volunteer project. If this isn't to your
liking, feel free to move on, or get to work restoring functionality
that you think is important. Either way, you need to dial down the
rhetoric quite a bit if you expect people to help you.

>  I still have not solved the going to comsonsole mode if there is no
> keyboard detected crap, new "feature".  Yea great for those who could
> benifit from it.. But I have YET to have one person be able to show me
> how to STOP it from doing that.

Remove the 0x01 flag from the atkbd0 line in your kernel config.


-- 

This .signature sanitized for your protection

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

Re: 5.2-RELEASE TODO -2

[Doug Barton]

On Mon, 1 Sep 2003, Nicole wrote:

>  Sorry I didn't mean to be so "testy" I guess would discribe it. It's
> an old issue for me.

Not to put too fine a point on it, but I've seen numerous posts from
you, on several topics, all of them berating people for not giving you
what you want, when you wanted it. I tend to ignore posts from you for
just this reason.

> > Remove the 0x01 flag from the atkbd0 line in your kernel config.
>
>  I will give that a shot. Thats certainly different than abyone else has
> suggested.

That's because they didn't understand the problem you were trying to
solve.

> In my 5.1 system I see this in my .hints file. So I assume I edit it
> there or do I treat it like a defaults file and import and change in
> in my config file?

I didn't say anything about your hints file. You need to edit your
kernel config file, build a new kernel, then reboot. If any of that is
confusing to you, please follow up on freebsd-questions, since people
running -current are assumed to have that base of knowledge.

Hope this helps,

Doug

-- 

This .signature sanitized for your protection

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

Re: 5.2-RELEASE TODO -2

[Doug Barton]

On Mon, 1 Sep 2003, Scott Long wrote:

> Device flags are not specified in the kernel config anymore unless you
> try really, really hard.  /etc/device.hints is the correct place to
> adjust this flag.

Yeah, I was looking at the kernel config on the wrong box. This flag did
used to be in GENERIC, so it's worth double-checking the kernel config
anyway just to be sure, but it should definitely be updated in
/boot/device.hints if it's there.

Sorry for the confusion,

Doug

-- 

This .signature sanitized for your protection

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

Re: swapon vs savecore dilemma

[Doug Barton]

On Tue, 2 Sep 2003, Poul-Henning Kamp wrote:

> Hmm, that was an unfortunate side effect.

Heh, well, stuff happens. I think your idea of opening swap exclusive is
probably a good one, but it will require some gymnastics to accomodate
it. One thing that'd really help is an option to savecore that tells us
if there is a dump to deal with or not. If I had that, we could do
something like this in /etc/rc.d/savecore

if there is no dump
exit
else
does fsck -p of the fs to write the dump to succeed?
mount it rw
write the dump
clear the dump
exit
else
does try fsck -y of the fs without swap succeed?
mount, write, clear, exit
else
???

At the ??? point I'm not sure how best to proceed, since if we swapon to
the same partition with the dump, it's likely to corrupt the dump, yes?
On the other hand, we're doing swapon before savecore now, so I guess
I'm curious about how dangerous this really is.

Probably the right thing to do is to swapon, fsck -y, and if it succeeds
then swapoff, and try writing the dump anyway. I just want to be
sure before we start re-writing rc.d/savecore.

So, the first question is does the pseudocode above look reasonable, and
the second question is what's the likelihood of getting an option to
savecore to detect a dump to play with?

Doug

-- 

This .signature sanitized for your protection

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

Re: swapon vs savecore dilemma

[Doug Barton]

On Tue, 2 Sep 2003, Matthew D. Fuller wrote:

> On Tue, Sep 02, 2003 at 12:58:40AM -0600 I heard the voice of
> Scott Long, and lo! it spake thus:
> >
> > I still think that the real problem is in running swapon before
> > savecore.  In 99% of the cases out there, RAM scales with storage,
> > so I really can't imaging fsck needing to swap, and certainly not
> > in it's 'preen-before-background' mode.
>
> Note also that (last I heard, anyway) this is often "worked around", or
> non-issued, by us allocating swap from the "bottom" of the partition up,
> and coredumps happening from the "top" down.  So, if you've got 512 megs
> of swap, and 128 megs of ram, you'd need to use 384 megs of swap (+/-
> housekeeping) before you corrupted your core.

I agree that this _should_ be the case, but I've seen the advice of
putting in swap space equal to the amount of memory often enough to make
me nervous that this is a safe assumption.

Doug

-- 

This .signature sanitized for your protection

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

Re: swapon vs savecore dilemma

[Doug Barton]

On Tue, 2 Sep 2003, Scott Long wrote:

> I still think that the real problem is in running swapon before
> savecore.  In 99% of the cases out there, RAM scales with storage,
> so I really can't imaging fsck needing to swap, and certainly not
> in it's 'preen-before-background' mode.

I agree, but the proble is that in order to make this successful in a
scenario when the system is well and truly fubar (which is where you're
most likely to want a good dump), then just moving it earlier isn't
enough.

Doug

-- 

This .signature sanitized for your protection

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

Re: swapon vs savecore dilemma

[Doug Barton]

On Tue, 2 Sep 2003, Poul-Henning Kamp wrote:

> In message <[EMAIL PROTECTED]>, Doug Barton writes:
> >On Tue, 2 Sep 2003, Poul-Henning Kamp wrote:
> >
> >> Hmm, that was an unfortunate side effect.
> >
> >Heh, well, stuff happens. I think your idea of opening swap exclusive is
> >probably a good one, but it will require some gymnastics to accomodate
> >it.
>
> Yeah, but I'm ENOTIME right now, so I've just dropped the exclusive
> bit for now with an XXX comment.

I wasn't suggesting that you do the rc part, I was volunteering myself
(or the team) for that bit. However, the voices are whispering in my ear
that making savecore tell me if I have a dump is really easy to
implement, so I might be able to do this bit too.

Doug

-- 

This .signature sanitized for your protection

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

savecore "check for a dump" patch for review

[Doug Barton]

I'm sure there's lots of errors, so be gentle. :) It does work though,
so that's a plus.

Doug

-- 

This .signature sanitized for your protectionIndex: savecore.8
===
RCS file: /usr/local/ncvs/src/sbin/savecore/savecore.8,v
retrieving revision 1.19
diff -u -r1.19 savecore.8
--- savecore.8  21 Aug 2002 18:11:42 -  1.19
+++ savecore.8  2 Sep 2003 10:11:04 -
@@ -42,6 +42,10 @@
 .Nm
 .Fl c
 .Nm
+.Fl C
+.Op Fl v
+.Op Ar directory device
+.Nm
 .Op Fl fkvz
 .Op Ar directory Op Ar device ...
 .Sh DESCRIPTION
@@ -58,6 +62,14 @@
 .Pp
 The options are as follows:
 .Bl -tag -width indent
+.It Fl C
+Check to see if a dump exists,
+and display a brief message to indicate the status.
+An exit status of 0 indicates that a dump is there,
+1 indicates that none exists.
+This option is compatible only with the
+.Op Fl v
+option.
 .It Fl c
 Clear the dump, so that future invocations of
 .Nm
Index: savecore.c
===
RCS file: /usr/local/ncvs/src/sbin/savecore/savecore.c,v
retrieving revision 1.63
diff -u -r1.63 savecore.c
--- savecore.c  1 Jan 2003 18:48:46 -   1.63
+++ savecore.c  2 Sep 2003 10:17:07 -
@@ -88,7 +88,7 @@
 /* The size of the buffer used for I/O. */
 #defineBUFFERSIZE  (1024*1024)
 
-int compress, clear, force, keep, verbose; /* flags */
+int checkfor, compress, clear, force, keep, verbose;   /* flags */
 int nfound, nsaved, nerr;  /* statistics */
 
 extern FILE *zopen(const char *, const char *);
@@ -321,6 +321,12 @@
goto closefd;
}
 
+   if (checkfor) {
+   printf("A dump exists on %s\n", device);
+   close(fd);
+   exit(0);
+   }
+
if (kdhl.panicstring[0])
syslog(LOG_ALERT, "reboot after panic: %s", kdhl.panicstring);
else
@@ -478,7 +484,7 @@
 static void
 usage(void)
 {
-   fprintf(stderr, "usage: savecore [-cfkv] [directory [device...]]\n");
+   fprintf(stderr, "usage: savecore [-Cv|-cfkv] [directory [device...]]\n");
exit (1);
 }
 
@@ -496,8 +502,11 @@
syslog(LOG_ERR, "Cannot allocate memory");
exit(1);
}
-   while ((ch = getopt(argc, argv, "cdfkN:vz")) != -1)
+   while ((ch = getopt(argc, argv, "CcdfkN:vz")) != -1)
switch(ch) {
+   case 'C':
+   checkfor = 1;
+   break;
case 'c':
clear = 1;
break;
@@ -519,6 +528,8 @@
default:
usage();
}
+   if (checkfor && (clear || force || keep))
+   usage();
argc -= optind;
argv += optind;
if (argc >= 1) {
@@ -547,8 +558,13 @@
}
 
/* Emit minimal output. */
-   if (nfound == 0)
+   if (nfound == 0) {
+   if (checkfor) {
+   printf("No dump exists\n");
+   exit(1);
+   }
syslog(LOG_WARNING, "no dumps found");
+   }
else if (nsaved == 0) {
if (nerr != 0)
syslog(LOG_WARNING, "unsaved dumps found but not saved");
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: [GCC 3.3.1 regression] loop miscompiled.

[Doug Barton]

You should really file a PR about this.

Doug

-- 

This .signature sanitized for your protection

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

Re: cvs commit: src/sbin/savecore savecore.8 savecore.c

[Doug Barton]

Ok, two days of silence -> commit. :)  This is the first step of the
plan I suggested to make savecore behavior conditional in rc.d so that
we can run it safely(?) before swapon.

While the guys mentioned below did help with and review this patch, I'm
responsible for any screwups. :)

Doug


On Thu, 4 Sep 2003, Doug Barton wrote:

> dougb   2003/09/04 03:07:01 PDT
>
>   FreeBSD src repository
>
>   Modified files:
> sbin/savecoresavecore.8 savecore.c
>   Log:
>   Add a flag that reports the existence of a dump, and does nothing else.
>
>   The immediate purpose for this option is to use it in rc.d so that we
>   can make savecore behavior conditional.
>
>   Tremendous assistance with ideas and sanity checking provided by tjr
>   and [EMAIL PROTECTED]
>
>   Revision  ChangesPath
>   1.20  +12 -0 src/sbin/savecore/savecore.8
>   1.64  +20 -4 src/sbin/savecore/savecore.c
>
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/savecore/savecore.8.diff?&r1=1.19&r2=1.20&f=h
> http://www.FreeBSD.org/cgi/cvsweb.cgi/src/sbin/savecore/savecore.c.diff?&r1=1.63&r2=1.64&f=h
>
>

-- 

This .signature sanitized for your protection

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

Re: Entropy harvesting: interrupts ethernet point_to_point

[Doug Barton]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I've seen this problem on my compaq evo n610c as well, but didn't
realize it was affecting other hardware as well. I tried to stir up
interest in getting the acpi problem fixed, but wasn't successful.

Mark, ok with you if I nuke the sysctl -a line in rc.d/initrandom? I
hate to lose that source (no matter how small), but if the "can't finish
sysctl -a" cancer is spreading...

Doug

- -- 

This .signature sanitized for your protection

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)

iD8DBQE/V2i4yIakK9Wy8PsRAj9xAKDln9La1f89JUzxNm4Q9OlQbFD5PgCgyUuO
A8HcT5QFudf0ohwrpDebZTE=
=qrg7
-END PGP SIGNATURE-
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Latest -current boot stops cold after first CD

[Doug Barton]

I compiled the latest -current, and now it doesn't even boot. :(  My
first cd drive (a CD-ROM) is probed, but it falls back to PIO4. The
kernel boot freezes after that point, and my CD-RW is never detected.
This time the trick of putting a CD into the second drive doesn't help.
I've added back the atapicam and ATA_STATIC_ID options to my kernel.
Haven't had a chance to try the latest kernel without atapicam.

I posted a dmesg recently, let me know if you need another copy. My 8/31
kernel works fine, FYI.

Doug

-- 

This .signature sanitized for your protection

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

Important changes to the .org tld today. (fwd)

[Doug Barton]

FYI,

Doug


-- Forwarded message --
Date: Fri, 05 Sep 2003 06:03:15 -0700
From: Rodney Joffe <[EMAIL PROTECTED]>
Organization: UltraDNS Corp
Subject: Important changes to the .org tld today.


-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

During the root zone (.) update later today, specifically with root
zone serial number 2003090501, the entries for .org will me modified.

The current zone entry contains the following authoritative
nameservers for the .org tld:

org.2D IN NSA7.NSTLD.COM.
org.2D IN NSL7.NSTLD.COM.
org.2D IN NSG7.NSTLD.COM.
org.2D IN NSF7.NSTLD.COM.
org.2D IN NSM5.NSTLD.COM.
org.2D IN NSTLD1.ULTRADNS.NET.
org.2D IN NSTLD2.ULTRADNS.NET.
org.2D IN NSJ5.NSTLD.COM.
org.2D IN NSI5.NSTLD.COM.
org.2D IN NSC5.NSTLD.COM.
org.2D IN NSE5.NSTLD.COM.

Effective with the 2003090501 load, the entry will reflect the
removal of the Verisign NSTLD.COM nameservers. The zone entry will
therefore contain the following only:

org.2D IN NSTLD1.ULTRADNS.NET.
org.2D IN NSTLD2.ULTRADNS.NET.

If you have the 9 ??.NSTLD.COM nameservers cached or hard coded in
any way, you may wish to flush your cache or modify your nameservers
in the near future to avoid any inconsistent or stale data, and you
may want to make your system administrators, NOCs and customer
support groups aware of the changes.

The .org zone file will continue to be pushed to the Verisign
nameservers for a short period of time. However due to the fact that
the UltraDNS nameservers publish and propagate zone changes globally
within 5 minutes, rather than the twice daily update schedule of the
Verisign nameservers, answers from the NSTLD.COM nameservers may be
out of date and inconsistent with the actual SOA for up to 24 hours
after a change is accepted by the Public Interest Registry (PIR.org).

Any questions or concerns regarding this change should be directed to
the PIR (http://www.pir.org).

Sincerely,
Rodney Joffe

CTO and Chairman
UltraDNS Corp.
http://www.ultradns.com

-BEGIN PGP SIGNATURE-
Version: PGP 8.0.2

iQA/AwUBP1iJJEa3pZtqJ3OwEQJvwACdHkKdAW3TqDSpOJVoguhFAx0YebwAnAw9
c6fW3PeXcgvjwhvLIPaxRVEW
=+m9c
-END PGP SIGNATURE-

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

My acpi-errant laptop will be at the 'con

[Doug Barton]

The Compaq Evo N610c that I'm having all these acpi problems with will
be at bsdcon, if anyone wants to take a look.

Doug

-- 

This .signature sanitized for your protection

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

Re: My acpi-errant laptop will be at the 'con

[Doug Barton]

On Mon, 8 Sep 2003, Robert [unknown-8bit] Blacquière wrote:

> Doug,
>
> We have already posted some info about the N610c here in the mailing
> list. I've got a acpi code uploadable from the bootloader to bios
> available:
>
>   http://www.guldan.cistron.nl/acpi_dsdt.dsl
>
> This code can be compiled using iasl from the acpicatools port.
> This produces a aml code which could be loaded into memory at boot,
> using the /boot/loader.conf.
>
> acpi_dsdt_load="YES"
> acpi_dsdt_name="/boot/acpi_dsdt.aml"
>
> Hope this will reduce your problems with acpi on your 610c,

Hey hey hey!  Now it's working. :)) Thanks for posting that file. Now I
have a battery monitor.

> please also update your bios to the F15 release (some bug fixes and
> support issues are fixed)

Yeah, I'd done that one already, but thanks for the reminder.

Doug

-- 

This .signature sanitized for your protection

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

No pccard with last night's kernel

[Doug Barton]

With a kernel updated last night, I get the following every time I try
to put in a wireless card, in either slot:

pccard0: can't alloc memory to read attributes
pccard0: CARD ERROR!
cbb0: PC Card card activation failed
pccard1: can't alloc memory to read attributes
pccard1: CARD ERROR!
cbb1: PC Card card activation failed

The same card (a netgear ma401ra) mostly works in -stable, also from
last night.

I'll try upgrading tonight when I get home, but meanwhie, any hints?

Doug

-- 

This .signature sanitized for your protection

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

Re: -pthread deprecated, but when?

[Doug Barton]

On Tue, 9 Sep 2003, Harald Schmalzbauer wrote:

> On Tuesday 09 September 2003 06:23, leafy wrote:
> > IMO this deprecation deserves a place in UPDATING. And what are the
> > plans to Do The Right Thing? QT currently does not compile on -current
> > with the -pthread deprecated.

Probably be nice to bump __FreeBSD_version too, just for fun.

> Was port@ informed before the change?

Yes.

> I'm also very interested what the plans are to Do The Right Thing.

The right thing to do is to file a PR when this stuff breaks. This
process will actually be a good thing, since ports should not have been
compiling on -current with -pthread for a long time now.

BTW, several ports have already been fixed, and the fix is not
difficult. I do the following in my ports:

@ ${CP} ${WRKSRC}/configure ${WRKSRC}/configure.Patched
@ ${SED} -e 's#-lpthread#${PTHREAD_LIBS}#g' \
-e 's#malloc.h#stdlib.h#g' \
${WRKSRC}/configure.Patched > ${WRKSRC}/configure

Any occurences of -lc_r should be changed to ${PTHREAD_LIBS} too.

HTH,

Doug

-- 

This .signature sanitized for your protection

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

Re: No pccard with last night's kernel

[Doug Barton]

Argh. I got this working again by putting the
hw.pci.allow_unsupported_io_range back into my /boot/loader.conf.local
file. I had it in there originally thinking it would help with my acpi
problems, but when the new .aml file fixed the acpi issues, I took it
out.

I attached two files, one is the result in the logs when I insert the
card, and the other is a verbose dmesg, just in case it's useful.

Sorry for the false alarm,

Doug

-- 

This .signature sanitized for your protectionSep  9 00:27:02 lap kernel: end () > sc->memlimit (403f)
Sep  9 00:27:03 lap kernel: end () > sc->memlimit (403f)
Sep  9 00:27:03 lap kernel: pccard0:  (manufacturer=0x000b, 
product=0x7300) at function 0
Sep  9 00:27:03 lap kernel: pccard0:CIS info: NETGEAR MA401RA Wireless PC, Card, 
ISL37300P
Sep  9 00:27:24 lap kernel: end () > sc->memlimit (403f)
Sep  9 00:27:24 lap kernel: wi0:  at port 
0x100-0x13f irq 11 function 0 config 1 on pccard0
Sep  9 00:27:24 lap kernel: wi0: 802.11 address: 00:09:5b:31:2d:2f
Sep  9 00:27:24 lap kernel: wi0: using RF:PRISM2.5 MAC:ISL3873
Sep  9 00:27:24 lap kernel: wi0: Intersil Firmware: Primary (1.1.1), Station (1.5.6)
Sep  9 00:27:24 lap kernel: wi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps

PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
real memory  = 536674304 (511 MB)
Physical memory chunk(s):
0x1000 - 0x0009efff, 647168 bytes (158 pages)
0x004e6000 - 0x1f6aafff, 521949184 bytes (127429 pages)
avail memory = 516050944 (492 MB)
bios32: Found BIOS32 Service Directory header at 0xc00fa000
bios32: Entry = 0xf (c00f)  Rev = 0  Len = 1
pcibios: PCI BIOS entry at 0xf+0x3a2
pnpbios: Found PnP BIOS data at 0xc00f4330
pnpbios: Entry = f:435e  Rev = 1.0
pnpbios: Event flag at f4356
pnpbios: OEM ID 4d00110e
Other BIOS signatures found:
null: 
random: 
mem: 
Pentium Pro MTRR support enabled
VESA: information block
56 45 53 41 00 02 00 01 00 01 01 00 00 00 22 00 
00 01 ff 01 00 01 19 01 00 01 2f 01 00 01 34 01 
00 01 82 01 0d 01 0e 01 0f 01 20 01 92 01 93 01 
94 01 95 01 96 01 a2 01 a3 01 a4 01 a5 01 a6 01 
VESA: 60 mode(s) found
VESA: v2.0, 32704k memory, flags:0x1, mode table:0xc03f2502 (122)
VESA: ATI MOBILITY RADEON 7500
VESA: ATI Technologies Inc. P7   01.00
ACPI: DSDT was overridden.
ACPI-0375: *** Info: Table [DSDT] replaced by host OS
npx0: [FAST]
npx0:  on motherboard
npx0: INT 16 interface
acpi0:  on motherboard
pci_open(1):mode 1 addr port (0x0cf8) is 0x80010014
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:   device 0 [class=06] [hdr=00] is there (id=1a308086)
pcibios: BIOS version 2.10
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 1 dev 0 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 0 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 2 dev 6 func 0
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 2 dev 6 func 1
acpi_bus_number: root bus has no _BBN, assuming 0
AcpiOsDerivePciId: bus 0 dev 31 func 0
acpi0: power button is handled as a fixed feature programming model.
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
ACPI timer looks GOOD min = 4, max = 5, width = 1
Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000
acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_cpu0:  port 0x530-0x537 on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_tz0:  port 0x530-0x537 on acpi0
mss_probe: no address given, try 0x530
mss_detect, busy still set (0xff)
acpi_tz1:  port 0x530-0x537 on acpi0
pcib0:  port 0xcf8-0xcff on acpi0
 initial configuration 
\\_SB_.C045.C0C2 irq   0: [  5 10 11] low,level,sharable 0.31.0
\\_SB_.C045.C0C1 irq  11: [  5 10 11] low,level,sharable 0.31.1
 before setting priority for links 
\\_SB_.C045.C0C2:
interrupts:  51011
penalty:   110   110   210
references: 1
priority:   0
 before fixup boot-disabled links -
\\_SB_.C045.C0C2:
interrupts:  51011
penalty:   110   110   210

Re: -pthread deprecated, but when?

[Doug Barton]

On Tue, 9 Sep 2003, Khairil Yusof wrote:

> On Tue, 2003-09-09 at 16:07, Doug Barton wrote:
>
> > Any occurences of -lc_r should be changed to ${PTHREAD_LIBS} too.
>
> Seems that -lc_r is set by default in bsd.port.mk for ${PTHREAD_LIBS}.

The reason we use the variable is that it expands differently on
different platforms, so in theory it's always doing the right thing.

> Does it mean that we should be able to specify a pthread library in
> future as a make option for installing ports?

It means that you should always use the existing method of substituting
any instances of -pthread or -lc_r that are hard coded into a port with
${PTHREAD_LIBS}.

Doug

-- 

This .signature sanitized for your protection

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

Re: -pthread deprecated, but when?

[Doug Barton]

On Tue, 9 Sep 2003, Kevin Oberman wrote:

> For which versions of FreeBSD? I just tried using ${PTHREAD_LIBS}, but
> the loader could not find any of the pthread routines. I assume it
> should be defined in one of the .mk files, but it does not seem to be
> on either a current (yesterday) or an older current (9/19).

Sounds to me like you missed a step somewhere... you should follow up on
this topic on -ports.

Doug

-- 

This .signature sanitized for your protection

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

Re: -pthread deprecated, but when?

[Doug Barton]

On Tue, 9 Sep 2003, Matthias Andree wrote:

> Doug Barton <[EMAIL PROTECTED]> writes:
>
> > @ ${CP} ${WRKSRC}/configure ${WRKSRC}/configure.Patched
> > @ ${SED} -e 's#-lpthread#${PTHREAD_LIBS}#g' \
>
> How about: ${SED} -Ee 's#-l?pthread#${PTHREAD_LIBS}#g' \
>
> That's the one necessary to catch -pthread (such as BerkeleyDB) in
> addition to -lpthread.

You should use whatever is appropriate for your port... I just posted an
example from one of mine.

Doug

-- 

This .signature sanitized for your protection

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

Re: new rc system

[Doug Barton]

On Tue, 9 Sep 2003, Peter Jeremy wrote:

> On Mon, Sep 08, 2003 at 12:59:11PM +0200, Philipp Grau wrote:
> >Next problem is that /etc/rc.d/ntpd is evaluated before /etc/rc.d/devfs (see
> >the output of "rcorder /etc/rc.d*) So the start of ntpd fails because it is
> >requires the devfs link. Ntpd likes to open /dev/refclock-0.
> >
> >What should I do to circumvent this problem? By simply adding a
> >"# REQUIRE: devfs" to the /etc/rc.d/ntpd file? Or this there some other
> >mechanism?

ntpd[ate] is a very difficult thing to order, because a lot of things
need/want accurate time before they start, and yet by definition, ntp is
a network protocol so it has a lot of other dependencies before it can
even start. A lot of the things that ntp depends on (like network) want
logging before they start, but syslog wants accurate time before IT
starts...  and we spiral back in time infinitely.

I've currently been giving a reasonable amount of thought to a "two
pass" concept to rc that would allow you to get a minimal system with
logging up, fire up the network, do things like dns and ntp, then
restart any systems that have to have accurate time to live within a
running system. This is extremely non-trivial though. :)

> This is a known shortcoming in the new rc system.  Luke Mewburn
> commented on it in a talk recently but does not yet have a
> satisfactory solution.

Can you describe in more detail what you mean by "this is a known
shortcoming?"

Doug

-- 

This .signature sanitized for your protection

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

Re: devd/devctl

[Doug Barton]

On Sat, 13 Sep 2003, M. Warner Losh wrote:

> Yes.  that has been the plan for some time now.  However, dhclient is
> really lame in a lot of ways.  Martin Blapp has made it a lot better
> of lates.  In geral, I tend to believe that I shouldn't fix bugs in
> dhclient with devd things.  However, a more general trend to more
> event types would be good because a device arriving isn't quite the
> same as a network interface arriving...

In dhclient's defense, it's really designed to provide functionality on
a wide variety of platforms, with a wide variety of dhcpd's, so it has
"issues." I think Martin did a good job of defining an improvement that
applies to all/most platforms (only try to broadcast if we have link).
That functionality is being ported back to the vendor, if it hasn't been
already. If we want really cool whizbang features that are more specific
to us, we _should_ be looking at stuff like devd. The trick is definig
which problem space we're addressing at any given moment. :)

Doug

-- 

This .signature sanitized for your protection

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

Re: devd/devctl

[Doug Barton]

On Sat, 13 Sep 2003, M. Warner Losh wrote:

> In message: <[EMAIL PROTECTED]>
>     Doug Barton <[EMAIL PROTECTED]> writes:
> : That functionality is being ported back to the vendor, if it hasn't been
> : already. If we want really cool whizbang features that are more specific
> : to us, we _should_ be looking at stuff like devd. The trick is definig
> : which problem space we're addressing at any given moment. :)
>
> You can't do it in devd.  You must be able to either (a) tell a
> running dhclient about arrival/departures of interfaces

Ok, maybe I misunderstand, but wouldn't _this_ be the right thing for
devd to do? In other words, devd should be able to notice this, and
devd.conf should be able to define what I want to do with this like
sending a signal to dhclient. Then we can move to the dhclient problem
space, and define behavior in dhclient that says "when X happens, I need
to do Y."

One way to do this would be to define multiple interfaces in
dhclient.conf, and add an "optional" flag to each interface stanza. Then
when dhclient receives a signal, it rescans the list of interfaces it
knows about looking for link. This is just a conceptual example of
course, other solutions might well be possible.

> or (b) run multiple dhclients.

This is evil, and basically undoable with the current state of things,
but it might be possible down the road, although I still think it's evil
for other reasons.

Doug

-- 

This .signature sanitized for your protection

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

Re: new rc system

[Doug Barton]

We discuss rc on [EMAIL PROTECTED] Feel free to send any ideas
to that list.

Doug

-- 

This .signature sanitized for your protection

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

Re: ports and -current

[Doug Barton]

On Sat, 20 Sep 2003, Daniel Eischen wrote:

> On Sat, 20 Sep 2003, M. Warner Losh wrote:
>
> > In message: <[EMAIL PROTECTED]>
> > Harald Schmalzbauer <[EMAIL PROTECTED]> writes:
> > : Not only the -pthread removement broke countless ports (some of them are
> >
> > Maybe I missed the reason why FreeBSD needs to be unique wrt threading
> > programs and not have -pthread...
>
> Because -pthread allows selection of one specific threadling library,
> not multiple.  It is also unnecessary since the library is specified
> as a link option, not a compiler option.  In the future, -pthread
> will be a NOOP, but it suits us now to have it cause an error so
> that ports that don't honor PTHREAD_LIBS can be found and fixed.

IF this is a good idea (and I'm not convinced it is), I still have two
major objections to it. First, this action was taken with very little
(any?) discussion. Second, the timing is truly horrible, occurring
during a ports freeze.

If your goal is actually to find and fix broken ports, there are a LOT
of other options, including enlisting volunteers, and using the package
building cluster.

I'd really like to see this change backed out, at minimum until the
ports freeze is over.

Doug

-- 

This .signature sanitized for your protection

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

Re: Fixing -pthreads (Re: ports and -current)

[Doug Barton]

On Sun, 21 Sep 2003, Daniel Eischen wrote:

> Well, actually it is directly related.  Part of the plan to
> transition to libpthread is making ports PTHREAD_LIBS compliant.
> As stated in that thread, if a libpthread exists on the system,
> autoconf/configure will pick it up and the port will also end up
> using -pthread and/or PTHREAD_LIBS.  If PTHREAD_LIBS is set
> to libthr or libc_r (something other than libpthread), then
> the port ends up linking to both libraries.  This doesn't work
> but you don't know it until your run the application and very
> weird things happen.  Causing a clean breakage is better because
> you know at compile-time that something is wrong.  So ports need to
> first be PTHREAD_LIBS compliant before we make the switch.  Soon
> after ports are fixed, we can rename it.

Where the ports are concerned, I think this is a reasonable course of
action, and I'd like to thank you for backing out the -pthread change on
HEAD. I am a little confused about one thing though. What is going to
happen to third party apps that use -pthread that aren't compiled
through the ports?

Doug

-- 

This .signature sanitized for your protection

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

Re: Fixing -pthreads (Re: ports and -current)

[Doug Barton]

On Sun, 21 Sep 2003, John Birrell wrote:

> On Sun, Sep 21, 2003 at 01:25:09AM -0700, Doug Barton wrote:
> > I am a little confused about one thing though. What is going to
> > happen to third party apps that use -pthread that aren't compiled
> > through the ports?
>
> They need to replace -pthread with their thread library of choice
> (e.g. -lc_r or -lpthread).

E...  I'm not sure this is an optimal solution. There is an awful
lot of software out there which expects -pthread to "just work."
Wouldn't it make more sense to default it to one thing or the other,
then make it configurable (isn't this what libmap.conf is supposed to
help with)?

Doug

-- 

This .signature sanitized for your protection

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

Re: Need to trim the disc1 packages

[Doug Barton]

On Sat, 29 Nov 2003, Scott Long wrote:

> All,
>
> We are badly overflowing the disc1 release ISO with packages, and need
> to trim it down.  One package that could easily get axed is the
> linux-netscape-communicator package.

I concur with that. For those of us who use linux netscape for whatever
reason (like me), the linux installer for netscape 7, available on
netscape's site, works just fine.

Doug

-- 

This .signature sanitized for your protection

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

Re: ports/net/mpd[45] broken with utmpx.h change

[Doug Barton]

On 2/15/2010 10:33 PM, Alexander Motin wrote:
> Andrey V. Elsukov wrote:
>> On 16.02.2010 4:51, Bernd Walter wrote:
>>> I don't know how difficult it is to fix, but for many of us mpd is
>>> important to have network connection.
>>
>> You can try this patch. I don't know why Alexander did't commit it.
> 
> I've committed it to mpd5 CVS repo. It will be present in next release soon.

If "soon" is not "in the next couple of days" my vote would certainly be
that you patch the port in place until the next mpd release is released.
Our users need working ports.


Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: bind fails with sig11 on start

[Doug Barton]

On 2/15/2010 1:39 PM, Bernd Walter wrote:
> [62]# uname -a
> FreeBSD  9.0-CURRENT FreeBSD 9.0-CURRENT #0 r203927: Mon Feb 15 19:12:36 CET 
> 2010 
> ti...@cicely14.cicely.de:/data/builder/arm-current/head/sys/arm/compile/FBOX  
> arm
> [64]# /etc/rc.d/named start
> Starting named.
> /etc/rc.d/named: WARNING: failed to start named
> 1.000u 0.000s 0:03.94 54.0% 7446+33509k 0+0io 17pf+0w
> Exit 1

Are you getting a core file? If so can you do a backtrace?

> [66]# cat /etc/rc.conf 
> hostname="Please.tell.me.who.am.I"

Bonus points here for not ending in .am. :)

> tmpmfs="AUTO"
> tmpsize="4m"
> tmpmfs_flags="-S -M"

FYI, that size of /tmp will probably not allow your periodic/weekly
process to generate a locate.database. IME you need a /tmp at least 2.5
times the size of that file in order for it to complete successfully.

> ntpdate_enable="YES"
> ntpdate_program="ntpdate"

IMO you'd be better off with a full path here, although this will
probably work for /usr/sbin/ntpdate. However you're actually better off
with the ntpd_sync_on_start option in any case.

> cloned_interfaces="vlan0 vlan1 vlan2 vlan3"
> ifconfig_vlan0="192.168.53.1/24 vlan 256 vlandev ate0"
> ifconfig_vlan1="vlan 257 vlandev ate0"
> ifconfig_vlan2="vlan 258 vlandev ate0"
> ifconfig_vlan3="vlan 259 vlandev ate0"

This is the only area that I have real questions about, since I haven't
done any work with vlans I'm not sure how named will respond to it. Is
it possible for you to try starting named with a plain vanilla network
setup?

> /etc/namedb isn't changed from distribution yet

Ok, since you're not chroot'ing it have you checked to make sure that
directory is populated? It shouldn't segfault even if it isn't, but nice
to cover all the bases.


hth,

Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: bind fails with sig11 on start / pthread failure on ARM?

[Doug Barton]

On 2/16/2010 10:39 AM, Bernd Walter wrote:
> [55]Please.tell.me.who.am.I# gdb /usr/sbin/named named.core 
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it and/or distribute copies of it under certain conditions.
> Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB.  Type "show warranty" for details.
> This GDB was configured as "arm-marcel-freebsd"...(no debugging symbols 
> found)...
> Core was generated by `named'.
> Program terminated with signal 5, Trace/breakpoint trap.
> Reading symbols from /lib/libcrypto.so.6...(no debugging symbols 
> found)...done.
> Loaded symbols for /lib/libcrypto.so.6
> Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done.
> Loaded symbols for /lib/libthr.so.3
> Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
> Loaded symbols for /lib/libc.so.7
> Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols 
> found)...done.
> Loaded symbols for /libexec/ld-elf.so.1
> #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
> [New Thread 20804280 (LWP 100062)]
> [New Thread 20804140 (LWP 100052)]
> (gdb) bt
> #0  0x203571b0 in _thread_bp_create () from /lib/libthr.so.3
> #1  0x203572b8 in _thread_bp_death () from /lib/libthr.so.3
> #2  0x20349da4 in pthread_create () from /lib/libthr.so.3
> #3  0x00164cb8 in ?? ()
> (gdb) 
> 
> Do we have a general threading problem on ARM?

Wow, that was fast. :)  It sure looks like that's the problem. Can you
try compiling ports/dns/bind96 without threads and see if that works for
you? If it does then it would be good to follow up on
freebsd-...@freebsd.org and see if the problem can be addressed.


Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: SUJ update

[Doug Barton]

On 05/03/10 06:19, sth...@nethelp.no wrote:
 I would vote for decoupling. If I have SU on, then enable journaling,
 then disable journaling, I would expect SU to still be on.
>>>
>>> Fully agreed. I see no reason why these sould be coupled.
>>
>> It does not look like it is a prerequisite to have SU enabled when you  
>> want to enable SUJ. So I assume SUJ implies SU, and as such I think  
>> you can agree that it is not easy to determine at disable time of SUJ,  
>> if the FS was SU before or not.
> 
> If SUJ requires SU then IMHO tunefs should prohibit setting SUJ unless
> SU was already enabled, with a nice explanatory error message if needed.

I agree, although I think it should be possible to specify both on the
same command line. At that point however the user would know what they
did, so they should be able to undo it appropriately.

I also don't want to bikeshed this to death. I imagine that once the
feature is stable that users will just twiddle it once and then leave it
alone, or it will be set at install time and then not twiddled at all. :)

> Looking at it from a slightly different angle - assume I have a file
> system with SU enabled, and I want to experiment with SUJ. So I enable
> SUJ. When I'm finished testing, maybe I want to disable SUJ again. I
> would be *highly surprised* (badly breaking POLA) if SU was disabled
> at the same time.
> 
>> So whatever the consensus is (disabling SUJ does or dosn't enable SU),  
>> the man page needs to tell what it does.
> 
> Agreed.
> 
> Steinar Haug, Nethelp consulting, sth...@nethelp.no
> ___
> 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"
> 



-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: Unable to establish HE gif0 tunnel

[Doug Barton]

Before I forget, I can't find the key that you signed this message with
on any key servers; FYI.

On 05/03/10 07:16, Mark Atkinson wrote:
> I updated a border gateway yesterday from a Feb 23 kernel to a May 2
> version kernel/world,

There have been numerous changes to IPv6 related stuff, both in the code
and in the rc.d configuration. Please make sure that your kernel, world,
AND /etc are all up to date.

> and lost my connectivity to my gif0 HE tunnel.

I'm sorry to hear that you're having trouble.

> I've been using the following in /etc/rc.conf successfully for some time
> to establish the tunnel:
> 
> # Hurricane Electric v6 tunnel
> ipv6_enable="YES"

FYI, this is now (basically) a no-op, you should be able to remove it
safely.

> gif_interfaces="gif0"
> gifconfig_gif0="[MY V4 ADDRESS] [HE V4 ADDRESS]"
> ifconfig_gif0="inet6 [MY V6 ENDPOINT] [HE V6 ENDPOINT] prefixlen 128"
> ipv6_defaultrouter="[HE V6 ENDPOINT]"
> 
> # v6 gateway
> ipv6_gateway_enable="YES"
> ipv6_network_interfaces="internal"
> ipv6_prefix_internal="[MY V6 /64 prefix]
> rtadvd_interfaces="internal"
> 
> Two problems:
> 
> * That seems to configure the tunnel, but it appears as 'tentative'.

Do this: ifconfig gif0 -ifdisabled

That should fix the problem with the tunnel. If it does, try changing
ifconfig_gif0 to ifconfig_gif0_ipv6 in rc.conf and let me know if that
fixes it for you.

> * the v6 EUI64 address on interface internal is not assigned as before

That was my fault, I just committed the fix in r207592. Sorry for the
hassle.


hth,

Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: [CFT]: ClangBSD is selfhosting, we need testers now - STATUS UPDATE

[Doug Barton]

On 05/05/10 10:13, Roman Divacky wrote:

> 2) mergemaster problems - I have a fix but have not commited it yet

Can you describe the problem, and your proposed fix?


Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: Recent sys/vm/ changes and nvidia-driver

[Doug Barton]

On 05/05/10 11:56, Alan Cox wrote:
>
> I'm afraid that I would advise waiting a few days.  This round of changes
> are not yet complete.

Is the coast clear yet? :)  I have been holding off on updating -current
due to the SUJ stuff, but that seems to have mostly settled down now, so
I'm hoping that the work on the VM won't prevent me from running
nvidia-driver.


Thanks,

Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: Recent sys/vm/ changes and nvidia-driver

[Doug Barton]

On 05/08/10 13:36, Alan Cox wrote:
> Doug Barton wrote:
>> On 05/05/10 11:56, Alan Cox wrote:
>>  
>>> I'm afraid that I would advise waiting a few days.  This round of
>>> changes
>>> are not yet complete.
>>> 
>>
>> Is the coast clear yet? :)  I have been holding off on updating -current
>> due to the SUJ stuff, but that seems to have mostly settled down now, so
>> I'm hoping that the work on the VM won't prevent me from running
>> nvidia-driver.
>>
>>   
> 
> No, it's still in a state of flux.

Ok, thanks for the info. I'm not going to pretend I understand what
you're doing, but it sure _looks_ exciting. :)


Doug

-- 

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

[Doug Barton]

On 5/26/2010 9:51 AM, Kostik Belousov wrote:


I did a quick glance over the driver, try this:
http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch
I did not even compiled the patched driver.


Kostik,

Thanks for taking a look at this! I sent the following to Alexey 
recently in regards to his query about whether or not the new version of 
the driver works. Maybe it will assist you:


Good news, it was a simple version bump to upgrade to 195.36.24. Bad 
news, no improvement. Under very light load (X11 using openbox, Alpine 
mail client) it lasted about an hour. As soon as I started adding more 
stress (firefox, flash, etc.) it wedged after about 30 minutes (total 
uptime, 90 minutes). This was still on the old kernel that I've been 
using in combination with 195.22:


FreeBSD dougb.net 9.0-CURRENT FreeBSD 9.0-CURRENT #3 r207134: Thu Apr 29 
23:14:20 PDT 2010  i386


The combination of the r207134 kernel and the 195.22 version of the 
driver has been very stable for me. If I try to go newer than that in 
either category I get lockups and/or panics.



hth,

Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

[Doug Barton]

On 05/26/10 09:51, Kostik Belousov wrote:

I did a quick glance over the driver, try this:
http://people.freebsd.org/~kib/misc/nvidia-vm_page_lock.1.patch
I did not even compiled the patched driver.


cc -pipe -g -g -g -DNV_VERSION_STRING=\"195.36.15\" -D__KERNEL__ -DNVRM 
-O -Werror -D_KERNEL -DKLD_MODULE -nostdinc  -I/src -I. -I@ 
-I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100 
--param large-function-growth=1000 -fno-common -g 
-mno-align-long-strings -mpreferred-stack-boundary=2  -mno-mmx 
-mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -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 nvidia_subr.c

cc1: warnings being treated as errors
nvidia_subr.c: In function 'nv_alloc_system_pages':
nvidia_subr.c:1306: warning: implicit declaration of function 'vm_page_lock'
nvidia_subr.c:1306: warning: nested extern declaration of 'vm_page_lock'
nvidia_subr.c:1308: warning: implicit declaration of function 
'vm_page_unlock'

nvidia_subr.c:1308: warning: nested extern declaration of 'vm_page_unlock'
*** Error code 1

FYI,

Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

Re: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and

[Doug Barton]

On 5/27/2010 12:12 PM, Kostik Belousov wrote:

I think you have stale/wrong includes used by the build. I just checked
that driver indeed builds with my patch. vm_page_lock() and vm_page_unlock()
are the macros defined in vm/vm_page.h that are present since first
Kip commit.


As I reported earlier, I am using an older kernel atm for stability 
reasons. I will try again with a more up to date kernel when time allows.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"

wpi not working on today's current (r208626)

[Doug Barton]

I am trying to update -current in order to try kib's patch for the 
nvidia driver, and the wpi driver won't establish a connection. I'm 
using r207134 right now without any problems, but that's a long time 
back to try and do a binary search.


I don't see any changes to wpi or wpa_supplicant between then and now, 
anyone have an idea of where to look? My WAP is using WPA2 with AES if 
that's any help.



Doug

--

... and that's just a little bit of history repeating.
-- Propellerheads

Improve the effectiveness of your Internet presence with
a domain name makeover!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"