Re: 5.2-RELEASE TODO
Actually, I would think it a desirable feature mac support that won't panic within 24 hours. :-) I've given up on mac again. Can't have it if it panics on every daily. :-( What's the plans for dealing with that? Robert Watson wrote: This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | |
Re: 5.1-RELEASE TODO
On Mon, 02 Jun 2003 07:09:44 -0300 Daniel C. Sobral [EMAIL PROTECTED] wrote: I hadn't any program running with legitimate access to /mnt and I have no program running which accesses a random filesystem path, so no vnodes should have been open then. Alas, lsof (ports) would be a better way of checking if there are vnodes open or not. I think fstat does that too, but I'm too used to lsof. Also, what is the error message? It was EBUSY. The first time I thought: sure, there's something open on it... with 3 xterms open where I use zsh as the shell it was easy to hunt for a program which I may have suspended, but I wasn't able to find one. Even umount -f wasn't able to umount the slice. As the disk was used to transport some data I wasn't able to look further into this. Now with a new kernel (from May 30) and another data transport on a harddisk I'm not able to reproduce the problem (a May 25 kernel failed to umount the slice). Bye, Alexander. -- ...and that is how we know the Earth to be banana-shaped. http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
On Sun, Jun 01, 2003 at 03:00:09PM +0200, Bernd Walter wrote:
On Sun, Jun 01, 2003 at 02:26:34AM -0700, Luigi Rizzo wrote:
On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote:
...
:)
And I hoped a programmer who knows the source could find out and fix
very quickly.
sorry, i missed the offending line number in your previous email.
I think i missed a in all the first arguments to bcopy in
the src/sbin/ipfw2.c changes :(
this happens at lines 818, 1224, 1461 and 1701. Fortunately
the kernel part seems correct.
In detail, the fix should be the following:
818:
- bcopy(rule-next_rule, set_disable, sizeof(set_disable));
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
1224:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
1461:
- bcopy(((struct ip_fw *)data)-next_rule,
+ bcopy(((struct ip_fw *)data)-next_rule,
1701:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
Look way bettter now :)
I wasn't able to crash the kernel with missaligned access any more, but
the userland tool still does in some situations:
[59]cicely12# ipfw show
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc
op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120003bdc ra=0x120003bc8
op=ldq
001005237 824333 allow tcp from any to any dst-port 1-65535,1-65535
00200 0 0 allow tcp from any to any dst-port 1-65535,1-65535,1-65535
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120002260 ra=0x1200015ec
op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120002264 ra=0x1200015ec
op=ldq
65535 5836817 1002036976 allow ip from any to any
I'm currently using the attached diff to ipfw2.c + your other changes.
It seems to work now.
I hope that I catched all missalignemts that were missing.
Thanks for the work on this.
I'm very happy to see this running on alpha.
--
B.Walter BWCThttp://www.bwct.de
[EMAIL PROTECTED] [EMAIL PROTECTED]
Index: ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.23
diff -u -r1.23 ipfw2.c
--- ipfw2.c 15 Mar 2003 01:12:59 - 1.23
+++ ipfw2.c 2 Jun 2003 13:22:30 -
@@ -348,6 +348,14 @@
{ NULL, 0 }
};
+static __inline u_int64_t
+align_uint64(u_int64_t *pll) {
+ u_int64_t ret;
+
+ bcopy (pll, ret, sizeof(ret));
+ return ret;
+};
+
/**
* match_token takes a table and a string, returns the value associated
* with the string (0 meaning an error in most cases)
@@ -813,8 +821,9 @@
int flags = 0; /* prerequisites */
ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */
int or_block = 0; /* we are in an or block */
+ u_int32_t set_disable;
- u_int32_t set_disable = rule-set_disable;
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
if (set_disable (1 rule-set)) { /* disabled */
if (!show_sets)
@@ -825,8 +834,8 @@
printf(%05u , rule-rulenum);
if (do_acct)
- printf(%*llu %*llu , pcwidth, rule-pcnt, bcwidth,
- rule-bcnt);
+ printf(%*llu %*llu , pcwidth, align_uint64(rule-pcnt),
+ bcwidth, align_uint64(rule-bcnt));
if (do_time) {
char timestr[30];
@@ -1213,13 +1222,16 @@
{
struct protoent *pe;
struct in_addr a;
+ uint16_t rulenum;
if (!do_expired) {
if (!d-expire !(d-dyn_type == O_LIMIT_PARENT))
return;
}
- printf(%05d %*llu %*llu (%ds), d-rulenum, pcwidth, d-pcnt, bcwidth,
+ bcopy(d-rule, rulenum, sizeof(rulenum));
+
+ printf(%05d %*llu %*llu (%ds), rulenum, pcwidth, d-pcnt, bcwidth,
d-bcnt, d-expire);
switch (d-dyn_type) {
case O_LIMIT_PARENT:
@@ -1454,7 +1466,9 @@
err(EX_OSERR, malloc);
if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, nbytes) 0)
err(EX_OSERR, getsockopt(IP_FW_GET));
- set_disable = ((struct ip_fw *)data)-set_disable;
+ bcopy(((struct ip_fw *)data)-next_rule,
+ set_disable, sizeof(set_disable));
+
for (i = 0, msg = disable ; i 31; i++)
if ( (set_disable (1i))) {
@@ -1620,23 +1634,27 @@
for (n = 0, r = data; n nstat;
n++, r = (void *)r + RULESIZE(r)) {
/* packet counter */
- width = snprintf(NULL, 0, %llu, r-pcnt);
+ width = snprintf(NULL, 0, %llu,
+
Re: 5.2-RELEASE TODO
On Mon, 2 Jun 2003, Daniel C. Sobral wrote: Actually, I would think it a desirable feature mac support that won't panic within 24 hours. :-) I've given up on mac again. Can't have it if it panics on every daily. :-( What's the plans for dealing with that? Right now I'm aware of one panic that shows up only if labeled MAC policies are linked to the kernel, rather than loaded as modules during the boot process. Currently, it manifests when multiple applications open sockets listening on the same UDP port, and may relate to multiple delivery of mbufs; this panic does not occur when using the modules, however. I'm still tracking down the details. We corrected the compat/linux/dev/null panic (or at least, eliminated it) -- this turned out to be a bug in UFS2 that can be triggered without the use of MAC. Are there are additional panics you're experiencing? Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Mon, Jun 02, 2003 at 03:31:49PM +0300, Petri Helenius [EMAIL PROTECTED] wrote: FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. This is only my opinion and I don't want to offend anyone. IMO, software does not magically get better but it must be actively being used and problems reported and fixed in reasonable time. So if 5.x never gets users it never gets production quality. As do I, but I initially thought you needed stable platform. I vaguely remember your mails about some network related things etc. which seemed to indicate such need. I've sent you personal reply. Sorry. -- Vallo Kallaste ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
Hiten Pandya wrote: My fingers have been itching to do this since the day phk@ planted this idea in my brain (re: cdevsw initialisations). Basically, it changes the vfsops to use C99 sparse format, just like cdevsw. It removes a lot of junk default initialisations, and duplication. I really dislike the changes to vfs_init(). Specifically, it's not the overhead, so much as it's the implied side effects. Consider this going forward: someone adds a new VFSOP to the list of allowable VFSOPs, and the vfs_init() doesn't have any specific code for it. This could happen with a new VFS implementation that gets loaded as a module. While the current code can't really handle this well, the changes move us further away from ever being able to handle something like this. 8-(. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
On Mon, Jun 02, 2003 at 08:17:03AM -0700, Terry Lambert wrote: Hiten Pandya wrote: My fingers have been itching to do this since the day phk@ planted this idea in my brain (re: cdevsw initialisations). Basically, it changes the vfsops to use C99 sparse format, just like cdevsw. It removes a lot of junk default initialisations, and duplication. I really dislike the changes to vfs_init(). Specifically, it's not the overhead, so much as it's the implied side effects. And how many times is vfc_register() called? Its not in the patch of an I/O operation or anything. Its just a mount time overhead which will go through -- a one time thing. Consider this going forward: someone adds a new VFSOP to the list of allowable VFSOPs, and the vfs_init() doesn't have any specific code for it. Considered. Now consider this, would you argue this about the sparse cdevsw initialisation in make_dev()? I hardly think so. It does a good job of centralising things, and making it easier for all of us. This could happen with a new VFS implementation that gets loaded as a module. While the current code can't really handle this well, the changes move us further away from ever being able to handle something like this. 8-(. But, up to now, this has not been a problem, unless you make it so. I don't think I even needed to add conditional checks for the mount and nmount ops in vfs_init. These are things which would be fault of developer if he doesn't update the `centralised' code, not yours or mine, or FreeBSD's. I also don't see the point of having a gazillion default ops being inited in every fs specific vector when we can just do this centrally. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenOffice-devel: repeatable coredump with sun autodoc in libstd++
Hi all, I'm still working to get OpenOffice1.1Beta2 ready, but am now stuck with a segfault. The compile currently aborts on many places where -frtti is used, so everybody is using -fno-rtti these days. But here I get serious trouble with autodoc ... For some strange reason it didn't happen with -frtti, it happens only with -fno-rtti. Segmentation fault (core dumped) dmake: Error code 139, while making '../../unxfbsd.pro/bin/OpenOffice.org1.1_Beta_2_SDK/docs/common/ref/module-ix.html' ---* RULES.MK *--- ERROR: Error 65280 occurred while making /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/odk/pack/gendocu fuchur# gdb /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/solver/644/unxfbsd.pro/bin/autodoc ./pack/gendocu/autodoc.core GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... Core was generated by `autodoc'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/lib/libkse.so.1...done. Loaded symbols for /usr/lib/libkse.so.1 Reading symbols from /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/solver/644/unxfbsd.pro/lib/libstlport_gcc.so...done. Loaded symbols for /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/solver/644/unxfbsd.pro/lib/libstlport_gcc.so Reading symbols from /usr/lib/libstdc++.so.4...done. Loaded symbols for /usr/lib/libstdc++.so.4 Reading symbols from /usr/lib/libm.so.2...done. Loaded symbols for /usr/lib/libm.so.2 Reading symbols from /usr/lib/libc.so.5...done. Loaded symbols for /usr/lib/libc.so.5 Reading symbols from /usr/libexec/ld-elf.so.1...done. Loaded symbols for /usr/libexec/ld-elf.so.1 #0 __dynamic_cast (src_ptr=0x826c9d0, src_type=0x815baa8, dst_type=0x815ba9c, src2dst=0) at /usr/src/contrib/libstdc++/libsupc++/tinfo.cc:696 696 whole_type-__do_dyncast (src2dst, __class_type_info::__contained_public, (gdb) bt #0 __dynamic_cast (src_ptr=0x826c9d0, src_type=0x815baa8, dst_type=0x815ba9c, src2dst=0) at /usr/src/contrib/libstdc++/libsupc++/tinfo.cc:696 #1 0x081399cd in csi::dsapi::SapiDocu_PE::SetCurSeeAlsoAtTagLinkText(ary::info::DocuToken) (this=0x81a6500, [EMAIL PROTECTED]) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/parser_i/idoc/docu_pe2.cxx:393 #2 0x081394e0 in csi::dsapi::SapiDocu_PE::Process_Word(csi::dsapi::Tok_Word const) (this=0x81a6500, [EMAIL PROTECTED]) at d_token.hxx:101 #3 0x0813b58a in csi::dsapi::Tok_Word::Trigger(csi::dsapi::TokenInterpreter) const (this=0x826c850, [EMAIL PROTECTED]) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/parser_i/idoc/tk_docw2.cxx:79 #4 0x08137e46 in csi::dsapi::SapiDocu_PE::ProcessToken(csi::dsapi::Token) (this=0x81a6500, [EMAIL PROTECTED]) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/parser_i/idoc/docu_pe2.cxx:122 #5 0x08120643 in csi::uidl::TokenDistributor::Documentation::Receive(csi::dsapi::Token) (this=0x81b3584, [EMAIL PROTECTED]) at template/dyn.hxx:218 #6 0x08136720 in csi::dsapi::Context_Docu::PassNewToken() (this=0x0) at template/dyn.hxx:237 #7 0x0811cf09 in TokenParse2::GetNextToken() (this=0x821ff90) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/parser_i/tokens/tkp2.cxx:90 #8 0x0811fba5 in csi::uidl::TokenDistributor::TradeToken() (this=0x81b3544) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/parser_i/idl/distrib.cxx:102 #9 0x081343bf in autodoc::FileParsePerformers::ParseFile(char const*) (this=0x81b3500, i_sFullPath=0x81c8000 ./../../unxfbsd.pro/bin/OpenOffice.org1.1_Beta_2_SDK/idl/com/sun/star/beans/PropertySetInfoChangeEvent.idl) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/parser_i/idl/unoidl.cxx:178 #10 0x08133e5c in autodoc::IdlParser::Run(autodoc::FileCollector_Ifc const) (this=0x81b8670, [EMAIL PROTECTED]) at template/dyn.hxx:218 #11 0x08063de5 in autodoc::command::run::Parser::Perform() (this=0xbfbfe3d0) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/exes/adc_uni/cmd_run.cxx:156 #12 0x08061a58 in autodoc::command::Parse::do_Run() const (this=0x81b0180) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/exes/adc_uni/adc_cmd_parse.cxx:267 #13 0x0805e7af in autodoc::CommandLine::Run() const (this=0xbfbfe430) at adc_cmd.hxx:135 #14 0x0805e44c in main (argc=13, argv=0xbfbfe490) at /usr/ports/editors/openoffice-devel-fixed/work/oo_644_src/autodoc/source/exes/adc_uni/main.cxx:83 #15 0x0805e335 in _start () (gdb) frame 0 #0 __dynamic_cast (src_ptr=0x826c9d0, src_type=0x815baa8, dst_type=0x815ba9c,
Re: VFS: C99 sparse format for struct vfsops
Hiten Pandya wrote: Consider this going forward: someone adds a new VFSOP to the list of allowable VFSOPs, and the vfs_init() doesn't have any specific code for it. Considered. Now consider this, would you argue this about the sparse cdevsw initialisation in make_dev()? I hardly think so. It does a good job of centralising things, and making it easier for all of us. This is a different thing entirely... you are not adding elements in the cdevsw case. The VFSOP case is less of a problem than the VOP case, but it's still a problem. Poul broke the VOP case a long time ago, when he added the default stuff, since there is no way to add a new default to an already existing array, and the entries with a default can't be proxied (e.g. over the network or to user space via a descriptor, per John Heidemann's original design for VFS stacking in UCLS's FICUS). By making this change, you are basically changing it from a data structure to something that has to be coded, and there's no way to add code for a new entry that needs to be defaulted to a non-NULL value -- which they all have to be. This could happen with a new VFS implementation that gets loaded as a module. While the current code can't really handle this well, the changes move us further away from ever being able to handle something like this. 8-(. But, up to now, this has not been a problem, unless you make it so. I don't think I even needed to add conditional checks for the mount and nmount ops in vfs_init. These are things which would be fault of developer if he doesn't update the `centralised' code, not yours or mine, or FreeBSD's. I also don't see the point of having a gazillion default ops being inited in every fs specific vector when we can just do this centrally. As I said above: Poul broke this for VOPs. It doesn't make sense to say It's broken for VOPs now, so it's OK to break it for VFSOPs, too. It's not been a problem, as you say, so far, because the VFS stacking in FreeBSD has been broken for a long time. Breaking it more just moves us farther away from ever fixing the code, which I think is a bad thing. If, at some point, we get rid of the default crap, then it would be possible to add VOPs to a running kernel by just reallocating the VOP array for each mounted FS to add the entry to the end of the array. Your change makes this impossible for VFSOPS. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Pedantic and Werror together...
Pete Carah wrote: pedantic and Werror together cause problems again... I presume we really need the quad type here. (or is this one due to a compiler upgrade?) -pedantic is broken in a number of ways and has been for a long time. While it is still useful for occasional linting, combining it with -Werror in routine builds is just asking for grief. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
PAM
Hello. I'm using Kerberos (heimdal) and off course it uses PAM. It's working well but I want to know if is the way to change kerberos password through PAM, not using kpasswd command? Or maybe it's even possible to synchronize kerberos and UNIX passwords? Can someone help me? Pawel Doncer. (please forgive me poor English) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
Ouch, this is a serious bug indeed. I apologize if you reported this before and I missed it. I'll look at it today. Other than this bug (which appears to only be related to the management app), are there any other problems with aac? Note that aac is one of the few cards that even supports a management app! Scott Petri Helenius wrote: So far I´ve tried asr and aac, both cards end up in kernel panics and/or array hang in a few minutes (multiple hardware platforms so I don´t think the motherboard is to blame) After the bad experience with asr I thought I give aac a try with somewhat similar results. And asr does not work with 4G machines anyway (although I don´t put that amount of memory in the servers now, I don´t want to generate a barrier because of a disk controller) Judging from the limited set of responses, Mylex stuff seems to work. My offer to help you to debug the aac code is still valid. You mean this one as shot in the dark? I got this when configuring an array on 5.1-BETA and aaccli: lock order reversal 1st 0xc2671134 AAC sync FIB lock (AAC sync FIB lock) @ /usr/src/sys/dev/aac/aac.c:1703 2nd 0xc03f5f20 Giant (Giant) @ vm/vm_fault.c:210 Stack backtrace: backtrace(c0397297,c03f5f20,c0393ecb,c0393ecb,c03a4e34) at backtrace+0x17 witness_lock(c03f5f20,8,c03a4e34,d2,d1d33ad8) at witness_lock+0x697 _mtx_lock_flags(c03f5f20,0,c03a4e2b,d2,2) at _mtx_lock_flags+0xb1 vm_fault(c03f1940,0,1,0,c267) at vm_fault+0x59 trap_pfault(d1d33c70,0,8,d1d33c40,8) at trap_pfault+0xef trap(18,c2670010,c2670010,d26402a4,c2671000) at trap+0x39d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc24e5959, esp = 0xd1d33cb0, ebp = 0xd1d33ce0 --- aac_handle_aif(c2671000,d2640284,d1d33cfc,d1d33d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2671000,d1d33d48,c0392341,310,0) at aac_command_thread+0x179 fork_exit(c24e36c0,c2671000,d1d33d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d33d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc31f3959 stack pointer = 0x10:0xd1d39cb0 frame pointer = 0x10:0xd1d39ce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 550 (aac0aif) kernel: type 12 trap, code=0 Stopped at aac_handle_aif+0x139: cmpl0x8(%edx),%ecx db trace aac_handle_aif(c2679000,d2635284,d1d39cfc,d1d39d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2679000,d1d39d48,c0392341,310,c2670260) at aac_command_thread+0x179 fork_exit(c31f16c0,c2679000,d1d39d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d39d7c, ebp = 0 --- db Before that I got some message on GEOM not being properly locked but that scrolled off buffer before I could catch it. Pete - Original Message - From: Scott Long [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: Tim Robbins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 01, 2003 11:20 PM Subject: Re: raidframe Petri Helenius wrote: RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete Just settle down a bit. If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. As for hardware raid, what cards have you tried, and what problems have you experienced? You last message was jsut a shot in the dark that few of us would be able to help with. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
Sent to you, Mark and obrien on 15th May. Didn´t copy lists nor did a send-pr. Suggestions for future bug reporting appreciated. Ouch, this is a serious bug indeed. I apologize if you reported this before and I missed it. I'll look at it today. Other than this bug (which appears to only be related to the management app), are there any other problems with aac? Note that aac is one of the few cards that even supports a management app! I returned the card, they only had 14 day return policy. I didn´t spend more time with the card since after reporting the bug I didn´t get any replies and without a management utility the card would be useless for me anyway. I´ll ask them for another loaner if needed. While we´re at it, what´s the utility command to turn off the alarm on the card? It got annoying after a while practising pulling out drives :-) Pete Scott Petri Helenius wrote: So far I´ve tried asr and aac, both cards end up in kernel panics and/or array hang in a few minutes (multiple hardware platforms so I don´t think the motherboard is to blame) After the bad experience with asr I thought I give aac a try with somewhat similar results. And asr does not work with 4G machines anyway (although I don´t put that amount of memory in the servers now, I don´t want to generate a barrier because of a disk controller) Judging from the limited set of responses, Mylex stuff seems to work. My offer to help you to debug the aac code is still valid. You mean this one as shot in the dark? I got this when configuring an array on 5.1-BETA and aaccli: lock order reversal 1st 0xc2671134 AAC sync FIB lock (AAC sync FIB lock) @ /usr/src/sys/dev/aac/aac.c:1703 2nd 0xc03f5f20 Giant (Giant) @ vm/vm_fault.c:210 Stack backtrace: backtrace(c0397297,c03f5f20,c0393ecb,c0393ecb,c03a4e34) at backtrace+0x17 witness_lock(c03f5f20,8,c03a4e34,d2,d1d33ad8) at witness_lock+0x697 _mtx_lock_flags(c03f5f20,0,c03a4e2b,d2,2) at _mtx_lock_flags+0xb1 vm_fault(c03f1940,0,1,0,c267) at vm_fault+0x59 trap_pfault(d1d33c70,0,8,d1d33c40,8) at trap_pfault+0xef trap(18,c2670010,c2670010,d26402a4,c2671000) at trap+0x39d calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc24e5959, esp = 0xd1d33cb0, ebp = 0xd1d33ce0 --- aac_handle_aif(c2671000,d2640284,d1d33cfc,d1d33d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2671000,d1d33d48,c0392341,310,0) at aac_command_thread+0x179 fork_exit(c24e36c0,c2671000,d1d33d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d33d7c, ebp = 0 --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x8 fault code = supervisor read, page not present instruction pointer = 0x8:0xc31f3959 stack pointer = 0x10:0xd1d39cb0 frame pointer = 0x10:0xd1d39ce0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 550 (aac0aif) kernel: type 12 trap, code=0 Stopped at aac_handle_aif+0x139: cmpl0x8(%edx),%ecx db trace aac_handle_aif(c2679000,d2635284,d1d39cfc,d1d39d00,7d0) at aac_handle_aif+0x139 aac_command_thread(c2679000,d1d39d48,c0392341,310,c2670260) at aac_command_thread+0x179 fork_exit(c31f16c0,c2679000,d1d39d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xd1d39d7c, ebp = 0 --- db Before that I got some message on GEOM not being properly locked but that scrolled off buffer before I could catch it. Pete - Original Message - From: Scott Long [EMAIL PROTECTED] To: Petri Helenius [EMAIL PROTECTED] Cc: Tim Robbins [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Sunday, June 01, 2003 11:20 PM Subject: Re: raidframe Petri Helenius wrote: RAIDframe is non-functional in 5.1 and -current [kern/50541] and it would be unwise to use it in 5.0 for anything other than experimentation. Hopefully it will be fixed before 5.2. Makes one wonder how broken code ever got into the tree in the first place... Pete Just settle down a bit. If you rewind to last October, RAIDFrame worked well. Unfortunately, some kernel interfaces changed in between now and then and RAIDFrame was left behind. I am remis in not fixing it, but please understand that I also have quite a few other responsibilities, and I get paid $0 to work on RAIDframe. As for hardware raid, what cards have you tried, and what problems have you experienced? You last message was jsut a shot in the dark that few of us would be able to help with. Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Polishing touch
here what is (probably) going on. when system starts up you have no tap0 interface. ifconfig(8) can not find tap0 interface and hmmm, dunno, long before ifconfig I get : tap0: bpf attached now the thing about tap(4) (and tun(4)) interfaces is that they are *virtual*, i.e. in order to create interface one need to open corresponding character device first, i.e. /dev/tapX (or /dev/tunX). yip; NB, I think we should concentrate on tun0 anyway, since device tun is in GENERIC, whilst tap0 is a hack of mine ... Arno ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
OpenSSL CA.pl only in src dir?
Hi,
is there any reason, why
/usr/src/crypto/openssl/apps/CA.{sh,pl}
are not installed outside /usr/src?
Some end users may not install src,
yet still need this wrapper...
Thanks,
-FH
--
Farid Hajji -- Unix Systems and Network Management.
http://www.farid-hajji.net/address.html
Quoth the Raven, Nevermore. --Edgar Allan Poe.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
vm stuff
Mon Jun 2 14:46:26 EDT 2003 lock order reversal 1st 0xc2a67250 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:509 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:325 Stack backtrace on request. uname -a FreeBSD zeebo 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Mon Jun 2 12:32:15 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TK i386 Dell OptiPlex PIV 1.2 G 512 RAM cvsupped and built this AM ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: raidframe
On Mon, 2 Jun 2003 08:09:17 +0300, Vallo Kallaste [EMAIL PROTECTED] said: FreeBSD 5.x series is slowly progressing, but is nowhere near to production quality. As the things are currently, you simply waste your time. I'm running an old 5.1-current and a more recent 5.1-beta of about a week ago in production as news servers and am reasonably pleased with the results. Other than the cvsup mirror I don't have any more intensive test workload than that. The 5.1-beta installation replaced a W2K Advanced Server running NNTPRelay, and so far it's stayed up three whole days, which is a hell of a lot longer than W2K ever did. 5.x is getting there. It has been stable enough for desktop use for a long time, and now the rest of the system is catching up. -GAWollman ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote:
David P. Reese Jr. [EMAIL PROTECTED] writes:
In rev 1.214 of sys/dev/pci/pci.c, we have started checking if a
pci_set_command_bit() was successful with a subsequent PCI_READ_CONFIG
and comparing the results. For some odd reason, this doesnt work when
my viapropm tries to attach.
viapropm is seriously broken for other reasons and needs professional
help.
What kind of breakage? Setting resources in probe? Right. Anybody having
the viapm driver loaded usually should please try the attached patch.
pci_set_command_bit(dev, child, bit);
command = PCI_READ_CONFIG(dev, child, PCIR_COMMAND, 2);
if (command bit)
return (0);
It should allow the register to settle between write and read, which
may take some time (see chipset docs for timing details). DELAY(1000)
should be OK in an attach function.
The datasheet states that the command bits are RW but fixed at 0.
Nicholas
--
Nicholas Souchu - [EMAIL PROTECTED] - [EMAIL PROTECTED]
Index: viapm.c
===
RCS file: /home/ncvs/src/sys/pci/viapm.c,v
retrieving revision 1.2
diff -u -r1.2 viapm.c
--- viapm.c 9 Nov 2002 20:13:16 - 1.2
+++ viapm.c 25 May 2003 22:00:03 -
@@ -79,7 +79,6 @@
#define VIAPM_TYP_8233 5
struct viapm_softc {
- int type;
u_int32_t base;
bus_space_tag_t st;
bus_space_handle_t sh;
@@ -179,137 +178,42 @@
static int
viapm_586b_probe(device_t dev)
{
- struct viapm_softc *viapm = (struct viapm_softc *)device_get_softc(dev);
- u_int32_t l;
- u_int16_t s;
- u_int8_t c;
+ if (pci_get_devid(dev) != VIA_586B_PMU_ID)
+ return ENXIO;
- switch (pci_get_devid(dev)) {
- case VIA_586B_PMU_ID:
-
- bzero(viapm, sizeof(struct viapm_softc));
-
- l = pci_read_config(dev, VIAPM_586B_REVID, 1);
- switch (l) {
- case VIAPM_586B_OEM_REV_E:
- viapm-type = VIAPM_TYP_586B_3040E;
- viapm-iorid = VIAPM_586B_3040E_BASE;
-
- /* Activate IO block access */
- s = pci_read_config(dev, VIAPM_586B_3040E_ACTIV, 2);
- pci_write_config(dev, VIAPM_586B_3040E_ACTIV, s | 0x1, 2);
- break;
-
- case VIAPM_586B_OEM_REV_F:
- case VIAPM_586B_PROD_REV_A:
- default:
- viapm-type = VIAPM_TYP_586B_3040F;
- viapm-iorid = VIAPM_586B_3040F_BASE;
-
- /* Activate IO block access */
- c = pci_read_config(dev, VIAPM_586B_3040F_ACTIV, 1);
- pci_write_config(dev, VIAPM_586B_3040F_ACTIV, c | 0x80, 1);
- break;
- }
-
- viapm-base = pci_read_config(dev, viapm-iorid, 4)
- VIAPM_586B_BA_MASK;
-
- /*
-* We have to set the I/O resources by hand because it is
-* described outside the viapmope of the traditional maps
-*/
- if (bus_set_resource(dev, SYS_RES_IOPORT, viapm-iorid,
- viapm-base, 256)) {
- device_printf(dev, could not set bus resource\n);
- return ENXIO;
- }
- device_set_desc(dev, VIA VT82C586B Power Management Unit);
- return 0;
-
- default:
- break;
- }
-
- return ENXIO;
+ device_set_desc(dev, VIA VT82C586B Power Management Unit);
+ return 0;
}
-
static int
viapm_pro_probe(device_t dev)
{
- struct viapm_softc *viapm = (struct viapm_softc *)device_get_softc(dev);
-#ifdef VIAPM_BASE_ADDR
- u_int32_t l;
-#endif
- u_int32_t base_cfgreg;
char *desc;
switch (pci_get_devid(dev)) {
case VIA_596A_PMU_ID:
desc = VIA VT82C596A Power Management Unit;
- viapm-type = VIAPM_TYP_596B;
- base_cfgreg = VIAPM_PRO_BASE;
- goto viapro;
+ break;
case VIA_596B_PMU_ID:
desc = VIA VT82C596B Power Management Unit;
- viapm-type = VIAPM_TYP_596B;
- base_cfgreg = VIAPM_PRO_BASE;
- goto viapro;
+ break;
case VIA_686A_PMU_ID:
desc = VIA VT82C686A Power Management Unit;
- viapm-type = VIAPM_TYP_686A;
- base_cfgreg = VIAPM_PRO_BASE;
- goto viapro;
+ break;
case VIA_8233_PMU_ID:
desc = VIA VT8233 Power Management Unit;
- viapm-type = VIAPM_TYP_UNKNOWN;
- base_cfgreg = VIAPM_8233_BASE;
- goto viapro;
-
-
phoenix crash in libc_r on sparc64
phoenix on my sparc64 crashed while idle with the following: Fatal error '_waitq_insert: Already in queue' at line 321 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 2) Any ideas? Kris pgp0.pgp Description: PGP signature
Re: VFS: C99 sparse format for struct vfsops
On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote: This is a different thing entirely... you are not adding elements in the cdevsw case. Er, huh? Did you read Poul's HEADSUP mail for cdevsw sparse init? The VFSOP case is less of a problem than the VOP case, but it's still a problem. Poul broke the VOP case a long time ago, when he added the default stuff, since there is no way to add a new default to an already existing array, and the entries with a default can't be proxied (e.g. over the network or to user space via a descriptor, per John Heidemann's original design for VFS stacking in UCLS's FICUS). OK, we are moving away from UCLS' FICUS. Could you kindly provide me with some examples, and practicle use of this ``adding'' a new default in an already existing array? By making this change, you are basically changing it from a data structure to something that has to be coded, and there's no way to add code for a new entry that needs to be defaulted to a non-NULL value -- which they all have to be. Huh? Come again please? Could you ellaborate on this point as it is sending me in circles. I don't see how it is not possible to do that, please provide a practical case, so I can understand. As I said above: Poul broke this for VOPs. It doesn't make sense to say It's broken for VOPs now, so it's OK to break it for VFSOPs, too. ... It's not been a problem, as you say, so far, because the VFS stacking in FreeBSD has been broken for a long time. Breaking it more just moves us farther away from ever fixing the code, which I think is a bad thing. That is such of a broad statement..= If, at some point, we get rid of the default crap, then it would be possible to add VOPs to a running kernel by just reallocating the VOP array for each mounted FS to add the entry to the end of the array. And here is the question again, why would you want to add VOPs to a running kernel? Please provide some examples, or practical cases. Your change makes this impossible for VFSOPS. Awaiting your reply... Cheers. -- Hiten ([EMAIL PROTECTED]) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
umtx/libthr SMP fixes.
If you have had issues with libthr on SMP or umtx panics, the following patch may solve these issues. http://www.chesapeake.net/~jroberson/umtxlocks.diff This patch fixes several race conditions and other issues with umtx. Thanks, Jeff ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remove absolute symlink in $MAKEOBJDIR
At Mon, 2 Jun 2003 10:10:26 + (UTC),
Bruce Evans wrote:
As marcel pointed out, there are technical reasons for not using cp.
Use cat.
OK, thanks!
(2) Use correct dependency in sys/boot/i386/kgzldr.
This is too hackish for me. Try using the same method as for lib/csu.
I think you nmainly care about make install building things. This is
from longstanding brokenness of installation of man pages which was
cloned to brokenness of installation of FILES.
Hmm, like this? I don't know which owner and mode should be used at
realinstall stage.
Index: Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/kgzldr/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- Makefile30 Sep 2002 20:37:57 - 1.12
+++ Makefile3 Jun 2003 03:41:02 -
@@ -1,6 +1,5 @@
# $FreeBSD: src/sys/boot/i386/kgzldr/Makefile,v 1.12 2002/09/30 20:37:57 peter Exp $
-FILES= kgzldr.o
SRCS= start.s boot.c inflate.c lib.c crt.s sio.s
OBJS= ${SRCS:N*.h:R:S/$/.o/g}
CFLAGS=-ffreestanding
@@ -15,7 +14,13 @@
BOOT_COMCONSOLE_PORT?= 0x3f8
AFLAGS+=--defsym SIO_PRT=${BOOT_COMCONSOLE_PORT}
+all: ${OBJS} kgzldr.o
+
kgzldr.o: ${OBJS}
${CC} ${LDFLAGS} -o ${.TARGET} ${OBJS}
+
+realinstall:
+ ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${LIBMODE} \
+ kgzldr.o ${DESTDIR}${BINDIR}
.include bsd.prog.mk
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenOffice-devel: repeatable coredump with sun autodoc inlibstd++
In message: [EMAIL PROTECTED] Martin Blapp [EMAIL PROTECTED] writes: : I'm still working to get OpenOffice1.1Beta2 ready, but am now stuck with : a segfault. The compile currently aborts on many places where -frtti is : used, so everybody is using -fno-rtti these days. But here I get serious : trouble with autodoc ... : : For some strange reason it didn't happen with -frtti, it happens only with : -fno-rtti. -frtti is required for dynamic_castT(expr) to work. so if it is broken, then you've got big problems. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Radeon VE 7000 VGA card support under xfree86 4.3.0
Hello, Thanks for the advices of the mailing group. I finally figure out the problem of my previous mail concerning the X under XFree86 4.3.0 with Freebsd-5.1 beta 2. I use the same VGA card with the crt mon and everything work ok without extra work for the X-config file. The problem may be the refresh rate of the LCD is too slow for the VGA card to pick up. I would like to know if there exists any method that would fix the problem. Thanks for your effort. Clarence _ No masks required! Use MSN Messenger to chat with friends and family. http://go.msnserver.com/HK/25382.asp ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.1-RELEASE TODO
Where do we stand on this now? Is this ready for committing? Is it
completely solved?
Scott
Bernd Walter wrote:
On Sun, Jun 01, 2003 at 03:00:09PM +0200, Bernd Walter wrote:
On Sun, Jun 01, 2003 at 02:26:34AM -0700, Luigi Rizzo wrote:
On Sun, Jun 01, 2003 at 03:32:56AM +0200, Bernd Walter wrote:
...
:)
And I hoped a programmer who knows the source could find out and fix
very quickly.
sorry, i missed the offending line number in your previous email.
I think i missed a in all the first arguments to bcopy in
the src/sbin/ipfw2.c changes :(
this happens at lines 818, 1224, 1461 and 1701. Fortunately
the kernel part seems correct.
In detail, the fix should be the following:
818:
- bcopy(rule-next_rule, set_disable, sizeof(set_disable));
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
1224:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
1461:
- bcopy(((struct ip_fw *)data)-next_rule,
+ bcopy(((struct ip_fw *)data)-next_rule,
1701:
- bcopy(d-rule, rulenum, sizeof(rulenum));
+ bcopy(d-rule, rulenum, sizeof(rulenum));
Look way bettter now :)
I wasn't able to crash the kernel with missaligned access any more, but
the userland tool still does in some situations:
[59]cicely12# ipfw show
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120003bb4 ra=0x120003bfc op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120003bdc ra=0x120003bc8 op=ldq
001005237 824333 allow tcp from any to any dst-port 1-65535,1-65535
00200 0 0 allow tcp from any to any dst-port 1-65535,1-65535,1-65535
pid 2121 (ipfw): unaligned access: va=0x1200ac09c pc=0x120002260 ra=0x1200015ec op=ldq
pid 2121 (ipfw): unaligned access: va=0x1200ac0a4 pc=0x120002264 ra=0x1200015ec op=ldq
65535 5836817 1002036976 allow ip from any to any
I'm currently using the attached diff to ipfw2.c + your other changes.
It seems to work now.
I hope that I catched all missalignemts that were missing.
Thanks for the work on this.
I'm very happy to see this running on alpha.
Index: ipfw2.c
===
RCS file: /home/ncvs/src/sbin/ipfw/ipfw2.c,v
retrieving revision 1.23
diff -u -r1.23 ipfw2.c
--- ipfw2.c 15 Mar 2003 01:12:59 - 1.23
+++ ipfw2.c 2 Jun 2003 13:22:30 -
@@ -348,6 +348,14 @@
{ NULL, 0 }
};
+static __inline u_int64_t
+align_uint64(u_int64_t *pll) {
+ u_int64_t ret;
+
+ bcopy (pll, ret, sizeof(ret));
+ return ret;
+};
+
/**
* match_token takes a table and a string, returns the value associated
* with the string (0 meaning an error in most cases)
@@ -813,8 +821,9 @@
int flags = 0; /* prerequisites */
ipfw_insn_log *logptr = NULL; /* set if we find an O_LOG */
int or_block = 0; /* we are in an or block */
+ u_int32_t set_disable;
- u_int32_t set_disable = rule-set_disable;
+ bcopy(rule-next_rule, set_disable, sizeof(set_disable));
if (set_disable (1 rule-set)) { /* disabled */
if (!show_sets)
@@ -825,8 +834,8 @@
printf(%05u , rule-rulenum);
if (do_acct)
- printf(%*llu %*llu , pcwidth, rule-pcnt, bcwidth,
- rule-bcnt);
+ printf(%*llu %*llu , pcwidth, align_uint64(rule-pcnt),
+ bcwidth, align_uint64(rule-bcnt));
if (do_time) {
char timestr[30];
@@ -1213,13 +1222,16 @@
{
struct protoent *pe;
struct in_addr a;
+ uint16_t rulenum;
if (!do_expired) {
if (!d-expire !(d-dyn_type == O_LIMIT_PARENT))
return;
}
- printf(%05d %*llu %*llu (%ds), d-rulenum, pcwidth, d-pcnt, bcwidth,
+ bcopy(d-rule, rulenum, sizeof(rulenum));
+
+ printf(%05d %*llu %*llu (%ds), rulenum, pcwidth, d-pcnt, bcwidth,
d-bcnt, d-expire);
switch (d-dyn_type) {
case O_LIMIT_PARENT:
@@ -1454,7 +1466,9 @@
err(EX_OSERR, malloc);
if (getsockopt(s, IPPROTO_IP, IP_FW_GET, data, nbytes) 0)
err(EX_OSERR, getsockopt(IP_FW_GET));
- set_disable = ((struct ip_fw *)data)-set_disable;
+ bcopy(((struct ip_fw *)data)-next_rule,
+ set_disable, sizeof(set_disable));
+
for (i = 0, msg = disable ; i 31; i++)
if ( (set_disable (1i))) {
@@ -1620,23 +1634,27 @@
for (n = 0, r = data; n nstat;
n++, r = (void *)r + RULESIZE(r)) {
/* packet counter */
- width = snprintf(NULL, 0, %llu, r-pcnt);
+ width = snprintf(NULL, 0, %llu,
+ align_uint64(r-pcnt));
if (width pcwidth)
pcwidth = width;
/* byte counter */
- width = snprintf(NULL, 0, %llu, r-bcnt);
+ width = snprintf(NULL, 0, %llu,
+ align_uint64(r-bcnt));
if (width bcwidth)
bcwidth = width;
}
}
if (do_dynamic ndyn) {
for (n = 0, d = dynrules; n ndyn; n++, d++) {
- width = snprintf(NULL, 0, %llu, d-pcnt);
+ width = snprintf(NULL, 0, %llu,
+ align_uint64(d-pcnt));
if (width pcwidth)
pcwidth = width;
- width = snprintf(NULL, 0, %llu,
whats an UDMA ICRC error ?
Hi, my console today shows the following error message from my disk: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? Here the output of uname -a and dmesg FreeBSD titan.klemm.apsfilter.org 5.1-RC FreeBSD 5.1-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 i386 Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RC #0: Sun Jun 1 14:21:32 CEST 2003 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/TITAN5 Preloaded elf kernel /boot/kernel/kernel at 0xc04b3000. Preloaded elf module /boot/kernel/acpi.ko at 0xc04b31f4. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 997461361 Hz CPU: Intel Pentium III (997.46-MHz 686-class CPU) Origin = GenuineIntel Id = 0x686 Stepping = 6 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 536854528 (511 MB) avail memory = 516313088 (492 MB) Pentium Pro MTRR support enabled VESA: v3.0, 32768k memory, flags:0x1, mode table:0xc03eb202 (122) VESA: NVidia npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS MED_2001 on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00f0eb0 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0xe408-0xe40b on acpi0 acpi_cpu0: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: VIA 82C691 (Apollo Pro) host to PCI bridge mem 0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pcib1: could not get PCI interrupt routing table for \\_SB_.PCI0.AGP_ - AE_NOT_FOUND pci1: ACPI PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 4.0 on pci0 isa0: ISA bus on isab0 atapci0: VIA 82C686A UDMA66 controller port 0xd800-0xd80f at device 4.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: VIA 83C572 USB controller port 0xd400-0xd41f irq 5 at device 4.2 on pci0 usb0: VIA 83C572 USB controller on uhci0 usb0: USB revision 1.0 uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered ulpt0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode umass0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2 ugen0: Syncrosoft Protected Executer, rev 1.10/1.01, addr 3 uhci1: VIA 83C572 USB controller port 0xd000-0xd01f irq 5 at device 4.3 on pci0 usb1: VIA 83C572 USB controller on uhci1 usb1: USB revision 1.0 uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered ahc0: Adaptec 2940 Ultra SCSI adapter port 0xb800-0xb8ff mem 0xed80-0xed800fff irq 9 at device 9.0 on pci0 aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs pci0: multimedia, audio at device 10.0 (no driver attached) fxp0: Intel 82557/8/9 EtherExpress Pro/100(B) Ethernet port 0xa000-0xa03f mem 0xec80-0xec8f,0xed00-0xed000fff irq 10 at device 11.0 on pci0 fxp0: Ethernet address 00:d0:b7:ba:c1:c2 miibus0: MII bus on fxp0 inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: Option ROMs at iomem 0xd-0xd0fff,0xcc000-0xcc7ff,0xc-0xcb7ff on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec acpi_cpu: throttling enabled, 16 steps (100% to 6.2%), currently 100.0% ad0: 76319MB ST380021A [155061/16/63] at ata0-master UDMA66 ad2: 38166MB ST340823A
Re: OpenOffice-devel: repeatable coredump with sun autodoc inlibstd++
Hi, -frtti is required for dynamic_castT(expr) to work. so if it is broken, then you've got big problems. Lokks like you are definitly right: grep dynamic `find ./ -name *.c*` ./source/ary/cpp/c_class.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); ./source/ary/cpp/c_define.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); ./source/ary/cpp/c_enum.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); ./source/ary/cpp/c_enuval.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); ./source/ary/cpp/c_funct.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); ./source/ary/cpp/c_macro.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); ./source/ary/cpp/c_namesp.cxx: ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whats an UDMA ICRC error ?
In the last episode (Jun 03), Andreas Klemm said: Hi, my console today shows the following error message from my disk: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? An ICRC error is an error detected by the IDE controller. It usually means a cabling problem, as a disk error would be reported by the drive, not the controller. From the ATA spec: ICRC shall be set to one if an interface CRC error has occurred during an Ultra DMA data transfer. The content of this bit is not applicable for Multiword DMA transfers. There are other error bits that indicate uncorrectable media errors. -- Dan Nelson [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: viapropm doesnt like sys/dev/pci.c rev 1.214
On 02-Jun-2003 Nicolas Souchu wrote: On Sun, Jun 01, 2003 at 01:52:57AM +0200, Dag-Erling Smorgrav wrote: viapropm is seriously broken for other reasons and needs professional help. What kind of breakage? Setting resources in probe? Right. Anybody having the viapm driver loaded usually should please try the attached patch. I'm sorry to report that those patches didn't fix the problem for me. They all applied cleanly, I built a new kernel, but I still see the same messages at boot. Couldn't enable port mapping. Thanks anyway, though. :-) -- Conrad Sabatier [EMAIL PROTECTED] - In Unix veritas pgp0.pgp Description: PGP signature
SU not working after CVSUP
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I sent a similar message to 'questions' before I realized that I had access to 'current' on this machine. Since this is really a 'current' issue I'll post again here. Make sense? Anyway... Just cvsup'd to current a few hours ago. Built and installed world and kernel without any errors. Now I get this error when I try to su to any user: Jun 3 01:45:22 enola su: in openpam_load_module(): no pam_wheel.so found Bus error (core dumped) enola# Jun 3 01:45:22 enola kernel: pid 507 (su), uid 0: exited on signal 10 (c ore dumped) - -- Mike Loiterman grantADLER Medical Corporation Tel: 630-302-4944 Fax: 773-868-0071 Email: [EMAIL PROTECTED] PGP Key 0xD1B9D18E -BEGIN PGP SIGNATURE- Version: PGP 8.0.2 Comment: This message has been digitally signed by Mike Loiterman iQA/AwUBPtxLpWjZbUnRudGOEQKPdwCgqdjFvxXiyX+H16cMrxPAIU+DajUAoPhq qGt21zVtSnITnAK6UDrSmWI8 =yUfu -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: VFS: C99 sparse format for struct vfsops
Hiten Pandya wrote:
On Mon, Jun 02, 2003 at 09:28:05AM -0700, Terry Lambert wrote:
This is a different thing entirely... you are not adding
elements in the cdevsw case.
Er, huh? Did you read Poul's HEADSUP mail for cdevsw sparse
init?
Yes. You are not adding new structure elements with previously
unknown entry points; it's just not possible with cdevsw.
With the VFS code, you *could* add new decriptors for previously
unknown VOP_ types, if you are willing to replace the elements
of the default_vnodeop_entries[] array, and re-vfs_init() the
vnodeopv_entry_desc's for the already mounted FS instances.
The VFSOP case is less of a problem than the VOP case, but it's
still a problem. Poul broke the VOP case a long time ago, when
he added the default stuff, since there is no way to add a new
default to an already existing array, and the entries with a
default can't be proxied (e.g. over the network or to user space
via a descriptor, per John Heidemann's original design for VFS
stacking in UCLS's FICUS).
OK, we are moving away from UCLS' FICUS. Could you kindly
provide me with some examples, and practicle use of this
``adding'' a new default in an already existing array?
Yes. For example, suppose you added an new FS type to the
kernel, and it supported a previously unknown VOP_TRANSACT()
entry point that took a vp and a flag which was one of the
set {VTA_BEGIN, VTA_ABORT, VTA_COMMIT}, and you added a new
system call to externalize the ability to access these
transactions to user space database programs.
Then you stacked a stacking layer for doing management of disk
quotas on top of it, and that stacking layer didn't know about
VOP_TRANSACT() at all. But you wanted it to work.
By making this change, you are basically changing it from a
data structure to something that has to be coded, and there's
no way to add code for a new entry that needs to be defaulted
to a non-NULL value -- which they all have to be.
Huh? Come again please? Could you ellaborate on this point as
it is sending me in circles. I don't see how it is not possible
to do that, please provide a practical case, so I can
understand.
Because the code is required to fill in the sparse entries
that are not filled in in the array byt the user. If you add
a new VOP_ entry type that was not known before (e.g. our
vop_transact_desc entry), then you need to add code to set its
defaults for any FS that didn't make an entry for it.
Only you can't, because there's nohooks for adding code to
vfs_register() to do the equivalent of what your patch does,
e.g.:
+ if (vfsops-vfs_start == NULL)
+ /* make a file system operational */
+ vfsops-vfs_start = vfs_stdstart;
The principle is the same for new VFSOPS as for new VOPS: you
can't grow the list, if you have to add code for each entry
you add.
As I said above: Poul broke this for VOPs. It doesn't make
sense to say It's broken for VOPs now, so it's OK to break it
for VFSOPs, too.
...
It's not been a problem, as you say, so far, because the VFS
stacking in FreeBSD has been broken for a long time. Breaking
it more just moves us farther away from ever fixing the code,
which I think is a bad thing.
That is such of a broad statement..=
Yes, but it's accurate.
If, at some point, we get rid of the default crap, then it
would be possible to add VOPs to a running kernel by just
reallocating the VOP array for each mounted FS to add the entry
to the end of the array.
And here is the question again, why would you want to add VOPs
to a running kernel? Please provide some examples, or practical
cases.
See my transaction example. You might also have a VFSOP for
a cleaner entry point, e.g. for an LFS or XFS or JFS.
As to why: so I can load an FS module into a ditribution kernel
without having to recompile everything. For example, the
commercial AFS module.
Your change makes this impossible for VFSOPS.
Awaiting your reply...
Cheers.
I hope the above has clarified the issue for you: it's because
of the VFSOP-specific code you are required to add to the
vfs_register() in kern/vfs_init.c.
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenOffice-devel: repeatable coredump with sun autodocinlibstd++
Martin Blapp wrote: Hi, -frtti is required for dynamic_castT(expr) to work. so if it is broken, then you've got big problems. Lokks like you are definitly right: grep dynamic `find ./ -name *.c*` ./source/ary/cpp/c_class.cxx:ary::cpp::Display * pD = dynamic_cast ary::cpp::Display* (o_rOut); [ ... ] I have seen this type of error and core dump with a new C++ and old rtti header files. Make sure you are not mixing them, since these header files definitely have to match the compiler. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenOffice-devel: repeatable coredump with sun autodocinlibstd++
Terry Lambert wrote:
Martin Blapp wrote:
-frtti is required for dynamic_castT(expr) to work. so if it is
broken, then you've got big problems.
Lokks like you are definitly right:
grep dynamic `find ./ -name *.c*`
./source/ary/cpp/c_class.cxx:ary::cpp::Display * pD = dynamic_cast
ary::cpp::Display* (o_rOut);
[ ... ]
I have seen this type of error and core dump with a new C++
and old rtti header files. Make sure you are not mixing them,
since these header files definitely have to match the compiler.
BTW: On older FreeBSD, you can't use a ports C++ to compile
C++ code, since bsd.prog.mk and bsd.lib.mk reset the include
path and will get you the older headers all the time, if
DESTDIR is set, which it will be.
If you are using a ports C++, then to see if you have this
problem, type the following:
cd /usr/share/mk
grep include/g++ *
If you see:
bsd.lib.mk:CXXINCLUDES+= -I${DESTDIR}/usr/include/g++
bsd.prog.mk:CXXINCLUDES+= -I${DESTDIR}/usr/include/g++
Then you have the problem. This is fixed in 5.x; I'm not sure
if it has been MFC'ed into more recent -stable, or not (i.e.
it may not be a problem on 4.8; the above is from a 4.6 system).
-- Terry
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: OpenOffice-devel: repeatable coredump with sun autodocinlibstd++
Hi, I have seen this type of error and core dump with a new C++ and old rtti header files. Make sure you are not mixing them, since these header files definitely have to match the compiler. This is a fresh current 5.1RC1 ... Martin ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On Sun, 1 Jun 2003 10:00:14 -0400 (EDT) [EMAIL PROTECTED](Robert Watson) said: | | | | The FreeBSD KAME| | | | | IPv6 code is now| | | | | substantially dated | | | | | with respect to the | | KAME| | | KAME vendor source. | | Synchronization | -- | -- | The FreeBSD Project | | | | | needs to take | | | | | initiative in | | | | | driving the merge | | | | | of new bug fixes, | | | | | features, et al.| I discussed this issued within KAME. Here's our rough plan about this synchronization. If you have some opinion, please let me know. When I've finished each merge, I'll ask you how to proceed. - sync per feature; don't do a complete sync with the KAME-snap: Since some of the KAME-specific features are still under standardization or immature, it's dangerous to sync without much consideration. - items to be merged Here's the candidate items to be merged. 5.2-RELEASE - IPv6 Advanced API (RFC3542 = written as 'RFC2292bis' in source code) Binary compatibility to RFC2292 is provided. - Source Address Selection (RFC3484) It involves too many unessential changes. (e.g. NDP data structure change, use struct sockaddr_in6 instead of struct in6_addr). So if time does not permit, I'll shift it to the future release. 5.x-RELEASE - IGMPv3 (RFC3478 and draft-ietf-magma-msf-api-04.txt) seems almost okay in terms of standardization, but has less priority. So if time permits, I'll shift it to 5.2-RELEASE. - Mobile IPv6 Corresponding Node (draft-ietf-mobileip-ipv6-22.txt) waiting for becoming an RFC - items not to be merged The following items are not merged for the time being, because of their immaturity, wating for standardization, etc. MLDv2 mDNS Scoped routing VRRPv6 Mobile-IPv6 Home-Agent and Mobile-Node Router Selection ISATAP DNS server discovery DHCPv6 SCTP ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[-CURRENT tinderbox] failure on ia64/ia64
TB --- 2003-06-03 08:15:43 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-06-03 08:15:43 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-06-03 08:23:12 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/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/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries [...] cc -O -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_getprio.c -o thr_getprio.o cc -O -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_getschedparam.c -o thr_getschedparam.o cc -O -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_info.c -o thr_info.o cc -O -pipe -DPTHREAD_KERNEL -D_THREAD_SAFE -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../libc/include -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/../../include -D_PTHREADS_INVARIANTS -g -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_init.c -o thr_init.o cc1: warnings being treated as errors In file included from /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_init.c:67: /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_private.h:677: warning: excess elements in struct initializer /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr/thread/thr_private.h:677: warning: (near initialization for `_giant_mutex') *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib/libthr. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/lib. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-06-03 09:00:45 - /usr/bin/make returned exit code 1 TB --- 2003-06-03 09:00:45 - ERROR: failed to build world TB --- 2003-06-03 09:00:45 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: whats an UDMA ICRC error ?
Am Dienstag, 03.06.03, um 07:57 Uhr (Europe/Berlin) schrieb Andreas Klemm: ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying ad2: UDMA ICRC error cmd=read fsbn 74689079 of 74689079-74689206 retrying What exactly does an UDMA ICRC error mean ? I think this is simply a read error. AFAIK an IDE disk doesn't have spare sectors or am I wrong ? How severe is this error ? What do you think ?? IDE disks have (hidden) spare sectors, and will transparently remap sectors as long as they have spare ones left. If the drive reports errors (hard error reading fsbn...), then it likely has run out of spare sectors, and probably will die soon. -- Stefan Bethke [EMAIL PROTECTED] Fon +49 170 346 0140 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SU not working after CVSUP
On 2003.06.03 02:17:58 -0500, Mike Loiterman wrote: Just cvsup'd to current a few hours ago. Built and installed world and kernel without any errors. Now I get this error when I try to su to any user: Jun 3 01:45:22 enola su: in openpam_load_module(): no pam_wheel.so found Bus error (core dumped) enola# Jun 3 01:45:22 enola kernel: pid 507 (su), uid 0: exited on signal 10 (c ore dumped) Since pam_wheel something must still be referencing it... Have you run mergemaster ? -- Simon L. Nielsen pgp0.pgp Description: PGP signature
panic: initiate_write_inodeblock_ufs2: already started
Hi My laptop paniced while it was (mostly) idle, running X server and X chat. I wasn't about when the panic happened so I don't know very much about it. I'll try to reproduce this panic. Any way here is a kgdb log from debug session and few most interesting lines from dmesg and uname: GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: initiate_write_inodeblock_ufs2: already started panic messages: --- panic: initiate_write_inodeblock_ufs2: already started syncing disks, buffers remaining... 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 giving up on 366 buffers Uptime: 56m45s Dumping 80 MB ata0: resetting devices .. ata0-slave: timeout waiting for cmd=ec s=00 e=04 ata0-slave: ATA identify failed done 16 32 48 64 80 --- Reading symbols from /boot/kernel/if_ep.ko...done. Loaded symbols for /boot/kernel/if_ep.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /boot/kernel/snd_mss.ko...done. Loaded symbols for /boot/kernel/snd_mss.ko Reading symbols from /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/ipfw/ipfw .ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/ipfw/ipfw .ko.debug Reading symbols from /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/linux/lin ux.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/linux/lin ux.ko.debug Reading symbols from /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/if_tap/if _tap.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/if_tap/if _tap.ko.debug #0 0xc01896a0 in doadump () (kgdb) bt #0 0xc01896a0 in doadump () #1 0xc0189b80 in boot () #2 0xc0189df7 in panic () #3 0xc024cd33 in initiate_write_inodeblock_ufs2 () #4 0xc024bf9f in softdep_disk_io_initiation () #5 0xc015df16 in spec_xstrategy () #6 0xc015e1b1 in spec_specstrategy () #7 0xc015d483 in spec_vnoperate () #8 0xc01c0ff9 in bwrite () #9 0xc01c27d3 in vfs_bio_awrite () #10 0xc01c89c6 in vop_stdfsync () #11 0xc015de23 in spec_fsync () #12 0xc015d483 in spec_vnoperate () #13 0xc01cf8e5 in sched_sync () #14 0xc017a678 in fork_exit () (kgdb) quit # dmesg | grep ata GNU gdb 5.2.1 (FreeBSD) Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: initiate_write_inodeblock_ufs2: already started panic messages: --- panic: initiate_write_inodeblock_ufs2: already started syncing disks, buffers remaining... 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 1109 giving up on 366 buffers Uptime: 56m45s Dumping 80 MB ata0: resetting devices .. ata0-slave: timeout waiting for cmd=ec s=00 e=04 ata0-slave: ATA identify failed done 16 32 48 64 80 --- Reading symbols from /boot/kernel/if_ep.ko...done. Loaded symbols for /boot/kernel/if_ep.ko Reading symbols from /boot/kernel/snd_pcm.ko...done. Loaded symbols for /boot/kernel/snd_pcm.ko Reading symbols from /boot/kernel/snd_mss.ko...done. Loaded symbols for /boot/kernel/snd_mss.ko Reading symbols from /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/ipfw/ipfw .ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/ipfw/ipfw .ko.debug Reading symbols from /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/linux/lin ux.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/linux/lin ux.ko.debug Reading symbols from /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/if_tap/if _tap.ko.debug...done. Loaded symbols for /usr/src/sys/i386/compile/-=DLW=-/modules/usr/src/sys/modules/if_tap/if _tap.ko.debug #0 0xc01896a0 in doadump () (kgdb) bt #0 0xc01896a0 in doadump () #1 0xc0189b80 in boot () #2 0xc0189df7 in panic () #3 0xc024cd33 in initiate_write_inodeblock_ufs2 () #4 0xc024bf9f in softdep_disk_io_initiation () #5 0xc015df16 in spec_xstrategy () #6 0xc015e1b1 in spec_specstrategy () #7 0xc015d483 in spec_vnoperate () #8 0xc01c0ff9 in bwrite () #9 0xc01c27d3 in vfs_bio_awrite () #10 0xc01c89c6 in vop_stdfsync () #11 0xc015de23 in spec_fsync () #12 0xc015d483 in spec_vnoperate () #13 0xc01cf8e5 in sched_sync () #14 0xc017a678 in
Re: SU not working after CVSUP
Mike Loiterman [EMAIL PROTECTED] writes: Jun 3 01:45:22 enola su: in openpam_load_module(): no pam_wheel.so found Bus error (core dumped) First of all, you're supposed to run mergemaster when you upgrade; pam_wheel has been deprecated since February. Second, if your system ran -CURRENT previous to the upgrade, you should still have a functional pam_wheel. If you upgraded from -STABLE, you might have an old one which won't work with -CURRENT's libpam, but in that case you should have completely replaced /etc when you upgraded. Either way, the problem arose because you didn't follow the recommended upgrade procedure. As for the bus error, I don't know what caused it. A backtrace would be nice. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Remove absolute symlink in $MAKEOBJDIR
On Tue, 3 Jun 2003, Jun Kuriyama wrote:
At Mon, 2 Jun 2003 10:10:26 + (UTC),
Bruce Evans wrote:
(2) Use correct dependency in sys/boot/i386/kgzldr.
This is too hackish for me. Try using the same method as for lib/csu.
I think you nmainly care about make install building things. This is
from longstanding brokenness of installation of man pages which was
cloned to brokenness of installation of FILES.
Hmm, like this? I don't know which owner and mode should be used at
realinstall stage.
Same as for csu (LIBOWN/LIBGRP/LIBMODE/LIBDIR). BINDIR should have been
set to LIBDIR; LIBDIR can be used directly now the install rule is explicit.
Index: Makefile
===
RCS file: /home/ncvs/src/sys/boot/i386/kgzldr/Makefile,v
retrieving revision 1.12
diff -u -r1.12 Makefile
--- Makefile 30 Sep 2002 20:37:57 - 1.12
+++ Makefile 3 Jun 2003 03:41:02 -
@@ -1,6 +1,5 @@
# $FreeBSD: src/sys/boot/i386/kgzldr/Makefile,v 1.12 2002/09/30 20:37:57 peter Exp $
-FILES= kgzldr.o
SRCS=start.s boot.c inflate.c lib.c crt.s sio.s
OBJS=${SRCS:N*.h:R:S/$/.o/g}
CFLAGS= -ffreestanding
@@ -15,7 +14,13 @@
BOOT_COMCONSOLE_PORT?= 0x3f8
AFLAGS+=--defsym SIO_PRT=${BOOT_COMCONSOLE_PORT}
+all: ${OBJS} kgzldr.o
+
CLEANFILES needs to be adjusted too.
kgzldr.o: ${OBJS}
${CC} ${LDFLAGS} -o ${.TARGET} ${OBJS}
+
+realinstall:
+ ${INSTALL} -o ${BINOWN} -g ${BINGRP} -m ${LIBMODE} \
+ kgzldr.o ${DESTDIR}${BINDIR}
The continuation indent should be 4 as in csu/*/Makefile (except for the
zombie i386 (aout) Makefile).
.include bsd.prog.mk
I think it should include bsd.lib.mk.
Bruce
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 5.2-RELEASE TODO
On Tue, Jun 03, 2003 at 05:32:35PM +0900, SUZUKI Shinsuke wrote: I discussed this issued within KAME. Here's our rough plan about this synchronization. If you have some opinion, please let me know. When I've finished each merge, I'll ask you how to proceed. - sync per feature; don't do a complete sync with the KAME-snap: Since some of the KAME-specific features are still under standardization or immature, it's dangerous to sync without much consideration. For what its worth, I have some of this stuff already merged in my local cvs tree. Drop me note if I can be of any help. I have the IGMPv3 code in my repo merged. Cheers. -- Hiten [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Radeon VE 7000 VGA card support under xfree86 4.3.0
- Original Message - From: nobody nobody [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Tuesday, June 03, 2003 1:01 AM Subject: Radeon VE 7000 VGA card support under xfree86 4.3.0 Hello, Thanks for the advices of the mailing group. I finally figure out the problem of my previous mail concerning the X under XFree86 4.3.0 with Freebsd-5.1 beta 2. I use the same VGA card with the crt mon and everything work ok without extra work for the X-config file. The problem may be the refresh rate of the LCD is too slow for the VGA card to pick up. I would like to know if there exists any method that would fix the problem. Thanks for your effort. Clarence You'll likely need to hard-code the LCD's refresh rate in the config file. Involves manual hacking. Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/contrib/dev/acpica - Imported sources
On Wed, May 28, 2003 at 03:39:44PM -0700, Nate Lawson wrote: On Wed, 28 May 2003, Larry Rosenman wrote: --On Wednesday, May 28, 2003 03:59:24 -0500 Larry Rosenman Ok, with today's sources, I still get a page not present panic for address (0x7) on transistion to battery. as a followup, with this code, I no longer get the panic at ACPI shutdown, just some messages about references. As a further followup, today's update of the ACPI sources get's rid of the ACPI errors in the dmesg, but I STILL have the panic at 0x7 on transition to battery. There's something wrong with your DSDT and/or the Intel acpica interpreter such that reference counting on ns objects is incorrect. Is this going to be released like this? I'm doing my best as a volunteer. If none of us finds the problem before release, the answer is yes. In that case, you should disable acpi or use apm. Or feel free to hunt down the problem yourself. Just a note, but using apm is rarely a solution to using acpi because for a lot of people (me included) the box doesn't work at all without acpi support, interrupt routing and/or timecounter support is screwed to the point that FreeBSD doesn't work. ACPI isn't a power management tool, that's just one small aspect of it. -- Tis a wise thing to know what is wanted, wiser still to know when it has been achieved and wisest of all to know when it is unachievable for then striving is folly. [Magician] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
libc_r, libthr konsole news
Alas, I found *what* is going on differently depending on the library used. With libc_r, dup2() gets called and fails, preventing execution of konsole_grantpty, with libthr things work, konsole_grantpty gets called and... ttyname fails. :-) Now, dup2() implementation seems to differ between libc_r and libthr (though I'm open to be shown that is not so -- I don't quite understand how things work here). I have verified that by preventing execution of /usr/local/bin/konsole_grantpty (by the simple artifice of renaming it), the problem DOES NOT HAPPEN. Now... to find out what's different between both dup2() implementations... -- Daniel C. Sobral (8-DCS) Gerencia de Operacoes Divisao de Comunicacao de Dados Coordenacao de Seguranca VIVO Centro Oeste Norte Fones: 55-61-313-7654/Cel: 55-61-9618-0904 E-mail: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] Outros: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I think sex is better than logic, but I can't prove it. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Undefined symbol getpwuid_r
[Sorry for delayed reply. I'm offline mostly lately.] On Thu, May 22, 2003 at 12:09:06PM +, David Leimbach wrote: On Thursday, May 22, 2003, at 03:53 AM, CARTER Anthony wrote: Hi, Just done a buildworld and installworld from yesterdays CVSUp (today, 22nd, 10:51am GMT+1). However, whenever I launch ymessenger now I get: /usr/libexec/ld-elf.so.1: /usr/local/lib/libglib12.so.3: Undefined symbol getpwuid_r Has anyone got an idea about this? [snip] If any further info is required just let me know. Have you recompiled the ymessenger code? It sounds as if some .so got replaced from an old compile and the code should no longer link if you rebuild it. The new NS stuff Jacques is working on most likely has caused this. It looks as if you may just need a rebuild of ymessenger. I don't think it is my fault :-) ymessenger is a binary port. It is linked against libc.so.4 (IIRC), which does not have getpwuid_r. Therefore, when ymessenger loads libglib12.so.3 (which was built against the newer libc.so.5), glib cannot find getpwuid_r in libc.so.4 (naturally). If getpwuid_r hadn't gotten you, something else probably would have :-) Basically, ymessenger can't really run on later versions of FreeBSD. It is dynamically linked against 12 libraries (besides libc.so.4), many of which have had ABI changes. I had a need to run ymessenger on FreeBSD 5 several weeks ago. In order to do so, I had to go back to old 4.5 CDs and extract libglib, libgtk, and so on into a special environment just to run ymessenger. You are better off running some other client, e.g. GAIM. But, if you insist: WARNING: This could have any effect, including but not limited to data loss, hair loss, self-esteem issues, deforestation, defenestration, etc. etc. By breathing, you agree to hold me harmless due to any of these effects and any other effects directly, indirectly, or not caused by following these directions or reading this message. Download URL: http://people.freebsd.org/~nectar/ymessenger-hack.tgz and extract it somewhere (BUT NOT IN YOUR ROOT DIRECTORY) and run it as shown. % mkdir $HOME/ymessenger % cd $HOME/ymessenger % tar zxvf /path/to/ymessenger-hack.tgz % env LD_LIBRARY_PATH=$PWD/usr/local/lib ./usr/local/bin/ymessenger.bin Someone with time on hand should update the ymessenger port to install the dependent libraries, too. *shrug* Cheers, -- Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
