Re: _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode

[Robert N. M. Watson]

On 13 Jun 2016, at 12:09, Joel Dahl  wrote:
> 
>> On Mon, Jun 13, 2016 at 07:00:46AM -0400, Ngie Cooper (yaneurabeya) wrote:
>> 
>>> On Jun 13, 2016, at 06:57, Joel Dahl  wrote:
>>> 
>>> Hi,
>>> 
>>> I've just rebuilt and installed latest current on a machine here. I noticed
>>> the following message in dmesg after a reboot:
>>> 
>>> _secure_path: cannot stat /etc/login.conf: Not permitted in capability mode
>>> 
>>> I don't remember seeing this before.
>> 
>> Hi Joe,
>>Try reverting r301867. Let Robert know if that fixes your issue.
> 
> Hi,
> 
> This is with r301857. Forgot to mention that in my previous mail. Sorry.

I can't see that these are in any way related to the error message. In fact, I 
saw the same login.conf message (and wondered about it) before committing the 
BSM fix. This sounds like an sshd or login issue? The former is more likely as 
I don't think the latter uses sandboxing.

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

Re: panic: rm_rlock: recursed on non-recursive rmlock mac_policy_rm @ /usr/src/sys/security/mac/mac_framework.c:198

[Robert N. M. Watson]

On 28 Sep 2013, at 19:32, Konstantin Belousov wrote:

 It easy to reproduce. Just kldload mac_portacl and /etc/rc.d/syslogd restart
 
 This is due to priv_check_cred() call in mac_portacl.c:rules_check().
 The call causes recusion into the mac framework from the mac callback.
 
 Robert should have better idea about the proper way to fix the issue.
 The trivial attempt might be to enable recursion on the rm lock
 protecting the lists.
 
 diff --git a/sys/security/mac/mac_framework.c 
 b/sys/security/mac/mac_framework.c
 index 816bb0b..ed0c05a 100644
 --- a/sys/security/mac/mac_framework.c
 +++ b/sys/security/mac/mac_framework.c
 @@ -292,7 +292,8 @@ mac_init(void)
   mac_labelzone_init();
 
 #ifndef MAC_STATIC
 - rm_init_flags(mac_policy_rm, mac_policy_rm, RM_NOWITNESS);
 + rm_init_flags(mac_policy_rm, mac_policy_rm, RM_NOWITNESS |
 + RM_RECURSE);
   sx_init_flags(mac_policy_sx, mac_policy_sx, SX_NOWITNESS);
 #endif
 }

Let's go with this -- recursion into the framework should be supported.

Robert
___
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: libreoffice build error

[S . N . Grigoriev]

19.09.2013, 04:02, Jung-uk Kim j...@freebsd.org:

 On 2013-09-18 13:20:27 -0400, Jung-uk Kim wrote:
 2013년  9월 18일 13:20, Jung-uk Kim 쓴 글: On 2013-09-18 12:39:46
 - -0400, David Chisnall wrote:

  On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org
  wrote:
  On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote:
  -BEGIN PGP SIGNED MESSAGE- Hash: SHA1

  On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote:
  I am still working on libc++ issues but it is much more
  complicated. :-(
  I fixed almost everything except for exception handling
  issues. Unfortunately, libc++/libcxxrt's exception handling
  is not 100% compatible with libstdc++'s and I couldn't find
  a proper fix. :-(

  Basically, C++/UNO bridge for LibreOffice/OpenOffice does
  some clever hacks, somewhat similar to the example on this
  blog page:

  http://zbigg.blogspot.com/2009/03/catch-on-g.html
  The definition of struct __cxa_exception doesn't match the one
  in /usr/include/c++/v1/cxxabi.h.  There's an extra field at
  the start in the __LP64__ case: uintptr_t referenceCount.
  This field is present in newer versions of the ABI spec and is
  also there in new versions of libsupc++.  It's required for
  implementing C++11 dependent exceptions.
  It shouldn't matter for code that doesn't allocate the structure
  (and nothing outside of libsupc++ / libcxxrt should be
  allocating them), because these structures are always passed
  around by pointers to their ends (where the _Unwind_Exception
  structure lives).
  Ah, I see.  Now I wrote a proper fix and it looks very promising.
  :-)

 Committed:

 http://svnweb.freebsd.org/changeset/ports/327589

 Thanks!

 Jung-uk Kim

 * PS: IMHO, the ABI compatibility issue must be fixed before 10.0.
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.21 (FreeBSD)


Thanks for your commit! Now Libreoffice builds and works fine.

-- 
Regards,
S.Grigoriev.
___
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

libreoffice build error

[S . N . Grigoriev]

Hi list,

the following error occures when I try to build editors/libreoffice:

[build CXX] sal/rtl/source/ustrbuf.cxx
In file included from 
/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sal/rtl/source/bootstrap.cxx:22:
In file included from 
/usr/ports/editors/libreoffice/work/solver/unxfbsd.pro/inc/rtl/bootstrap.hxx:21:
In file included from 
/usr/ports/editors/libreoffice/work/solver/unxfbsd.pro/inc/rtl/ustring.hxx:26:
In file included from /usr/include/c++/v1/ostream:130:
In file included from /usr/include/c++/v1/ios:216:
In file included from /usr/include/c++/v1/__locale:15:
In file included from /usr/include/c++/v1/string:434:
In file included from /usr/include/c++/v1/algorithm:627:
/usr/include/c++/v1/memory:1616:18: error: no matching member function for call 
to 'construct'
{__a.construct(__p, _VSTD::forward_Args(__args)...);}
 ^
/usr/include/c++/v1/memory:1497:14: note: in instantiation of function template 
specialization 
'std::__1::allocator_traitsrtl::Allocatorstd::__1::__list_nodertl_bootstrap_NameValue,
 void *  ::__constructrtl_bootstrap_NameValue, const 
rtl_bootstrap_NameValue ' requested here
{__construct(__has_constructallocator_type, pointer, _Args...(),
 ^
/usr/include/c++/v1/list:1499:26: note: in instantiation of function template 
specialization 
'std::__1::allocator_traitsrtl::Allocatorstd::__1::__list_nodertl_bootstrap_NameValue,
 void *  ::constructrtl_bootstrap_NameValue, const rtl_bootstrap_NameValue 
' requested here
__node_alloc_traits::construct(__na, _VSTD::addressof(__hold-__value_), 
__x);


Any tips?

-- 
Regards,
S.Grigoriev.
___
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: libreoffice build error

[S . N . Grigoriev]

17.09.2013, 21:27, Jung-uk Kim j...@freebsd.org:

 On 2013-09-17 11:52:45 -0400, Baptiste Daroussin wrote:

  On Tue, Sep 17, 2013 at 11:51:41AM -0400, Shawn Webb wrote:
  I'm getting a build error as well, but on 9-STABLE under
  Poudriere. Relevant part of the logfile:

  In file included from
  
 /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sc/source/core/tool/scmatrix.cxx:34:

 In file included from /usr/local/include/mdds/multi_type_matrix.hpp:31:

  /usr/local/include/mdds/multi_type_vector.hpp:85:46: error:
  cannot initialize a parameter of type
  'mdds::mtv::base_element_block *' with an lvalue of type 'const
  element_block_type *' (aka 'const mdds::mtv::base_element_block
  *') element_block_func::delete_block(p); ^
  /usr/local/include/boost/interprocess/smart_ptr/unique_ptr.hpp:312:13:

 note: in instantiation of member function

  
 'mdds::multi_type_vectorcustom_string_trait::element_block_func::element_block_deleter::operator()'

 requested here

  ptr_.second()(ptr_.first()); ^
  /usr/local/include/boost/interprocess/smart_ptr/unique_ptr.hpp:196:7:

 note: in instantiation of member function

  'boost::interprocess::unique_ptrmdds::mtv::base_element_block,
  
 mdds::multi_type_vectorcustom_string_trait::element_block_func::element_block_deleter::reset'

 requested here

  {  reset(); } ^
  /usr/local/include/mdds/compat/unique_ptr.hpp:38:7: note: in
  instantiation of member function
  'boost::interprocess::unique_ptrmdds::mtv::base_element_block,
  
 mdds::multi_type_vectorcustom_string_trait::element_block_func::element_block_deleter::~unique_ptr'

 requested here

  class unique_ptr : public boost::interprocess::unique_ptr_T,
  _Deleter ^
  /usr/local/include/mdds/multi_type_vector_def.inl:2376:16: note:
  in instantiation of function template specialization
  
 'mdds::multi_type_vectorcustom_string_trait::element_block_func::set_cells_to_single_blockconst

 double *' requested here

  return set_cells_to_single_block(row, end_row, block_index1,
  start_row1, it_begin, it_end); ^
  /usr/local/include/mdds/multi_type_vector_def.inl:406:12: note:
  in instantiation of function template specialization
  
 'mdds::multi_type_vectorcustom_string_trait::element_block_func::set_cells_implconst

 double *' requested here

  return set_cells_impl(pos, end_pos, start_row1, block_index1,
  it_begin, it_end); ^
  /usr/local/include/mdds/multi_type_matrix_def.inl:239:13: note:
  in instantiation of function template specialization
  
 'mdds::multi_type_vectorcustom_string_trait::element_block_func::setconst

 double *' requested here

  m_store.set(get_pos(row,col), it_begin, it_end); ^
  
 /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sc/source/core/tool/scmatrix.cxx:502:15:

 note: in instantiation of function template specialization

  'mdds::multi_type_matrixcustom_string_trait::setconst double
  *' requested here maMat.set(nR, nC, pArray, pArray + nLen); ^
  
 /wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sc/source/core/tool/scmatrix.cxx:92:65:

 note: passing argument to parameter 'p' here

  static void delete_block(mdds::mtv::base_element_block* p) ^ 1
  error generated. gmake[2]: ***
  
 [/wrkdirs/usr/ports/editors/libreoffice/work/workdir/unxfbsd.pro/CxxObject/sc/source/core/tool/scmatrix.o]

 Error 1

  That is the mdds error I was speaking about.

 The mdds issue should be fixed by r327493.  I am still working on
 libc++ issues but it is much more complicated. :-(

 Jung-uk Kim


Thanks for all responses. As I can see the problem is much more complete then I 
thought initially.
-- 
Regards,
S.Grigoriev.
___
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: No gcc by default in -HEAD on platforms where clang is cc

[S . N . Grigoriev]

13.09.2013, 01:11, Dimitry Andric d...@freebsd.org:
 On Sep 12, 2013, at 21:47, S.N.Grigoriev serguey-grigor...@yandex.ru wrote:

  after upgrading to r255423 (make buildworld  make buildkernel  make 
 installkernel  make installworld  reboot; make delete-old  make 
 delete-old-libs) I cannot build the system with the WITH_GCC=yes and 
 WITH_GNUCXX=yes options in my src.conf. The following error occures:

  --- libgssapi_krb5.so.10 ---
  building shared library libgssapi_krb5.so.10
  --- gnu/lib__L ---
  /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:3: 
 error: use of undeclared identifier '_List_node_base'
   _List_node_base::swap(_List_node_base __x, _List_node_base __y)
   ^

 I just sent a mail to re@ to get approval for a fix for this.  In the
 mean time, please apply the attached patch.

 -Dimitry

 ,

Hi Dimitry,

thank you for your response. Your patch works for me!

-- 
Regards,
S.Grigoriev.
___
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: No gcc by default in -HEAD on platforms where clang is cc

[S . N . Grigoriev]

Hi list,

after upgrading to r255423 (make buildworld  make buildkernel  make 
installkernel  make installworld  reboot; make delete-old  make 
delete-old-libs) I cannot build the system with the WITH_GCC=yes and 
WITH_GNUCXX=yes options in my src.conf. The following error occures:

--- libgssapi_krb5.so.10 ---
building shared library libgssapi_krb5.so.10
--- gnu/lib__L ---
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:3: error: 
use of undeclared identifier '_List_node_base'
  _List_node_base::swap(_List_node_base __x, _List_node_base __y)
  ^
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:25: error: 
use of undeclared identifier '_List_node_base'; did you mean '__list_node_base'?
  _List_node_base::swap(_List_node_base __x, _List_node_base __y)
^~~
__list_node_base
/usr/obj/usr/src/tmp/usr/include/c++/v1/list:190:8: note: '__list_node_base' 
declared here
struct __list_node_base
   ^
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:25: error: 
no template named '_List_node_base'; did you mean '__list_node_base'?
  _List_node_base::swap(_List_node_base __x, _List_node_base __y)
^~~
__list_node_base
/usr/obj/usr/src/tmp/usr/include/c++/v1/list:190:8: note: '__list_node_base' 
declared here
struct __list_node_base
   ^
/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc:61:25: error: 
use of class template '__list_node_base' requires template arguments
  _List_node_base::swap(_List_node_base __x, _List_node_base __y)
^
/usr/obj/usr/src/tmp/usr/include/c++/v1/list:190:8: note: template is declared 
here
struct __list_node_base
   ^

Without options listed above all works fine.

-- 
Regards,
Serguey.
___
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] migrate lagg to an rmlock

[Robert N. M. Watson]

On 24 Aug 2013, at 17:36, Alfred Perlstein wrote:

 We should distinguish lock contention from line contention. When 
 acquiring a rwlock on multiple CPUs concurrently, the cache lines used to 
 implement the lock are contended, as they must bounce between caches via the 
 cache coherence protocol, also referred to as contention.  In the if_lagg 
 code, I assume that the read-only acquire of the rwlock (and perhaps now 
 rmlock) is for data stability rather than mutual exclusion -- e.g., to allow 
 processing to completion against a stable version of the lagg configuration. 
 As such, indeed, there should be no lock contention unless a configuration 
 update takes place, and any line contention is a property of the locking 
 primitive rather than data model.
 
 There are a number of other places in the kernel where migration to an 
 rmlock makes sense -- however, some care must be taken for four reasons: (1) 
 while read locks don't experience line contention, write locking becomes 
 observably e.g., rmlocks might not be suitable for tcbinfo; (2) rmlocks, 
 unlike rwlocks, more expensive so is not suitable for all rwlock line 
 contention spots -- implement reader priority propagation, so you must 
 reason about; and (3) historically, rmlocks have not fully implemented 
 WITNESS so you may get less good debugging output.  if_lagg is a nice place 
 to use rmlocks, as reconfigurations are very rare, and it's really all about 
 long-term data stability.
 
 Robert, what do you think about a quick swap of the ifnet structures to 
 counter before 10.x?

Could you be more specific about the proposal you're making?

Robert
___
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: A PRIV_* flag for /dev/mem?

[Robert N. M. Watson]

On 16 Jun 2013, at 23:48, Kirk McKusick wrote:

 I suppose it's safe to say further comment isn't forthcoming. So with
 one vote for and one against (or at least questioning), I'll humbly
 leave it up to myself to be the tie-breaker :-).
 
 Here's a proposed patch. I separate kmem access into read and write, as
 I saw other similar splits in the priv list. Perhaps that's overkill,
 and I can use a single PRIV_KMEM instead of PRIV_KMEM_READ and
 PRIV_KMEM_WRITE.
 
 Perhaps this is an overreach, because PRIV_KMEM_READ is used where the
 default isn't root privilege: the file permission and expected usage are
 group kmem gets to read /dev/[k]mem. I'm not about to go hard-coding a
 gid into the kernel, so it seems the proper thing to do (not included in
 the patch) would be to allow PRIV_KMEM_READ by default. I thought there
 might already be such cases where the default is to allow, but no: this
 would be the first default-allow permission. So perhaps the best answer
 is not worry about that one, and only add PRIV_KMEM_WRITE (leaving reads
 controlled by file permission alone as they are now).
 
 With the change from the error noted by Kostik, I concur with your 
 proposed change.

On the whole, the kernel privilege system is fairly straight-forward; the one 
real exception its its interaction with device-driver specific interfaces that 
seem privilege-like. On the whole, I take the view that we should define 
privileges in device drivers where either (a) there's a securelevel interaction 
or (b) it's likely we'll want to delegate access to the device node (perhaps in 
jail, or via chmod/chown) but there are special operations we still want to 
require privilege. For example, you could imagine wanting read/write access to 
a disk to be delegated, but not control operations to reset the bus it's on -- 
e.g., not wanting that to occur in jail.  /dev/kmem is particularly funky, 
since it inherently bypasses most aspects of the TCB -- even read access is 
quite dangerous, although not quite as overtly dangerous as write access. I'm 
not sure I see a strong argument for introducing further privileges here, as 
it's hard to imagine a situation where you'd delegate kmem a
 ccess and not mean to give out vast amounts of privilege. The main argument 
for doing so would be that we wanted to pull securelevel checks inside of 
priv(9), sucking awareness of securelevels out of most consumer subsystems.

More generally, there are many implied sources of privilege in the system that 
don't go through priv(9) -- for example, uid 0 is not just privileged because 
it is granted rights by priv(9), but also because it owns lots of key files in 
the file system and can read/write them (e.g., the password file). You can 
similarly argue that although aspects of the TCB are protected by priv(9), 
others are protected by DAC (or optionally MAC). This is simply an unclean 
bit of the UNIX design, and something we end up accepting because the notion of 
TCB protection generally does involve some lack of cleanliness, since it has to 
do with protecting low-level parts of the system that aren't easily abstracted 
away (e.g., device drivers).

Robert
___
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: panic: in_pcblookup_local (?)

[Robert N. M. Watson]

On 2 May 2013, at 01:57, Glen Barber wrote:

 So, I am admittedly not too familiar with DDB.  In fact, I just now
 realize the kernel is built without DDB...

DDB is a very powerful tool in that it's been custom-developed to help debug 
common kernel panics. It lacks some of the flexibility, and especially the 
data-type awareness of GDB, but GDB is a less well-suited tool when 
investigating common crash patterns. I'll usually start out debugging in DDB, 
and find that 90% of my in-development panics can be debugged with it, 
resorting to GDB for post-mortem analyses in production or particularly hard 
debugging cases (usually where DDB's pretty printers for data types fall 
short). I've wanted, for a long time, to teach DDB how to pretty-print 
arbitrary types using DTrace's CTF meta-data, which would address the most 
significant major case where I turn to GDB. Mind you, the limitations I see in 
GDB are made up for in most part by John's GDB scripts :-).

 Put those in a dir and do 'source gdb6'.  You can then run 'ps' to get a 
 good 
 ps listing that includes threads.  You can also use 'thread apply all bt' to 
 get stacktraces of all threads in kgdb.  I believe there is an 'allpcpu' 
 command that is similar to 'show allpcpu' in DDB.
 
 I have the outputs of 'ps', 'allpcpu', and 'thread apply all bt' saved
 to separate script(1) files.  Is there anything in particular I can look
 for before uploading the files somewhere public?  At quick-ish look
 though, I did not see anything cf-agent (the current process at time of
 panic) related.

To be honest, it's probably easiest if I just take a look at it and see what I 
see. In as much as I find interesting things, I'll follow up explaining what 
they are. We may find we can't track this problem down from the data we have -- 
but it's worth a try.

Robert
___
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: panic: in_pcblookup_local (?)

[Robert N. M. Watson]

On 2 May 2013, at 11:42, Glen Barber wrote:

 Hmm.  Perhaps it would be worthwhile for me to rebuild the current
 kernel with DDB support.  It looks like the machine has panicked a few
 times over the last two weeks or so, but based on the timestamps of the
 crash dumps and nagios complaints, happened during the middle of the
 night when I would not have really noticed, or otherwise would have just
 blamed my ISP.
 
 Two of the panics are ath(4) related.  One looks similar to the one
 referenced in this thread, similarly triggered by a CFEngine process.
 
 In that case, the backtrace looks like:
 
 #4 0x808cdbb3 at calltrap+0x8
 #5 0x807371d8 at in_pcb_lport+0x128
 #6 0x8073745a at in_pcbbind_setup+0x16a
 #7 0x80737d8e at in_pcbconnect_setup+0x71e
 #8 0x80737df9 at in_pcbconnect_mbuf+0x59
 #9 0x807bf29f at udp_connect+0x11f
 #10 0x80680615 at kern_connectat+0x275
 
 Regarding DDB though, it would be rather difficult to access the machine
 if it drops to a DDB debugger session, since the machine acts as my
 firewall.

Thanks -- will take a look at the attached.

FWIW, though, I'm worried by the number of panics you are seeing, especially 
given that they involve multiple subsystems, and in particular, John's 
observation about a potentially corrupted pointer. This makes me wonder whether 
(a) you are experiencing hardware faults -- it would be worth running some 
memory/cpu/etc tests and (b) if we might be seeing a software memory corruption 
bug of some sort.

Robert
___
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: panic: in_pcblookup_local (?)

[Robert N. M. Watson]

On 1 May 2013, at 16:56, John Baldwin wrote:

 It looks like the ipi_hash_lock is locked (and udp_connect() locks it), so I 
 think the offending code is somewhere else.  Also, I can't find anything that
 removes an inp without hold the correct pcbinfo lock.  Only thing I can think
 of is if the pcbinfo pointer for an inp could change, so we could maybe
 lock the wrong one while removing it?
 
 Hmm, you know.  In in_pcbremlists() and in_pcbdrop(), we read inp_phd 
 without holding the hash lock. I think that probably don't actaully break
 anything, but this feels like a locking issue of some sort.

I'll need to catch up on this thread later, but a few questions:

Do we know if the application in question is multithreaded, and if so, might it 
be attempting concurrent operations on this socket?

The corrupted pointer is worrying ... but interesting, and suggests something 
else is going on here -- stack corruption earlier in the system call, perhaps?

In general, to modify our various hash lists you must lock both the inpcb and 
the list. It's therefore sufficient to hold either lock to read, so reading 
inp_phd should be OK with the inpcb lock held, even without the hash lock held.

Do we have a dump of *inp, and if so, can we confirm that the inpcb is still 
properly referenced, if there is an associated socket, likewise a dump of 
*inp-inp_socket to check things are properly referenced there?

Robert
___
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: panic: in_pcblookup_local (?)

[Robert N. M. Watson]

On 1 May 2013, at 19:03, Glen Barber wrote:

 I'll need to catch up on this thread later, but a few questions:
 
 Do we know if the application in question is multithreaded, and
 if so, might it be attempting concurrent operations on this socket?
 
 I do not know if zabbix-agent is multithreaded, but cf-agent is.

If in DDB, it would be useful to do a ps so we can identify threads in the 
process, and in particular, whether they might be in the kernel around the 
moment of the panic.

 I will follow up with this information as soon as possible.

Thanks. Do keep around as much information as you can from DDB, crashdumps, 
etc. A useful set of things to keep from DDB includes the initial panic 
information and trap frame, show pcpu, show allpcpu, trace, alltrace, 
ps, and if WITNESS is compiled in, show locks and show alllocks. On busy 
systems, all the backtraces add up to a lot of space, so you might hold onto 
that rather than e-mail it, but contain useful information. Often, debugging 
this sort of race condition involves looking at what other network-centred 
threads are doing -- e.g., device-driver ithreads, netisr, other involved user 
threads. You may be able to extract much of that information using ps on the 
crashdump (not sure if procstat is there yet for crashdumps) -- if so, be sure 
to use -H (or whatever the argument is to print thread, not just process, 
information).

Off to a formal dinner, but back later!

Robert
___
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: please add auditdistd user/group to -stable and the 9.1-release?

[Robert N. M. Watson]

My intuition (hope) is that 9.1 is past the point of no return on builds and so 
that boat has been missed; however, my plan is to MFC the auditdistd user to 
stable/8 and stable/9 after the 3-day MFC timeout. If Ken thinks builds have 
yet to start on the final 9.1 image, however, then I'm happy to merge to there 
as well.

Brooks Davis has a work-in-progress port of the NetBSD mtree (etc) to FreeBSD 
that will hopefully be merged soon, and allow improved cross-install 
experiences. This is something 9.1 users will benefit from as it can be done 
entirely in the cross-build/install tools rather than requiring host changes. 
In the longer term, these changes are necessary to not only allow more diverse 
cross-builds on FreeBSD, but also to allow builds from other OS's, where add 
FreeBSD's auditdistd user makes no sense at all.

Robert

On 3 Dec 2012, at 05:08, Adrian Chadd wrote:

 Hi,
 
 Would you guys please add the auditdistd user/group info to
 9.1-release, so people doing crossbuilds of -HEAD on a fresh
 9.1-RELEASE won't get an install error?
 
 Thanks,
 
 
 Adrian

___
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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

[Robert N. M. Watson]

On 2 Dec 2012, at 14:21, Fbsd8 wrote:

 I've now committed the build glue required to install the recently merged 
 Audit Distribution Daemon (auditdistd) contributed by the Pawel Dawidek, and 
 sponsored by the FreeBSD Foundation.  This allows individual hosts 
 generating audit trails to submit trails to a central audit server for 
 review and safe keeping.  Part of the goal is to ensure that a host 
 submitting trail data can't later modify the trails.  Pawel uses a variety 
 of useful security- and resilience-related features such as TLS, Capsicum, 
 etc, in auditdistd.  As the recent security incident in the FreeBSD.org 
 cluster illustrated, having reliable and detailed audit trails makes a big 
 difference in forensic work, and hopefully this will allow the FreeBSD 
 Project (and our users) to do that better in the future.
 
 Is auditdistd going to be included in the base system as of 10.0-RELEASE
 or be a port that runs on 10.0-RELEASE and newer?

The plan is that auditdistd will be included in the base operating system for 
FreeBSD 10.0, and it is now integrated into the development branch that will 
naturally lead to that outcome; I would like to get it merged to stable/9 for 
inclusion in a future 9.2 release as well, but that will require a bit more 
work. I'll plan to let it shake out in 10-CURRENT for at least a few weeks, and 
let more users report on their experiences, before looking at a merge to 9.x.

Robert

___
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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))

[Robert N. M. Watson]

On 2 Dec 2012, at 15:34, Ryan Stone wrote:

 On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson rwat...@freebsd.org wrote:
 
 Just to follow up on this thread, since the question has come up a number of 
 times.  mergemaser -p should be run prior to installworld always, but most 
 of the time will do very little.  One of its responsibilities is to add any 
 necessary accounts and groups depended on by base system components -- e.g., 
 that will be referenced during installworld as part of setting file ownership 
 and groups.
 
 I often use make installworld installkernel distribution DESTDIR=... to 
 create bootable images (e.g. for a USB stick).  What's the recommendation for 
 that case?  Manually create the auditdistd user on the build host?

Yes, that's probably the best short-term bet.

In the longer term, it would be nice of installworld could not only generate an 
mtree on the side rather than directly chmod/chowning the files (Brooks Davis 
has patches for this), but also use UIDs/GIDs from a user database directly 
rather than assuming that the host where you are constructing the image has the 
same notion of users and groups. This is especially important if we want to 
support cross-building embedded images from Linux, Mac OS X, etc, in the future.

Robert
___
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: sysctl filesystem ?

[Robert N. M. Watson]

On 26 Jun 2012, at 15:42, m...@freebsd.org wrote:

 While I understand the problems you allude to, the sysctl(8) binary
 can protect itself from them.  IMO the biggest problem with sysctls
 not being files is that it makes no sense from the core UNIX
 philosophy that everything is a file.  Sockets and pipes and character
 devices and even unseekable things like stdout are files; why aren't
 these other objects that allow read, write, and have their own
 namespace?


I think I agree with what you're saying, subject to one modification: rather 
than saying files, say file descriptors, which are not quite the same but 
are, I think, what you mean. This doesn't mean you end up with a special file 
system mounted on /foo -- we don't do that for sockets or pipes --- but rather, 
we end up with using a similar object-oriented interface. And hence, BTW, our 
recent experimental addition of process descriptors to the API in support of 
Capsicum. However, I wonder how well that applies to sysctls, which unlike 
pipes/sockets, don't have an event model, etc...

Robert___
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: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server

[N V]

21.12.2011, 04:28, O. Hartmann ohart...@zedat.fu-berlin.de:
 On 12/21/11 00:29, Jeremy Chadwick wrote:

  On Tue, Dec 20, 2011 at 11:54:23PM +0100, O. Hartmann wrote:
  On 12/20/11 22:45, Samuel J. Greear wrote:
  http://www.osnews.com/story/25334/DragonFly_BSD_MP_Performance_Significantly_Improved

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

  Sam

  On Tue, Dec 20, 2011 at 1:20 PM, Igor Mozolevsky 
 i...@hybrid-lab.co.ukwrote:
  Interestingly, while people seem to be (arguably rightly) focused on
  criticising Phoronix's benchmarking, nobody has offered an alternative
  benchmark; and while (again, arguably rightly) it is important to
  benchmark real world performance, equally, nobody has offered any
  numbers in relation to, for example, HTTP or SMTP, or any other real
  world-application torture tests done on the aforementioned two
  platforms... IMO, this just goes to show that doing is hard and
  criticising is much easier (yes, I am aware of the irony involved in
  making this statement, but someone has to!)

  Cheers,
  Igor M :-)
  ___
  freebsd-current@freebsd.org mailing list
  http://lists.freebsd.org/mailman/listinfo/freebsd-current
  To unsubscribe, send any mail to 
 freebsd-current-unsubscr...@freebsd.org
  Thanks for those numbers.
  Impressive how Matthew Dillon's project jumps forward now. And it is
  still impressive to see that the picture is still in the right place
  when it comes to a comparison to Linux.
  Also, OpenIndiana shows an impressive performance.
  Preface to my long post below:

  The things being discussed here are benchmarks, as in how much work
  can you get out of Thing.  This is VERY DIFFERENT from testing
  interactivity in a scheduler, which is more of a test that says when
  Thing X is executed while heavier-Thing Y is also being executed, how
  much interaction is lost in Thing X.

  The reason people notice this when using Xorg is because it's visual,
  in an environment where responsiveness is absolutely mandatory above all
  else.  Nobody is going to put up with a system where during a buildworld
  they go to move a window or click a mouse button or type a key and find
  that the window doesn't move, the mouse click is lost, or the key typed
  has gone into the bit bucket -- or, that those things are SEVERELY
  delayed, to the point where interactivity is crap.

 I whitnessed sticky, jumpy and non-responsive-for seconds FreeBSD
 servers (serving homes, NFS/SAMBA and PostgreSQL database (small)).
 Those seconds where enough to cut a ssh line. Not funny. Network
 traffic droped significantly. X/Desktop makes the problem visible,
 indeed. But not seeing it does not mean it isn't there.
 This might be the reason why FreeBSD is so much behind when it comes to X?


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

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


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

Re: extattr_set_*() return type

[Robert N. M. Watson]

On 21 Dec 2011, at 15:31, John Baldwin wrote:

 On Tuesday, December 20, 2011 5:18:58 pm m...@freebsd.org wrote:
 On Tue, Dec 20, 2011 at 1:49 PM, John Baldwin j...@freebsd.org wrote:
 Hmm, if these functions are expected to operate like 'write(2)' and are
 supposed to return the number of bytes written, shouldn't their return value
 be 'ssize_t' instead of 'int'?  It looks like the system calls themselves
 already do the right thing in setting td_retval[] (they assign a ssize_t to 
 it
 and td_retval[0] can hold a ssize_t on all of our current platforms).  It
 would seem that the only change would be to the header and probably
 syscalls.master.  I guess this would require a symver bump to fix though.
 
 An extended attribute larger than 2GB is a programming abuse, though.
 Technically int may not be 32 bits but it is on all supported
 platforms now.
 
 Today it is an abuse.  In the 90's a 64-bit off_t was considered an abuse by
 some. :)
 
 The type should match the documented behavior.  On OS X the set operation
 doesn't return a size but instead returns a simple success/failure (0 or -1)
 for which an int is appropriate.  However, the FreeBSD API documents that it
 operates like write and consumes the buffer.   Note that the size of the
 buffer passed to the 'set' and 'get' operations is a size_t, not an int, and
 the 'get' operations already return a ssize_t, not an int.


Using an int was probably a bug. If we can switch to a ssize_t without undue 
disruption, it seems worthwhile to do so. There was never EA API 
standardisation, and it might be worth pondering whether to pick up additional 
API variants matching Mac OS X or Linux (note that they differ from each other 
even!).

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

FreeBSD-9.0-BETA1-i386-bootonly

[N V]

Hi.

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

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

Re: [poll / rfc] kdb_stop_cpus

[Robert N. M. Watson]

On 4 Jun 2011, at 09:22, Andriy Gapon wrote:

 on 03/06/2011 20:57 Robert N. M. Watson said the following:
 
 On 3 Jun 2011, at 16:13, Andriy Gapon wrote:
 
 I wonder if anybody uses kdb_stop_cpus with non-default value. If, yes, I
 am very interested to learn about your usecase for it.
 
 The issue that prompted the sysctl was non-NMI IPIs being used to enter the
 debugger or reboot following a core hanging with interrupts disabled. With
 the switch to NMI IPIs in some of those circumstances, life is better -- at
 least, on hardware that supports non-maskable IPIs. I seem to recall sparc64
 doesn't, however?
 
 Seems to be so as Nathan has also pointed out for PPC.
 For this I also plan the following change:
 
 commit 458ebd9aca7e91fc6e0825c727c7220ab9f61016
 
generic_stop_cpus: move timeout detection code from under DIAGNOSTIC
 
... and also increase it a bit.
IMO it's better to detect and report the (rather serious) condition and
allow a system to proceed somehow rather than be stuck in an endless
loop.

Agreed on detecting and reporting. It would be good to confirm that it works in 
practice, however, and also that there are no false positives. I'm not sure 
what the best test scenarios are for that.

Robert

___
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

Divert socket problem (was: Re: svn commit: r222488 - in head/sys: contrib/pf/net netinet netinet/ipfw netinet6)

[Robert N. M. Watson]

On 4 Jun 2011, at 15:30, Kristof Provost wrote:

 div_bind probably also needs to surround the call to in_pcbbind with
 INP_HASHW(UN)LOCK(...)
 
 I'm currently running 222680. I've only now seen the issue, but I've also
 just now activated INVARIANTS.

Hi Kristof:

Thanks for the detailed report, and yes, it looks like that is exactly what is 
required. Could you try the attached patch?

Robert



20110604-divert-fix.diff
Description: Binary data
___
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: [poll / rfc] kdb_stop_cpus

[Robert N. M. Watson]

On 3 Jun 2011, at 16:13, Andriy Gapon wrote:

 I wonder if anybody uses kdb_stop_cpus with non-default value.
 If, yes, I am very interested to learn about your usecase for it.

The issue that prompted the sysctl was non-NMI IPIs being used to enter the 
debugger or reboot following a core hanging with interrupts disabled. With the 
switch to NMI IPIs in some of those circumstances, life is better -- at least, 
on hardware that supports non-maskable IPIs. I seem to recall sparc64 doesn't, 
however? Not sure about MIPS, etc. Attilio has since significantly improved our 
shutdown behaviour -- initially, the switch to NMI IPIs broke other things 
(because certain IPIs then improperly preempted threads holding spinlocks), but 
that pretty much all seems worked out now.

Robert

 
 I think that the default kdb behavior is the correct one, so it doesn't make 
 sense
 to have a knob to turn on incorrect behavior.
 But I may be missing something obvious.
 
 The comment in the code doesn't really satisfy me:
 /*
 * Flag indicating whether or not to IPI the other CPUs to stop them on
 * entering the debugger.  Sometimes, this will result in a deadlock as
 * stop_cpus() waits for the other cpus to stop, so we allow it to be
 * disabled.  In order to maximize the chances of success, use a hard
 * stop for that.
 */
 
 The hard stop should be sufficiently mighty.
 Yes, I am aware of supposedly extremely rare situations where a deadlock could
 happen even when using hard stop.  But I'd rather fix that than have this 
 switch.
 
 Oh, the commit message (from 2004) explains it:
 Add a new sysctl, debug.kdb.stop_cpus, which controls whether or not we
 attempt to IPI other cpus when entering the debugger in order to stop
 them while in the debugger.  The default remains to issue the stop;
 however, that can result in a hang if another cpu has interrupts disabled
 and is spinning, since the IPI won't be received and the KDB will wait
 indefinitely.  We probably need to add a timeout, but this is a useful
 stopgap in the mean time.
 
 But that was before we started using hard stop in this context (in 2009).
 
 -- 
 Andriy Gapon

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

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

[N V]

Hello.

Don't know is this related.

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

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

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

Regards.


26.04.2011, 12:04, Matthias Apitz g...@unixarea.de:
 Hello,

 I'm trying to compile /usr/ports/mail/evolution-exchange/ and the gcc
 crashes with:

 [root@vm-9Current /usr/ports/mail/evolution-exchange]#  LANG=C make
 ===  Building for evolution-exchange-2.32.1_1
 gmake  all-recursive
 gmake[1]: Entering directory
 `/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1'
 Making all in server
 gmake[2]: Entering directory
 `/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1/server'
 Making all in xntlm
 gmake[3]: Entering directory
 `/usr/ports/mail/evolution-exchange/work/evolution-exchange-2.32.1/server/xntlm'
   CC libxntlm_la-xntlm.lo
 cc1: internal compiler error: Segmentation fault: 11

 Some notes about this:
 - the system runs in a VMworkstation 7.x
 - it has already compliled kernel, userland and ~1000 ports without any
   crash, i.e. it is *not* the typical hardware related crash;
 - the above mentioned version evolution-exchange-2.32.1_1 is a fake, in
   real it is compiling the original evolution-exchange-2.32.3 sources;
 - it is fully reproduceable

 What next?
 (David, should it be posted to evolut...@gnome.org as well?)

 matthias

 --
 Matthias Apitz
 t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211
 e g...@unixarea.de; - w http://www.unixarea.de/
 ___
 freebsd-current@freebsd.org mailing list
 http://lists.freebsd.org/mailman/listinfo/freebsd-current
 To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: ACL issue (Was Re: HEADS UP: ZFSv28 is in!)

[Robert N. M. Watson]

On 6 Mar 2011, at 16:30, Jeremy Chadwick wrote:

 2. Are you absolutely 100% sure the kernel you're using was built
   with options UFS_ACL defined in it?  Doing a strings -a
   /boot/kernel/kernel | grep UFS_ACL should suffice.
 
 
 Yep, it does:
 
 % strings -a /boot/kernel/kernel | grep UFS_ACL
 options UFS_ACL
 
 (My kernel config is just include GENERIC then a bunch of nooptions
 for KDB, DDB, GDB, INVARIANTS, WITNESS, etc.)
 
 Cool, good to rule out the obvious.  Thanks.
 
 The only other thing I can think of off the top of my head would be to
 ktrace -t+ -i the cp -p, then provide output of kdump -s -t+ after.
 I wouldn't say go about this quite yet (it may not even help determine
 what's going on); maybe wait for Robert to take a look first.
 
 It would help if I actually added Robert to the CC list, wouldn't it?
 :-)

There's a lot of information in that post, perhaps it would be useful for 
someone to clarify what's going on exactly. If you're using ACLs on UFS, have 
you turned them on using tunefs? What flavour of ACLs are you using -- POSIX.1e 
or NFSv4?

Robert___
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: www/chromium crashing whole system

[Robert N. M. Watson]

On 15 Nov 2010, at 22:19, Alexander Best wrote:

 thanks for all your help. i've recently switched to chromium 6.0.472.63
 and so far my computer has been very stable.
 
 if i experience more lock ups i'll let you know and try to figure out a way to
 gain access to some more debugging data.

I'd prefer we try to figure out why your system was crashing now -- the kernel 
bug has not gone away just because Chromium is no longer triggering it. Working 
around the bug means someone else gets to run into it later -- perhaps when 
it's 9.0-RELEASE rather than 9-CURRENT...

Robert___
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: [PATCH] Netdump for review and testing -- preliminary version

[Robert N. M. Watson]

On 15 Oct 2010, at 20:39, Garrett Cooper wrote:

But there are already some cases that aren't properly handled
 today in the ddb area dealing with dumping that aren't handled
 properly. Take for instance the following two scenarios:
 1. Call doadump twice from the debugger.
 2. Call doadump, exit the debugger, reenter the debugger, and call
 doadump again.
Both of these scenarios hang reliably for me.
I'm not saying that we should regress things further, but I'm just
 noting that there are most likely a chunk of edgecases that aren't
 being handled properly when doing dumps that could be handled better /
 fixed.

Right: one of the points I've made to Attilio is that we need to move to a more 
principled model as to what sorts of things we allow in various kernel 
environments. The early boot is a special environment -- so is the debugger, 
but the debugger on panic is not the same as the debugger when you can 
continue. Likewise, the crash dumping code is special, but also not the same as 
the debugger. Right now, exceptional behaviour to limit hangs/etc is done 
inconsistently. We need to develop a set of principles that tell us what is 
permitted in what contexts, and then use that to drive design decisions, 
normalizing what's there already.

This is not dissimilar to what we do with locking already, BTW: we define a set 
of kernel environments (fast interrupt handlers, non-sleepable threads, 
sleepable thread holding non-sleepable locks, etc), and based on those 
principles prevent significant sources of instability that might otherwise 
arise in a complex, concurrent kernel. We need to apply the same sort of 
approach to handling kernel debugging and crashing.

BTW, my view is that except in very exceptional cases, it should not be 
possible to continue after generating a dump. Dumps often cause disk 
controllers to get reset, which may leave outstanding I/O in nasty situations. 
Unless the dump device and model is known not to interfere with operation, we 
should set state indicating that the system is non-continuable once a dump has 
occurred.

Robert

___
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: [PATCH] Netdump for review and testing -- preliminary version

[Robert N. M. Watson]

On 13 Oct 2010, at 18:46, Ryan Stone wrote:

 On Fri, Oct 8, 2010 at 9:15 PM, Robert Watson rwat...@freebsd.org wrote:
 +   /*
 +* get and fill a header mbuf, then chain data as an
 extended
 +* mbuf.
 +*/
 +   MGETHDR(m, M_DONTWAIT, MT_DATA);
 
 The idea of calling into the mbuf allocator in this context is just freaky,
 and may have some truly awful side effects.  I suppose this is the cost of
 trying to combine code paths in the network device driver rather than have
 an independent path in the netdump case, but it's quite unfortunate and will
 significantly reduce the robustness of netdumps in the face of, for example,
 mbuf starvation.
 
 Changing this will require very invasive changes to the network
 drivers.  I know that the Intel drivers allocate their own mbufs for
 their receive rings and I imagine that all other drivers have to do
 something similar.  Plus the drivers are responsible for freeing mbufs
 after they have been transmitted.  It seems to me that the cost of
 making significant changes to the network drivers to support an
 alternate lifecycle for netdump mbufs far outweighs the cost of losing
 a couple of kernel dumps in extreme circumstances.

My concern is less about occasional lost dumps that destabilising the dumping 
process: calls into the memory allocator can currently trigger a lot of 
interesting behaviours, such as further calls back into the VM system, which 
can then trigger calls into other subsystems. What I'm suggesting is that if we 
want the mbuf allocator to be useful in this context, we need to teach it about 
things not to do in the dumping / crash / ... context, which probably means 
helping uma out a bit in that regard. And a watchdog to make sure the dump is 
making progress.

Robert___
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: [PATCH] Netdump for review and testing -- preliminary version

[Robert N. M. Watson]

On 14 Oct 2010, at 15:10, Attilio Rao wrote:

 My concern is less about occasional lost dumps that destabilising the 
 dumping process: calls into the memory allocator can currently trigger a lot 
 of interesting behaviours, such as further calls back into the VM system, 
 which can then trigger calls into other subsystems. What I'm suggesting is 
 that if we want the mbuf allocator to be useful in this context, we need to 
 teach it about things not to do in the dumping / crash / ... context, which 
 probably means helping uma out a bit in that regard. And a watchdog to make 
 sure the dump is making progress.
 
 I think that this would be way too complicated just to cope with panic
 within the VM/UMA (not sure what other subsystems you are referring
 to, wrt supposed to call). Besides, if we have a panic in the VM I'm
 sure that normal dumps could also be affected.
 When dealing with netdump, I'm not trying to fix all the bugs related
 to our dumping infrastructure because, as long as we already
 discussed, we know there are quite a few of them, but trying at least
 to follow the same fragile-ness than what we have today.
 And again, while I think the watchdog idea is good, I think it still
 applies to normal dumps too, it is not specific to netdump.

No, what I'm saying is: UMA needs to not call its drain handlers, and ideally 
not call into VM to fill slabs, from the dumping context. That's easy to 
implement and will cause the dump to fail rather than causing the system to 
hang.

Robert___
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: sysctls in kern_shutdown: add twin tunables

[Robert N. M. Watson]

On 30 Sep 2010, at 19:19, Andriy Gapon wrote:

 http://people.freebsd.org/~avg/kern_shutdown-tunables.diff
 
 The above patch adds twin tunables for the following (R/W) sysctls:
 - debug.debugger_on_panic
 - debug.trace_on_panic
 - kern.sync_on_panic
 
 This seems useful to me, but I am not sure if I am not missing something
 important.  E.g. security-wise.
 It seems that I am not paranoid enough often times.


This change seems fine to me. Our trust model assumes that loader.conf will be 
properly protected (or rather, that if you don't protect loader.conf properly, 
you should expect unfortunate results).

Robert___
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: MAXCPU preparations

[Robert N. M. Watson]

On 29 Sep 2010, at 12:49, John Baldwin wrote:

 On Tuesday, September 28, 2010 6:24:32 pm Robert N. M. Watson wrote:
 
 On 28 Sep 2010, at 19:40, Sean Bruno wrote:
 
 If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
 
 I assume that mp_maxid is the new kern.smp.maxcpus?  Can you inject some
 history here so I can understand why one is better than the other?
 
 So, unlike maxcpus, mp_maxid is in theory susceptible to races in a brave 
 new world in which we support hotplug CPUs -- a brave new world we're 
 not yet ready for, however. If you do use mp_maxid, be aware you need to add 
 one to get the size of the array -- maxcpus is the number of CPUs that 
 can be used, whereas mp_maxid is the highest CPU ID (counting from 0) that is 
 used.
 
 Hmm, I'm not sure that is true.  My feeling on mp_maxid is that it is the
 largest supported CPUID.  Platforms that support hotplug would need to set
 mp_maxid such that it has room for hotpluggable CPUs.  You don't want to
 go reallocate the UMA datastructures for every zone when a CPU is hotplugged
 for example.

Yes, we'll have to break one (or even both) of two current assumptions with the 
move to hotplug: contiguous in-use CPU IDs and mp_maxid representing the 
greatest possible CPU ID as a constant value. The former is guaranteed, but I 
wonder about the latter. On face value, you might say oh, we know how many 
sockets there are, but if course, we don't know how many threads will arrive 
when a package is inserted.  For many subsystems, DPCPU will present a more 
than adequate answer for avoiding resizing, although not for low-level systems 
(perhaps such as UMA?). Likewise, on virtual machine platforms where hotplug 
actually might reflect a longer-term scheduling choice by the admin/hypervisor 
(i.e., resource partitioning), it may be harder to reason about what the future 
holds.

Robert___
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: MAXCPU preparations

[Robert N. M. Watson]

On 28 Sep 2010, at 17:45, Sean Bruno wrote:

 Working on a dynamic version today.  I'll spam it over to you for review
 later.  
 
 I'm moving the percpu struct definitions outside of struct memory_type,
 allocating quantity kern.smp.maxcpus, removing the boundary checks based
 on MEMSTAT_MAXCPU and then removing MEMSTAT_MAXCPU all together.

Sounds like the right answer. Make sure to also keep the adapt the use of 
maxcpus from crashdumps so that we can also size the data structure when 
analyzing cores (or /dev/kmem or firewire).

Robert___
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: MAXCPU preparations

[Robert N. M. Watson]

On 28 Sep 2010, at 19:40, Sean Bruno wrote:

 If you go fully dynamic you should use mp_maxid + 1 rather than maxcpus.
 
 I assume that mp_maxid is the new kern.smp.maxcpus?  Can you inject some
 history here so I can understand why one is better than the other?

So, unlike maxcpus, mp_maxid is in theory susceptible to races in a brave new 
world in which we support hotplug CPUs -- a brave new world we're not yet ready 
for, however. If you do use mp_maxid, be aware you need to add one to get the 
size of the array -- maxcpus is the number of CPUs that can be used, whereas 
mp_maxid is the highest CPU ID (counting from 0) that is used.

Robert___
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: AppleTalk status

[Robert N. M. Watson]

On 25 May 2010, at 14:13, Nathan Whitehorn wrote:

 I'm working on updating net/netatalk to version 2.1 (or 2.1.1 when that 
 comes out the next couple of days), and I'm wondering what state AppleTalk 
 support is in these days.  Is anybody still using it, or would now be the 
 time to make all AppleTalk support in that port optional, and just focus on 
 the file server component?
 
 I haven't used AppleTalk for at least eight years now, and I don't quite see 
 which setting it still would be used in nowadays...

 I use it successfully on a router to connect my antique AppleTalk-only laser 
 printer. It seems to work quite well still.

I can confirm that whenever kernel netatalk gets broken, I get bug reports. :-) 
However, it hasn't gotten broken in a year or two so I've not polled recently.

Robert___
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: AppleTalk status

[Robert N. M. Watson]

On 25 May 2010, at 17:48, Julian Elischer wrote:

 I'm working on updating net/netatalk to version 2.1 (or 2.1.1 when
 that comes out the next couple of days), and I'm wondering what
 state AppleTalk support is in these days. Is anybody still using
 it, or would now be the time to make all AppleTalk support in that
 port optional, and just focus on the file server component?
 
 I haven't used AppleTalk for at least eight years now, and I don't
 quite see which setting it still would be used in nowadays...
 
 I did the original port to freeBSD (from a netbsd port from memory)
 I haven't checked recently but it was used by several companies running 
 legacy stuff in some industrial control situations.
 In any case it's good having a working example of another  protocol
 as the world is getting a bit too focused on IP these days
 and having a different protocol in the sources keeps us honest.

FWIW, I have no intention of removing the kernel support for appletalk (or, 
perhaps more properly, ethertalk). It does want to be changed to use our link 
layer improvements in 8.x, but what is there today works fine and should 
continue to work fine for the forseeable future. Virtualizing for VIMAGE will 
probably take someone a couple of afternoons, and I tentatively plan to do it 
at some point before 9.0.

Robert___
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: GrandCentralDispatch in FreeBSD?

[Robert N. M. Watson]

On 13 May 2010, at 10:21, Tom Evans wrote:

 I saw today that you've written a proof of concept MPM for apache in
 GCD [1] - are there any plans to port GCD to FreeBSD?

Hi Tom--

Actually, I also ported GCD to FreeBSD last year, and developed the MPM on 
FreeBSD/GCD :-). It requires a post-8.0 version of 8-STABLE, and then 
libdispatch port + clang compiler. You can find out more here:

  http://wiki.freebsd.org/GCD

The clang dependency is due to C Blocks, and we have an unpatched gcc so 
gcc-compiled applications can't use blocks.

Robert___
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

wpa_supplicant, Atheros AR9285 and FreeBSD 8.0 issue - wpa_supplicant hangs

[Eugeny N Dzhurinsky]

Hi!

I am facing very strange issue - for some reason wpa_supplicant hands after
associating connection with AP. It doesn't hang immediately - but after some
time (amout a minute or so).

I tried to run it as

wpa_supplicant -ddd -i wlan1 -c /etc/wpa_supplicant.conf 

and in logs I don't see any errors:

===



WPA: RX message 1 of Group Key Handshake from 00:1b:11:01:6b:f6 (ver=2)
State: GROUP_HANDSHAKE - GROUP_HANDSHAKE
WPA: Group Key - hexdump(len=32): [REMOVED]
WPA: Installing GTK to the driver (keyidx=2 tx=0 len=32).
WPA: RSC - hexdump(len=6): 0e 00 00 00 00 00
wpa_driver_bsd_set_key: alg=TKIP addr=ff:ff:ff:ff:ff:ff key_idx=2 set_tx=0 
seq_len=6 key_len=32
WPA: Sending EAPOL-Key 2/2
WPA: TX EAPOL-Key - hexdump(len=99): 01 03 00 5f fe 03 22 00 20 00 00 00 00 00 
00 00 03 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 
00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 91 13 79 11 04 55 fe 1e a3 12 f9 
63 96 6b e8 b8 00 00
WPA: Key negotiation completed with 00:1b:11:01:6b:f6 [PTK=CCMP GTK=TKIP]
Cancelling authentication timeout
State: GROUP_HANDSHAKE - COMPLETED
CTRL-EVENT-CONNECTED - Connection to 00:1b:11:01:6b:f6 completed (auth) [id=0 
id_str=]
EAPOL: External notification - portValid=1
EAPOL: External notification - EAP success=1
EAPOL: SUPP_PAE entering state AUTHENTICATING
EAPOL: SUPP_BE entering state SUCCESS
EAP: EAP entering state DISABLED
EAPOL: SUPP_PAE entering state AUTHENTICATED
EAPOL: SUPP_BE entering state IDLE
EAPOL authentication completed successfully
EAPOL: startWhen -- 0
EAPOL: disable timer tick
===

ifconfig looks like below:

===
re0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500

options=389bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_UCAST,WOL_MCAST,WOL_MAGIC
ether 00:26:18:92:e4:16
media: Ethernet autoselect (10baseT/UTP half-duplex)
status: no carrier
lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384
options=3RXCSUM,TXCSUM
inet 127.0.0.1 netmask 0xff00 
ath0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 2290
ether 00:25:d3:5c:f0:c8
media: IEEE 802.11 Wireless Ethernet autoselect mode 11g
status: associated
wlan1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500
ether 00:25:d3:5c:f0:c8
inet 192.168.10.3 netmask 0xff00 broadcast 192.168.10.255
media: IEEE 802.11 Wireless Ethernet OFDM/36Mbps mode 11g
status: associated
ssid freebsdap channel 10 (2457 MHz 11g) bssid 00:1b:11:01:6b:f6
regdomain NONE country UA indoor ecm authmode WPA privacy ON
deftxkey UNDEF TKIP 2:128-bit txpower 30 bmiss 7 scanvalid 450 bgscan
bgscanintvl 300 bgscanidle 250 roam:rssi 7 roam:rate 5 protmode CTS
wme burst roaming MANUAL
===

uname -a

FreeBSD localhost 8.0-STABLE FreeBSD 8.0-STABLE #34: Mon Mar 22 23:31:30 EET 
2010 r...@localhost:/usr/obj/usr/src/sys/BOFH  i386

atheros driver is loaded as module.

What may be wrong there?

Thank you in advance!

-- 
Eugene N Dzhurinsky
___
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

A tool for remapping bad sectors in CURRENT?

[Eugeny N Dzhurinsky]

Hello, all!

Recently I've started to see the following logs in messages:

Mar  8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Currently unreadable 
(pending) sectors
Mar  8 12:00:24 localhost smartd[795]: Device: /dev/ad4, 2 Offline 
uncorrectable sectors

smartctl did really show that something is wrong with my HDD, but still no
remaps - just read errors.

SMART Self-test log structure revision number 1
Num  Test_DescriptionStatus  Remaining  LifeTime(hours)  
LBA_of_first_error
# 1  Extended offlineCompleted: read failure   60%  1198 
222342559
# 2  Extended offlineCompleted: read failure   60%  1187 
222342557
# 3  Extended offlineCompleted: read failure   60%  1180 
222342559
# 4  Short offline   Completed without error   00%  1178 -
# 5  Extended offlineAborted by host   90%  1178 -

and

ATTRIBUTE_NAME  FLAG VALUE WORST THRESH TYPE  UPDATED  
WHEN_FAILED RAW_VALUE
...
Reallocated_Sector_Ct   0x0033   100   100   036Pre-fail  Always   -
   0
...

Now can I find out which file owns the LBAs 222342557 and 222342559 ? How do I
force remapping of these sectors? I assume that I have to write something
directly to the sectors?

Thank you all in advance!

-- 
Eugene N Dzhurinsky


pgpqQ6jlbF1Sg.pgp
Description: PGP signature

Re: net.inet.tcp.timer_race: does anyone have a non-zero value?

[Robert N. M. Watson]

On Mar 7, 2010, at 12:33 PM, Mikolaj Golub wrote:

 On Sun, 7 Mar 2010 11:59:35 + (GMT) Robert Watson wrote:
 
 Please check the results of the following command:
 
  % sysctl net.inet.tcp.timer_race
  net.inet.tcp.timer_race: 0
 
 Are the results for FreeBSD7 look interesting for you? Because currently we
 have mostly FreeBSD7.1 hosts in production and I observe nonzero values on 8
 hosts (about 15%). I would send more details to you privately if you are
 interested.

Yes, 7.x is also of interest, thanks!

Robert___
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: Proliant 1600R Install Failure (ida + SMPng to blame?)

[Matthew N. Dodd]

On Tue, 7 Oct 2003, Edward Aronyk wrote:
 Booting off the 5.1 boot floppies gives a page fault about 15 seconds
 after the mfsroot floppy finishes loading.

Boot off of a -CURRENT snapshot; 5.1 shipped with a broken IDA driver.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[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)

[Matthew N. Dodd]

On Wed, 24 Sep 2003, Daniel Eischen wrote:
 It isn't clear that libmap can deal with libraries that are
 linked to one specific threads library, and how libmap'd
 applications work.  If mplayer is libmap'd to libthr,
 ogle is libmap'd to libpthread, and both are linked to
 libGL which is linked to libc_r, what happens?

This is why its important to use the same name for the threading library
and never link directly with libkse, libthr, libc_r etc.  Make libpthread
a symlink, please.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: re-fdisk'ing a partition - permission denied?

[Matthew N. Dodd]

On Mon, 8 Sep 2003, Kevin Oberman wrote:
 In any case, since GEOM was added you can no longer slice or label an
 active device. As a result, the only way I know of to change slices or
 labels on V5 is to boot off of CD or floppy Fixit disks or install
 disks. (I just had to do this on my laptop this morning.)

I still use my foot-shooting patch.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: re-fdisk'ing a partition - permission denied?

[Matthew N. Dodd]

On Mon, 8 Sep 2003, Michael Edenfield wrote:
 There was, at one point, talk of adding some sort of
 geom.dont_blame_phk_when_you_shoot_your_ankle_off sysctl to permit this
 type of access when the user was absolutely sure they knew exactly what
 kind of dangerous and potentially corrupting thing they were doing and
 wanted to do it anyway, but I'm not sure it got anywhere.

ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: re-fdisk'ing a partition - permission denied?

[Matthew N. Dodd]

On Mon, 8 Sep 2003, Steve Kargl wrote:
 Any chance that this patch will be committed?  Or, has this patch been
 sent to the bikeshed?

There is some code that was a half-compromise:

geom/geom_subr.c:g_access_rel()
%%%
/* If foot-shooting is enabled, any open on rank#1 is OK */
if ((g_debugflags  16)  pp-geom-rank == 1)
;
%%%


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: kernel build fails in agp_nvidia.c

[Matthew N. Dodd]

On Sat, 23 Aug 2003, Harald Schmalzbauer wrote:
 cvsupped half an hour ago, the following error occurs when trying to build a
 kernel (mine, which worked fine with yesterdays source)

This one is mine, sorry.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dhclient problem with xl0

[Matthew N. Dodd]

On Sat, 9 Aug 2003, Martin Blapp wrote:
 Isn't there a way to see that the card doesn't support reporting
 media status ? If the card does report this, I could add code
 to dhclient and all would be fine.

Yes; check the media status word for IFM_AVALID.

(whitespace damaged)
%%%
--- dhclient.c  28 Jul 2003 13:25:04 -  1.27
+++ dhclient.c  9 Aug 2003 13:07:16 -
@@ -3221,13 +3221,11 @@
if (ifmr.ifm_status  IFM_ACTIVE)
return (1);
}
+   return (0);
}

-   return (0);
-#else /* ifdef __FreeBSD__ */
-
-   return (1);
 #endif /* Other OSs */
+   return (1);
 }

 #ifdef __FreeBSD__
%%%


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dhclient problem with xl0

[Matthew N. Dodd]

On Sat, 9 Aug 2003, Martin Blapp wrote:
  dhclient is still relying on behavior from the kernel that isn't
  guaranteed.

 I know. But I'd consider that as a kernel bug, not dhclient fault.
 Would it help the set the card into promisc. mode anyway, even
 if we don't have link ?

Except that you've added code to dhclient that makes poor assumptions
about the ifmedia status word.  Its optional; for hardware that you can
detect media status it can be used to display the status.  For other
hardware, we shouldn't have to lie about media status; if the hardware
doesn't support reporting media status then we shouldn't do anything with
the status word.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dhclient problem with xl0

[Matthew N. Dodd]

On Sat, 9 Aug 2003, Craig Rodrigues wrote:
 I just did a cvsup of -CURRENT and rebuilt the world.
 dhclient doesn't seem to work for me any more.
 It looks like a problem with dhclient, and not the
 kernel, because an older version of dhclient works fine.

 Here is the output of dhclient -v -d xl0

Try this (cut  paste):
%%%
Index: if_xl.c
===
RCS file: /cvs/src/sys/pci/if_xl.c,v
retrieving revision 1.150
diff -u -u -r1.150 if_xl.c
--- if_xl.c 27 Jul 2003 13:56:03 -  1.150
+++ if_xl.c 4 Aug 2003 15:46:36 -
@@ -3031,6 +3031,10 @@
icfg = XL_ICFG_CONNECTOR_BITS;

ifmr-ifm_active = IFM_ETHER;
+   ifmr-ifm_status = IFM_AVALID;
+
+   if (!(CSR_READ_2(sc, XL_W4_MEDIA_STATUS)  XL_MEDIASTAT_CARRIER))
+   ifmr-ifm_status |= IFM_ACTIVE;

switch(icfg) {
case XL_XCVR_10BT:
%%%

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dhclient problem with xl0

[Matthew N. Dodd]

On Sat, 9 Aug 2003, Martin Blapp wrote:
 You don't have a working link. Maybe it helps if you add a interface
 define in /etc/dhclient.conf wit the possible media.

dhclient is still relying on behavior from the kernel that isn't
guaranteed.

I posted a patch to if_xl.c that should correct the link status for cards
with builtin non-MII PHYs.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dhclient problem with xl0

[Matthew N. Dodd]

On Sat, 9 Aug 2003, Matthew N. Dodd wrote:
 Try this (cut  paste):

The patch I posted was incorrect as I forgot to do a register window
select before reading media status.

ftp://ftp.jurai.net/users/winter/patches/xl_media.patch

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: ML370 crash

[Matthew N. Dodd]

On Thu, 7 Aug 2003, Alexandre Biancalana wrote:
   Following John Cagle instructions, I made an trace at db prompt, the
 result can be viewed at
 http://www.seudns.net/ftp/ale/Pictures/ml370/trace.jpg, the crash can be
 viewed at http://www.seudns.net/ftp/ale/Pictures/ml370/crash_boot.jpg

   As John told me, It looks like a bug that involves the ida driver.

   What can I do ??

I just committed the fix to ida_disk.c (1.41).

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: dhclient/dhclient.conf change in -CURRENT?

[Matthew N. Dodd]

On Mon, 4 Aug 2003, Martin Blapp wrote:
 Yes, there have been some changes. The most important was the interface
 polling addition, but that should not make any difference here.

Read the code.

dhclient.c:send_discover() bails out if interface_active() is false BEFORE
iterating all the possible media settings.

As I've explained in private email using the ifm_status word to determine
if the interface is up and running is incorrect.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: problem with nvidia graphics card and -current

[Matthew N. Dodd]

On Mon, 4 Aug 2003, Glenn Johnson wrote:
 Question for the developers: Is there someway to avoid having the
 combination of vesa and nvidia cause a total lockup of the machine?  I
 have a feeling I may not be the last person to try the nvidia driver
 with vesa enabled, either as a module, or compiled in the kernel.

I'm running a system with the VESA stuff compiled in; the nvidia drivers
work just fine.

IIRC you're running with ACPI; try not doing that.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: STEP 2, fixing dhclient behaviour with multiple interfaces

[Matthew N. Dodd]

On Wed, 30 Jul 2003, Martin Blapp wrote:
 control does only release leases and exit (state 2), I never managed
 to make dhclient sleep (state 3) and wake up (state 2).

Odd:

%%%
# cat /etc/sleep_dhclient
#!/bin/sh

omshell  /dev/null  EOF
connect
new control
open
set state = 3
update
close
EOF
# cat /etc/wakeup_dhclient
#!/bin/sh

omshell  /dev/null  EOF
connect
new control
open
set state = 4
update
close
EOF
%%%

This was working fine for me a few months ago.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: 8MB install

[Matthew N. Dodd]

On Wed, 25 Jun 2003, M-Trade wrote:
 Has anyone had any success installing 5.1 release on a 486
 w/ 8MB RAM?  I can't install.

 avail memory = (245760) 0 MB

 Is this expected behavior?

Yes.  I got pre 5.1 running on a 386dx33 with 16mb; it wouldn't work with
8.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: nVidia nForce2 AGP chipset drivers

[Matthew N. Dodd]

On Sun, 22 Jun 2003, Matthew N. Dodd wrote:
 On Mon, 23 Jun 2003, Arjan van Leeuwen wrote:
  Hmm... I don't have the hardware either, but I was thinking about buying
  a new mainboard based on it (if there is support in FreeBSD, of course
  :)). Maybe someone who actually has an nForce2 board can help us out
  here? Can you post the patches to the list so that someone can test
  them?

 Lacking the hardware, (and sleep last night when I started), I'm not yet
 far along enough to have something that is testable.

ftp://ftp.jurai.net/users/winter/patches/nforce-agp.diff

I suspect using this will result in a panic so load this as a module.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: nVidia nForce2 AGP chipset drivers

[Matthew N. Dodd]

On Sun, 22 Jun 2003, Arjan van Leeuwen wrote:
 Now that nVidia has released kernel patches for Linux to support their AGP
 chipset (see http://www.nvidia.com/view.asp?IO=linux_nforce_1.0-0261), is it
 possible to easily port these patches and include them in the agp(4) driver?

 How does one start with such a thing?

I actually started writing a driver based on the released Linux one but
don't actually have the hardware to test things.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: nVidia nForce2 AGP chipset drivers

[Matthew N. Dodd]

On Mon, 23 Jun 2003, Arjan van Leeuwen wrote:
 Hmm... I don't have the hardware either, but I was thinking about buying
 a new mainboard based on it (if there is support in FreeBSD, of course
 :)). Maybe someone who actually has an nForce2 board can help us out
 here? Can you post the patches to the list so that someone can test
 them?

Lacking the hardware, (and sleep last night when I started), I'm not yet
far along enough to have something that is testable.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: [-CURRENT tinderbox] failure on alpha/alpha

[Matthew N. Dodd]

This should be fixed now.

On Thu, 19 Jun 2003, Tinderbox wrote:

 TB --- 2003-06-19 16:00:22 - starting CURRENT tinderbox run for alpha/alpha
 TB --- 2003-06-19 16:00:22 - checking out the source tree
 TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha
 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src
 TB --- 2003-06-19 16:02:36 - building world
 TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src
 TB --- /usr/bin/make -B buildworld
  Rebuilding the temporary build tree
  stage 1: legacy release compatibility shims
  stage 1: bootstrap tools
  stage 2: cleaning up the object tree
  stage 2: rebuilding the object tree
  stage 2: build tools
  stage 3: cross tools
  stage 4: populating 
  /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include
  stage 4: building libraries
  stage 4: make dependencies
  stage 4: building everything..
 [...]
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:118: 
 warning: int format, different type arg (arg 6)
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:118: 
 warning: unsigned int format, different type arg (arg 8)
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c: In 
 function `dump_Elf_Rela':
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:140: 
 warning: unsigned int format, different type arg (arg 3)
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:140: 
 warning: unsigned int format, different type arg (arg 4)
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:140: 
 warning: unsigned int format, different type arg (arg 5)
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:140: 
 warning: int format, different type arg (arg 6)
 /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf/debug.c:140: 
 warning: unsigned int format, different type arg (arg 8)
 *** Error code 1

 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec/rtld-elf.
 *** Error code 1

 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/libexec.
 *** Error code 1

 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
 *** Error code 1

 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
 *** Error code 1

 Stop in /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src.
 TB --- 2003-06-19 16:49:56 - /usr/bin/make returned exit code  1
 TB --- 2003-06-19 16:49:56 - ERROR: failed to build world
 TB --- 2003-06-19 16:49:56 - tinderbox aborted

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


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: __thread support in -current..

[Matthew N. Dodd]

On Tue, 17 Jun 2003, Julian Elischer wrote:
 I guess the support is in gcc as Linux and solaris use it, but
 is our linker close enough to what they use to be able to benefit at all
 from them?

We'll need an updated GCC at the very least; I see some stuff in binutils
regarding TLS.  I think we're going to get updated binutils anway.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Problems with pcmcia on 5.1-RELEASE

[Matthew N. Dodd]

 Does anyone have a hint, that will help me get this working?

[cut and paste]
--- ata-card.c  3 Jun 2003 01:30:55 -   1.13
+++ ata-card.c  15 Jun 2003 18:46:28 -
@@ -53,6 +53,8 @@
PCMCIA_CARD(OEM2, IDE, 0),
PCMCIA_CARD(PANASONIC, KXLC005, 0),
PCMCIA_CARD(TEAC, IDECARDII, 0),
+   { FREECOM PCCARD-IDE, PCCARD_VENDOR_ANY, PCCARD_PRODUCT_ANY, 0,
+   { FREECOM, PCCARD-IDE, NULL, NULL } },
{NULL}
 };




-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Problems with pcmcia on 5.1-RELEASE

[Matthew N. Dodd]

On Sun, 15 Jun 2003, Christian Laursen wrote:
 However, no devices are found on it.

 ata2: FREECOM PCCARD-IDE at port 0x100-0x10f irq 11 function 0 config 1 on pccard0

 vulcan# atacontrol info ata2
 Master:  no device present
 Slave:   no device present

 I believe tha master should be the cdrom drive.

'atacontrol attach 2' or 'atacontrol reinit 2'

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: VIA ACPI power management controller

[Matthew N. Dodd]

On Fri, 6 Jun 2003, Alexander Leidinger wrote:
 This problem is under investigation. We already know why this error gets
 printed, but there is still a discussion how to fix it cleanly.

This is what I'll likely commit in the short term.

Index: pci.c
===
RCS file: /home/cvs/ncvs/src/sys/dev/pci/pci.c,v
retrieving revision 1.215
diff -u -u -r1.215 pci.c
--- pci.c   31 May 2003 20:34:36 -  1.215
+++ pci.c   4 Jun 2003 12:38:12 -
@@ -175,6 +175,12 @@
 enable these bits correctly.  We'd like to do this all the time, but there\n\
 are some peripherals that this causes problems with.);

+static int pci_disable_io_mode_sanity = 0;
+TUNABLE_INT(hw.pci.disable_io_mode_sanity, (int *)pci_disable_io_mode_sanity);
+SYSCTL_INT(_hw_pci, OID_AUTO, disable_io_mode_sanity, CTLFLAG_RW,
+   pci_disable_io_mode_sanity, 0,
+   Disable PCI IO mode sanity checks in resource allocation.);
+
 /* Find a device_t by bus/slot/function */

 device_t
@@ -1326,6 +1332,7 @@
struct pci_devinfo *dinfo = device_get_ivars(child);
struct resource_list *rl = dinfo-resources;
pcicfgregs *cfg = dinfo-cfg;
+   int error;

/*
 * Perform lazy resource allocation
@@ -1358,7 +1365,8 @@
 * Enable the I/O mode.  We should also be allocating
 * resources too. XXX
 */
-   if (PCI_ENABLE_IO(dev, child, type))
+   error = PCI_ENABLE_IO(dev, child, type);
+   if (error  !pci_disable_io_mode_sanity)
return (NULL);
break;
}

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: libmap.conf has the bug or not work correct?

[Matthew N. Dodd]

On Tue, 3 Jun 2003, Jeremy Messenger wrote:
 
 # ./test-libmap /usr/X11R6/bin/ggv libc_r.so.5
 Lookup of libc_r.so.5 for /usr/X11R6/bin/ggv - libc_r.so.5
 

Looks like its working to me.

 
 # ./test-libmap /usr/X11R6/bin/ggv libthr.so.1
 [...etmpy...]
 

Right, there was on mapping found.

So this isn't a libmap.conf issue.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: libmap.conf has the bug or not work correct?

[Matthew N. Dodd]

On Wed, 4 Jun 2003, Jeremy Messenger wrote:
 Nevermind, I think you are right it does work. Because, I did the test
 on mplayer by install it. It does link mplayer to libc_r correct, while
 not ggv. Looks like I will have to chase on ggv to find what ggv is
 depending on and get them link to libc_r.. This must be reason why it
 doesn't work.  Thanks!

'ldd -a' is usefule for finding this out.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: libmap.conf has the bug or not work correct?

[Matthew N. Dodd]

On Wed, 4 Jun 2003, Jeremy Messenger wrote:
 Sweet, thanks! This is what I need, which it made easier to locate the
 library that use libc_r.. I have found two that need to be link to libc_r
 instead libthr so far..

 /usr/X11R6/lib/libgnomeui-2.so.300
 /usr/local/lib/libgthread-2.0.so.200 -- This one, I might need to report
 at -threads.

This does bring up a UI issue (of sorts) since the behavior you expected
(constrained matches based on executable name) has some merit to it.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: libmap.conf has the bug or not work correct?

[Matthew N. Dodd]

On Tue, 3 Jun 2003, Jeremy Messenger wrote:
 It seems like the [/path/to/exec] and [exec] don't work?

ftp://ftp.jurai.net/users/winter/libmap-test.tar

Untar that in src/libexec/rtld-elf/
cd test/
make
./test-libmap /path/to/exec library-name


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: Preliminary ELF prebinding patches available.

[Matthew N. Dodd]

On Fri, 30 May 2003, Anthony Ginepro wrote:
  I've implemented per-executable ELF prebinding:
 
  ftp://ftp.jurai.net/users/winter/patches/prebind.patch
 
  Initial performance measurements are very encouraging.

 Is it similar to Linux's prelink implementation ?
 How does it compare with (feature, performance) ?

I've not taken a look at the Linux stuff yet.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: breakage this morning

[Matthew N. Dodd]

On Wed, 2 Apr 2003, Michael W . Lucas wrote:
 Thank you very much!

Sorry about the breakage.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: PC98 still broken

[Matthew N. Dodd]

On Sat, 29 Mar 2003, Takahashi Yoshihiro wrote:
  === pcspeaker
  @ - /usr/src/sys
  machine - /usr/src/sys/i386/include
  make: don't know how to make spkr.c. Stop
  *** Error code 2

Sorry about that.  Fixed.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

Re: buildkernel errors after latest cvsup

[Matthew N. Dodd]

On Mon, 24 Mar 2003, Donn Miller wrote:
 smapi_isa.c isn't in the tree yet.  Did someone forget to commit it?

Yep, sorry about that; I changed it in a different tree.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: Updated if_* attach/detach patches

[Matthew N. Dodd]

On Wed, 19 Mar 2003, Nate Lawson wrote:
 Patches are at:
 http://www.root.org/~nate/freebsd/if_pci/

I'd like to see calls to mtx_destroy() protected by a test for
mtx_initialized().

In most cases this isn't strictly necessary but its not bad practice.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: Updated if_* attach/detach patches

[Matthew N. Dodd]

On Fri, 21 Mar 2003, Nate Lawson wrote:
 Perhaps I should add a comment mentioning my assumption:  mtx_init is
 one of the first things called and since detach unconditionally locks
 the mtx, it should never be called unless the mutex is initialized.

This isn't the case for all drivers and the test would set a good example
for people reading the code.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: freebsd 5.0 on hp netserver lf

[Matthew N. Dodd]

On Fri, 21 Mar 2003, Brian J. Kirk wrote:
 but the dmesg and installer still don't list the scsi controller, and
 hence no drives.

set hw.eisa_slots=12

from the loader.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: Hang on Boot (still)

[Matthew N. Dodd]

On Sun, 16 Mar 2003, Lucas Reddinger wrote:
 The one alternative would be to compile a stripped kernel on another
 machine, and install off of it. I did this, but I do not have enough
 knowledge of the 5.x kernel/modules to be able to do this myself. If
 someone could give me some help with this instead, it would be greatly
 appriciated.

Try setting this from the loader

hw.eisa_slots=0

(or 1).

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: if_iso88025subr.c: doesn't compile.

[Matthew N. Dodd]

On Sat, 15 Mar 2003, walt wrote:
 So far today this file has been updated four times and it still won't
 compile.  Can this be debugged off-line before being committed?

You just happened to catch it at a bad time.  Sorry for the trouble.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: Any ideas why we can't even boot a i386 ?

[Matthew N. Dodd]

On Thu, 27 Feb 2003, Garance A Drosihn wrote:
 I'm thinking maybe the 5.x release CD's should include:
  GENERIC
  GENERIC +SMP
  GENERIC +VMWARE-friendly settings
  GENERIC for i386

GENERIC OLDCARD

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: The cbus driver for pc98

[Matthew N. Dodd]

On Mon, 17 Feb 2003, Takahashi Yoshihiro wrote:
 These are completely different.  All PC-98 machines don't have ISA
 devices and buses at all, but a little old PC-AT machines have ISA
 buses.  And, even if the PC-AT machine does not have ISA buses, it has
 PCI-ISA bridge.

This is semantics; like it or not the PC-98 boxes do have something that
fits into the definition of ISA.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: sys/pci/if* fixes

[Matthew N. Dodd]

On Fri, 14 Feb 2003, Nate Lawson wrote:
 Also, except for xl, all drivers have a common cleanup on error in
 attach that backs out allocated resources with no assumptions about the
 order they were allocated in.

Please see if_pcn.c for the correct approach to freeing resources; its not
necessary to wrap evrything in 'if (sc  error != 0) {}'.  If execution
reaches the 'fail' label then you assume that is what happened.

I also think you should just drop and reaquire locks around the
bus_setup_intr() rather than moving code around.

--
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: ACPI thermal panics ThinkPad 600X

[Matthew N. Dodd]

On Sat, 15 Feb 2003, Dag-Erling Smorgrav wrote:
 Unfortunately I can't afford a new laptop, so I'm stuck with my 600E.

APM works fine on the 600E.  The latest BIOS updates and new model main
batteries seem to solve most of the battery complaints.

My only outstanding issue is that I can't suspend if an application is
holding /dev/dsp or /dev/audio open.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: sys/pci/if* fixes

[Matthew N. Dodd]

On Sat, 15 Feb 2003, Nate Lawson wrote:
 The 'if' is a matter of coding style.  Which is preferred: multiple
 returns from the same function (one which is only reachable from a goto)
 or one linear path with an 'if' to see if this is an error exit?

In this case a single return is harder to read.

 See the previous thread on this regarding my original dc(4) changes.
 It is bogus to create a lock with mtx_init and then immediately lock it
 for the entire attach routine just for the intention of ensuring
 exclusive access to the device.

The problem is that the drivers aren't properly turning off interrrupts
before setting up the interrupt handler.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: kldloading smapi.ko on ThinkPad 600X

[Matthew N. Dodd]

On Fri, 14 Feb 2003, Ruslan Ermilov wrote:
 On a recent 5.0-CURRENT, a kldload of the smapi.ko panics my box. Is
 anyone else seeing this too?

I'd be interested in the traceback...

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: bus_setup_intr() vs. ether_ifattach() race

[Matthew N. Dodd]

On Sun, 9 Feb 2003, Nate Lawson wrote:
 Which is the correct order to do these two functions?  If the irq is
 enabled before the device is attached, it seems a response cannot be
 sent if a packet arrives before the attach.  The right way seems to be
 to attach the device before setting up an irq but does this have side
 effects?

The interrupt handler should be checking IFF_UP.

The driver shouldn't enable card interrupts until if_init() has been run
and should disable them in it foo_stop() routine (or when the interface is
brought down, detached etc.)

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: LOR on current as of last Friday

[Matthew N. Dodd]

On Tue, 28 Jan 2003, Alexander Pohoyda wrote:
   ps2 ? audio
 Enabled, Address 530, IRQ 5, DMA 3, SBAddress 220
...
 Anything else I may try?
 Thanks to all who replied!

Yes, there should be 2 DMA addresses assigned to the 'audio' device.

{0x0001630e, CS423x-PCI}, /* CSC0100 */

This is the PNP ID that should show up.

pcm0: CS423x-PCI at port 0x220-0x233,0x388-0x38b,0x530-0x537 irq 5 drq 3,1 on isa0

This uses the 'mss' PCM driver (which is enabled with 'device pcm' in your
config file.)

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: LOR on current as of last Friday

[Matthew N. Dodd]

On Tue, 28 Jan 2003, Alexander Pohoyda wrote:
  {0x0001630e, CS423x-PCI}, /* CSC0100 */

unknown: CSC0100 can't assign resources

You've got LOTS of ISA hints specified and they're conflicting with
PNPBIOS devices.

These are the only ones that don't get setup on my system:

unknown: PNP0c02 can't assign resources (port) /* System Resource */
unknown: PNP0e03 can't assign resources (port) /* PCIC i82365 */
unknown: PNP0680 can't assign resources (port) /* IDE controller */
unknown: PNP0680 can't assign resources (port) /* IDE controller */

Since we're using the PCI attachments for the PCIC (cardbus) and IDE
controllers these 'unknown' devices aren't unexpected.

If you boot verbose you can see what each 'unknown' device is looking for
in the way of resources.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: xl thinkpad 600x watchdog timeout

[Matthew N. Dodd]

On Mon, 27 Jan 2003, Toni Schmidbauer wrote:
 got no useful response from -mobile so re-posting to -current:

 i am having problems with 5.0-REL on an ibm thinkpad 600x.the xl
 driver for my 3com 3ccfe575ct writes the following message to the
 console xl0: watchdog timeout.

The 575 may require some special driver attention.  I haven't had much
time to look into it.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: LOR on current as of last Friday

[Matthew N. Dodd]

On Mon, 27 Jan 2003, Alexander Pohoyda wrote:
 I'd wish to have sound working..  On my second notebook (TP600E) I have
 a PCI sound card -- 0x1013 0x6001. Don't you?

You'll need to configure the sound resources in DOS using the 'ps2.exe'
utility.  (Or you can wait a few days until I get my config util working
in FreeBSD.)

pcm0: CS423x-PCI at port 0x220-0x233,0x388-0x38b,0x530-0x537 irq 5 drq 3,1 on isa0

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: LOR on current as of last Friday

[Matthew N. Dodd]

On Tue, 28 Jan 2003, Alexander Pohoyda wrote:
 I'm talking about TP600E and 4.7-STABLE (as of yesterday) here.

 Just recompiled:

 apog@oak:~$ grep csa /sys/conf/files
 dev/sound/pci/csa.c optional csa pci
 #dev/sound/pci/csa.coptional pcm pci
 dev/sound/pci/csapcm.c  optional csa pcm pci
 apog@oak:~$ grep pcm0 /sys/i386/conf/OAK
 device  pcm0at isa? port 0x530 irq 9 drq 1 flags 0x10
 apog@oak:~$ grep pcm /var/run/dmesg.boot
 apog@oak:~$


 ps2 ? audio
 Enabled, Address 530, IRQ 9, DMA 0 - 1, SBAddress 220

 ps2 ? midi
 Enabled, Address 580, IRQ 5

 No sound. Ideas?

Don't use hints; they're not going to work (I suppose they might if you
use 'snd_mss0')

Enable PNPBIOS.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |

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

Re: I want a sysctl kern.allow_shooting_into_my_foot!

[Matthew N. Dodd]

On Tue, 21 Jan 2003, Joerg Wunsch wrote:
 It already stopped me when accessing /dev/da0, so why try something
 more obscure?  Sorry, you've lost me.

ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch

Just apply it to your local source tree and get on with life.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

RE: Problem with RC3

[Matthew N. Dodd]

On Wed, 15 Jan 2003, Chris Knight wrote:
 It works under Win9x with an extra program, but doesn't work under
 Windows 2000. I'm happy to be corrected though. I have a DOS partition
 on my ThinkPad 600, but never managed to get it working.

Hibernation should work on ALL thinkpads, probably back as far as the 701.

I've got it working on a 560E as well.

Just create a DOS filesystem sized say 16 megs larger than your system
memory size and use the ps2 utility to create the hibernation file.

'ps2 hfile c' for example would create the file on C drive.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Problem with RC3

[Matthew N. Dodd]

On 15 Jan 2003, Alexander Pohoyda wrote:
 OK, this works for me, but then PCMCIA does not seem to work.

The installer only supports NEWCARD (ie, PCI CARDBUS) devices.

Do you have an ISA or PCMCIA only PCI based system?

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Problem with RC3

[Matthew N. Dodd]

On Wed, 15 Jan 2003, Alexander Pohoyda wrote:
 If ACPI is disabled, no PC Cards are found at the boot time and
 inserting one later does not have any effect for the system.

Set this fromt the loader:

hw.cbb.start_memory=536870912

And disable ACPI.

 Anyway, thanks to all developers for the great work!!

My 600E has real issues with ACPI; it works fine without (using APM).

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Problem with RC3

[Matthew N. Dodd]

On Wed, 15 Jan 2003, Alexander Pohoyda wrote:
 Done. System is up and running. While booting I got messages:

 apm0: APM BIOS on motherboard
 apm0: found APM BIOS v1.2, connected at 1.2
 ...
 ccb: Unable to map IRQ...
 device_probe_and_attach: cbb0 attach returned 12
 ...

You'll need to use the 'ps2' utility to tell the system which IRQ to use
for the cardbus bridge.

From my dmesg:

cbb0: TI1251 PCI-CardBus Bridge mem 0x50102000-0x50102fff irq 9 at device 2.0 on pci0
cardbus0: CardBus bus on cbb0
pccard0: 16-bit PCCard bus on cbb0
cbb1: TI1251 PCI-CardBus Bridge mem 0x50101000-0x50101fff irq 11 at device 2.1 on 
pci0
cardbus1: CardBus bus on cbb1
pccard1: 16-bit PCCard bus on cbb1

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Problem with RC3

[Matthew N. Dodd]

On Wed, 15 Jan 2003, Alexander Pohoyda wrote:
 Where do I get this utility?

Download it from IBM.  Its part of the DOS management utils.

You'll need to have a DOS partition setup so that hibernate works.

 I had a Windows XP preinstalled , and it
 told me that PCMCIA uses IRQ 9. I'll try to put this into
 /boot/device.hints:
 hint.ccb.0.irq=9

This won't work.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Problem with RC3

[Matthew N. Dodd]

On Wed, 15 Jan 2003, Alexander Pohoyda wrote:
 Well. This is not easy. I don't have a floppy drive, and I don't have
 DOS. I have, however, a second HDD with FreeBSD 4.7, where everything
 works allright. Can't I just get values from there?

Nope.  You can try to burn a windows/dos boot CD.

In 4.7 you were using the cardbus bridge in compatibility mode without an
assigned interrupt.

  You'll need to have a DOS partition setup so that hibernate works.

 I haven't had DOS for ages!! I really don't want to go that way. I
 will have to make DOS bootable CD-ROM, etc..

You've got to have it if only for the hibernation file.  (Hibernation is
worth it IMHO.)

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Troubles installing 5.0-RC2 on a Thinkpad560

[Matthew N. Dodd]

On Fri, 10 Jan 2003, [ISO-8859-1] Karl-Petter Åkesson wrote:
 Yes modified floppies would be great.

 I dont really get this. When I read the installation intructions I
 understood it as that all hardware listed in HARDWARE.txt is supported
 not only by FreeBSD by it self but also available on the floppies. But
 this isnt the case or?

Its supported by 'OLDCARD' which isn't on the install floppies.

ftp://ftp.jurai.net/users/winter/5.0-RC2/

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |



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

Re: Troubles installing 5.0-RC2 on a Thinkpad560

[Matthew N. Dodd]

I installed FreeBSD 5.0-RC2 on a 560E with the 'ed' driver last week.

You must re-roll ALOT of stuff to get it working since the kern.flp stuff
doesn't have OLDCARD support.

I can provide you with modified floppies if you like.

On Fri, 10 Jan 2003, [ISO-8859-1] Karl-Petter Åkesson wrote:

 Hi everyone,

 I just tried to install the 5.0-RC2 on one of my Thinkpad 560s but was
 not successful. Previously FreeBSD 4.x has always worked just fine to
 isntall on this machine. I think the problem is that the driver to my
 network card does not get loaded. I'm just a user of FreeBSD so I'm not
 fully into the exact steps of the boot and what gets done at certain
 times but these are my guesses...

 The configuration of tha machine is:
 Thinkpad 560, 64Mb memory, 20Gb HD set as slave, a 128Mb PCMCIA
 flashcard and a PCMCIA 3Com 3C589C networkcard.

 According to the
 ftp://ftp.freebsd.org/pub/FreeBSD/releases/i386/5.0-RC2/HARDWARE.TXT my
 network card should be supported but when I have chosen Passive FTP as
 installation medium and is about to setup the network I only get three
 options:
 lp0   Parallel Port IP (PLIP) peer connection
 sl0   SLIP inteface on device /dev/cuua0 (COM1)
 ppp0  PPP inteface on device /dev/cuua0 (COM1)

 It seesm that the drivers for the networkcard are not loaded and
 therefore I only get these three options. Another clue that points in
 this direction is that everytime sysinstall starts it complains about:
 Loading module if_awi.ko failed
 Baystack 660 and others

 The (awi) driver is for AMD Am79C930 and Harris (Intersil) based 802.11
 cards but I do not have any of those installed so I can't understand why
 it complains about that. But I guess since it fails, there are no other
 drivers are load after that point of time and thus my (ep) driver is not
 loaded, correct ? Can I somehow check what drivers are loaded? I thought
 the boot text gave that information but I can not find any information
 about any awi device so why should sysinstall complain?

 The only other thing that could be a problem that I could identify are a
 number of unknowns in the boot sequence. Just after the Generic ISA VGA
 I get these:

 unknown: PNP0303 can't assign resources (port)
 unknown: PNP0f13 can't assign resources (irq)
 unknown: PNP0700 can't assign resources (port)
 unknown: PNP0600 can't assign resources (port)
 unknown: PNP0c02 can't assign resources (port)
 unknown: PNP0400 can't assign resources (port)
 unknown: IBM0070 can't assign resources (port)


 Best Regards,
 Kalle


-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: Status of NEWCARD for IBM ThinkPad 600s

[Matthew N. Dodd]

On Thu, 2 Jan 2003, Kevin Oberman wrote:
 After DP2 was released, PCCARDs were no longer recognized by IBM
 ThinkPads in the 600 series. I just get:

 pccard1: Card has no functions!
 cbb1: PC Card card activation failed

either set from the loader or add to /boot/device.hints

hw.cbb.start_memory=536870912

(or some other memory address  physical)

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: ep0 hard lockup during install

[Matthew N. Dodd]

On Mon, 30 Dec 2002, Roderick van Domburg wrote:
 For three days in a row now I have tried installing the most recent 5.0
 snapshots on my Armada V300 from floppies. I have also tried the RC2
 floppies.

I just installed RC2 using a 3C574B with the 'ep' driver; worked just fine
aside from needing to re-roll kern.flp and mfsroot.flp to support OLDCARD.

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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

Re: writing to mbr under GEOM

[Matthew N. Dodd]

On Mon, 16 Dec 2002, Ray Kohler wrote:
 What's the status of the issue where devices with open partitions can't
 have their boot sectors written to? I know phk@ was working on it a
 while back but it's something I'd like to see fixed soon, maybe before
 release?

I've been using the following:

ftp://ftp.jurai.net/users/winter/patches/geom-foot.patch

Set the sysctl 'kern.geom.allow_foot_shooting' to 1 and cross your
fingers.  Most of the time accessing an already open device is harmless
but I've encountered panics a few times.  YMMV

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter |  For Great Justice!  | ISO8802.5 4ever |


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