Re: USB crappiness?
On Sat, 19 Jul 2003, Juli Mallett wrote: > Hi, > > I tried to upgrade my workstation to current recently, and I have to > use a lot of USB, and while using some USB mass storage device, with > a UFS filesystem on it, and doing a large operation to it (tar c|tar x) > everything deadlocked on ufs, the USB stack blew up, and upon causing > an interrupt to it, it panicked, and panic pagefaulted. > > Anyone else seeing these sorts of cohesive fallovers? > > Thanx, > juli. > Yes, I can confirm that. I do an nightly dump to a file on my USB hard disk (ehci). I woke up to find a screen full of read errors, and at first I thought the disk went belly up. I reverted back and it was working fine. I/O speed has _seriously_ degraded as well. Prior to the bus dma patches, I was getting a little better than 8 MB/s writes to the disk, afterwards, less than 2 MB/s. The "performance hit" discussed prior to the commit is a bit of an understatement. -Bryan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
background processes stuck in locks with ULE
Trying out ULE scheduling on an SMP machine causes background processes to be stuck in locks. One or two processes will always get stuck in *Giant (and takes up like 60% of lock) and if these are killed, then other processes are always taking up a total of around 10% in lock, which makes the system crawl. Anybody else seeing this on an SMP machine with ULE scheduler? -- "Optimized, readable, on time; Pick any two." FreeBSD 5.1-CURRENT i386 1:08PM up 40 mins, 2 users, load averages: 1.53, 1.62, 1.33 signature.asc Description: This is a digitally signed message part
USB crappiness?
Hi, I tried to upgrade my workstation to current recently, and I have to use a lot of USB, and while using some USB mass storage device, with a UFS filesystem on it, and doing a large operation to it (tar c|tar x) everything deadlocked on ufs, the USB stack blew up, and upon causing an interrupt to it, it panicked, and panic pagefaulted. Anyone else seeing these sorts of cohesive fallovers? Thanx, juli. -- juli mallett. email: [EMAIL PROTECTED]; efnet: juli; aim: bsdflata; i have lost my way home early - i don't care cause i won't stay there. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
OT:escaping X barfings
Hello all! CAn you tell me how a procedure how to patch X and kernel to avoid X barfings from securelevel? My release is a FreeBSD 5.1. I looked for patches, unfortunately they're more than a year old.Googled and searched on MARC - nothing new under the sun. Therefore I suppose all works ok in -CURRENT.I'm thinking of: 1) CVSup src and ports to "." 2) adding `options APERTURE` to my kernel 3) make buildkernel && make install kernel && make buildworld 4) reboot and face the music TIA, Dimitar Vassilev - hobbyist and FDP-BG translator ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel coredumps with 4GB of ram/SMP? with -current
On my two test (1gb of ram and 512mb of ram) systems if I do reboot -d I get a kernel crash dump I can read ok (which is what -d is supposed to do). On my two systems with 4GB of ram when I do reboot -d it says: Dumping 3838 MB Then it sits there. It doesnt print out any progress like it does with the systems with smaller amounts of ram. If I press a space bar it says: [CTRL-C to abort] If I let it sit for hours then try pressing the space bar again it has stopped respondng. In all cases dumpon was run pointing at the first swap area. Is anyone with 4GB of ram and -current getting kernel core dumps? Also the 4GB systems are XEON 2800mhz if having SMP matters. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
[SMALL PATCH] usbdevs
Hi, I've attached a patch for usbdevs that adds a manufacturer id for "X10 Wireless Technology" and the RF Receiver that they bundle as part of ATI's Radeon 8500DV video card package. Regards, Andy > Andre Guibert de Bruet | Enterprise Software Consultant > > Silicon Landmark, LLC. | http://siliconlandmark.com/>--- usbdevs Mon Jul 14 15:30:01 2003 +++ usbdevs.new Fri Jul 18 11:07:35 2003 @@ -339,6 +339,7 @@ vendor NEC20x0b62 NEC vendor ATI20x0b6f ATI vendor ASIX0x0b95 ASIX Electronics +vendor X10 0x0bc7 X10 Wireless Technology vendor REALTEK 0x0bda RealTek vendor AGATE 0x0c08 Agate Technologies vendor DMI 0x0c0b DMI @@ -1188,6 +1189,9 @@ product WACOM GRAPHIRE 0x0010 Graphire product WACOM INTUOSA5 0x0021 Intuos A5 product WACOM GD0912U 0x0022 Intuos 9x12 Graphics Tablet + +/* X10 Wireless Technology */ +product X10 USBRFRCVR 0x0004 USB RF Receiver (Sometimes Branded ATI) /* Xirlink products */ product XIRLINK PCCAM 0x8080 IBM PC Camera ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: weird 5.1 crash
On Sat, Jul 19, 2003 at 10:41:31PM +0200, Branko F. Gra?nar wrote: > oday my 5.1-RELEASE (i386) died by panic. > > panic message was: See the chapter on kernel debugging in the developer's handbook for information on how to obtain a debugging traceback, which is pretty much required in order for someone to analyze kernel panis. Kris pgp0.pgp Description: PGP signature
Re: Annoucning DragonFly BSD!
Matthew Dillon wrote: A Packaging system is a very important piece of any distribution. Our goal will be to create a packaging system that, via VFS 'environments', causes any particular package to see only the dependancies that it depends on, and the proper version of said dependancies as well. Multiple versions of third party apps that normally conflict with each other could be installed simultaniously. The packaging-system-controlled VFS environment would also hide everything a package does not depend on, like other libraries in the system, in order to guarentee that the dependancies listed in the packaging system are in fact what the application depends on. There's no point in having a packaging system that can't detect broken and incorrect dependancies or we wind up with the same mess that we have with ports. Wouldn't it be possible to achive the same result without the VFS with well organized lib subdirs? like "usr/lib/xyzlib1.2/" and "usr/lib/xyzlib1.3/" which would maintain the install for any given version of a lib? In other words, instead of just dumping all the libs into the one place, you simply place them into sub folders instead and then link them as needed? Granted this would cause havoc for things like LD_LIBRARY_PATH. I never did like the way we dump things in the lib dir's, its messy. The VFS idea is interesting, but it like cleaning the mess by sending parts of the big mess into another dimention, making it a trans-dimentional mess (technically a larger mess). This throws away the KISS principle. To make this work the VFS environment would have to be able to run as a userland process. Otherwise we would never be able to throw in the type of flexibility and sophistication required to make it do what we want it to do, and the kernel interfacing would have to be quite robust. I want to make these environments so ubiquitous that they are simply taken for granted. Begin userland VFSs with the capability of overlaying the entire filesystem space, these environments would be extremely powerful. I suspect this ability would usefull for other things too, possibly for security lock-downs on shell users env's without chrooting them as an example. -Jon It might be possible to build this new packaging system on top of the existing ports infrastructure. It will be several months (possibly 6-12 months) before the kernelland is sufficienctly progressed to be able to imlpement the userland VFS concept so we have a lot of time to think about how to do it. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]" ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.1 setfacl problem
On Sat, 19 Jul 2003, [iso-8859-2] Branko F. Graènar wrote: > Hi there! > > I'm running 5.1 on i386 platform and i have silly problem with acls. > > I have disks mounted with acl option (ofcourse they are formatted with > ufs2) and acls generally work okay. > > But when i try to set default directory acl entry i get 'Invalid > argument' error. > > Here is example command usage: > > # setfacl -dm m::rwx,u:some_user:rwx test_directory > setfacl: acl_set_file() failed for test_directory: Invalid argument > > This is really annoying... > > Any ideas, how to solve this? POSIX.1eD17 23.1.3 requires that default ACLs have the same minimum entries as an access ACL, meaning that all default ACLs must contain at least object owner, object group, and other fields. If you have extended entries, you must also have a mask field. If the test_directory above doesn't already have an ACL on it to modify, the command you're using will specify what POSIX.1e considers an incomplete ACL and rejects. Try using: setfacl -dm u::rwx,g::rx,o::rx,u:some_user:rwx,m:rwx test_directory and see if that works better for you. If so, that was probably the problem. I haven't checked to see if other implementations have different interpretations of POSIX.1e, or bend the rules in various ways, but they might well do. We could, in theory, weaken the rules, but the logic to combine partial default ACLs, requested creation mode, and umask would be complicated... 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: ufs2 snapshots in 5.1 still broken
>I'm not use what you mean. The suspension of I/O during creation of a >snapshot is the intended behaviour, but it doesn't take long. For example, df -h /dev/x 813G 7.1G 741G 1%/export df -i /dev/853004856 7422014 777342454 1% 328978 1480728120% /export ~330k files. Size mostly about ~20-30 kbytes. If i run dump -L (which creates snapshot) it runs for ever (machine doesn't respond even after 30-40 minutes). If i unplug power cable and turn on my machine again, then this filesystem will be checked by fsck and if background_fack in rc.conf is "YES", fsck will create snapshot and machine will boot, but after 2-3 minutes (background fsck starts 60 seconds after system boot) machine stop responding. If i issue simple ls command it just hangs. You cannot even ssh to machine, becouse event network system stops responding. Disks were formatted on a clean 5.0-RELEASE using sysinstall (using -O2 newfs option) during system installation and system was upgraded with cvsup/make build/installworld to 5.1-RELEASE Maybe this is an issue and i should reformat my disks and everything will be fine again? I have this problem on two machines. The third one with about 200k files boots okay, but this one was installed cleanly with 5.1-RELEASE. Brane ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Negative bio_offset -current kernel panic
I got a got this kernel panic:
geom/geom_dev.c:("Negative bio_offset (%jd) on bio %p",
Anyone seeing this also?
This is on a 2 processor XEON intel motherboard / adaptec 5400S raid /
AMD g2 console card.
The AMI g2 console card provides via USB a keyboard virtual cdrom etc.
Most of which freebsd isnt very happy with. But im not trying to use the
virtual cdrom at all. They keyboard had not been used since last boot
either.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: ufs2 snapshots in 5.1 still broken
On Sat, 19 Jul 2003, [iso-8859-2] Branko F. Gra?nar wrote: > This only accours if there is alot (several 100 thousand) of small files > on a filesystem. > > During snapshot creation all userland I/O hangs until snapshot is made. > Machine doesn't respond even on ping!. After snapshot is created, > everything works okay. If you want to remove that snapshot file the same > scenario is repeated. Ideas, suggestions? I'm not use what you mean. The suspension of I/O during creation of a snapshot is the intended behaviour, but it doesn't take long. For example, /usr here has about 185000 files: # time mksnap_ffs /usr /usr/snapshot real0m3.059s user0m0.001s sys 0m0.143s regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX-Systemadministrator Tel.: (+43 1) 4277-14073 Zentraler Informatikdienst (ZID) Fax.: (+43 1) 4277-9140 der Universität Wien http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
On Sat, Jul 19, 2003 at 08:31:26PM +0200, Lara & Harti Brandt wrote: [...] > Well the problem is, that nothing is starved. I have an idle machine and > a zone that I have limited to 60 or so items. When allocating the 2nd > item I get block on the zone limit. Usually I get unblocked whenever I > free an item. This will however not happen, because I have neither > reached the limit nor is there memory pressure in the system to which I > could react. I simply may be blocked forever. UMA_ZFLAG_FULL is set on the zone prior to the msleep(). This means that the next free will result in your wakeup, as the next free will be sent to the zone internally, and not the pcpu cache. > That makes the limit feature for zones rather useless, because I cannot > predict how many of the items I can really allocate (this depends on the > number of processors, the page size and the configuration of UMA itself). > > Perhaps we could make the behaviour dependent on the maximum number of > items. When it is rather low (a couple of pages worth) and I would block > on the zone limit and I have free items in another CPU's cache then > drain one of the caches. > > Or I could simply remove the limits. > > > harti > > > -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
ufs2 snapshots in 5.1 still broken
Hi. I upgraded my home server to 5.1-release today with hope, that ufs2 filesystem snapshot issues will be fixed and working ... but they are not. this is a serious issue, becouse background fsck is on by default, which reflects in creating filesystem snapshot on mounting not cleanly umounted device. set background_fsck to "NO" in your rc.conf. i've sent problem report in the early days of 5.0-Release, but nothing changed. This only accours if there is alot (several 100 thousand) of small files on a filesystem. During snapshot creation all userland I/O hangs until snapshot is made. Machine doesn't respond even on ping!. After snapshot is created, everything works okay. If you want to remove that snapshot file the same scenario is repeated. Ideas, suggestions? Brane ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
weird 5.1 crash
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 oday my 5.1-RELEASE (i386) died by panic. panic message was: Syncing disks, buffers remaining... Fatal trap 12: page fault while in kernel mode fault code: supervisor read, page not present instruction pointer: 0xc01b5737 panic: spin lock sched lock held by 0xc151e850 for > 5 sec panic: spin lock sched lock held by 0xc151e850 for > 5 sec panic: spin lock sched lock held by 0xc151e850 for > 5 sec panic: spin lock sched lock held by 0xc151e850 for > 5 sec panic: spin lock sched lock held by 0xc151e850 for > 5 sec Machine was up for 40 days without cousing trouble. Hardware: - - 2 pentium3 1266 mhz - - 512 MB ram - - promise sx6000 disk controller with raid5 array - - 6 ibm ide disks I'm using ULE scheduler. Any ideas? my kernel config file: - -- snip -- machine i386 ident MYMACHINE cpu I686_CPU device ata device atadisk device atapicd device atkbd device atkbdc device bpf device ether device fdc device fxp device isa device loop device md device miibus device npx device pci device psm device pst device pty device random device sc device sio device splash device tun device vga options COMPAT_LINUX options DIRECTIO options INCLUDE_CONFIG_FILE options ROOTDEVNAME=\"ufs:pst0s1a\" options SC_DISABLE_REBOOT options APIC_IO options ATA_STATIC_ID options CD9660 options COMPAT_43 options COMPAT_FREEBSD4 options FFS options INET options KTRACE options NFSCLIENT options NFSSERVER options SCHED_ULE options SMP options SOFTUPDATES options SYSVMSG options SYSVSEM options SYSVSHM options UFS_ACL options UFS_DIRHASH options _KPOSIX_PRIORITY_SCHEDULING - -- snip -- -BEGIN PGP SIGNATURE- iD8DBQE/GBizfiC/E+t8hPcRAi04AKCRz9akBdLHhOZiVa2nTY4oPv80jwCfR+r9 BpK7WKpF9PMfZUT6qWu8HD0= =kuvD -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5.1 setfacl problem
Hi there! I'm running 5.1 on i386 platform and i have silly problem with acls. I have disks mounted with acl option (ofcourse they are formatted with ufs2) and acls generally work okay. But when i try to set default directory acl entry i get 'Invalid argument' error. Here is example command usage: # setfacl -dm m::rwx,u:some_user:rwx test_directory setfacl: acl_set_file() failed for test_directory: Invalid argument This is really annoying... Any ideas, how to solve this? Brane ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing gcc 3.3 compile failures -- kde ports proposal
Hi !
Luckily the KDE ports are very uniform.
Applying the obvious, trivial patch to configure always works on
current.
(Of course only since the patch utility is clever enough to
try the hunk at different offsets...):
--- configure.orig Sat Jul 19 16:54:39 2003
+++ configure Sat Jul 19 16:55:37 2003
@@ -4236,7 +4236,7 @@
CXXFLAGS="-ansi -D_XOPEN_SOURCE=500 -D_BSD_SOURCE
-Wcast-align -Wconversion $CXXFLAGS"
;;
esac
-CXXFLAGS="-Wall -pedantic -W -Wpointer-arith
-Wmissing-prototypes -Wwrite-strings $CXXFLAGS"
+CXXFLAGS="-Wall -pedantic -fpermissive -W -Wpointer-arith
-Wmissing-prototypes -Wwrite-strings $CXXFLAGS"
echo "$as_me:$LINENO: checking whether $CXX supports -Wundef" >&5
echo $ECHO_N "checking whether $CXX supports -Wundef... $ECHO_C" >&6
(Beware of newlines when doing cut-and-paste).
But that would break things on non-current.
So how about setting a variable in /etc/make.conf ?
I think for the time being this is not too much for
a current-user...
MY_CXX_BAILS_OUT_ON_KDE_CONFIGURE=yo
(It needn't be so long though ;-)
Then put that patch in the files directory as - e.g. -
`current-patch-configure'.
And change the ports Makefile along the lines of
the following patch for koffice:
--- Makefile.orig Sat Jul 19 21:48:15 2003
+++ MakefileSat Jul 19 21:49:34 2003
@@ -38,4 +38,9 @@
.include "${.CURDIR}/../../x11/kde3/Makefile.kde"
+.ifdef MY_CXX_BAILS_OUT_ON_KDE_CONFIGURE
+pre-configure:
+ cd ${WRKSRC} && patch < ${FILESDIR}/current-patch-configure
+.endif
+
.include
With those settings, I could do a forced upgrade for everything.
I know this can't be the clean, now-we-all-are-happy-solution.
But as I already mentioned - for the time being...
Cheers
Peter
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Fixing gcc 3.3 compile failures -- fix for math/freefem
On Sat, Jul 19, 2003 at 05:05:39AM +0200, Simon Barner wrote:
> --- freefem/fem/femDisk.cpp.orig Sat Jul 19 04:09:32 2003
> +++ freefem/fem/femDisk.cpp Sat Jul 19 04:13:43 2003
> @@ -95,7 +95,7 @@
> char *result = 0;
> int dummy;
>
> -ifstream fin( path );
> +std::ifstream fin( path );
>
> if ( fin.fail() )
>{
[... 405 lines deleted ...]
A much smaller patch could be produced with
using namespace std;
as appropriate.
Have you checked with the upstream author to see which approach is
likely to be rolled into the distribution?
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]"
Re: Annoucning DragonFly BSD!
:Matthew, :OK, you want a divergent kernel, EG src/sys/ , fair enough. : : - Are there any benefits to the BSD community in having :a 4th BSD bin/ sbin/ usr.bin/ usr.sbin/ ? :Can you not share & co-operate with toolset maintainers of NetBSD :or OpenBSD, even if you can't work with some FreeBSD CVS people ? I don't think these particular subhiearchies are that big a deal. Except for libc and libc_r, most of the above will wind up being almost identical to their 4.x counterparts. You know the old saying... if it aint broke... One big part of the goal set will be the creation of a middle 'emulation' layer which is managed by the kernel but runs in userland, which will take over all primary system call entry points (in userland) and convert them to syscall messages that the kernel understands. 4.x, 5.x, SysV, Linux, and other compatibility sets will be moved out of the kernel and into this middle layer. Even the 'native' syscall set will run through an emulation layer (though being aware of it the native sets will call the emulation layer directly rather then bounce through the kernel). The advantage of this methodology is that we will be able to keep the kernel clean. For example, we would be able to modify how certain syscall messages work and simply by fixing the backend of the appropriate emulation layers we can maintain binary compatibility with any past userland. The emulation layer would be fully versioned so older userland programs use emulation layers targeted to older APIs, and newer userland programs use emulation layers targeted to newer APIs. So there would no longer be five different versions of stat() in the kernel, for example. There might be five different versions of the '4.x emulation layer', but there would be only *ONE* stat in the kernel. : - Do you intend your own ports/ collection too ? (or Free, Net or Open ?) : :- :Julian Stacey Freelance Systems Engineer, Unix & Net Consultant, Munich. A Packaging system is a very important piece of any distribution. Our goal will be to create a packaging system that, via VFS 'environments', causes any particular package to see only the dependancies that it depends on, and the proper version of said dependancies as well. Multiple versions of third party apps that normally conflict with each other could be installed simultaniously. The packaging-system-controlled VFS environment would also hide everything a package does not depend on, like other libraries in the system, in order to guarentee that the dependancies listed in the packaging system are in fact what the application depends on. There's no point in having a packaging system that can't detect broken and incorrect dependancies or we wind up with the same mess that we have with ports. To make this work the VFS environment would have to be able to run as a userland process. Otherwise we would never be able to throw in the type of flexibility and sophistication required to make it do what we want it to do, and the kernel interfacing would have to be quite robust. I want to make these environments so ubiquitous that they are simply taken for granted. Begin userland VFSs with the capability of overlaying the entire filesystem space, these environments would be extremely powerful. It might be possible to build this new packaging system on top of the existing ports infrastructure. It will be several months (possibly 6-12 months) before the kernelland is sufficienctly progressed to be able to imlpement the userland VFS concept so we have a lot of time to think about how to do it. -Matt Matthew Dillon <[EMAIL PROTECTED]> ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: SMP problem with uma_zalloc
Bosko Milekic wrote: On Fri, Jul 18, 2003 at 07:05:58PM +0200, Harti Brandt wrote: Hi all, it seems there is a problem with the zone allocator in SMP systems. I have a zone, that has an upper limit on items that resolves to an upper limit of pages of 1. It turns out, that allocations from this zone get stuck from time to time. It seems to me, that the following happens: - on the first call to uma_zalloc a page is allocated and all the free items are put into the cache of the CPU. uz_free of the zone is 0 and uz_cachefree holds all the free items. - when the next call to uma_zalloc occurs on the same CPU, everything is fine. uma_zalloc just gets the next item from the cache. - when the call happens on another CPU, the code finds uz_free to be 0 and checks the page limit (uma_core.c:1492). It finds the limit already reached and puts the process to sleep (uma_zalloc was called with M_WAITOK). - the process may sleep there forever (depending on circumstances). If M_WAITOK is not set, the code will falsely return NULL while there are still free items (albeight in the cache of another CPU). I wonder whether this is intended behaviour. If yes, this should be definitely documented. uma_zone_set_max() seems to be documented only in the header file and it does not mention, that free items may not actually be allocatable because they happen to sit in another CPU's cache. If it is not intended (I would prefer this), I wonder how one can get the items out of another's CPU cache. I'm not too familiar with this code. I suppose this should be done somewhere around uma_core.c:1485? Regards, harti -- harti brandt, http://www.fokus.fraunhofer.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED], [EMAIL PROTECTED] If the per-cpu caches are relatively small (which they ought to be, especially when you've hit a maximum number of allocations from the zone), then this is actually not that bad of a behavior. I spoke to Jeff about this and it seemed to me that he was leaning toward keeping the behavior this way and, in fact, also perhaps _not_ even doing an internal free to the zone when UMA_ZFLAG_FULL is in effect but we still have space in the pcpu cache. While I'm not sure if going that far is a good idea, I _don't_ really think that the current behavior is a bad idea. As mentionned, when you have a zone that is mostly starved, all future frees will go back to the zone and not the per-cpu caches, but if you have some free items in another per-cpu cache, you're not likely to hit a starvation situation unless something is horribly wrong. And having the free code actually drain the per-cpu caches in a zone-full situation may lead to bad behavior under heavy load. Think about what happens under heavy load... your zone is starved and if you then flush all the pcpu caches and the load is still heavy, you're likely to have other threads try to allocate anyway, so they'll end up having to dip into the zone anyway; therefore, there doesn't seem to be much of a reason to push the cached objects back into the zone (if they're going to leave it again soon anyway). Well the problem is, that nothing is starved. I have an idle machine and a zone that I have limited to 60 or so items. When allocating the 2nd item I get block on the zone limit. Usually I get unblocked whenever I free an item. This will however not happen, because I have neither reached the limit nor is there memory pressure in the system to which I could react. I simply may be blocked forever. That makes the limit feature for zones rather useless, because I cannot predict how many of the items I can really allocate (this depends on the number of processors, the page size and the configuration of UMA itself). Perhaps we could make the behaviour dependent on the maximum number of items. When it is rather low (a couple of pages worth) and I would block on the zone limit and I have free items in another CPU's cache then drain one of the caches. Or I could simply remove the limits. harti ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: panic: improper umtx access
On Sat, Jul 19, 2003 at 08:12:42PM +1000, Peter Kostouros wrote: > Hi > > I received a panic: improper umtx access from a system cvsup'ed about 8 > hours ago. It occurred when executing mcs (mono C# compiler). Note > /etc/libmap.conf had libc_r.so* pointing to libthr.so* for mono/mcs. I > am also running the SCHED_ULE scheduler. My fault. It's fixed now. $FreeBSD: src/sys/kern/kern_umtx.c,v 1.11 2003/07/19 11:32:48 mtm Exp $ Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 [EMAIL PROTECTED]| FreeBSD - Unleash the Daemon! ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: improper umtx access
Hi
I received a panic: improper umtx access from a system cvsup'ed about 8
hours ago. It occurred when executing mcs (mono C# compiler). Note
/etc/libmap.conf had libc_r.so* pointing to libthr.so* for mono/mcs. I
am also running the SCHED_ULE scheduler.
I hope the attached backtrace is useful.
--
Regards
Peter
As always the organisation disavows knowledge of this email
Script started on Sat Jul 19 19:53:59 2003
eva# gdb -k -f kernel.debun [Kg -f /var/crash/vmcore.18
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: improper umtx access
panic messages:
---
panic: improper umtx access
syncing disks, buffers remaining... 4819 4819 4817 4816 4816 4816 4815 4815 4815 4815
4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815
giving up on 2893 buffers
Uptime: 27m10s
acd0: timeout waiting for cmd=e7 s=01 e=04
acd0: flushing device failed
Dumping 1023 MB
ata0: resetting devices ..
done
16 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 48[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] 64[CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304
320 336 352 368 384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640
656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976
992 1008
---
Reading symbols from
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
#0 doadump () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:240
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:240:6807:beg:0xc023a65b
(kgdb) bt
#0 doadump () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:240
#1 0xc023ac91 in boot (howto=256) at
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc023b027 in panic () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:550
#3 0xc024bcd1 in _umtx_unlock (td=0xc32ae390, uap=0x0)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_umtx.c:306
#4 0xc03911e3 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135333020, tf_esi = 135332992,
tf_ebp = -1081159924, tf_isp = -530489996, tf_ebx = 674411260, tf_edx = 0, tf_ecx =
134524928, tf_eax = 435, tf_trapno = 12, tf_err = 2, tf_eip = 674719375, tf_cs = 31,
tf_eflags = 2097734, tf_esp = -1081159968, tf_ss = 47}) at
/mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c:1023
#5 0xc038157d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb) up 3
#3 0xc024bcd1 in _umtx_unlock (td=0xc32ae390, uap=0x0)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_umtx.c:306
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_umtx.c:306:7814:beg:0xc024bcd1
(kgdb) l
301 }
302 } else {
303 UMTX_UNLOCK();
304 old = casuptr((intptr_t *)&umtx->u_owner,
305 owner, UMTX_CONTESTED);
306 KASSERT(old != -1 && old != owner, ("improper umtx access"));
307 }
308
309 if (old == -1)
310 return (EFAULT);
(kgdb) p old
$1 = -1020599407
(kgdb) p owner
$2 = -1020599407
(kgdb) p td
$3 = (struct thread *) 0xc32ae390
(kgdb) p uq
$4 = (struct umtx_q *) 0x0
(kgdb) l q
eva# exit
exit
Script done on Sat Jul 19 19:57:24 2003
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: gcc-3.3 issues
Hi ! > http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/Warning-Options.html#Warning%20Options Hmm, that's exactly as in the info page. > http://gcc.gnu.org/onlinedocs/gcc-3.3/gcc/C---Dialect-Options.html#C++%20Dialect%20Options > and search for permissive, to see the condition Alexander speaks of. Well, here it is: -fpermissive Downgrade messages about nonconformant code from errors to warnings. By default, G++ effectively sets -pedantic-errors without -pedantic; this option reverses that. This behavior and this option are superseded by -pedantic, which works as it does for GNU C. I admit, I'm not a native speaker, so please correct me. Doesn't that mean, if you don't specify any pedantic, it defaults to -pedantic-errors for C++, but if you specify -pedantic, you don't get errors for warnings like it should be... ?? Cheers Peter ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: cyclades isa card not recognized on 5-current ?
On Sat, 19 Jul 2003, Bruce Evans wrote: Hi, > > firmware_version always is 0xff. > > This usually means that the maddr is wrong or that the hardware is not > there for some other reason. A normal hex dump of cyclades isa memory > looks something like this > (output from "dd if=/dev/mem bs=1 iseek=0xd4000 count=0x2000 | hd"): thanks. useful hint. going to see what I can do with this information. > Values at even offsets are always repeated at the next (odd) offset. > > CD1400_GFRCR is at offset 0x80 (contents 0x46 in the above). > > > If I give another maddr in hints file than dip switches are set to > > kernel aborts somwhere in sioprobe(dev) and will reboot so I assume > > maddr really is set correct (also verified with cyclades manual > > y_30.pdf again). > > The abort is a bit unusual since the cyclades probe is not very invasive. yeah. aehm and if we are with it. Is it really correct that 0xc and 0xd4000 have the same dip settings ? This is the case according to ftp://ftp.cyclades.de/pub/cyclades/cyclom-y/doc/y_30.pdf (english) Though I also tried other addresses as said I hink this might be an error in the table ? > > There is a "Rev 5" oder 5.0 on the card. > > I think mine is much older (model 8Yb). Everything interesting I can find on the card: CYCLOM-8Yo Rev 5.00 (c) 1995 Cyclades Corporation 25 Mhz FOX 2x CL-CD1400-10PC-G, 48360-208BC, 9535-B CY7C371, -66JC 9537, CYP 119265,+, U178Y100(*) and on the back: MTI-Y, 94V-0, 0196 and a barcode with CYC0013184 > Did you say that it worked under old versions of FreeBSD? no, I got the card from someone who no longer had a use for it. Don't know which OS he had been running. I only have one 4-STABLE maschine which is up 24-7-365 and another 5.0 notebook. So not much chance to test it in another machine with an older FreeBSD version. OK some more investigation done: a) silly me also tried addresses that where in the middle of orm0: at iomem 0xc8000-0xcbfff,0xc-0xc7fff on isa0 these where the panics on startup. Cannot reproduce them with addresses outside of this range. Must have missed this the first time I checked free resources :( b) set maddr and dips to 0xd8000 and now getting (see marked areas): e0-0# dd if=/dev/mem bs=1 iseek=0xd8000 count=0x2000 | hd 00 00 00 00 00 00 00 00 00 00 81 81 00 00 00 00 || 0010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0080 00 00 00 00 61 61 61 61 61 61 00 00 41 41 41 41 |aa..| 0090 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@@..| 00a0 61 61 00 00 61 61 61 61 61 61 81 81 41 41 40 40 |aa..aa..AA@@| 00b0 40 40 00 00 40 40 00 00 00 00 00 00 00 00 40 40 |@@..@@@@| 00c0 40 40 40 40 00 00 00 00 ff ff ff ff ff ff 00 00 || 00d0 c0 c0 08 08 10 10 18 18 a8 a8 a8 a8 a0 a0 a8 a8 || 00e0 54 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |TT..| 00f0 00 00 00 00 08 08 08 08 08 08 08 08 00 00 00 00 || 0100 00 00 00 00 00 00 00 00 00 00 81 81 00 00 00 00 || 0110 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0180 00 00 00 00 61 61 61 61 61 61 00 00 41 41 41 41 |aa..| 0190 40 40 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |@@..| 01a0 61 61 00 00 61 61 61 61 61 61 81 81 41 41 40 40 |aa..aa..AA@@| 01b0 40 40 00 00 40 40 00 00 00 00 00 00 00 00 40 40 |@@..@@@@| 01c0 40 40 40 40 00 00 00 00 ff ff ff ff ff ff 00 00 || 01d0 c0 c0 08 08 10 10 18 18 a8 a8 a8 a8 a0 a0 a8 a8 || 01e0 54 54 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |TT..| 01f0 00 00 00 00 08 08 08 08 08 08 08 08 00 00 00 00 || 0200 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * ::--> 0400 00 00 00 00 00 00 00 00 22 22 00 00 00 00 00 00 |""..| 0410 00 00 00 00 00 00 00 00 00 00 26 26 00 00 00 00 |..&&| 0420 00 00 34 34 00 00 00 00 00 00 00 00 00 00 a0 a0 |..44| 0430 00 00 26 26 00 00 00 00 00 00 00 00 00 00 00 00 |..&&| 0440 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || * 0480 46 46 00 00 00 00 00 00 00 00 00 00 00 00 47 47 |FFGG| ::<-- 0490 00 00 00 00 00 00 00 00 00 00 00 00 83 83 00 00 || 04a0 34 34 22 22 00 00 00 00 00 00 00 00 00 00 00 00 |44""| 04b0 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 || 04c0 26 00 00 26 00 26 46 00 0e 0e 42 42 00 00 00 00 |&..&.&F...BB| 04d0 c0 c0 0b 0b 10 10 18 18 a8 a0 a0 a0 a0 a0 a8 a8 || 04e0 54 54 00 00 41 41 06 3e 04 84 08 08 01 01 89 81 |TT..AA.>| 04f0 41 41 41 41 00 00 38 18 01 19 02 22 ff ff bd bc |..8"| ::--> 05
