Hello,
while porting FICL, I noticed an aliasing bug which manifests (at least)
with gcc 4.4.2 and 4.4.3 when strict-aliasing is enabled. The root cause is
#define LVALUEtoCELL(v) (*(CELL *)v)
in sys/boot/ficl/ficl.h. CELL is a union:
typedef union _cell
{
FICL_INT i;
FICL_UNS u
On Sat, 2004-02-07 at 15:18, Didier Wiroth wrote:
Hi,
using freebsd5.2-release
I've set vfs.usermount=1 in sysctl.conf.
Normal user get permission denied when trying to
mount an ntfs permission (slice ars01), until root
has mount and umount it at least once.
See the following
Hello,
I'm seeing daily lockups on an up to date -CURRENT machine.
I've had the debugger already compiled in, but it didn't save a
crashdump. The machine is mostly idle, it has only some IMAP mailboxes
under cyrus.
All I could save from the console is the following:
pst: timeout mfa=0x002a5850
On Tue, 2 Dec 2003, Attila Nagy wrote:
I'm seeing daily lockups on an up to date -CURRENT machine.
I've had the debugger already compiled in, but it didn't save a
crashdump. The machine is mostly idle, it has only some IMAP mailboxes
under cyrus.
It appears you have the hardware watchdog
Doug White wrote:
It appears you have the hardware watchdog enabled. Any reason you need
that? It might be malfunctioning on your system.
It's FreeBSD's WATCHDOG, and all I compiled that in is why I needed the
machine to go. But it doesn't :-O
It freezes without the watchdog completely.
Also
This fixes a bug where an attempt to load a file path which contains
an intermediate path element which is a file on the CD rather then
a directory results in the file being accessed like a directory... which
can lockup the boot code.
The fix is simple. Check to see
Terry Lambert wrote:
Stefan Farfeleder wrote:
On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
From: Jacques A. Vidrine [EMAIL PROTECTED]
The application is broken. You must only check errno if you get an
error indication from the library call.
errno is only
Wrong, strtol() can set errno in two cases, when the value is outside
the range of representable values or when no conversion could be
performed.
well 'natch. it's trying to do math.h style hacks and overloads errno.
iirc those sorts of things stem from V6/V7 on the PDP/11 when you
may have
Maxime Henrion wrote:
Terry Lambert wrote:
Wrong, counter-example: strtol().
Wrong; the standard specifies that the errno shall only be
checked when the return value is -1. The exception in the
strtol() case is only for presetting errno to 0 before you
make the call, and making a
From: Stefan Farfeleder [EMAIL PROTECTED]
errno is meaningful for syscalls after an error (the original
message). The fact that other functions also dink with errno is not
relevant to that statement.
I read boyd's statement as a contradiction to Jacques' one (only after
syscall error
In message [EMAIL PROTECTED], boyd, rounin write
s:
From: Stefan Farfeleder [EMAIL PROTECTED]
errno is meaningful for syscalls after an error (the original
message). The fact that other functions also dink with errno is not
relevant to that statement.
I read boyd's statement as a
of
the use of errno, that's unfortunate :-)
The problem is that the emulated/wrapped close from libc_r does not
behave like the real one. libc_r is leaking some of its guts
(the tricks it's doing with O_NONBLOCK, etc) in the interface.
This is technically a bug. The fix was trivial.
Regards,
Adi
.
This is technically a bug. The fix was trivial.
I don't see a bug. You don't check errno unless the return is -1.
If the return is -1, then it must be because ret = __sys_close(fd)
failed in which case errno will be set appropriately.
Even so, there are other things to worry about aside from the fcntl
) in the interface.
This is technically a bug. The fix was trivial.
Hello Enache,
My point was that this is not technically a bug. According to
IEEE Std 1003.1-2001 aka the Single Unix Specification Version 3
(``SUSv3'') aka POSIX, an application must not examine and interpret
`errno' unless the library
Stefan Farfeleder wrote:
On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
From: Jacques A. Vidrine [EMAIL PROTECTED]
The application is broken. You must only check errno if you get an
error indication from the library call.
errno is only meaningful after a syscall error.
On Sun, Nov 23, 2003 at 04:14:08PM +0200, Enache Adrian wrote:
$ cc close.c -o close ./close
0
0
$ cc close.c -lc_r -o close ./close
0
25
$ cat close.c
#include errno.h
main()
{
int fd = open(/dev/null, 1);
printf(%d\n, errno);
close(fd);
From: Jacques A. Vidrine [EMAIL PROTECTED]
The application is broken. You must only check errno if you get an
error indication from the library call.
errno is only meaningful after a syscall error.
it is also well known that stdio uses isatty(3) (or equivelant) that may
set errno to ENOTTY.
On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
From: Jacques A. Vidrine [EMAIL PROTECTED]
The application is broken. You must only check errno if you get an
error indication from the library call.
errno is only meaningful after a syscall error.
Wrong, counter-example:
In message: [EMAIL PROTECTED]
Stefan Farfeleder [EMAIL PROTECTED] writes:
: On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
: From: Jacques A. Vidrine [EMAIL PROTECTED]
: The application is broken. You must only check errno if you get an
: error indication from the
On Mon, Nov 24, 2003 at 03:33:49PM -0700, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Stefan Farfeleder [EMAIL PROTECTED] writes:
: On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote:
: From: Jacques A. Vidrine [EMAIL PROTECTED]
: The application is broken.
$ cc close.c -o close ./close
0
0
$ cc close.c -lc_r -o close ./close
0
25
$ cat close.c
#include errno.h
main()
{
int fd = open(/dev/null, 1);
printf(%d\n, errno);
close(fd);
printf(%d\n, errno);
}
This confuses rather badly applications which assume errno is
parameter, so if a have dowloaded 4.5G (for example) what
number will send to radius?
Regards,
Boris
Barney Wolff wrote:
On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote:
I found a serious bug in RADIUS accounting code. The problem is that
OctetsIn and OctetsOut are defined
Hi,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
Hello!
Yes, unsigned, so we have 4G limit, which may simple be overflowed
by (for example) PPPoE connection. Yes, RADIUS standard defines new
attributes for big words, but current PPP does not supports it (it, so
our knowledge about RFC is
Hello!
Standard PPP does not support UPDATE packets, and of course (as my
RADIUS knowledge) the counters should not be resetted, because RADIUS
updates the same record.
Regards,
Boris
Michael Bretterklieber wrote:
Hi,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
Hello!
Yes,
Hi Boris,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
Hello!
Standard PPP does not support UPDATE packets, and of course (as my
but a patch could be written :-)
RADIUS knowledge) the counters should not be resetted, because RADIUS
updates the same record.
The RFC says:
5.4.
The RFC says:
5.4. Acct-Output-Octets
blabla
can only be
present in Accounting-Request records where the Acct-Status-Type
is set to Stop.
It looks like, that these counters must not present in accounting updates.
You are right, but your words - but a patch could be written :-).
Hi,
On Wed, 19 Nov 2003, Boris Kovalenko wrote:
The RFC says:
5.4. Acct-Output-Octets
blabla
can only be
present in Accounting-Request records where the Acct-Status-Type
is set to Stop.
It looks like, that these counters must not present in accounting updates.
You
Hello!
So sending interim update packets won't help.
Like I said :)
looking for someone who supervises my patch and commit it if no problems
will be founded.
this can be a problem :-)
This is the problem now :) I'm wondering if I only one useing ppp with
RADIUS accounting with FreeBSD.
On Wed, Nov 19, 2003 at 09:00:01AM +0500, Boris Kovalenko wrote:
I found a serious bug in RADIUS accounting code. The problem is that
OctetsIn and OctetsOut are defined as unsingned long long, but the
RADIUS supports only INT32 values, so, when
we're doing rad_put_int(r-cx.rad
Hello!
I found a serious bug in RADIUS accounting code. The problem is that
OctetsIn and OctetsOut are defined as unsingned long long, but the
RADIUS supports only INT32 values, so, when
we're doing rad_put_int(r-cx.rad, RAD_ACCT_OUTPUT_OCTETS,
stats-OctetsOut) in radius.c for OctetsOut
Hi,
shouldn't this work?
# ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
ether 00:07:e9:0a:26:52
ifconfig: ether: bad value
This is with today's -current, but this may have been around longer - I
hadn't tried it before today. Using two commands to set MAC and IP
addresses
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote:
shouldn't this work?
# ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
ether 00:07:e9:0a:26:52
ifconfig: ether: bad value
This is with today's -current, but this may have been around longer - I
hadn't tried it
Bruce M Simpson wrote:
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote:
shouldn't this work?
# ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
ether 00:07:e9:0a:26:52
ifconfig: ether: bad value
This is with today's -current, but this may have been around longer - I
Eugene M. Kim wrote:
Validating a root password is possible with other means in many cases,
if not always. OpenSSH sshd is a good example. Even with
PermitRootLogin set to no, the attacker can differentiate whether the
password has been accepted or not.
That's because the software in
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote:
shouldn't this work?
# ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \
ether 00:07:e9:0a:26:52
ifconfig: ether: bad value
This is with today's -current, but this may have been around longer - I
hadn't tried it
Craig Boston wrote:
Absolutely worst case, the root user could log in remotely, gdb
your screen saver, type foobar as the password, and then hack
the authentication function return value to say yes, that's the
correct password for [EMAIL PROTECTED], and get in without needing
to have
Eugene M. Kim wrote:
Terry Lambert wrote:
I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
I can unlock it with the root's password as well as my normal user's
password. I don't think it is a good thing. Is it a bug?
It is intentional, although you can eliminate
Terry Lambert wrote:
Eugene M. Kim wrote:
Terry Lambert wrote:
I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
I can unlock it with the root's password as well as my normal user's
password. I don't think it is a good thing. Is it a bug?
It is intentional, although you
[EMAIL PROTECTED] wrote:
I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
I can unlock it with the root's password as well as my normal user's
password. I don't think it is a good thing. Is it a bug?
It is intentional, although you can eliminate it with a recompile
Absolutely worst case, the root user could log in remotely, gdb
your screen saver, type foobar as the password, and then hack
the authentication function return value to say yes, that's the
correct password for [EMAIL PROTECTED], and get in without needing
to have xscreensaver accept the root
Terry Lambert wrote:
[EMAIL PROTECTED] wrote:
I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
I can unlock it with the root's password as well as my normal user's
password. I don't think it is a good thing. Is it a bug?
It is intentional, although you can eliminate
Hi,
I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
I can unlock it with the root's password as well as my normal user's
password. I don't think it is a good thing. Is it a bug?
Regards,
--
Zeng Nan
Simple is Beautiful
[EMAIL PROTECTED] wrote:
Hi,
I'm new in FreeBSD. I found that after I lock screen with xscreensaver,
I can unlock it with the root's password as well as my normal user's
password. I don't think it is a good thing. Is it a bug?
It is not a bug, but rather a feature of xscreensaver. It has
Maybe at a good time the next snapshot should be imported into
freebsd to get this fix, too :-)
Some ports (eg. mysql40, apache) are switchable to high optimization
where a bug in gcse could cause invalid code which will be removed
with the patch for this bug.
Original Message
On Sat, 08 Nov 2003 17:08:10 +
Jens Rehsack [EMAIL PROTECTED] wrote:
Maybe at a good time the next snapshot should be imported into
freebsd to get this fix, too :-)
Some ports (eg. mysql40, apache) are switchable to high optimization
where a bug in gcse could cause invalid code which
Hello,
I noticed that using pppctl interactively doesn't work quite right, at least for
certain commands that produce a lot of output. I cut and pasted a few invocations
to show what works and what doesn't quite work:
$ pppctl /var/ppp/ppp
PPP ON bogushost2 show route
Destination
Hi,
Looking over the code for nmount(), I think I noticed a few bugs.
(tried send-pr, but the lack of a web-front-end at freebsd.org,
and a decent mail system locally means that's not a runner)
nmount() calls vfs_nmount() pretty much directly after copying in
the io vector from userland.
.
So I assume this is an NIS/ACL bug of some kind? Both my uid
and gid as well as both the gid's above (nes and loki) are mapped via
NIS. If anyone needs me to do anything else, let me know. I don't feel
nearly competent enough to start debugging the source for get/setfacl to
try to grok any
On 03 Nov 2003, Robert Watson wrote:
revision 1.11
date: 2003/07/24 23:33:25; author: rwatson; state: Exp; lines: +3 -2
Print group name in getfacl output when calculating an effective
permission set based on a more restrictive mask.
Duh. I need to add cvsweb to my list of
I think I might have found a bug in ACL's under UFS2 with
5.1-RELEASE-p10. I have been using ACL's successfully for awhile
now, but I'd never played with default ACL's for directories and
files you create underneath said directories until I came across
the daemon news article at:
---
http
.
Of course, looking at the example right after I sent the
message, I see that the file inherited default UID's from the
directory, not GID's, but blah, I assume it should still work the
same either way? Or maybe it's a feature and not a bug. :)
--
Mark Nipper
my /usr/local/lib/sasl2/Sendmail.conf:
pwcheck_method: auxprop
auxprop_plugin: sasldb
Is the Sendmail.conf file the same as the FreeBSD file on the Solaris 8
system?
yes of course. On Solaris8 box and FreeBSD box i have a identical
configuration.
Does sasldblistusers2 on the
From:[EMAIL PROTECTED]
I have a problem with nss_ldap on FreeBSD.
After tranfer users from /etc/passwd to ldap directories my users cannot
send a mail via /usr/bin/mail | /usr/sbin/sendmail program:
:
Any ideas ?
What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?
Is
I have a problem with nss_ldap on FreeBSD.
After tranfer users from /etc/passwd to ldap directories my users cannot
send a mail via /usr/bin/mail | /usr/sbin/sendmail program:
What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?
Is pwcheck_method set to saslauthd, or sasldb?
From: Alex Deiter [EMAIL PROTECTED]
I have a problem with nss_ldap on FreeBSD.
After tranfer users from /etc/passwd to ldap directories my users
cannot
send a mail via /usr/bin/mail | /usr/sbin/sendmail program:
What are the contents of the /usr/local/lib/sasl*/Sendmail.conf file?
Is
From: Scot W. Hetzel [EMAIL PROTECTED]
From: Alex Deiter [EMAIL PROTECTED]
I have a problem with nss_ldap on FreeBSD.
After tranfer users from /etc/passwd to ldap directories my users
cannot
send a mail via /usr/bin/mail | /usr/sbin/sendmail program:
What are the contents of the
Folks,
I've noted that the following inconsistency exists in make release. If
there is a install.cfg file in /usr/src/release when executing make
release (the file which if exists is placed into the root of mfs and
customises behaviour of sysinstall), /usr/src/release/install.cfg takes
and then setting them back again).
My hunch is that some hardware bug is being tickled by gcc somehow. I
don't think it's the standard broken hardware thing because I've not
received any signal 11/7/4 errors at all and the system runs
wonderfully. So far it's been up for over 24 hours
the problem (actually, I've had greater success
leaving my CFLAGS set to -O2 -pipe and occasionally bringing them back
to -O -pipe when I run into an ICE and then setting them back again).
My hunch is that some hardware bug is being tickled by gcc somehow. I
don't think it's the standard broken
the CFLAGS from -O to -O2 or
vice-versa works around the problem (actually, I've had greater success
leaving my CFLAGS set to -O2 -pipe and occasionally bringing them back
to -O -pipe when I run into an ICE and then setting them back again).
My hunch is that some hardware bug is being tickled
that toggling the CFLAGS from -O to -O2 or
vice-versa works around the problem (actually, I've had greater success
leaving my CFLAGS set to -O2 -pipe and occasionally bringing them back
to -O -pipe when I run into an ICE and then setting them back again).
My hunch is that some hardware bug is being
them back again).
My hunch is that some hardware bug is being tickled by gcc somehow. I
don't think it's the standard broken hardware thing because I've not
received any signal 11/7/4 errors at all and the system runs
wonderfully. So far it's been up for over 24 hours, compiling ports
after the timeout, not 2.
can someone verify this? is it a bug that must be fixed from the freebsd
side or should a bug report to the isc-dhcp people?
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe
Hi,
with a missing dhcpserver or non-existent interface, this works.
however, it does not when i unplug the ethernet cable. in that case, i get
back true after the timeout, not 2.
can someone verify this? is it a bug that must be fixed from the freebsd
side or should a bug report to the isc
It seems David Gilbert wrote:
I submitted kern/56572 a few minutes ago. It patches ata-disk.c to
reject a disk that has zero blocks.
This is a good thing ... malicious or broken disks (compact flash,
whatever) shouldn't crash machines.
But in this case, the detected ad3 doesn't exist.
Soren == Soren Schmidt [EMAIL PROTECTED] writes:
Soren It seems David Gilbert wrote:
I submitted kern/56572 a few minutes ago. It patches ata-disk.c to
reject a disk that has zero blocks.
This is a good thing ... malicious or broken disks (compact flash,
whatever) shouldn't crash
It seems David Gilbert wrote:
Soren Uhm, I'm working on finding the real problem, and I'd like that
Soren to be the solution. However the above may be a good workaround
Soren for those bitten by this...
Well... is it not possible for malicious hardware to claim to have
zero blocks (by
Hi all, maybe not really proper mailling list, I just cvsuped 4.9 prerelease
and funny thing with syslog
this is newsyslog.conf
/var/log/httpd-referer.log 644 20*$M1D0 BZ /var/run/httpd.pid
30
this is newsyslog -v output
/var/log/httpd-referer.log 20Z: -- will
I submitted kern/56572 a few minutes ago. It patches ata-disk.c to
reject a disk that has zero blocks.
This is a good thing ... malicious or broken disks (compact flash,
whatever) shouldn't crash machines.
But in this case, the detected ad3 doesn't exist. The machine is a
laptop with a drive
-src/obj/private/freebsd-src/src/sys/CISEKERN
i386
1) getnetgrent still seems to ignore the NIS netgroup maps and only uses
/etc/netgroup. A '+' as the only entry in /etc/netgroup does not force
an NIS netgroup map lookup. This bug has been reported in the 4.x tree
as well.
2
Greetings,
I have not seen anyone discussing this issue and was
wonering if anyone had seen the nasty current
counterstrike hack that is making it's way around the net?
/usr/src/sys/contrib/dev/acpica/acfreebsd.h includes ctype.h which is
incompatible with its redefinition in /usr/include/stand.h
As result we got:
=== i386/libi386
cc -O -pipe -march=pentium3 -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DTERM_EMU -I/usr/src/sys/boot/i386/libi386/../../common
Andrey Chernov wrote:
/usr/src/sys/contrib/dev/acpica/acfreebsd.h includes ctype.h which is
incompatible with its redefinition in /usr/include/stand.h
As result we got:
=== i386/libi386
cc -O -pipe -march=pentium3 -ffreestanding -DCOMPORT=0x3f8 -DCOMSPEED=9600
-DTERM_EMU
Hi there,
when running gstat I'm seeing things like this:
dT: 0.509 flag_I 50us sizeof 240 i -1
L(q) ops/sr/s kBps ms/rw/s kBps ms/w %busy Name
1189149 21136.2 39785 20.6 87.8| da0
1226218 8891 14.2 8785 24.6
Hi Lucas,
Which versions ? 5.0, 5.1 or -current ?
Does the large numbers persist when the system is idle, or do they
fall back to zero ?
Poul-Henning
In message [EMAIL PROTECTED], Lukas Ertl writes:
Hi there,
when running gstat I'm seeing things like this:
dT: 0.509 flag_I 50us
On Mon, 4 Aug 2003, Poul-Henning Kamp wrote:
Hi Lucas,
Which versions ? 5.0, 5.1 or -current ?
CURRENT from this morning CEST.
Does the large numbers persist when the system is idle, or do they
fall back to zero ?
This is a snapshot from an idle system:
dT: 0.510 flag_I 50us
On Mon, 4 Aug 2003, Lukas Ertl wrote:
This is a snapshot from an idle system:
dT: 0.510 flag_I 50us sizeof 240 i -1
0 0 0 00.0 0 00.00.0| da0s1f
4294967293 4 0 00.0 4 63 10.6 561.0| da0s1g
0 0 0
On Fri, Aug 01, 2003 at 06:37:03 +0400, Andrey Chernov wrote:
On Fri, Aug 01, 2003 at 04:44:08 +0400, Andrey Chernov wrote:
This patch address two problems.
Revides patch version with accurate skipping. Surprisingly, the code is
reduced.
If you ever plan, don't try this patch, use
On Sat, Aug 02, 2003 at 10:11:24AM +0200, Eivind Olsen wrote:
db trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at g_dev_strategy+0x29
launch_requests(c299bf00,0,1,,47) at launch_requests+0x448
vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
vinumstart(c5ada2d0,0,c22ab000,cfb5294c,c02e5bc6) at vinumstart+0x2b2
vinumstrategy(c5ada2d0,0,c09719b0,40,0) at vinumstrategy+0xa6
Looks like a problem in vinum. The other backtrace was the same, right?
Please take a look at an older thread named (IIRC) vinum or geom bug?
Greg asked for special
[Sending to [EMAIL PROTECTED], and Kris copied in Greg so I'll also do that]
--On 2. august 2003 02:00 -0700 Kris Kennaway [EMAIL PROTECTED] wrote:
db trace
g_dev_strategy(c2156024,c2153800,0,cfb528d0,c2099eca) at
g_dev_strategy+0x29 launch_requests(c299bf00,0,1,,47) at
--On 2. august 2003 11:16 +0200 Bernd Walter [EMAIL PROTECTED]
wrote:
Looks like a problem in vinum. The other backtrace was the same, right?
Please take a look at an older thread named (IIRC) vinum or geom bug?
Greg asked for special debug output, but it never happened again for me.
A real
On Fri, Aug 01, 2003 at 06:12:13AM +0400, Andrey Chernov wrote:
On Fri, Aug 01, 2003 at 12:02:04 +1000, Tim Robbins wrote:
8 bits by casting to char. Using charcoll() to sort char arrays may
work on little endian machines, but may not on big endian machines.
s-set is array of ints, not
Because of the nature of this bug, I have no network access on my FreeBSD
machine and so I'm filing this off my wife's laptop. I can't send-pr in any
other manner. Would someone please post this
SYSTEM
IBM 380XD Thinkpad Laptop running either a recent (post-May) 4.8-STABLE or
5.1-RELEASE (off
Here about the latest bug, i was telling about ...
Regards Kai
-Ursprüngliche Nachricht-
Von: pinskia at physics dot uc dot edu [mailto:[EMAIL PROTECTED]
Gesendet: Donnerstag, 31. Juli 2003 01:45
An: [EMAIL PROTECTED]
Betreff: [Bug c++/11735] [3.3 Regression] internal compiler error
This patch address two problems.
1st one is relatively minor: according our own manpage, upper and lower
classes must be sorted, but currently not.
2nd one is serious:
tr '[:lower:]' '[:upper:]'
(and vice versa) currently works only if upper and lower classes
have exact the same number
On Fri, Aug 01, 2003 at 04:44:08AM +0400, Andrey Chernov wrote:
@@ -208,10 +210,18 @@
if ((func)(cnt))
*p++ = cnt;
*p = OOBCH;
+ n = p - cp-set;
s-cnt = 0;
- s-state = SET;
s-set = cp-set;
+ if (strcmp(s-str, upper) ==
On Fri, Aug 01, 2003 at 12:02:04 +1000, Tim Robbins wrote:
8 bits by casting to char. Using charcoll() to sort char arrays may
work on little endian machines, but may not on big endian machines.
s-set is array of ints, not array of chars. In any case thanx for
looking.
Also, watch out for
On Fri, Aug 01, 2003 at 04:44:08 +0400, Andrey Chernov wrote:
This patch address two problems.
Revides patch version with accurate skipping. Surprisingly, the code is
reduced.
Only in .: CVS
diff -u ./extern.h /usr/src/usr.bin/tr/extern.h
--- ./extern.h Fri Jun 14 19:56:52 2002
+++
Hello,
If no one objects to it, I'd like to commit the following ASAP. It
fixes an obvious bug in the big pipe code, a discrepancy between
how free space is calculated in write vs poll. The bug affects
stable as well.
The bug's implications are less obvious: it make write(2) on a
non-blocking
On Wed, Jul 30, 2003 at 11:32:49PM +0200, Pierre Beyssac wrote:
- if (space 0 (wpipe-pipe_buffer.cnt PIPE_SIZE)) {
+ if (space 0
+ wpipe-pipe_buffer.cnt wpipe-pipe_buffer.size) {
PS : not-so-obvious after all since the above is equivalent to
(space
On Wed, 30 Jul 2003, Pierre Beyssac wrote:
On Wed, Jul 30, 2003 at 11:32:49PM +0200, Pierre Beyssac wrote:
- if (space 0 (wpipe-pipe_buffer.cnt PIPE_SIZE)) {
+ if (space 0
+wpipe-pipe_buffer.cnt wpipe-pipe_buffer.size) {
PS : not-so-obvious
On Sun, Jul 20, 2003, Divacky Roman wrote:
Hi,
I might be wrong but this:
free(mp-mnt_data, M_UNIONFSMNT); /* XXX */
mp-mnt_data = 0;
seems to me wrong and might cause crashes etc.
am I correct or wrong?
its from union_vfsops.c:384
What's wrong with
Hi,
I might be wrong but this:
free(mp-mnt_data, M_UNIONFSMNT); /* XXX */
mp-mnt_data = 0;
seems to me wrong and might cause crashes etc.
am I correct or wrong?
its from union_vfsops.c:384
thnx
Roman Divacky
___
On Sun, Jul 20, 2003 at 03:02:21PM +0200, Divacky Roman wrote:
+ I might be wrong but this:
+
+ free(mp-mnt_data, M_UNIONFSMNT); /* XXX */
+ mp-mnt_data = 0;
+
+ seems to me wrong and might cause crashes etc.
+ am I correct or wrong?
Could you describe scenario when
Harald Schmalzbauer wrote:
Please forget that. It was because for convinience reasons I had turned the
80-pin ATA cables upside down. So the black was at the controller and the
blue at the drive.
I can't imagine that this makes any technical difference (as long as no
slave drive is connected
It seems Harald Schmalzbauer wrote:
I also think the RAID configuration is stored on the disks since when I
create a non-DOS compatible slice (starting at 0 not 63) the RAID
configuration vanishes.
Yes the Highpoint BIOS uses sector 9 to hold the RAID config, so if you
use that for other
Harald Schmalzbauer wrote:
Harald Schmalzbauer wrote:
Ok, like I thought, the disk was not defect. There seems to be a
bug in ata
regarding HPT372
First: Wiht BIOS version 2.342 the secondary master disk id is incorrectly
detected (something liek X X X X X X X X X X X X X X X instead
Soeren Schmidt wrote:
which is named FreeBSD)
And that's why FreeBSD panics until I delete the mirror relationship.
Well Highpoints way of dealing with broken arrays and lost disks are less
than optimal, I've tried to do my best in the ATA driver to fool the HPT
system, but its not
Harald,
When in doubt, install freebsd 5.x on a different drive running off of a
different controller, mount the slices from one of the disks in the RAID
array and copy your data to a safe and trusted location.
Regards,
Andre Guibert de Bruet | Enterprise Software Consultant
Silicon
601 - 700 of 1405 matches
Mail list logo
