Re: 5.2-BETA: giving up on 4 buffers (ata)
On Thu, Nov 27, 2003 a.d., Bruce Evans wrote: This is a known problem for nearly three months now (See PR 56675). It happens to me every time I shut down the system if i don't unmount my (read-only) ext2 file systems manually. I'm not sure if the problem is known for the read-only case. It is the same problem as in the read-write case. ext2fs hangs onto buffers, so shutdown cannot tell if it can look at the buffers and considers them to be busy. Then since shutdown cannot tell if it synced all dirty buffers or which buffers are associated with which file systems, it doesn't unmount any file systems and all dirty file systems that aren't unmounted before shutdown are left dirty. Read-only-mounted ext2fs file systems aren't left dirty but they break cleaning of other file systems. I positively know that the given up buffers are the ones got with bread() in compute_sb_data() (ext2_vfsops:481). I doesn't matter if the mount is rw or ro. The comments in fs.h:155 suggests they will be released by biodone, but this doesn't happen :-) Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 a.d., Jacques A. Vidrine wrote: The application is broken. You must only check errno if you get an error indication from the library call. Sorry, but I don't see your point. I know when to check for errno. If you took the little illustrating program for a real life example 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
$ 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 meaningful.
It could be fixed easily by repeating the trick from uthread/uthread_fd.c:
--- /arc/freebsd/src/lib/libc_r/uthread/uthread_close.c Tue Jun 10 23:42:27 2003
+++ lib/libc_r/uthread/uthread_close.c Sun Nov 23 00:50:30 2003
@@ -87,10 +87,12 @@ _close(int fd)
*/
if ((S_ISREG(sb.st_mode) || S_ISCHR(sb.st_mode))
(_thread_fd_getflags(fd) O_NONBLOCK) == 0) {
+ int saved_errno = errno;
/* Get the current flags: */
flags = __sys_fcntl(fd, F_GETFL, NULL);
/* Clear the nonblocking file descriptor flag: */
__sys_fcntl(fd, F_SETFL, flags ~O_NONBLOCK);
+ errno = saved_errno;
}
/* XXX: Assumes well behaved threads. */
Regards,
Adi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADS UP: /bin and /sbin are now dynamically linked
On Sat, Nov 22, 2003 a.d., M. Warner Losh wrote: Grepping seems unsatisfying to find out which keys are used. Do you have a list? Believe it or not, vi only needs 'cm' :-) Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[PATCH] /bin/sh buglet
$ a=foo
$ : $((a=15))
arithmetic expression: variable assignment error: a=15
$ echo $a
15
--- /usr/src/bin/sh/arith.y Thu Sep 4 23:31:14 2003
+++ ./arith.y Sun Sep 7 01:04:06 2003
@@ -155,7 +155,7 @@
} |
ARITH_VAR ARITH_ASSIGN expr
{
- if (arith_assign($1, $3) != 1)
+ if (arith_assign($1, $3) != 0)
yyerror(variable assignment error);
$$ = $3;
} |
Regards,
Adi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Regarding VMWare 3.0 Port and an odd bug that i've been gettingover and over again...
On Fri, Jul 11, 2003 at 09:15:48PM -0700, Scott M. Likens wrote: Jul 11 16:45:20: ide0:0|NOT_IMPLEMENTED F(831):712 Jul 11 16:45:20: ide0:0|AIO: ide0:0, Process 60017 panic. Jul 11 16:45:20: ide0:0|AIOSlave: Exit after panic. Jul 11 16:45:20: VMX|AIO: NOT_IMPLEMENTED F(831):712 Jul 11 16:45:20: VMX|Panic loop I'm pretty sure that's the nice incompatibility in recent glibc's. vmware still thinks nice returns -1 on error, and that's no longer true: it returns the new nice value, which could be very well -1. The error message is totally bogus - it's probably issued by higher layers that assume nice cannot fail. Your only solution is to disassemble and binary patch vmware itself using a hexeditor. That may not be legal :-) Good luck, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ReiserFS
On Sun, Jun 22, 2003 at 07:37:12PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Sunday 22 June 2003 18:17, Simon Watson wrote: Maybe I should have clarified this, I'm only after readonly support - just enough to be able to successfully move my data over to UFS. If you can live with creating UFS1 filesystems, you can just mount them read-write in Linux and move your data over that way. Or you wait a little while longer until Linux' UFS implementation can mount UFS2 (shouldn't be to difficult to hacked up anyway). Hmm, last time I mounted read-write an UFS partition from linux (with a 2.4.18 kernel) all the filesystem was unrecoverably trashed - and I see that read-write support for UFS is still marked DANGEROUS in 2.5.X kernels, so better don't try that :) Regards, Adi ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux emulation busted
On Mon, Mar 24, 2003 at 08:40:55AM -0700, M. Warner Losh wrote: I had a working Linux world on my laptop. I upgraded my kernel and acroread4 stopped working. Now all I get is: Is acroread4 multithreaded ? Because since about 2 months all multithreaded linux binaries have stopped working for me; I don't know if this because the new glibc 2.2.93 ( I upgraded at the same time to RH 8.0 ) or something in the linux emulation ( I couldn't spot any relevant change there). I didn't have yet the time to investigate, but: - I could reproduce it with small multithreaded test programs. - It seems that the 'thread model' (i.e. what parameters are passed to clone()) hasn't changed in glibc 2.3 Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Shell programming 101: Is this an expr(1) bug ?
On Tue, Feb 18, 2003 at 12:39:22PM +0100, Poul-Henning Kamp wrote: Running: #!/bin/sh set -ex for p in ad2 ad0 ad1 do a0=`expr $p : '^ad\([0-9]\)$'` done I get: syv# sh _ + expr ad2 : ^ad\([0-9]\)$ + a0=2 + expr ad0 : ^ad\([0-9]\)$ + a0=0 syv# echo $? 1 syv# That looks like a bug to me... Confusing but documented behaviour: 1. expr ad0 : ad\([0-9]\) = expr 0 man expr If the match succeeds and the pattern contains at least one regu- lar expression subexpression ``\(...\)'', the string correspond- ing to ``\1'' is returned; otherwise the matching operator 2. `expr 0` = exit status = 1 man expr The expr utility exits with one of the following values: 0 the expression is neither an empty string nor 0. 1 the expression is an empty string or 0. This behaviour is the same on linux, *BSD and probably other systems too. Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
multithreaded binaries dump core in linux emulation
I'm using a very recent FreeBSD-current ( ~ 4 days ago ). Since I upgraded my linux installation to RH 8.0 ( ~ 2 months ), I'm not able to run multithreaded binaries under linux emulation any more. ( I hope you understand me - I don't want to install another set of native mozilla, ooffice and other bloats :-) ). That mean: glibc 2.2.93 linuxthreads 0.10 They used to work fine with older glibc - and no significant change has occurred since then in the linux emulation code. I cannot test with other system since I don't have either an older glibc stuff or an older FreeBSD at hand. Is anyone else aware of this problem or should I try to investigate it myself ? Thanks Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: add ext2fs to the module list in modules/Makefile
On Tue, Jan 28, 2003 at 09:54:30PM -0800, David O'Brien wrote: On Mon, Jan 27, 2003 at 11:14:41PM +0200, Enache Adrian wrote: please add ext2fs to the modules list in src/sys/modules/Makefile. It is already there. :-) Just wrapped by WANT_EXT2FS_MODULE. So you need to add that to your /etc/make.conf. Oh, really thank you for the answer. And sorry for posting without carefully checking before. Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: VOP_STRATEGY on VCHR
On Tue, Jan 28, 2003 at 09:38:19AM +0100, [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Enache Adrian writes: I get this when I try to access for the first time a file on an ext2fs filesystem. VOP_STRATEGY on VCHR Please try this patch and let me know if it helps ? Of course, it fixes it. Thanks Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
add ext2fs to the module list in modules/Makefile
please add ext2fs to the modules list in src/sys/modules/Makefile. my /usr/src tree resides on an ext2fs partition and the fact that ext2fs.ko isn't built causes me trouble when making installworld just after rebooting the new kernel. Thanks Regards Adi --- /arc/freebsd/src/sys/modules/Makefile 2003-01-22 01:31:50.0 +0200 +++ sys/modules/Makefile2003-01-27 21:36:45.0 +0200 @@ -34,6 +34,7 @@ de \ digi \ dummynet \ + ext2fs \ fdc \ fdescfs \ firewire \ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VOP_STRATEGY on VCHR
I get this when I try to access for the first time a file on an ext2fs filesystem. VOP_STRATEGY on VCHR : 0xc1c23000: tag devfs, type VCHR, usecount 2, writecount 0, refcount 3, backtrace(c02fe7bd,c1c23000,0,c87eb938,c0166ed8) at backtrace+0x8 spec_strategy(c87eb960,c87eb97c,c1c4163b,c87eb960,0) at spec_strategy+0x2d spec_vnoperate(c87eb960,0,c87eb95c,0,0) at spec_vnoperate+0x18 ext2_strategy(c87eb9c8,0,0,1000,0) at ext2_strategy+0x8b breadn(c1c22e6c,0,0,1000,0) at breadn+0x126 bread(c1c22e6c,0,0,1000,0) at bread+0x4c ext2_read(c87ebaf0,c0328a20,0,0,0) at ext2_read+0x293 ext2_readdir(c87ebc98,20002,c0b9a1e0,0,c1c22e6c) at ext2_readdir+0x130 getdirentries(c0b9a1e0,c87ebd14,c03195a7,407,4) at getdirentries+0x128 syscall(2f,2f,2f,80d1000,80d1040) at syscall+0x271 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (196), eip = 0x808cf1f, esp = 0xbfbff1bc, ebp = 0xbfbff1d8 --- Is that anything serious or just noise ? (this is -CURRENT from yesterday) Regards Adi To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
boot delay when testing for ata devices
FreeBSD used to have an irritating boot delay in 4.4. It was gone in
~4.6, never reappeared in -STABLE, but is there in -CURRENT.
(I've seen it also mentioned in some vmware documentation).
Applying this patch fixes it:
--- /arc/freebsd/src/sys/dev/ata/ata-all.c Sun Jan 19 23:54:13 2003
+++ sys/dev/ata/ata-all.c Mon Jan 27 21:02:34 2003
@@ -514,7 +514,7 @@
/* apparently some devices needs this repeated */
do {
- if (ata_command(atadev, command, 0, 0, 0, ATA_WAIT_INTR)) {
+ if (ata_command(atadev, command, 0, 0, 0, ATA_IMMEDIATE)) {
ata_prtdev(atadev, %s identify failed\n,
command == ATA_C_ATAPI_IDENTIFY ? ATAPI : ATA);
free(ata_parm, M_ATA);
I'm not familiar with the ata code, but I can't see from ata-all.c
which harm this could cause.
Regards
Adi
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
