Re: Strange warning with clang and 9RC1 (ntohs)
Here is the output (short version):
...
(snip)
static __inline __uint16_t
__bswap16_var(__uint16_t _x)
{
return ((__uint16_t)((_x) << 8 | (_x) >> 8));
}
...
(snip)
int main()
{
uint16_t x = (__builtin_constant_p(80) ? (__uint16_t)(((__uint16_t)(80)) << 8
| ((__uint16_t)(80)) >> 8) : __bswap16_var(80));
printf("%hu\n", (uint16_t)(__builtin_constant_p(x) ? (__uint16_t)
(((__uint16_t)(x)) << 8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x)));
printf("%hu\n", (__builtin_constant_p(x) ? (__uint16_t)(((__uint16_t)(x)) <<
8 | ((__uint16_t)(x)) >> 8) : __bswap16_var(x)));
return (0);
}
% clang -E ntohs.c > ntohs_.c
% clang -Wall -o ntohs ntohs_.c
In file included from ntohs.c:1:
ntohs.c:8:12: warning: conversion specifies type 'unsigned short' but the
argument has type
'int' [-Wformat]
...%hu\n", (__builtin_constant_p(x) ? (__uint16_t)(((__uint16_t)(x)) << 8 |
((__uint16_t)(x)) >> 8) : __bswap16_var(x))...
~~^
%d
1 warning generated.
And I missed it the first mail:
FreeBSD moonlight 9.0-RC1 FreeBSD 9.0-RC1 #0: Fri Oct 28 22:53:45 CDT 2011
toor@moonlight:/usr/obj/usr/src/sys/LXCORE9 i386
Thanks!
A
On Tuesday 01 November 2011 07:56:51 Roman Divacky wrote:
> It doesnt warn here. Can you check with "clang -E" what the ntohs()
> is being expanded to and what the real prototype is?
>
--
Tue Nov 1 01:01:15 2011 GMT
**
*
**
***
***
**
*
** 6.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: gmirror failed with error 19.
On 28.10.2011 13:48, Sascha Klauder wrote: > I've got bitten by this as well when trying a source up- > grade of a freshly installed 8.2-RELEASE system that had > gmirror configured after installation according to the > procedure in the Handbook. > > The 9.0-RC1 kernel drops to the mountroot prompt when > booting with > > GEOM_MIRROR: Device mirror/gm0 launched (2/2). > GEOM_PART: partition 1 has end offset beyond last LBA: 490350671 > 490350670 > GEOM_PART: integrity check failed (mirror/gm0, MBR) This is the main problem. Your MBR' slice is bigger than actual space you have. The only way to fix this - recreate slice. You can break your mirror, recreate the slice (NOTE: you must preserve one sector for the gmirror's meta-data), then copy your data to the newly created slice, then reboot from the new slice and recreate mirror. -- WBR, Andrey V. Elsukov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ng_ubt fatal trap 12 on RELENG_9 and CURRENT
On Monday 31 October 2011 09:22:40 Matt Mullins wrote: > It's late, so I'm going to come back to this later. Any ideas on > where I should go from here? Try to figure out where the NULL valued structure is initialised. --HPS ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [9.0-RC1 FreeBSD] [amd64] buildworld fails on building lib/libss with CLANG
Le 30.10.2011 23:23, Dimitry Andric a écrit : I pulled Roman's fixes into head in r226951. This will be merged to stable/9 later, but if you want to try it out in the meantime, please use the attached diff. Thanks a lot. FYI, `make buildworld & kernel` were successful after I applied the patch. -- David Marec, mailto:david.ma...@davenulle.org http://user.lamaiziere.net/david/Site http://www.diablotins.org/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: GEOM MULTIPATH rewrite
On Mon, Oct 31, 2011 at 10:10:14PM +0200, Alexander Motin wrote: > Hi. > > Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So > I would like to present my results and request for testing and feedback. > > The main changes: > - Improved locking and destruction process to fix crashes in many cases. > - Improved "automatic" configuration method to make it safe by reading > metadata back from all specified paths after writing to one. > - Added provider size check to reduce chance of conflict with other > GEOM classes. > - Added "manual" configuration method without using on-disk metadata. > - Added "add" and "remove" commands to manage paths manually. > - Failed paths no longer dropped from GEOM, but only marked as FAIL and > excluded from I/O operations. > - Automatically restore failed paths when all others paths are marked > as failed, for example, because of device-caused (not transport) errors. > - Added "fail" and "restore" commands to manually control FAIL flag. > - GEOM is now destroyed on last provider disconnection. IMHO it is > right to do if device was completely removed. > - Added optional Active/Active mode support. Unlike Active/Passive > mode, load evenly distributed between all working paths. If supported by > device, it allows to significantly improve performance, utilizing > bandwidth of all paths. It is controlled by -A option during creation. > Disabled by default now. > - Improved `status` and `list` commands output. > > Latest patch can be found here: > http://people.freebsd.org/~mav/gmultipath4.patch > > Feedbacks are welcome! > > Sponsored by: iXsystems, Inc. There are two possible issues that comes to my mind, not sure if you address them. 1. When configuration is based on on-disk metadata, GEOM spoil/taste is not fully helpful - if you have two paths: da0 and da1 and I write to da0, gmultipath won't be informed by GEOM that da1 changed as well. One solution is to basically keep all paths open exclusively all the time, even if gmultipath provider is not open or emulate spoil/taste for other paths if any path was modified. 2. In active/active mode do you do anything to handle possible reordering? Ie. if you have overlapping writes and send both of them using different paths, you cannot be sure that order will be preserved. Most of the time that's not a problem, as file systems rarely if at all send overlapping writes to device, but this is weak assumption. -- Pawel Jakub Dawidek http://www.wheelsystems.com FreeBSD committer http://www.FreeBSD.org Am I Evil? Yes, I Am! http://yomoli.com pgpJEqgC1I0SO.pgp Description: PGP signature
Re: RFC: GEOM MULTIPATH rewrite
On 11/01/11 14:39, Pawel Jakub Dawidek wrote: > On Mon, Oct 31, 2011 at 10:10:14PM +0200, Alexander Motin wrote: >> Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So >> I would like to present my results and request for testing and feedback. >> >> The main changes: >> - Improved locking and destruction process to fix crashes in many cases. >> - Improved "automatic" configuration method to make it safe by reading >> metadata back from all specified paths after writing to one. >> - Added provider size check to reduce chance of conflict with other >> GEOM classes. >> - Added "manual" configuration method without using on-disk metadata. >> - Added "add" and "remove" commands to manage paths manually. >> - Failed paths no longer dropped from GEOM, but only marked as FAIL and >> excluded from I/O operations. >> - Automatically restore failed paths when all others paths are marked >> as failed, for example, because of device-caused (not transport) errors. >> - Added "fail" and "restore" commands to manually control FAIL flag. >> - GEOM is now destroyed on last provider disconnection. IMHO it is >> right to do if device was completely removed. >> - Added optional Active/Active mode support. Unlike Active/Passive >> mode, load evenly distributed between all working paths. If supported by >> device, it allows to significantly improve performance, utilizing >> bandwidth of all paths. It is controlled by -A option during creation. >> Disabled by default now. >> - Improved `status` and `list` commands output. >> >> Latest patch can be found here: >> http://people.freebsd.org/~mav/gmultipath4.patch >> >> Feedbacks are welcome! >> >> Sponsored by: iXsystems, Inc. > > There are two possible issues that comes to my mind, not sure if you > address them. > > 1. When configuration is based on on-disk metadata, GEOM spoil/taste is >not fully helpful - if you have two paths: da0 and da1 and I write >to da0, gmultipath won't be informed by GEOM that da1 changed as well. >One solution is to basically keep all paths open exclusively all the >time, even if gmultipath provider is not open or emulate spoil/taste >for other paths if any path was modified. Now I am opening all underlying providers exclusively on attach to spoil other consumers. It is configurable via sysctl. > 2. In active/active mode do you do anything to handle possible >reordering? Ie. if you have overlapping writes and send both of them >using different paths, you cannot be sure that order will be >preserved. Most of the time that's not a problem, as file systems >rarely if at all send overlapping writes to device, but this is weak >assumption. No, I don't. I have doubt that it is sane to send even dependent I/O simultaneously without waiting for completion, not speaking about overlapping. When most of present devices support command queuing and so officially justify reordering simultaneous commands in custom way, I am not sure why above layers should be more strict, especially in cases when it is problematic. If somebody have ideas why and how to implement it, I am ready to discuss. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3
Yes that seems to be the problem. It will is for out of tree modules. http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 . I have to verify if moving the module to /usr/src/ tree fixes the problem. Thanks, Penta On Tue, Nov 1, 2011 at 2:04 AM, K. Macy wrote: > Someone was seeing the same issue with the vmtools kmod. The only > thing that might make sense is that the page lock array is defined as > being a different size in your kmod as in the kernel itself so the > lock corresponding to the page you're locking differs between the two > files. > > Cheers > > On Fri, Oct 21, 2011 at 5:25 PM, Penta Upa wrote: > > Hi, > > > > I'm facing a kernel panic at vm_page_wire(). Page is locked with > > vm_page_lock() yet i get the following panic > > panic: mutex page lock not owned at /usr/src/sys/vm/vm_page:1845 > > > > Code sequence is as below > > vm_page_lock(pp); > > vm_page_lock_assert(pp, MA_OWNED); /* No panic here */ > > vm_page_wire(pp); /* Panic here for the same assertion as above, strange > */ > > vm_page_unlock(pp); > > > > Kernel on the system is unchanged after install. The only thing which > > occurred out the way was that the first time install failed for checksum > > mismatch for src.txz. Also there were some SCSI errors/warnings with the > CD > > drive during install. So the next time, i only installed the base and > > kernel and later unpacked src.txz under /usr/src . Could this lead to any > > issues ? > > > > Attached is a test module (vmtest) and the makefile used. Uname output > from > > the system is > > > > FreeBSD scache 9.0-BETA3 FreeBSD 9.0-BETA3 #0: Sat Sep 24 21:31:28 UTC > > 2011 > > r...@farrell.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 > > > > Is there anything i'm doing wrong here ? Kindly help. > > > > Regards, > > Penta > > > > ___ > > freebsd-current@freebsd.org mailing list > > http://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > > > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: smp_rendezvous runs with interrupts and preemption enabled on unicore systems
On Mon, Oct 31, 2011 at 7:43 PM, Attilio Rao wrote: > I'm not entirely sure why this exactly breaks though (do you see that > happening with a random rendezvous callback or it is always the > same?), because that just becames a simple function calling on cpu0, > even if I think that there is still a bug as smp_rendezvous callbacks > may expect to have interrupts and preemption disabled and the > short-circuit breaks that assumption. I have only observed the problem with i686_mrstoreone(smp_rendezvous is called from i686_mrstore). I notice that i686_mrstoreone does scary things like disabling the cache and global TLB entries. My experience was that everything got very slow when i686_mrstoreone was preempted, so it easily could be the case that the system because so slow with the cache disabled that it became livelocked. > I don't think that we strictly need the lock here, my preferred > solution would be (only test-compiled): I tried the same thing for the SMP case, and it fixed my problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: GEOM MULTIPATH rewrite
Alexander Motin wrote this message on Tue, Nov 01, 2011 at 15:05 +0200: > > 2. In active/active mode do you do anything to handle possible > >reordering? Ie. if you have overlapping writes and send both of them > >using different paths, you cannot be sure that order will be > >preserved. Most of the time that's not a problem, as file systems > >rarely if at all send overlapping writes to device, but this is weak > >assumption. > > No, I don't. I have doubt that it is sane to send even dependent I/O > simultaneously without waiting for completion, not speaking about > overlapping. When most of present devices support command queuing and so > officially justify reordering simultaneous commands in custom way, I am > not sure why above layers should be more strict, especially in cases > when it is problematic. If somebody have ideas why and how to implement > it, I am ready to discuss. I know that phk and others have an idea what the contract for writes like this, but I just checked geom(4) and the IO section doesn't describe it.. I believe that you should not submit overlapping writes unless it's preceded or is an _ORDERED write, and that reads can be satisifed w/ stale data if it is submitted after a write of the same location, but it's not in geom(4). Hmm... turns out BIO_ORDERED isn't even documented in geom(4)... I'm willing to put some of this in the man page if someone comes up w/ a good list of points. Are the ones I listed above enough? -- John-Mark Gurney Voice: +1 415 225 5579 "All that I will do, has been done, All that I have, has not." ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: RFC: GEOM MULTIPATH rewrite
On 01.11.2011 19:50, Dennis Kögel wrote:
> Not sure if replying on-list or off-list makes more sense...
Replying on-list could share experience to other users.
> Anyway, some first impressions, on stable/9:
>
> The lab environment here is a EMC VNX / Clariion SAN, which has two Storage
> Processors, connected to different switches, connected to two isp(4)s on the
> test machine. So at any time, the machine sees four paths, but only two are
> available (depending on which SP owns the LUN).
>
> 580# camcontrol devlist
>at scbus0 target 0 lun 0 (da0,pass0)
>at scbus0 target 1 lun 0 (da1,pass1)
>at scbus1 target 0 lun 0 (da2,pass2)
>at scbus1 target 1 lun 0 (da3,pass3)
> at scbus2 target 0 lun 0 (da4,pass4)
> at scbus2 target 1 lun 0 (da5,pass5)
>at scbus4 target 0 lun 0 (cd0,pass6)
>
> I miss the ability to "add" disks to automatic mode multipaths, but I (just
> now) realized this only makes sense when gmultipath has some kind of path
> checking facility (like periodically trying to read sector 0 of each
> configured device, this is was Linux' devicemapper-multipathd does).
In automatic mode other paths supposed to be detected via metadata
reading. If in your case some paths are not readable, automatic mode
can't work as expected. By the way, could you describe how your
configuration supposed to work, like when other paths will start
working? Only when second storage processor itself detect that first one
is dead or it suppose to be controlled somehow? If booted with verbose
messages, what SCSI errors do you see on console/logs when trying to
access second storage processor?
Speaking about user-level daemons, it should be possible to do the same:
write rc.d script to create multipath device in manual mode on boot and
hook small script into devd.conf that will check models, serial numbers,
or whatever else of newly detected devices and manually add them. At
least if you are not booting from that device.
Another possible way I see is to make geom_multipath to analyze device
models and serial numbers on kernel level and attach devices based on it
without using metadata.
> First I did a test with active/active and manual mode (gmultipath create -A
> TESTBSD da{0,1,2,3}).
>
> This worked fine, and immediately kicked da{0,2} (which are not available)
> after writing something.
Predictable. Errors caused not working paths to be marked as failed. If
all working paths fail, these will be retried.
> It's quite unexpected that act/act is apparently based on the writer's
> process id or CPU affinity (guessing) -- I needed multiple parallel dd(1)
> jobs to get gmultipath to use more than one path, but then it worked fine.
> (This also means that a dysfunct path isn't recognized before some I/O is
> attempted). Performance was similar to an identical Linux setup (for a very
> simple sequential I/O test at least).
It is not an affinity, but just a dumb probe order. Now geom_multipath
only balances immediate load, not average. So if you have only one
request at a time, it will always use one path. If you have only one
initiator, it should not be important, but if there are several, it
should probably be improved.
> Using automatic mode (gmultipath label -A TESTBSD da{1,3,0,2}) silently
> ignores da{0,2}, which are not available. "list" does not show them at all. I
> guess it should at least throw an error.
Now "label" command only hints kernel to retaste other paths. If kernel
is unable to read metadata from specified devices or there is no
metadata, they just silently won't be added. I can add metadata checking
in user-level. It will not guarantee success, but should at least handle
basic mistakes.
> Do any of the layers below gmultipath currently have information about
> metadata like the volume's WWN? This could be helpful in status / list
> output, maybe for other things, I guess...
That information may be present inside CAM, but not above at the moment.
Only device model and serial number exported to GEOM.
> Another thought: As I guess "automatic" mode is meant to be the common case,
> the choice of "create" vs. "label" might be misleading. Users in a hurry will
> probably just look through the built-in help, see "create", and then use it.
> (I'm guilty as charged here, I didn't realize at first that I was using
> manual mode.)
It is a somewhat unified among several GEOM classes that label is for
automatic method and create is for manual.
Thank you for your feedback!
--
Alexander Motin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
10.0-CUR && ports/security/libgcrypt fails
Hello, I've pulled out r226986 fromm SVN and port from CVS completely fresh on November 1st; ports/security/libgcrypt fails to build with: # make install ... /bin/sh /usr/local/bin/libtool--mode=compile cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -Wa,--noexecstack -O2 -pipe -fno-strict-aliasing -std=gnu89 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c -o mpih-add1-asm.lo mpih-add1-asm.S libtool: compile: cc -DHAVE_CONFIG_H -I. -I.. -I../src -I../src -I/usr/local/include -Wa,--noexecstack -O2 -pipe -fno-strict-aliasing -std=gnu89 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c mpih-add1-asm.S -fPIC -DPIC -o .libs/mpih-add1-asm.o mpih-add1-asm.S: Assembler messages: mpih-add1-asm.S:44: Error: alignment not a power of 2 mpih-add1-asm.S:79: Error: alignment not a power of 2 *** Error code 1 Any ideas? Thanks matthias -- Matthias Apitz t +49-89-61308 351 - f +49-89-61308 399 - m +49-170-4527211 e - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3
On Tue, 1 Nov 2011, Penta Upa wrote: Yes that seems to be the problem. It will is for out of tree modules. http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 . I have to verify if moving the module to /usr/src/ tree fixes the problem. Thanks, Penta On Tue, Nov 1, 2011 at 2:04 AM, K. Macy wrote: Someone was seeing the same issue with the vmtools kmod. The only thing that might make sense is that the page lock array is defined as being a different size in your kmod as in the kernel itself so the lock corresponding to the page you're locking differs between the two files. Quoting from the PR, Andriy Gapon wrote: A standalone module build doesn't get some important definitions from kernel config (e.g. via opt_global.h) and can be in a serious disagreement with the kernel. In particular, if a kernel is built with SMP option, but a module build doesn't have SMP defined, then they will have different definitions of PA_LOCK_COUNT and thus would work on different actual locks when manipulating the same page. I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include opt_global.h' to be passed on the command line. Is the issue just that the opt_global.h used for the kmod could be different from the actual kernel's opt_global.h, because KERNCONF was not specified and the header is generated at module-build time? In this case, clearly the onus is on the user to pass KERNCONF at module build time. (I have gotten my laptop to panic in vm_page_free() with the page lock not owned, in OpenAFS' vop_getpages implementation, but I had previously attributed this to having an old -current snapshot on my laptop and openafs sources that were using freebsd major version for API decisions (we're not converted to __FreeBSD_version, yet). If there is a real problem here, I will need to care much more.) Thanks, Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
