panic at shutdown
For about a week, I've been getting panics at shutdown, caused by cn_devopen() calling devsw() with a NULL dev argument. I imagine it may be related to recent changes in the console code. If it's of any interest, I have -Dh in my /boot.config. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: latest -current broke netscape's name lookup?
David Wolfskill <[EMAIL PROTECTED]> writes: > Actually, I tried that. Maybe I should have put it in braces, but I > thought I tried that, too. Hmmm... I can hack on the build machine a > bit... I was aware that sed, by default, would print its input to > output, but had thought that awk would not I don't remember if it does, or if it only prints a blank line, but I put that clause in for a reason. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: latest -current broke netscape's name lookup?
>From: Dag-Erling Smorgrav <[EMAIL PROTECTED]>
>Date: 03 Nov 2001 03:34:01 +0100
>> course, one of the other interesting issues with the above patch is that
>> awk was whining about the empty regex ("//"). Since the idea was
>> apparently to do nothing for such a record, it seemed simpler to just
>> not tell awk to do anything with it, and that seemed to work in my
>> tests.]
>Bzzzt! Wrong. That clause needs to be there to prevent awk from
>copying non-matching lines from nsswitch.conf to host.conf. If 1Tawk
>complains about empty regexps, just remove the regexp, but leave the
>clause there.
Actually, I tried that. Maybe I should have put it in braces, but I
thought I tried that, too. Hmmm... I can hack on the build machine a
bit... I was aware that sed, by default, would print its input to
output, but had thought that awk would not
OK; my error -- this does work:
Index: etc/rc.network
===
RCS file: /cvs/freebsd/src/etc/rc.network,v
retrieving revision 1.110
diff -u -r1.110 rc.network
--- etc/rc.network 1 Nov 2001 12:39:01 - 1.110
+++ etc/rc.network 3 Nov 2001 02:47:06 -
@@ -888,7 +888,7 @@
print xlat[$n];
quit;
}
-// {
+{
next;
}
' <$nsswitch_conf >$host_conf
Sorry about that,
david
--
David H. Wolfskill [EMAIL PROTECTED]
As a computing professional, I believe it would be unethical for me to
advise, recommend, or support the use (save possibly for personal
amusement) of any product that is or depends on any Microsoft product.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: latest -current broke netscape's name lookup?
David Wolfskill <[EMAIL PROTECTED]> writes:
> Of
> course, one of the other interesting issues with the above patch is that
> awk was whining about the empty regex ("//"). Since the idea was
> apparently to do nothing for such a record, it seemed simpler to just
> not tell awk to do anything with it, and that seemed to work in my
> tests.]
Bzzzt! Wrong. That clause needs to be there to prevent awk from
copying non-matching lines from nsswitch.conf to host.conf. If 1Tawk
complains about empty regexps, just remove the regexp, but leave the
clause there.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: About stscasestr() prototyped with string.h of current lib
On Fri, Nov 02, 2001 at 22:01:13 +0900, Hajimu UMEMOTO wrote: > I think nin said that having strcasestr() in our standard header > breaks existing program. Existen programs must be ported to FreeBSD first. > That is, our header seems not confirm > standard. Use #define _ANSI_SOURCE or _POSIX_SOURCE to get standard conformance. All those functions clearly marked as Nonstandard extensions in corresponding string.h section. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
odd error
What's this mean? i can't find anything in docs about it: acpi_tz0: _AC0: temperature 60.0 >= setpoint 50.0 acpi_tz0: switched from _AC-1 to _AC0 acpi_tz0: _AC0: temperature 60.0 >= setpoint 50.0 acpi_tz0: switched from _AC-1 to _AC0 acpi_tz0: switched from _AC0 to _AC-1 THanks! -Rob To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About stscasestr() prototyped with string.h of current lib
On Fri, Nov 02, 2001 at 05:50:07 -0500, Thomas David Rivers wrote: > > > > On Fri, Nov 02, 2001 at 17:36:04 +0900, NINOMIYA Hideyuki wrote: > > > > > In implementation with current, even if you implemented it for the > > > reason that Linux included, there is the problem that behavior is > > > different from Linux in about prototyping reference. > > > > 1) Our strcasestr() implementation is not related to Linux that way. > > 2) Program must not prototype by itself system-wide functions and should > > relay on system headers instead. > > 3) Programs which not follows rule #2 must be fixed by removing > > prototypes in question from their headers. > > What about the ANSI standard regarding polluting the user's > name space? Use standard way - #define _ANSI_SOURCE to switch them off, as for other FreeBSD extensions in that area (see string.h) -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
how to handle clean module loading/unloading ?
I am trying to figure out how to cleany handle error
conditions with module loading/unloading, especially
when trying to load a module which is already statically
compiled in the kernel.
I have browsed through the source a bit but haven't found
a good example that I could understand.
Basically, i see a problem in the way module_register_init()
is implemented. This function ends like this:
void
module_register_init(const void *arg)
{
...
error = MOD_EVENT(mod, MOD_LOAD);
if (error) {
MOD_EVENT(mod, MOD_UNLOAD);
module_release(mod);
}
}
and I have a problem understanding the reason of
the call to MOD_UNLOAD in case of failure.
To me the most obvious way to handle a LOAD failure was that
the called function should take care to do the necessary
cleanup, without deferring this task to a further call to
MOD_UNLOAD.
Furthermore, the latter is indistinguishable
from a regular call to MOD_UNLOAD generated by kldunload
unless the module that failed to register stores some
state to record the failure itself.
Finally, perhaps there ought to be some automatic way
(such as in the DECLARE_MODULE macro) to make sure that
when a module is statically compiled in, kldload
fails with EEXIST without even attempting to
call MOD_LOAD ?
I can easily implement some conditional code in
modevent, such as
static int
foo_modevent(module_t mod, int type, void *unused)
{
switch (type) {
case MOD_LOAD:
err = foo_init();
break ;
case MOD_UNLOAD:
#if !defined(KLD_MODULE)
printf("cannot unload module foo, it is statically compiled\n");
err = EINVAL
#else
err = foo_unload();
#endif
break;
default:
err = EINVAL ;
break;
}
but it would be much more convenient if the check were done
in some automatic way with some trick in DECLARE_MODULE.
cheers
luigi
--+-
Luigi RIZZO, [EMAIL PROTECTED] . ACIRI/ICSI (on leave from Univ. di Pisa)
http://www.iet.unipi.it/~luigi/ . 1947 Center St, Berkeley CA 94704
Phone: (510) 666 2927
--+-
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
cdevsw_add() removal patch.
Please run this patch on you current machine and report any problems you might notice! Background: All dev_t's in the system should be created with an explicit make_dev() call and the old "wildcard" cdevsw[] mechanism be killed to the extent we can. This patch covers what I think is the trivial drivers, and if no problems are reported I will sweep all these drivers for cdevsw_add() related code and commit it one by one. If you know any of the drivers involved and know for sure that the driver is covered with make_dev() calls (ie: it works correctly on DEVFS systems) please feel (more than) free to remove the cdevsw_add() call yourself. Poul-Henning http://phk.freebsd.dk/patch/cdevsw_add.patch Remove the majority of the cdevsw_add() calls in the kernel. All main-stream drivers have been fixed for DEVFS which by definition makes cdevsw_add() calls unneeded for both the DEVFS and !DEVFS cases. I have not removed the cdevsw_add() calls from driver where I think it might make a difference for the !DEVFS case still or where I could not figure out what was going on. This patch is not the commit-ready version, but offered as a HEADSUP for people to test the effect of the actual patch on their systems. The actual patch will remove the entire cdevsw_add() family. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel won't build - atomic.c/atomic.h errors...
Is anyone else seeing this problem? I posted a message the other day to this list, and have yet to see a single response. This is from a completely fresh cvsup of everything. buildworld succeeds, but the kernel build fails on atomic.c with the following message about the ATOMIC_ASM macros in atomic.h. The archetecture is 5.0-really-current on an SMP P2-333 machine. the message seems to be: "inconsistent operand constraints in an `asm'" I checked the CVS sebsite, and noticed a change three weeks ago in atomic.h, but atomic.c hasn't been changed in better than a year. jim -- ET has one helluva sense of humor! He's always anal-probing right-wing schizos! - POWER TO THE PEOPLE! - "Religious fundamentalism is the biggest threat to international security that exists today." United Nations Secretary General B.B.Ghali, 1995 _ Do You Yahoo!? Get your free @yahoo.com address at http://mail.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: broken read-only paradigm?
On Fri, Nov 02, 2001 at 10:10:08AM -0800, Matthew Jacob wrote: > > /usr/src/lib/compat/compat4x.alpha /tstsys/alpha/compile/GPLUS > yorp.feral.com > root make obj all install clean You cannot do this due to make(1) evaluation timming. You need to do: root (make obj && make all install clean) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with PCCARD
Ogawa-san, : Thank you for your patch. : That completely fixed my pccard problem. I've committed the fix. : Now my pccard-modem gets attached as sio2, instead of sio3 like few days : ago which seemed bogus, because my system don't have sio2! Interesting. Do you have a sio2 that is disabled on isa or a sio3 that's disabled? I didn't see these problems on my machine when I tested, so I'm interested to see why/how they happen. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with PCCARD
In message <[EMAIL PROTECTED]> Munehiro Matsuda writes:
: ::- Let pccardd(8) pass -1 as unit number for
: :: pccard.conf entries without unit number
...
: ::--- usr.sbin/pccard/pccardd/file.c.orig Fri Nov 2 17:16:58 2001
: ::+++ usr.sbin/pccard/pccardd/file.c Fri Nov 2 17:17:17 2001
: ::@@ -573,6 +573,7 @@
: ::drivers = drvp;
: ::drvp->name = newstr(name);
: ::drvp->kernel = newstr(name);
: ::+ drvp->unit = -1;
: ::p = drvp->kernel;
: ::while (*p++)
: ::if (*p >= '0' && *p <= '9') {
I think this is OK. At first I thought there were problems, but on
closer look, it is right.
I'll commit these.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Panic with PCCARD
In message <[EMAIL PROTECTED]> Munehiro Matsuda writes: : Hello Ogawa-san, : : Thank you for your patch. : That completely fixed my pccard problem. : : Now my pccard-modem gets attached as sio2, instead of sio3 like few days : ago which seemed bogus, because my system don't have sio2! : : Regards, :Haro : : From: OGAWA Takaya <[EMAIL PROTECTED]> : Date: Fri, 02 Nov 2001 18:43:43 +0900 : :: : ::Same here. Stack trace is as below. : :: : ::This panic seems to be related to the recent change of : ::devclass_alloc_unit() in subr_bus.c, which no longer : ::automatically assigns a free unit number if specified unit : ::number was already ocuppied. /me very angry about this. Thank you for tracking it down. Grump. Thank you for this nice patch ogawa-san. I'll see that it gets in right away. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with PCCARD
Hello Ogawa-san,
Thank you for your patch.
That completely fixed my pccard problem.
Now my pccard-modem gets attached as sio2, instead of sio3 like few days
ago which seemed bogus, because my system don't have sio2!
Regards,
Haro
From: OGAWA Takaya <[EMAIL PROTECTED]>
Date: Fri, 02 Nov 2001 18:43:43 +0900
::
::Same here. Stack trace is as below.
::
::This panic seems to be related to the recent change of
::devclass_alloc_unit() in subr_bus.c, which no longer
::automatically assigns a free unit number if specified unit
::number was already ocuppied.
::
::Currently pccardd(8) creates struct dev_desc with unit
::number 0 for pccard.conf entries without unit number,
::while devclass_add_unit() expects -1 for automatic
::unit number assignment.
::
::So fix for this problem would be:
::- Let pccardd(8) pass -1 as unit number for
:: pccard.conf entries without unit number
::- Make sure devclass_add_child() didn't fail in
:: sys/pccard/pccard.c in order to avoid panic.
::- Print warning regardless of bootverbose in
:: devclass_alloc_unit() in sys/kern/subr_bus.c to
:: inform user why device allocation failed.
::
::Patch includes above changes is attached.
::
::
::(kgdb) where
::#0 dumpsys () at /usr/src/sys/kern/kern_shutdown.c:492
::#1 0xc0157a9b in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:335
::#2 0xc0157ecd in panic (fmt=0xc022f99e "from debugger")
::at /usr/src/sys/kern/kern_shutdown.c:634
::#3 0xc011f4d9 in db_panic (addr=-1072278331, have_addr=0, count=-1,
::modif=0xc8934974 "") at /usr/src/sys/ddb/db_command.c:443
::#4 0xc011f477 in db_command (last_cmdp=0xc0257cec, cmd_table=0xc0257b2c,
::aux_cmd_tablep=0xc0252ae0, aux_cmd_tablep_end=0xc0252ae4)
::at /usr/src/sys/ddb/db_command.c:341
::#5 0xc011f543 in db_command_loop () at /usr/src/sys/ddb/db_command.c:465
::#6 0xc01217db in db_trap (type=12, code=0) at /usr/src/sys/ddb/db_trap.c:72
::#7 0xc0212c4e in kdb_trap (type=12, code=0, regs=0xc8934ac0)
::at /usr/src/sys/i386/i386/db_interface.c:167
::#8 0xc021f894 in trap_fatal (frame=0xc8934ac0, eva=60)
::at /usr/src/sys/i386/i386/trap.c:934
::#9 0xc021f601 in trap_pfault (frame=0xc8934ac0, usermode=0, eva=60)
::at /usr/src/sys/i386/i386/trap.c:853
::#10 0xc021f013 in trap (frame={tf_fs = -1071316968, tf_es = -1056767984,
:: tf_ds = -1057947632, tf_edi = -1056341504, tf_esi = 0,
:: tf_ebp = -929871104, tf_isp = -929871124, tf_ebx = -1056718336,
:: tf_edx = 0, tf_ecx = 4, tf_eax = 0, tf_trapno = 12, tf_err = 2,
:: tf_eip = -1072278331, tf_cs = 8, tf_eflags = 66118, tf_esp = -929871044,
:: tf_ss = -1071852163}) at /usr/src/sys/i386/i386/trap.c:405
::#11 0xc01654c5 in device_set_flags (dev=0x0, flags=0)
::at /usr/src/sys/kern/subr_bus.c:835
::#12 0xc01cd57d in allocate_driver (slt=0xc0730400, desc=0xc1098200)
::at /usr/src/sys/pccard/pccard.c:245
::#13 0xc01cdd5f in crdioctl (dev=0xc0276858, cmd=3232518150,
::data=0xc1098200 "sio", fflag=3, td=0xc8426104)
::at /usr/src/sys/pccard/pccard.c:603
::#14 0xc01380b6 in spec_ioctl (ap=0xc8934ba4)
::at /usr/src/sys/fs/specfs/spec_vnops.c:320
::#15 0xc0137d59 in spec_vnoperate (ap=0xc8934ba4)
::at /usr/src/sys/fs/specfs/spec_vnops.c:119
::#16 0xc0197db7 in vn_ioctl (fp=0xc0fc9e40, com=3232518150,
::data=0xc1098200 "sio", td=0xc8426104) at vnode_if.h:357
::#17 0xc0171838 in ioctl (td=0xc8426104, uap=0xc8934d20)
::at /usr/src/sys/sys/file.h:177
::#18 0xc021fd40 in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
:: tf_edi = 0, tf_esi = 134689024, tf_ebp = -1077937408,
:: tf_isp = -929870476, tf_ebx = 134689088, tf_edx = 8, tf_ecx = 9,
:: tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 134565072, tf_cs = 31,
:: tf_eflags = 659, tf_esp = -1077937676, tf_ss = 47})
::at /usr/src/sys/i386/i386/trap.c:1129
::#19 0xc0213cbd in syscall_with_err_pushed ()
::#20 0x8049345 in ?? ()
::---Type to continue, or q to quit---
::#21 0x8048dff in ?? ()
::#22 0x8048abf in ?? ()
::#23 0x8048135 in ?? ()
::(kgdb) up 12
::#12 0xc01cd57d in allocate_driver (slt=0xc0730400, desc=0xc1098200)
::at /usr/src/sys/pccard/pccard.c:245
::245 device_set_flags(child, desc->flags);
::(kgdb) print *desc
::$1 = {name = "sio", '\000' , unit = 0, mem = 0, memsize = 0,
:: iobase = 744, iosize = 8, irqmask = 512, flags = 0,
:: misc = '\000' }
::(kgdb) quit
::
::
::--- usr.sbin/pccard/pccardd/file.c.orig Fri Nov 2 17:16:58 2001
::+++ usr.sbin/pccard/pccardd/file.cFri Nov 2 17:17:17 2001
::@@ -573,6 +573,7 @@
:: drivers = drvp;
:: drvp->name = newstr(name);
:: drvp->kernel = newstr(name);
::+ drvp->unit = -1;
:: p = drvp->kernel;
:: while (*p++)
:: if (*p >= '0' && *p <= '9') {
::--- sys/pccard/pccard.c.orig Fri Nov 2 17:17:52 2001
::+++ sys/pccard/pccard.c Fri Nov 2 17:30:04 2001
::@@ -242,6 +242,10
Re: Panic with PCCARD
Hello Mark, From: mark tinguely <[EMAIL PROTECTED]> Date: Fri, 2 Nov 2001 08:31:28 -0600 (CST) ::> I'm having panic for the last few days, if I have PCCARD inserted. ::> If no card is inside, system boots up fine. ::> ::> Here's the panic message, I've written down. ::the panic appears to be a side affect that allocate_driver() in ::sys/pccard/pccard.c does not check the success/failure of device_add_child(). ::The patch that would fix that is: ::--- pccard.c.orig Fri Sep 14 03:43:15 2001 ::+++ pccard.c Fri Nov 2 08:21:48 2001 :: ::The real question is, why is device_add_child failing? The best answer ::is that the device class is not being found in make_device() ::sys/kern/subr_bus.c. I would suggest you print the string in variable ::"name", I think it is corrupt. :: ::--mark tinguely. Thank you for the patch, that fixed my panic problem. Unfortunatly that was not enough for my pccard to get recognized correctly, as suggested by OGAWA-san on anther thread. Thank you anyway, Haro =-- _ _Munehiro (haro) Matsuda -|- /_\ |_|_| Business Incubation Dept., Kubota Corp. /|\ |_| |_|_| 1-3 Nihonbashi-Muromachi 3-Chome Chuo-ku Tokyo 103-8310, Japan Tel: +81-3-3245-3318 Fax: +81-3-3245-3315 Email: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Panic with PCCARD
> I'm having panic for the last few days, if I have PCCARD inserted.
> If no card is inside, system boots up fine.
>
> Here's the panic message, I've written down.
>
> Fatal trap 12: page fault while in kernel mode
> fault virtual address= 0x3c
> fault code = supervisor write, page not present
> instruction pointer = 0x8:0xc01ecea5
> stack pointer= 0x10:0xc8ca3b00
> frame pointer= 0x10:0xc8ca3b00
> 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 = 201 (pccardd)
> kernel: type 12 trap, code=0
> Stopped at device_set_flags+0x9: movl %eax,0x3c (%edx)
> db> Context switches not allowed in debugger
> db> t
> device_set_flags(0,0,c139a080,c1411e00,0) at device_set_flags+0x9
> allocate_driver(c139c600,c1497400,c8ca8ba4,c13a9800,c87a0804) at
>allocate_driver+0xd9
> crdioctl(c13a9800,c0ac5006,c1497400,3,c87a0804) at crdioctl+0x337
> spec_ioctl(c8ca8b4,c8ca8c34,c0cf,c8ca8ba4,c1496d80) at spec_ioctl+0x26
> spec_vnoperate(c8ca8ba4,c1496d80,ac,c1497400,c03521a0) at spec_vnoperate+0x15
> vn_ioctl(c1496d80,c0ac5006,c1497400,c87a0804,c87a090c) at vn_ioctl+0x10f
> ioctl(c87a0804,c8ca8d20,8073140,8073100,0) at ioctl+0x20c
> syscall(2f,2f,2f,0,8073100) at syscall+0x24c
> syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> --- syscall(54, FreeBSD ELF, ioctl), eip = 0x8054cd0, esp = 0xbfbff93c, ebp =
>0xbfbffa48 ---
the panic appears to be a side affect that allocate_driver() in
sys/pccard/pccard.c does not check the success/failure of device_add_child().
The patch that would fix that is:
--- pccard.c.orig Fri Sep 14 03:43:15 2001
+++ pccard.cFri Nov 2 08:21:48 2001
@@ -236,6 +236,8 @@
bcopy(desc->misc, devi->misc, sizeof(desc->misc));
resource_list_init(&devi->resources);
child = device_add_child(pccarddev, devi->name, desc->unit);
+ if (child == NULL)
+ return (EIO); /* XXX */
device_set_flags(child, desc->flags);
device_set_ivars(child, devi);
if (bootverbose) {
The real question is, why is device_add_child failing? The best answer
is that the device class is not being found in make_device()
sys/kern/subr_bus.c. I would suggest you print the string in variable
"name", I think it is corrupt.
--mark tinguely.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld breakage during "make depend" at usr.bin/kdump
On 02-Nov-2001 (12:58:55/GMT) Cyrille Lefevre wrote: >>> because `echo' nicely removes \n's from env vars when it prints them. >> des@des ~% foo='bar >> quote> baz' >> des@des ~% echo $foo >> bar >> baz >> des@des ~% /bin/echo $foo >> bar >> baz > humm! what shell ($SHELL) are you using ? Here (5.0-CURRENT 31-Oct and 4.4-STABLE 12-Oct), with /bin/sh works fine: % /bin/sh # foobar="foo > bar" # echo $foobar foo bar # echo $SHELL /bin/sh Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About stscasestr() prototyped with string.h of current lib
Hi,
> On Fri, 2 Nov 2001 12:01:19 +0300
> "Andrey A. Chernov" <[EMAIL PROTECTED]> said:
ache> On Fri, Nov 02, 2001 at 17:36:04 +0900, NINOMIYA Hideyuki wrote:
> In implementation with current, even if you implemented it for the
> reason that Linux included, there is the problem that behavior is
> different from Linux in about prototyping reference.
ache> 1) Our strcasestr() implementation is not related to Linux that way.
ache> 2) Program must not prototype by itself system-wide functions and should
ache> relay on system headers instead.
ache> 3) Programs which not follows rule #2 must be fixed by removing
ache> prototypes in question from their headers.
I think nin said that having strcasestr() in our standard header
breaks existing program. That is, our header seems not confirm
standard. Mew2 could be compiled even on Linux which has
strcasestr().
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: buildworld breakage during "make depend" at usr.bin/kdump
Dag-Erling Smorgrav wrote: > "David O'Brien" <[EMAIL PROTECTED]> writes: > > because `echo' nicely removes \n's from env vars when it prints them. > > des@des ~% foo='bar > quote> baz' > des@des ~% echo $foo > bar > baz > des@des ~% /bin/echo $foo > bar > baz > > DES > -- > Dag-Erling Smorgrav - [EMAIL PROTECTED] humm! what shell ($SHELL) are you using ? Cyrille. -- Cyrille Lefevre mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: guide to downgrading from 5.0 to 4.4-STABLE
Having done this several times before, I highly recommend downgrading via binary package. Back up your system first! Get your 4.4 CD, throw it in the drive, and see what happens. As a rule this is not guaranteed to work, but if it doesn't then a downgrade from source certainly won't. I believe (knock on wood) that the filesystems between 4.4 and -current are in sync, so you'll probably be OK. You will, of course, have to reinstall every single program on the system. Enjoy. :) On Fri, Nov 02, 2001 at 12:36:18PM +, John wrote: > Hello List > > Is there a guide or a how-to showing how to downgrade from a > 5.0-CURRENT snapshot to 4.4-STABLE without having to blat the system and > start again? The reason 5.0 is on there is because only 5 had support for > the promise udma 100 tx2 card, but now that 4.4 has it, i would like to > downgrade. Any help or pointers how to accomplish this welcomed. If I have > to blat the system, I guess I have to do it but it is the least favoured > option. > > Please cc to [EMAIL PROTECTED] as I am not on this list at this address > > Thanks > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
guide to downgrading from 5.0 to 4.4-STABLE
Hello List Is there a guide or a how-to showing how to downgrade from a 5.0-CURRENT snapshot to 4.4-STABLE without having to blat the system and start again? The reason 5.0 is on there is because only 5 had support for the promise udma 100 tx2 card, but now that 4.4 has it, i would like to downgrade. Any help or pointers how to accomplish this welcomed. If I have to blat the system, I guess I have to do it but it is the least favoured option. Please cc to [EMAIL PROTECTED] as I am not on this list at this address Thanks To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: uscanner and devfs
In message <[EMAIL PROTECTED]>, Riccardo Torrini writes: >Yes, I know that /etc/rc.devfs is executed only at boot time. >Is /etc/usbd.conf usable also for chown/chmod commands? Must usbd >be running (I have no usbd now but it attach/detach the same). Yes, you need usbd running and yes, that is the way to do it. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
uscanner and devfs
With world of 31 oct I finally make my new scanner visible. It appear under /dev as uscanner0 and on console I got the notify: uscanner0: EPSON Perfection1240, rev 1.00/1.14, addr 2 and if I switch it off I got: uscanner0: at uhub0 port 1 (addr 2) disconnected uscanner0: detached and sane is able to use it, it works. But... .../dev/uscanner is owned by root:operator with mode 644 and only root can use it, I changed mode to 666 and also my user can scan. So the question: /dev/uscanner0 is a dynamic entry under DEVFS and I am unable to change mode to 666 at boot time if scanner is off. How can I make it reboot resistant, or how can I change protection every time I switch it on? Yes, I know that /etc/rc.devfs is executed only at boot time. Is /etc/usbd.conf usable also for chown/chmod commands? Must usbd be running (I have no usbd now but it attach/detach the same). TIA, Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About stscasestr() prototyped with string.h of current lib
On Fri, Nov 02, 2001 at 17:36:04 +0900, NINOMIYA Hideyuki wrote: > In implementation with current, even if you implemented it for the > reason that Linux included, there is the problem that behavior is > different from Linux in about prototyping reference. 1) Our strcasestr() implementation is not related to Linux that way. 2) Program must not prototype by itself system-wide functions and should relay on system headers instead. 3) Programs which not follows rule #2 must be fixed by removing prototypes in question from their headers. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Revert awk to one that works
On 01-Nov-01 Mike Barcroft wrote: > Doug Barton <[EMAIL PROTECTED]> writes: >> On Wed, 31 Oct 2001, David O'Brien wrote: >> > I *DID* test it with a full `make world'. By chance is this your second >> > `make world' after the change? It seems we are using the host awk >> > instead of the one we built. Requiring someone to do two back-to-back >> > `make world's before a commit has never been a requirement. Some things >> > we just find out after a commit. >> >> "Required" isn't really the question. It seems like common sense >> to me when discussing such a frequently used build tool. > > I'm sure there's better things you could be doing besides lecturing > David about testing his changes before committing. Not every bug can > be found before committing, which is why we have a little thing called > -CURRENT. And the irony being that David has one of the best test methodologies of any committer I know. The number of torture tests he has submitted binutils and gcc updates to in the past is amazing. So he missed one, give him a break and help fix it if you can. -- John Baldwin <[EMAIL PROTECTED]> -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFmail and libc.so.3
On 27-Oct-2001 (12:28:50/GMT) Riccardo Torrini wrote: I have the same problem of 27 october with src and world of last 31 oct, xfmail doesn't work with libc.so.3 from compat3x (either from ports or from COMPAT3X=yes), it crashes. Any ideas? The only method to make it happy is this hack: -8<-[ before ]-8<- # ldconfig -r | grep libc.so 33:-lc.5 => /usr/lib/libc.so.5 67:-lc.3 => /usr/lib/compat/libc.so.3 89:-lc.4 => /usr/lib/compat/libc.so.4 -8<-[ hack ]-8<- # cd /usr/lib # mv compat/libc.so.3 compat/libc.so.3-NO_THANKS # ln -s libc.so libc.so.3 -8<-[ after ]-8<- # ldconfig -r | grep libc.so 33:-lc.5 => /usr/lib/libc.so.5 66:-lc.3 => /usr/lib/libc.so.3 89:-lc.4 => /usr/lib/compat/libc.so.4 Riccardo. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
About stscasestr() prototyped with string.h of current lib
Hello # please Cc: to me in reply time. because, i doesn't subscribe # in to hackers and current. There is a little problem in ports build on current, and I send an email to you with its having been the function that you committed to because the cause seemed to be lib function of current. include/string.h cvslog: ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- 1.8 Wed Oct 10 2:19:09 JST 2001 UTC by ache Implement strcasestr() which many others (f.e. Linux) already have ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- Ports mail/mew2 has that problem, in current ports build error message: ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- mewls.c:128: conflicting types for `strcasestr' /usr/include/string.h:86: previous declaration of `strcasestr' ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- It is reported in [EMAIL PROTECTED] that there is the problem that mewls.c which this ports includes don't build. If Linux has the same problems in build of mew2, mew2 should solve it as a problem of mew2. But he had the report that he had on to build without a problem with Linux (gcc-2.95.4 or 3.0.2, glibc-2.2.4, PPC etc...) in a mew-dist mailing list (This is a thing for Mew develop- ment. http://www.mew.org/). That report said, Linux's /usr/include/string.h ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- #ifdef __USE_GNU /* Similar to `strstr' but this function ignores the case of both strings. */ extern char *strcasestr (__const char *__haystack, __const char *__needle) __THROW __attribute_pure__; #endif ---8<--8<--8<--8<--8<--8<--8<--8<--8<--- This seems to be the prototyping that becomes effective when special definitions of __USE_GNU is done. On this account a problem seems not to have been caused by general program in that this prototyping was not referred to, and mewls.c can build. In implementation with current, even if you implemented it for the reason that Linux included, there is the problem that behavior is different from Linux in about prototyping reference. I consider a method to solve this problem shuts up this function in a cage of special definitions similar to __USE_GNU of Linux, or remove it. *** * This message is a thing by output of automatic translation. * * Therefore it will be for there to be a lot of funny parts. * * Please approve it. * *** NINOMIYA(family name) Hideyuki(fast name) @ ehime japan mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED] PGP-Fingerprint:6C59 EC08 5B23 6490 44D0 7CD3 DA40 219F 7114 8553 PGP-Public-Key: http://user.shikoku.ne.jp/~nin/pgp/public-key.txt To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
