Re: Stale mount on disconnected device: how to delete it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 18, 2007 at 10:03:42PM +1030, Daniel O'Connor wrote: On Tue, 18 Dec 2007, Nikos Ntarmos wrote: Off the top of my head, what is wrong/hard with just logging a device failure, discarding all remaining cached operations, and unmounting the fs when a disk device goes missing? I understand that this is not a viable solution for critical filesystems, but I can see nothing wrong with this approach for removable devices and/or non-critical fs's. There was a long, long thread which discussed this earlier. It's easy to say what should be done, it's harder to submit patches that clean up the respective failure modes. Point taken. Do you have any pointers to that thread? I did a quick search in hackers@ and current@ but failed to find anything relevant, other than people reporting related crashes and don't do that, then-type answers. \n\n -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Nikos Ntarmos [EMAIL PROTECTED] iD8DBQFHaOZqm6J1ac+VFgoRAs/5AJ9sPZblF1T3MBkDP8K4ycRaFDf9KgCdH3oL u+43/UxmFZnclQvcI4K+Xh8= =E7ue -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Stale mount on disconnected device: how to delete it?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Tue, Dec 18, 2007 at 01:13:55AM +0100, Romain Tartière wrote: On Mon, Dec 17, 2007 at 10:32:48AM -0800, Yuri wrote : In case of USB device (which device in question in this problem happens to be) usbd can be used to mount it. If attach/detach events trigger mount/unmount commands this problem shouldn't exist. I didn't try though. The problem is that the detach event can be caught only too late to unmount the device properly. How may it be possible to sync a disk ``as soon as it is detached'' (that is when it is not physically connected to the computer anymore)? Mounting the disk read-only may be a workaround, just as not caching writes (default behaviour of some versions of Windows) and syncing the disk all the time, but this is not as reliable as the mount system provided by Unix and Unix like operating systems. AFAICR, this is the sole weakness of the FreeBSD operating system I know :) And since it is, according to me, an operator error, the best we can do is to use the system as it was designed for ;) Off the top of my head, what is wrong/hard with just logging a device failure, discarding all remaining cached operations, and unmounting the fs when a disk device goes missing? I understand that this is not a viable solution for critical filesystems, but I can see nothing wrong with this approach for removable devices and/or non-critical fs's. Just my $0.02. \n\n -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.4 (FreeBSD) Comment: Nikos Ntarmos [EMAIL PROTECTED] iD8DBQFHZ2ABm6J1ac+VFgoRAhWtAJ4uomUoe0IDVG0qG2W+t7y9ZSMjugCbBAoz LtIIMhMCk9iZ3NeStO8uwLU= =+o7j -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Linux executable picks up FreeBSD library over linux one and breaks
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Sat, Dec 01, 2007 at 11:01:46PM +, Robert Watson wrote:
On Sat, 1 Dec 2007, Alexander Leidinger wrote:
Have a look at the search order of libs in linux. Correlate this with
the fact that when in linux an access is done to e.g. /lib/libX.so.y
which means that the linuxulator first looks if
/compat/linux/lib/libX.so.y is there, and if it isn't it looks if
/lib/libX.so.y is available.
AFAIR a work around is to add a link in
/compat/linux/usr/lib/librt.so.1 - /lib/librt.so.1
I want to do something like this in the FC4 port, but hadn't time to
do it and test it so far.
It sounds like the real problem is that there are some cases where we
don't want the Linuxulator to merge the underlying and Linux views of
the file system -- we don't want the union of /compat/linux/lib and
/lib, we just want /compat/linux/lib?
The problem mainly arises when a library appears earlier in the search
path in the underlying view of the file system than in the Linux view.
(e.g. there is no /compat/linux/path1/lib/libX.so.y but there is a
/path2/libX.so.y and path2 appears before path1 in the ld search path).
X-related libraries are a good example; since we moved to a
${LOCALBASE}-based X hierarchy, all X-based dynamically-linked linux
binaries pick up the native X libraries (i.e. from /usr/local/lib),
unless advised otherwise (e.g. via
LD_LIBRARY_PATH=/compat/linux/usr/X11R6/lib:$LD_LIBRARY_PATH).
Symbolic links do work. Another solution is to rearrange dynamic
libraries under /compat/linux so that they match the FreeBSD hierarchy
(and teach ld-linux to use the same search path as the native loader).
And yet another solution is to teach the linuxolator to first do an
exhaustive search for libraries under /compat/linux and only then fall
back to native ones (this seems similar to the above LD_LIBRARY_PATH
incantation).
Just my $0.02.
\n\n
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.4 (FreeBSD)
Comment: Nikos Ntarmos [EMAIL PROTECTED]
iD8DBQFHUgqim6J1ac+VFgoRAunbAJ4/zMkaKVO4Nuu5ddyjww1WIzdtQACeOq7C
i4a+uIyjPXAHfghAhfOgs9M=
=qKI+
-END PGP SIGNATURE-
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Configure error
Hi there.
On Fri, Dec 15, 2006 at 05:16:12PM -0900, Beech Rintoul wrote:
I googled the problem and found that autoconf by default doesn't look
in usr/local/include even if it's in the path. So, my question is what
to put in the makefile or what to patch in the sources to make
autoconf pick up that header?
I was just bitten by the same problem while trying to make a new port.
Adding:
USE_AUTOTOOLS= aclocal:19 automake:19 autoheader:259 autoconf:259
LDFLAGS+= -L${LOCALBASE}/lib
CFLAGS+=-I${LOCALBASE}/include
CONFIGURE_ENV= CFLAGS=${CFLAGS} LDFLAGS=${LDFLAGS}
pre-configure:
@(cd ${CONFIGURE_WRKSRC} \
${SETENV} ${AUTOTOOLS_ENV} ${ACLOCAL})
in the Makefile did the trick for me. This is without GNU_CONFIGURE=yes.
Cheers.
\n\n
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Bogus ioapic entry
Hi all.
I spent a couple of hours last night trying to get ACPI to function
correctly on my new Acer Aspire 1692WLMi. I found out that with apic
enabled, the system hangs when returning from S3, while with apic
disabled it suffers from interrupt storms on irq9 and the screen is not
reinitialized on return from S3 (with hw.acpi.reset_video set to both
0 and 1). While trying to hunt this thing down, I noticed that the
GENERIC kernel of 6.0-STABLE (and probably of other branches as well)
incorrectly discovers two ioapic devices:
ioapic1: Changing APIC ID to 2
ioapic0 Version 2.0 irqs 0-23 on motherboard
ioapic1 Version 15.15 irqs 24-23 on motherboard
There is something obviously wrong with ioapic1. The cause seems to be
the handling of value and numintr in ioapic_create(...). value is a
uint32_t, while numintr is a u_int, both of which are 32-bits long (per
sys/types.h and machine/_types.h at least on my i386). The code in
ioapic_create(...), after the call to ioapic_read(apic, IOAPIC_VER),
uses the latter's return value to compute the number of interrupts
assigned to the current ioapic. This return value is checked against
0xff (that's 24 1-bits) to detect an error and bail out. This code
chunk is also in -current (so perhaps I'm missing something here...)
The (buggy?) BIOS implementation of my laptop returns a value of
0x (32 1-bits) in ioapic_read(...). This, however, doesn't
trigger the current if-clause, so the code proceeds and creates ioapic1
with -1(!) assigned IRQs (due to the and-and-shift-plus-one formula of
computing numintr).
The attached diff fixes this situation and seems more correct to me than
the current code, given that io_numintr is 8 bits and u_int is 32 bits
per cannot-remember C standard. The problems with resuming from S3
still haunt me though. I guess I should have a look at acpi@ later
today...
Cheers.
\n\n
--- io_apic.c.orig Fri Aug 5 22:08:25 2005
+++ io_apic.c Wed Nov 16 12:26:47 2005
@@ -478,14 +478,21 @@
value = ioapic_read(apic, IOAPIC_VER);
mtx_unlock_spin(icu_lock);
- /* If it's version register doesn't seem to work, punt. */
- if (value == 0xff) {
+ /* Determine the number of vectors and set the APIC ID. */
+ numintr = ((value IOART_VER_MAXREDIR) MAXREDIRSHIFT) + 1;
+
+ /* numintr is a uint32_t but io_numintr is only 8 bits long. On my
+* Acer Aspire 1692WLMi, two ioapic's are discovered. However, the
+* second one is bogus, since ioapic_read(apic, IOAPIC_VER) returns
+* 0x, which doesn't trigger the old if-clause (value ==
+* 0xff). Keeping around an ioapic with -1 assigned IRQs doesn't
+* make much sense, so:
+*/
+ if ((numintr 0x00ff) == 0) {
pmap_unmapdev((vm_offset_t)apic, IOAPIC_MEM_REGION);
return (NULL);
}
- /* Determine the number of vectors and set the APIC ID. */
- numintr = ((value IOART_VER_MAXREDIR) MAXREDIRSHIFT) + 1;
io = malloc(sizeof(struct ioapic) +
numintr * sizeof(struct ioapic_intsrc), M_IOAPIC, M_WAITOK);
io-io_pic = ioapic_template;
signature.asc
Description: Digital signature
Re: hot path optimizations in uma_zalloc() uma_zfree()
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi there. On Sat, Jul 02, 2005 at 01:27:00PM +0300, Andriy Tkachuk wrote: here even more refereces to memory in your variant. Ummm... What compiler version are you use? The pointer variant produces faster code for me on both NetBSD/alpha (gcc 3.3.3) and Linux/x86 (gcc 3.3.5), using both -O0 and -O2 (other compiler flags also tested with similar results). Perhaps something specific to FreeBSD then? I guess I'll have to set up a FBSD box and have a look at it, when I catch up with some of the other stuff in my todo list... Anyway, the proposed optimization even makes sense if you think about it in a logical pen-and-paper way: array variant: 1. load address of element 0 of array to register A 2. load counter to register B 3. decrease register B 4. store back new decreased B 5. load (dereference) A[B] This last operation may either translate to a leal-type instruction, or to an add+load-type sequence of instructions. pointer variant: 1. load address of pointer to register A 2. decrease register A 3. store back new decreased A 4. load (dereference) A \n\n -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Nikos Nikolai Ntarmos [EMAIL PROTECTED] iD8DBQFCyIw0m6J1ac+VFgoRAonNAJ0Zs4Ohl+VWyv0FzgBfGV17Kt+uswCgkkRc +u9Ly5w59makY/R2noNI3nM= =ScoK -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hot path optimizations in uma_zalloc() uma_zfree()
Hi there.
I wouldn't have gone into this if ant hadn't produced that 10% figure
for the speed improvement with simply reordering of increments and
dereferences (although jhb@ reported the speed-up he noticed was much
less than that).
I attach* a patch that: (i) incorporates ant's exchange of uc_freebucket
for uc_allocbucket, and (ii) throws away the uma_bucket.ub_cnt counter
of free bucket entries, in favor of a pointer -- uma_bucket.ub_last --
to the last free bucket entry. If a simple reordering is capable of
producing a 10% improvement, this change should do much better, since it
saves the 'add-' in the 'add-and-dereference' process of using arrays
and counters. The semantics of the pointer closely follow those of the
ub_cnt counter: ub_last - ub_bucket should equal the old value of
ub_cnt.
I grep'ed through the whole source repository and the uses of
uma_bucket.ub_cnt seem confined within sys/vm/uma_core.c, so this change
must be quite self-contained -- i.e. the change in the fields of
uma_bucket doesn't seem to affect any other part of the system. One
could argue that it may make the code a bit less readable, but it only
affects uma_core.c, so it may be worth the inconvenience.
I don't have a FreeBSD box around any more, so I can't test this patch.
Heck, I can't either check it for syntax errors and such, so don't throw
things at me if this doesn't even compile. Can somebody with the time
and resources give it a try?
\n\n
* Also online at http://noth.ceid.upatras.gr/Misc/uma_bucket.diff
to avoid being bitten by mailers auto{wrapp,indent}ing the diff
content.
diff -urbB src.orig/sys/vm/uma_core.c src/sys/vm/uma_core.c
--- src.orig/sys/vm/uma_core.c 2005-06-30 19:09:06.777623184 +0300
+++ src/sys/vm/uma_core.c 2005-06-30 19:12:59.907182104 +0300
@@ -322,7 +322,7 @@
#ifdef INVARIANTS
bzero(bucket-ub_bucket, sizeof(void *) * ubz-ubz_entries);
#endif
- bucket-ub_cnt = 0;
+ bucket-ub_last = bucket-ub_bucket;
bucket-ub_entries = ubz-ubz_entries;
}
@@ -559,11 +559,11 @@
if (zone-uz_keg-uk_flags UMA_ZONE_MALLOC)
mzone = 1;
- while (bucket-ub_cnt 0) {
- bucket-ub_cnt--;
- item = bucket-ub_bucket[bucket-ub_cnt];
+ while (bucket-ub_last != bucket-ub_bucket) {
+ bucket-ub_last--;
+ item = *(bucket-ub_last);
#ifdef INVARIANTS
- bucket-ub_bucket[bucket-ub_cnt] = NULL;
+ *(bucket-ub_last) = NULL;
KASSERT(item != NULL,
(bucket_drain: botched ptr, item is NULL));
#endif
@@ -1820,11 +1820,11 @@
bucket = cache-uc_allocbucket;
if (bucket) {
- if (bucket-ub_cnt 0) {
- bucket-ub_cnt--;
- item = bucket-ub_bucket[bucket-ub_cnt];
+ if (bucket-ub_last != bucket-ub_bucket) {
+ bucket-ub_last--;
+ item = *(bucket-ub_last);
#ifdef INVARIANTS
- bucket-ub_bucket[bucket-ub_cnt] = NULL;
+ *(bucket-ub_last) = NULL;
#endif
KASSERT(item != NULL,
(uma_zalloc: Bucket pointer mangled.));
@@ -1851,7 +1851,7 @@
* We have run out of items in our allocbucket.
* See if we can switch with our free bucket.
*/
- if (cache-uc_freebucket-ub_cnt 0) {
+ if (cache-uc_freebucket-ub_last !=
cache-uc_freebucket-ub_bucket) {
#ifdef UMA_DEBUG_ALLOC
printf(uma_zalloc: Swapping empty with
alloc.\n);
@@ -1880,12 +1880,12 @@
cache = zone-uz_cpu[cpu];
bucket = cache-uc_allocbucket;
if (bucket != NULL) {
- if (bucket-ub_cnt 0) {
+ if (bucket-ub_last != bucket-ub_bucket) {
ZONE_UNLOCK(zone);
goto zalloc_start;
}
bucket = cache-uc_freebucket;
- if (bucket != NULL bucket-ub_cnt 0) {
+ if (bucket != NULL bucket-ub_last != bucket-ub_bucket) {
ZONE_UNLOCK(zone);
goto zalloc_start;
}
@@ -1897,7 +1897,7 @@
/* Our old one is now a free bucket */
if (cache-uc_allocbucket) {
- KASSERT(cache-uc_allocbucket-ub_cnt == 0,
+ KASSERT(cache-uc_allocbucket-ub_last ==
cache-uc_allocbucket-ub_backet,
(uma_zalloc_arg: Freeing a non free bucket.));
LIST_INSERT_HEAD(zone-uz_free_bucket,
cache-uc_allocbucket, ub_link);
@@ -1906,7 +1906,7 @@
/* Check the free list for a new alloc bucket */
if ((bucket = LIST_FIRST(zone-uz_full_bucket)) != NULL) {
-
GCC optimization bugs -- still there or a historic artifact?
Hi all.
There was a thread on the CFLAGS knob in make.conf in early Feb.'04
(the exact subject was need help on CFLAGS in /etc/make.conf
please), where some posters raised the issue of gcc optimization bugs
that supposedly manifest in optimization levels above -O2. The last
post on this subject was on Feb. 13th, though, and nothing has come up
ever since. AFAIK 5.2.1+ and -CURRENT have moved to gcc-3.3.3. Are
these issues still there?
I've been making my way around FreeBSD's and GCC's gnat and couldn't
find anything relevant. Ummm... Actually almost all relevant entries
in our gnat end with something like bug the gcc guys for we're too
overwhelmed to look into gcc issues. The funny thing is there is no
entry in the gcc's gnat about optimization bugs in 3.3.3. As some very
specific person noted, -O gets about an order of magnitude less
testing than -O2 by the gcc community.
This whole thing came up in the [EMAIL PROTECTED] list, in a thread
about Compaq's C compiler (aka ccc) for linux/alpha (lang/compaq-cc in
our ports tree) and its status in NetBSD. The manpage for make.conf
states that the issues with levels 1 are even worse on alpha. Well,
gcc-3.3.3 is as fast as (if not faster than) ccc for optimization
levels above -O2, and can be used for a much wider part of the C/C++
source available out there. So the question is: are these gcc issues
still there or just a historic artifact left lurking around manpages
just to be sure?
\n\n
--
Nikos Noth Ntarmos| ntarmos at ceid dot upatras dot gr
NetCINS Lab. @ C.E.I.D. | [ http://{noth,p2p}.ceid.upatras.gr/ ]
U. of Patras - Greece | ( 38.2594N, 21.7428E ) ( 1024D / CF95160A )
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
