Re: spec violation of xHCI?
On 12/12/13 08:40, Kohji Okuno wrote: From: Hans Petter Selasky h...@bitfrost.no Hi HPS, The endpoint type is BULK, and the direction is OUT. I checked by using a USB analyzer. When I did not set CHAIN bit in LINK TRB, my host controller sent illegal packets sometimes. But, ZLPs were sent. Hi, Test OK here aswell. Does this commit look OK to you: http://svnweb.freebsd.org/changeset/base/259248 --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: spec violation of xHCI?
From: Hans Petter Selasky h...@bitfrost.no Date: Thu, 12 Dec 2013 09:37:29 +0100 On 12/12/13 08:40, Kohji Okuno wrote: From: Hans Petter Selasky h...@bitfrost.no Hi HPS, The endpoint type is BULK, and the direction is OUT. I checked by using a USB analyzer. When I did not set CHAIN bit in LINK TRB, my host controller sent illegal packets sometimes. But, ZLPs were sent. Hi, Test OK here aswell. Does this commit look OK to you: http://svnweb.freebsd.org/changeset/base/259248 Hi HPS, I confirmed that your commit is OK. Many thanks, Kohji Okuno. ___ 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: boot failure after upgrade to HEAD from svn: zfs i/o error - all block copies unavailable invalid format
10.12.2013 18:59, 乔楚 wrote: *Today, after **upgrade to HEAD from svn, My FreeBSD can't boot.* *Error message:* *ZFS: i/o error all block copies unavailable **Invalid format* I see you are using GPT. Have you updated bootcode then? Can you import your pool from any HEAD snapshot? -- Sphinx of black quartz, judge my vow. ___ 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
Something wrong with -CURRENT? (network problems)
Since about the time of teh NEWCONS commit, freshly built kernels do not work correctly for me. Symptoms are: - long delays opening TCP connections (even to localhost) - TCP transmission errors (e.g. fetchmail aborts because of short transfers, could be due to a timeout being triggered) I first noticed this during multi-user startup, since some of the daemons took tens of seconds to start (especially bad is SpamAssasin), instead of fractions of a second. At first I thought this could be caused by testing NEWCONS, but the symptoms of a kernel with SCONS are identical. Kernel configuration and other parameters are unchanged. I do not have time to bisect the commits, but just wanted to ask whether this is a general problem with -CURRENT, or only affects my test system (my local file-, media-, mail-, and web-server). (I might have time to bisect revisions during the week-end, though.) System information: i7-2660, N67 chipset, 24GB RAM, amd64 ZFS only configuration (ZRAID1, 4*2TB) Kernel config is just a stripped down generic (removing all unnecessary devices) with the following KLDs loaded: Id Refs AddressSize Name 1 25 0x8020 e0efe8 kernel 21 0x8100f000 22dd88 zfs.ko 32 0x8123d000 5b68 opensolaris.ko 41 0x81412000 1478 fdescfs.ko 51 0x81414000 c250 ipfw.ko 61 0x81421000 3923 linprocfs.ko 71 0x81425000 999 linsysfs.ko Kernel based on SVN rev. 258894 works reliably with latest world. The kernel I built after seeing the initial NEWCONS commits (still with SCONS) worked, but shortly thereafter, when I tried NEWCONS, the symptoms started (but persisted after going back to SCONS). I just checked SVN rev 259250 and the problem persists (without NEWCONS configured into the kernel). So my questions are: - is anybody else affected or is this a local problem? - has there been a commit that touched the network stack or might cause the observed delays? Thanks in advance fpr any insight you might be able to offer! Regards, STefan ___ 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: boot failure after upgrade to HEAD from svn: zfs i/o error - all block copies unavailable invalid format
Have you updated bootcode then? After make installkernel make installworld reboot, boot error. Yes ,I can import in -currentr258961( http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/11.0/FreeBSD-11.0-CURRENT-amd64-20131205-r258961-memstick.img ). Now, I install -currentr258961 on an new disk, and copy every from old disk to new disk. 2013/12/12 Volodymyr Kostyrko c.kw...@gmail.com 10.12.2013 18:59, 乔楚 wrote: *Today, after **upgrade to HEAD from svn, My FreeBSD can't boot.* *Error message:* *ZFS: i/o error all block copies unavailable **Invalid format* I see you are using GPT. Have you updated bootcode then? Can you import your pool from any HEAD snapshot? -- Sphinx of black quartz, judge my vow. ___ 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: Request for testing an alternate branch
On Wednesday, December 11, 2013 5:40:30 pm Justin Hibbits wrote: On Wed, Dec 11, 2013 at 1:26 PM, John Baldwin j...@freebsd.org wrote: On Thursday, December 05, 2013 1:21:13 am Justin Hibbits wrote: I've been working on the projects/pmac_pmu branch for some time now to add suspend/resume as well as CPU speed change for certain PowerPC machines, about a year since I created the branch, and now it's stable enough that I want to merge it into HEAD, hence this request. However, it does touch several drivers, turning them into early drivers, such that they can be initialized, and suspended and resumed at a different time. Saying that, I do need testing from other architectures, to make sure I haven't broken anything. The technical details: To get proper ordering, I've extended the bus_generic_suspend() and bus_generic_resume() to do multiple passes. Devices which cannot be enabled or disabled at the current pass level would return an EAGAIN. This could possibly cause problems, since it's an addition to an existing API rather than a new API to run along side it, so it needs a great deal of testing. It works fine on PowerPC, but I don't have any i386/amd64 or sparc64 hardware to test it on, so would like others who do to test it. I don't think that it would impact x86 at all (testing is obviously required), because the nexus is not an EARLY_DRIVER_MODULE, so all devices would be handled at the same pass. But, I do know the sparc64 has an EARLY_DRIVER_MODULE() nexus, so that will likely be impacted. I have patches to change many x86 drivers to use EARLY_DRIVER_MODULE() FWIW. Also, I'm still not a fan of the EAGAIN approach. I'd rather have a method in bus_if.m to suspend or resume a single device and to track that a device is suspended or resumed via a device_t flag or some such. (I think I had suggested this previously as it would also allow us to have a tool to suspend/resume individual drivers at runtime apart from a full suspend/resume request). -- John Baldwin Understood. You had mentioned something along those lines before. Is it safe/sane to partially merge a branch into HEAD? If so, I can merge only the changes necessary for PMU cpufreq, and work on the suspend/resume separately. I put them together because most of the low level code involved is the same between them. Yes, you can split them up. However, the way to do that is to generate a diff and patch that into a head checkout and commit. There's not a good way to have 'svn merge' do it AFAIK. I do like your idea of a device_t flag, but I'm not sure what the best way to go with that would be. I do already use a device_t flag to determine if the device is suspended, but only bus_generic_* access that in this patch. Would a better way be: * root_suspend instead of suspending its children, instead traverses and suspends each descendent in reverse order. * While doing this, insert each device upon successful suspend into a list. * For root_resume(), traverse the list back, and suspend each device in the reverse order. I would rather do it more the way that multipass attach now works where you do scans of the entire device tree as you walk the pass number down (during suspend) suspending any devices that are not yet suspended if their pass number is = current pass number, then on resume you do scans of the entire tree raising the pass number back up using similar logic to attach where you resume any suspended devices if the driver's pass number is = current pass number. With this, add a new method, called device_suspend_child() to suspend a specific child if it hasn't already been suspended. Well, I would call it 'bus_suspend_child' and 'bus_resume_child' as these would be bus methods in bus_if.m. * This could require modifying the PCI driver to move the device child suspend/resume into those functions, instead of doing that logic in the device_suspend/device_resume itself. Correct. bus_generic_suspend() and bus_suspend_resume() would turn into loops that look a lot like bus_generic_new_pass() (so the logic for honoring pass numbers would happen in these routines and they would invoke bus_suspend_child() and bus_resume_child() to change the state of individual drivers). device_suspend() and device_resume() for the root device would look like bus_set_pass() with a similar loop that walked through the pass levels and invoked bus_generic_suspend/resume after each pass change to start the pass across the device tree. I guess, in short, I'm asking: Is it fine if I merge only the code necessary for this cpufreq? That would require making other changes to this before merging in, to isolate that code, but it's very doable. - Justin -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to
P4 question. not really a freebsd but using with freebsd
so I have a freebsd tree checked into perforce. one particular subdirectory has been heavily modified to teh extent that it's not really hte same thing any more and I want to move it out to a separate place, and then replace it with the original contents so I can update the tree and get changes to that original directory. I can think of two ways to do this: # move the modified one out p4 open p4 move //depot/Freebsd/src1/sys/netatalk/... //depot/Freebsd/src1/sys/netmumble/... followed by: # bring back the original version by copying it from before changes started. p4 integrate //depot/Freebsd/src1/sys/netatalk/...@original_import //depot/Freebsd/src1/sys/netmumble/... p4 resolve p4 submit Or, a second alternative: not quite sure how to do this if there are deletions and additions on the tree #copy out the modified version. #revert the directory in question to exactly how it was before the changes started files in netmumble should see all their history even when they were in netatalk, and files now in netatalk should see history from before the changes started, and MAYBE from when they were modified (optional). Julian ___ 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
review request: sendfile kqueue notification
Hi, I'd like to start committing this to FreeBSD-HEAD: http://people.freebsd.org/~adrian/netflix/20131211-sendfile-kqueue-11.diff It implements kqueue notifications for sendfile so users can get an asynchronous notification that the underlying mbufs have been freed. This allows userland users of sendfile to know that the underlying memory / file object can be recycled or overwritten. Right now the only way to do this is to set SF_SYNC and this causes sendfile() to sleep until the transaction is complete and the mbufs have been freed. I've been testing this out locally in my lab environment and it's running flawlessly at 30gbit/sec of TCP across 32,768 active transmitting sockets. I'd like to start merging this into -HEAD in small pieces to make it easier to MFC to -10. Thanks! -adrian ___ 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: review request: sendfile kqueue notification
And yes, I know this breaks the 32 bit compat sendfile call. I'm thinking of how to fix this without just duplicating all of that code. Thanks, -a On 12 December 2013 12:41, Adrian Chadd adr...@freebsd.org wrote: Hi, I'd like to start committing this to FreeBSD-HEAD: http://people.freebsd.org/~adrian/netflix/20131211-sendfile-kqueue-11.diff It implements kqueue notifications for sendfile so users can get an asynchronous notification that the underlying mbufs have been freed. This allows userland users of sendfile to know that the underlying memory / file object can be recycled or overwritten. Right now the only way to do this is to set SF_SYNC and this causes sendfile() to sleep until the transaction is complete and the mbufs have been freed. I've been testing this out locally in my lab environment and it's running flawlessly at 30gbit/sec of TCP across 32,768 active transmitting sockets. I'd like to start merging this into -HEAD in small pieces to make it easier to MFC to -10. Thanks! -adrian ___ 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: P4 question. not really a freebsd but using with freebsd
On 13/12/2013 06:00, Julian Elischer wrote: so I have a freebsd tree checked into perforce. one particular subdirectory has been heavily modified to teh extent that it's not really hte same thing any more and I want to move it out to a separate place, and then replace it with the original contents so I can update the tree and get changes to that original directory. I can think of two ways to do this: # move the modified one out p4 open p4 move //depot/Freebsd/src1/sys/netatalk/... //depot/Freebsd/src1/sys/netmumble/... followed by: # bring back the original version by copying it from before changes started. p4 integrate //depot/Freebsd/src1/sys/netatalk/...@original_import //depot/Freebsd/src1/sys/netmumble/... p4 resolve p4 submit Or, a second alternative: not quite sure how to do this if there are deletions and additions on the tree #copy out the modified version. #revert the directory in question to exactly how it was before the changes started files in netmumble should see all their history even when they were in netatalk, and files now in netatalk should see history from before the changes started, and MAYBE from when they were modified (optional). Personally, using svn I would use the second approach mv netatalk netmumble rm -R netmumble/.svn svn co netatalk diff -ru netatalk netmumble or cp then svn revert would give the same result. ___ 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: libc++ vs. libstdc++ usage in the ports tree
On Sun, Dec 01, 2013 at 03:06:40PM +0100, Tijl Coosemans wrote: On Wed, 27 Nov 2013 20:45:56 +0100 Tijl Coosemans wrote: On Wed, 27 Nov 2013 19:31:44 +0100 Jan Henrik Sylvester wrote: Trying to migrate to 10, I would like to keep octave. Have you found anything new? Having build the port and all dependencies with standard options, octave is segfaulting for me, too. Anyhow, I can run octave with: env LD_PRELOAD=/usr/lib/libc++.so.1 octave Some very light testing indicates that it is working. Of course, this is not ideal. Maybe this gives a clue how to fix the octave port properly. I have a preliminary patch for math/octave that I wanted to test on redports first, but it is down at the moment so here it is. The tests were successful: https://redports.org/buildarchive/20131201105316-94935/ (octave) https://redports.org/buildarchive/20131201115701-22333/ (octave-forge-base) The octave logs also contain the results of running the regression-test target. The output is the same on all FreeBSD versions. The problem is that USE_FORTRAN=yes implies USE_GCC=yes. This means the C++ code in math/octave is compiled with gcc46/libstdc++ which does not work if dependencies have been built with clang/libc++. The patch copies the USE_FORTRAN=yes logic from Mk/bsd.gcc.mk into a new file Mk/Uses/fortran.mk. It allows ports to use a Fortran compiler together with the base system C/C++ compiler. I see the octave port is still broken. After a clean install on my self, removing all installed ports, reverting my local chnages in /usr/pors, and rebuilding all ports, I'm see the original problem. % octave Segmentation fault (core dumped) PLEASE, commit your patch ASAP. -- Steve ___ 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: P4 question. not really a freebsd but using with freebsd
On 12/13/13, 6:59 AM, Shane Ambler wrote: On 13/12/2013 06:00, Julian Elischer wrote: so I have a freebsd tree checked into perforce. one particular subdirectory has been heavily modified to teh extent that it's not really hte same thing any more and I want to move it out to a separate place, and then replace it with the original contents so I can update the tree and get changes to that original directory. I can think of two ways to do this: # move the modified one out p4 open p4 move //depot/Freebsd/src1/sys/netatalk/... //depot/Freebsd/src1/sys/netmumble/... followed by: # bring back the original version by copying it from before changes started. p4 integrate //depot/Freebsd/src1/sys/netatalk/...@original_import //depot/Freebsd/src1/sys/netmumble/... p4 resolve p4 submit Or, a second alternative: not quite sure how to do this if there are deletions and additions on the tree #copy out the modified version. #revert the directory in question to exactly how it was before the changes started files in netmumble should see all their history even when they were in netatalk, and files now in netatalk should see history from before the changes started, and MAYBE from when they were modified (optional). Personally, using svn I would use the second approach mv netatalk netmumble rm -R netmumble/.svn svn co netatalk diff -ru netatalk netmumble or cp then svn revert would give the same result. unfortunately I have to use P4 :-/ ___ 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: P4 question. not really a freebsd but using with freebsd
On 12/13/13, 2:48 AM, Julian Elischer wrote: so I have a freebsd tree checked into perforce. one particular subdirectory has been heavily modified to teh extent that it's not really hte same thing any more and I want to move it out to a separate place, and then replace it with the original contents so I can update the tree and get changes to that original directory. the only way I can thi sorry.. something weird happened there.. I left this email partly written to go do something else and Tunderbird seems to have sent it out several times while I was away instead of doing saves to disk.. this happened immediately after upgrading to a new Thunderbird so I think they may have a bug there. ___ 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: Fwd: r259154 panics
On 13.12.13 05:34, Eitan Adler wrote: Since I got no reply on -hackers... Have you tried after 259221? I had a similar panic where the process was vidcontrol and doing the IOCPARM_IVAL part only for the COMPAT_XX helped me. Andreas ___ 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: Fwd: r259154 panics
On Fri, Dec 13, 2013 at 12:02 AM, Andreas Tobler andreast-l...@fgznet.ch wrote: On 13.12.13 05:34, Eitan Adler wrote: Since I got no reply on -hackers... Have you tried after 259221? I had a similar panic where the process was vidcontrol and doing the IOCPARM_IVAL part only for the COMPAT_XX helped me. FreeBSD gravity.local 11.0-CURRENT FreeBSD 11.0-CURRENT #7 r259286: Fri Dec 13 00:33:37 EST 2013 eitan@gravity.local:/usr/obj/usr/src/sys/EADLER amd64 seems to work: thanks! -- Eitan Adler ___ 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
