Re: CFT: TRIM Consolodation on UFS/FFS filesystems
On 8/23/18 5:38 AM, bob prohaska wrote: On Tue, Aug 21, 2018 at 06:47:19PM -0700, Mark Millard wrote: I've used a SSD both directly via SATA and via a USB enclosure, the same partitions/file systems across the uses. Only when it was SATA-style-use did TRIM work. This is likely the key to my question. If USB blocks the TRIM service the behavior of the device doesn't matter. This is kind of off-topic in this thread about UFS, but if you investigate TRIM on USB enclosures: Some of them advertise TRIM support, for example Startech SM21BMU31C3 (based on Asmedia ASM1351 USB 3.1 Gen 2 chipset), but that is not the whole story. Using the UASP protocol, they pass on the ata trim command, which is used by Windows for NTFS trim support, but they do not pass the SCSI UNMAP command, which is used by Linux. Sorry, I have not yet tested this on FreeBSD, but on Linux, security erase of the entire SSD works with the enclosure I have just mentioned, whereas trimming of a filesystem (fstrim) does not work. I have had exactly one enclosure that offered trimming on filesystems on Linux: I have bought it on Ebay directly from China and I think it is based on JMicron JMS567 USB 3.0 chipset. I have not found an mSATA enclosure from any vendor in Europe that has this chipset. Of course, having the right chipset is not enough, either, the firmware also has to support it. Please, correct me if I am wrong, but I think FreeBSD does not implement UASP, yet. Hence, I doubt there will be any kind of trim support for any USB-SATA bridge on FreeBSD and even security erase will probably not be passed on. Cheers, Jan Henrik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [patch] USB after second suspend/resume on ThinkPads.
On 06/16/2014 21:21, Edward Tomasz Napierała wrote: Hi. Patch below should fix a problem where USB stops working after _second_ suspend/resume, which happens on various ThinkPad models. Please test, and report both success stories and failures. If nothing comes up, I'll commit it in a week or so. I applied it to 10.0-RELEASE on my T510 and did four successful suspend/resume cycles. My USB mouse did return after about 10 seconds for each try, which is a huge improvement. Thanks a lot! Jan Henrik ___ 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: Re: Thinkpad T410: resume broken
On 05/17/2014 14:20, John Baldwin wrote: On 5/16/14, 2:10 PM, Kevin Oberman wrote: On Fri, May 16, 2014 at 10:44 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! I wonder what changed between 9.2-RELEASE and 10.0-RELEASE. Please poke me about this next week. I'm busy this week with work and maker faire but I will try to help you later. (It's possible something like ACPI updates or a driver update has broken things.) -a Does your kernel include VESA? My T320 behaved as you describe until I removed VESA from my kernel. I think using vt may also fix this without the need to remove VESA, bug I have not gotten around to confirming this. To be clear, vt does not fix resume. Using i915kms is what actually fixes resume when using Intel GPUs on the Thinkpad as i915kms is what actually turns the LCD backlight on during resume. You just have to use vt to have a useable console when you use i915kms. You can suspend/resume fine in X with syscons + i915kms, you just can't use your console if you do. If you are using the Nvidia GPU, then i915kms can't help you with turning the LCD backlight back on (and using vt shouldn't make any difference). VESA needs to be removed for i915kms, but I've no idea if it needs to be removed for Nvidia. The video reset code was reworked in 10 so that having VESA is supposed to be like using 'hw.acpi.reset_video=1' on 9, but in theory it works more often. The ACPI_PM setting to the kernel module along with removing VESA would seem like your best bet, but I see in follow-ups that that wasn't completely reliable. However, you can try using ACPI_PM with syscons, no need to use vt. Yes, without VESA, resume seems much more reliable on 10.0-RELEASE/amd64 with Nvidia: With a generic kernel, I put vesa_load=YES in /boot/loader.conf to be able to kldunload vesa later. With that, I just had four successful suspend-and-resume cycles. Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Cheers, Jan Henrik ___ 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: Thinkpad T410: resume broken
On 05/21/2014 21:22, Hans Petter Selasky wrote: On 05/21/14 21:16, Jan Henrik Sylvester wrote: Unfortunately, my USB mouse does not work anymore: After the first resume, it took a few seconds until it worked again (the build in touchpad was back immediately). After the second resume, it would not work anymore at all, even after reconnecting it to a different EHCI port. It does work at a XHCI, though, until the next resume. Anyhow, this is obviously not related to the original problem. Hi, USB controller are being reset at resume, so I think this indicates a more fundamental PCI/BUS problem. Looking through dmesg, it seems that other USB devices (build-in) are reappearing (Qualcomm Gobi 2000, Broadcom Bluetooth Device) after resume, just not the mouse. Are these lines likely related? pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.PEG_: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP1: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP2: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP4: AE_BAD_PARAMETER pci0: failed to set ACPI power state D2 on \134_SB_.PCI0.EXP5: AE_BAD_PARAMETER Thanks, Jan Henrik ___ 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: Thinkpad T410: resume broken
On 05/16/2014 20:10, Kevin Oberman wrote: On Fri, May 16, 2014 at 10:44 AM, Adrian Chadd adr...@freebsd.org wrote: Hi! I wonder what changed between 9.2-RELEASE and 10.0-RELEASE. Please poke me about this next week. I'm busy this week with work and maker faire but I will try to help you later. (It's possible something like ACPI updates or a driver update has broken things.) -a Does your kernel include VESA? My T320 behaved as you describe until I removed VESA from my kernel. I think using vt may also fix this without the need to remove VESA, bug I have not gotten around to confirming this. (Sorry, this is more or less a lengthy me, too:) I am observing exactly the same on my T510 (not surprisingly, as it is basically the same with a different screen size) using Nvidia (in contract to most other recent mailing list reports, which are using Intel). From 8.1-RELEASE to 9.2-RELEASE, suspend and resume used to work with a generic kernel (I like generic release kernels and freebsd-update) -- except for a short time, which was due to the Xorg port. Especially 9.X-RELEASE were really stable with all the hardware working after resume (maybe except firewire). After going to 10.0-RELEASE, resuming would briefly turn the screen on, but it would go back to black with the power LED continuing to blink (as it does while sleeping). After a while, I realized that I lost the non-default option ACPI_PM for x11/nvidia-driver installing 10.0. With ACPI_PM for x11/nvidia-driver, I had at least one resume with most of the hardware working: The screen was still unusable being static with colorful lines, but I could ssh into the machine over wireless. I have not had time to try 10-STABLE with vt, but from reading various reports on the lists, that is probably the only way. I hope there will be a vt enabled kernel on the 10.1-RELEAS media, if vt is going to be required even for configurations that would work just fine on 9.X (WITH_NEW_XORG=yes is very usable with x11/nvidia-driver even without vt). From what you said, you already have ACPI_PM for x11/nvidia-driver as it is listed on the wiki. Have you? Cheers, Jan Henrik ___ 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: Should we make WITHOUT_LIB32=yes the default for 11-RELEASE?
Adam McDougall wrote: On most amd64 systems I run, I usually set WITHOUT_LIB32=yes in /etc/src.conf because I don't need them. This weekend I did a stock install on an older AMD64 Core 2 Duo minipc and a buildworld of 10-STABLE took almost two hours with LIB32 and CLANG since much of it gets compiled twice. As you said, if you build from source, you can specify WITHOUT_LIB32=yes -- in contrast to systems using official install media and freebsd-update. The current situation is good, since lib32 is a separate install set. It makes the binary only people happy and does not put much burden on the people compiling from source. Is it time to deprecate LIB32 in -current for 11-RELEASE? I realize some ports may need it, but I hope that need is waning and we are just spending a lot of compile time by default for little gain. We could save a lot of compile time for a lot of users, and they could still opt-in if needed. Putting it up for discussion, not insisting it should be done. Thanks. With binary packages becoming usable, there will be more and more people going binary only for base and packages. Do you really want to break desktop packages like virtualbox (or wine) for them? And if you go binary only and get the lib32 set from another machine, it will not be updated by freebsd-update, if it is not part of the default build. This would create a vulnerability. Maybe lib32 can be a package in the spirit of misc/compat10x and (hopefully) get updated, if there are security updates to the base. As long as something like that is not the case, lib32 should be part of the binary distribution not to break binary only systems (especially desktops). Cheers, Jan Henrik ___ 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 12/13/2013 14:47, Tijl Coosemans wrote: On Thu, 12 Dec 2013 17:12:04 -0800 Steve Kargl wrote: 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. Committed in r336344. Thank you! Is it exactly the same as you attached here: http://lists.freebsd.org/pipermail/freebsd-current/2013-December/046986.html Or should I rebuild on my machines? Cheers, Jan Henrik ___ 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 12/01/2013 15:06, 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Cheers, Jan Henrik octave-3.6.4_7-fortran_patch-9.2-RELEASE-amd64.log.xz Description: Binary data octave-3.6.4_7-fortran_patch-10.0-BETA4-amd64.log.xz Description: Binary data octave-3.6.4_6-orig-9.2-RELEASE-amd64.log.xz Description: Binary data octave-3.6.4_6-orig-10.0-BETA4-amd64.log.xz Description: Binary data ___ 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 12/03/2013 21:54, Tijl Coosemans wrote: On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: WITH_PKGNG=yes WITH_NEW_XORG=yes TEX_DEFAULT=texlive Cheers, Jan Henrik ___ 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 12/04/2013 00:23, Tijl Coosemans wrote: On Tue, 03 Dec 2013 22:37:34 +0100 Jan Henrik Sylvester wrote: On 12/03/2013 21:54, Tijl Coosemans wrote: On Tue, 03 Dec 2013 21:26:18 +0100 Jan Henrik Sylvester wrote: On 12/01/2013 15:06, Tijl Coosemans wrote: 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. With the patch, math/octave fails for me on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64 with: checking for amd64-portbld-freebsd(9.2|10.0)-gfortran... f77 checking whether we are using the GNU Fortran 77 compiler... no checking whether f77 accepts -g... no checking how to get verbose linking output from f77... configure: WARNING: compilation failed checking for Fortran 77 libraries of f77... checking for dummy main to link with Fortran 77 libraries... none checking for Fortran 77 name-mangling scheme... configure: error: in `/usr/ports/math/octave/work/octave-3.6.4': configure: error: cannot compile a simple Fortran program Full logs attached (each with and without your patch). In both cases, it tries to use f77, while the original port uses gfortran46. Any idea what is wrong on my system? Do you define FC in make.conf maybe? No, besides some options (*_SET / *_UNSET) for some unrelated ports, I only have got this in make.conf: Hmm, apparently FC is defined by sys.mk. I've attached a new patch. Ok, with the new patch, it compiles and packages on 9.2-RELEASE/amd64 and 10.0-BETA4/amd64. From the new packages, the octave binaries were able to do some simple math. Thanks, Jan Henrik ___ 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: Re: libc++ vs. libstdc++ usage in the ports tree
On 11/14/2013 15:45, Steve Kargl wrote: On Thu, Nov 14, 2013 at 09:54:52AM +, David Chisnall wrote: On 13 Nov 2013, at 19:40, Dimitry Andric d...@freebsd.org wrote: On the other hand, different C++ standard libraries simply cannot be mixed. The internal implementations are usually completely different. This is not really news at all, certainly not to the ports people. :-) That said, it should still be possible to mix them in different libraries. The constraint from the wiki still applies: if you don't use STL types at library boundaries, then it should still work. If you do, then the libc++ and libstdc++ symbols will be mangled differently and so you will get link-time errors. In theory, if it links it should run... And in practice, it is broken. http://lists.freebsd.org/pipermail/freebsd-current/2013-November/046565.html QED 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. Cheers, Jan Henrik ___ 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: USB3 express card panics on 9.0-RC1
On 11/03/2011 09:27, Hans Petter Selasky wrote: On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? I have not done this before. The GENERIC kernel already contains makeoptions DEBUG=-g (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev=AUTO in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? Cheers, Jan Henrik ___ 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: USB3 express card panics on 9.0-RC1
On 11/03/2011 11:51, Jan Henrik Sylvester wrote: On 11/03/2011 09:27, Hans Petter Selasky wrote: On Wednesday 02 November 2011 16:22:20 Jan Henrik Sylvester wrote: I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment = base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort Hi, This looks like a NULL-pointer issue inside xhci_configure_msg() which probably should be easy to fix. Could you compile and boot a kernel with kernel debugging enable so that you get a backgtrace? I have not done this before. The GENERIC kernel already contains makeoptions DEBUG=-g (at least it is in /usr/src/sys/amd64/conf/GENERIC and there are all this large /boot/kernel/*.symbols). Is there anything else needed? (I do not need all the stuff that Ken Smith took out just before RC1 in r226405 just to get a trace, since I do not want to do online debugging, or do I need it anyhow?) From http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug.html , I thought that setting dumpdev=AUTO in /etc/rc.conf was enough to get a dump in /var/crash/ after the next boot to multiuser. That does not seem to be the case for me. What else do I have to do? After reading a bit more, I still do not know why I do not get a crash dump with dumpdev=AUTO (and /var/crash/ having enough space for a full memory dump). Is it too early during boot for dumpon to be set? After reading http://www.unixguide.net/freebsd/faq/18.13.shtml , I found that 806e8040 t usb_process is the last symbol before instruction pointer = 0x20:0x806e80aa. Does this help? Cheers, Jan Henrik ___ 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
USB3 express card panics on 9.0-RC1
I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort ___ 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: [CFR]RT305xF support, w/o attachment
Hello! On 01/-10/-28163 20:59, Aleksandr Rybalko wrote: 3. RT2860 802.11n controller authors Damien Bergamini and Alexander Egorenkov http://my.ddteam.net/files/2011-03-14_rt2860.patch only modification to work with RT2872 (embedded to RT305[02]F) wrote by me. Is this supposed to work on its own bringing support for Ralink 2860 to FreeBSD? (The one in the Asus EeePC 901/1000H according to http://wiki.freebsd.org/AsusEee .) Remaining issues: RT2860 support only Open(no crypto) mode for RT305[02]F Does this mean WPA should work for RT2860? (Just not for the chips you added support for?) If this is supposed to bring RT2860 support to FreeBSD in general: - Should it work on amd64 and i386? - Should it work on 8.2-RELEASE? - Should it work as a module? In case this is all supposed to work: I tried to create a module on 8.2-RELEASE/amd64 by adding a simple sys/modules/rt2860/Makefile (as I did not want to modify my stock 8.2-RELEASE kernel). I only got to: In file included from /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860.c:19: @/dev/rt2860/rt2860_softc.h:52:24: error: opt_rt2860.h: No such file or directory I do not find opt_rt2860.h anywhere in your patches. Assuming it was optional, I have commented it out only to get to: cc1: warnings being treated as errors /usr/src/sys/modules/rt2860/../../dev/rt2860/rt2860_pci.c:63: warning: 'rt2860_pci_detach' declared 'static' but never defined Probably, I am doing something unsupported here (especially as there is no if_rt2860_pci.c, which I would expect). Cheers, Jan Henrik ___ 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: Having a problem with security/libassuan-1 when compiling gnupg.
On 01/-10/-28163 20:59, Doug Barton wrote: 3. kdepim4 My understanding is that the version currently under development has support for libassuan 2.0.0, and will be released in August. The kde@ folks have indicated that if there is a need to update it sooner they can most likely do that based on patches that are currently available. [...] I am unsure what happens when some ports want v1 and others want v2. This may not be an issue if the updated ports can be deal with either API, but I have no idea whether that is the case. The current situation is that having both versions installed is incompatible. My preference would be that the maintainers of the affected ports upgrade to depend on assuan 2.0.0 and then we can remove libassuan-1. If it becomes necessary to support having both versions installed then Plan C at this point would be to modify libassuan-1 to support this. I thought Plan C was a requirement -- and from your first mails, I thought this was planned. deskutils/kdepim4 LIB_DEPENDS on libassuan-1 and gpgme. security/gpgme RUN_DEPENDS on gpg2. security/gnupg LIB_DEPENDS on assuan.0. Hence, building deskutils/kdepim4, I need security/libassuan-1 and security/libassuan installed that list each other in CONFLICTS. I have not actually tried to build deskutils/kdepim4 after the gnupg update, but is it not currently broken? If that is correct, either kde@ has to patch deskutils/kdepim4 (which they do not plan from the discussion at that list) or you have to patch security/libassuan-1 (which you do not plan from your statement above). Will we have a deskutils/kdepim4 with 8.1-RELEASE? Cheers, Jan Henrik ___ 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: Re: Intel H55 and em0
On 01/-10/-28163 20:59, Jack Vogel wrote: OH, as to my last statement, the code in CURRENT will NOT work on 8.0 RELEASE, it would require a change to sys/conf/files, and it also has a fix in the stack that is not in RELEASE. SO taking the latest would require you take the whole tree. Jack On Wed, Mar 31, 2010 at 11:39 PM, Jack Vogeljfvo...@gmail.com wrote: The device subfamily on those motherboards is called PCH, and its only in the em driver as of last December, The CVS delta of if_em is 1.27. You can either update to STABLE/8 or CURRENT. If you wish to just pull the e1000 driver directory it should work fine in 8.0 RELEASE also. Cheers, Jack In your correction, you did not really mention 8-STABLE, you only warn about putting e1000 from CURRENT to 8.0-RELEASE. I got the same problem: http://lists.freebsd.org/pipermail/freebsd-mobile/2010-March/011952.html Since I did not get a reply, I put the whole e1000 directory from CURRENT into 8-STABLE. Is there any problem with that? (It _seems_ to work so far.) Are you going to MFC the PCH devices to 8-STABLE any time soon? Thanks, Jan Henrik ___ 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
